Client Difference Log
API Changes
Added Property Button.ClickableWhenViewportHidden
Added Property TestService.ExecuteWithStudioRun
Added Property UserGameSettings.MicroProfilerWebServerEnabled
Added Function LocalizationTable.SetIsExemptFromUGCAnalytics
Added Enum AvatarJointPositionType
Added EnumItem AvatarJointPositionType.Fixed
Added EnumItem AvatarJointPositionType.ArtistIntent
Removed Property PVInstance.CoordinateFrame
Removed Property TaskScheduler.NumRunningJobs
Removed Property TaskScheduler.NumSleepingJobs
Removed Property TaskScheduler.NumWaitingJobs
Removed Property TaskScheduler.ThreadAffinity
This one might be a little concerning, can we get an elaboration on the behavior and purpose of this?
Studio now will print a warning if assets are fetched the are covered by copyright
The typo has me a bit confused - does this display a warning if an asset is copyrighted (e.g. a pokemon mesh or the sega logo)
And How does it know apart from text
This will establish a rate limit that should be safe for the vast majority of cases. The design is based on being able to support bursts of remote events. The feature will not be enabled this week due to last minute changes that only allow diagnostics when the rate limiting is active. The plan was to collect some statistics and notify places that might be affected.
Does the feature throttle per remote instance or globally for all remotes? Myself and many other developers use a single remote for all traffic.
The first pass is based on all remote events, and then two special cases for sounds and MarketplaceService – things where a much lower rate limit makes sense.
Keep in mind that, while rate limits can often be implemented in lua, gamescripts don’t have access to all remote events. Anything that requires Plugin/CoreScript/Roblox permissions would not currently be something a game dev could limit. The global limiter would include these remote events as well.
If anyone has any opinions on how best to expose this general feature to game developers, it probably makes more sense to create a feature request. That way it will be tracked properly.
Does this throttle bidirectionally, or only client --> server?
I doubt they’d throttle the server
Shouldn’t “Fixed bug where Humanoids didn’t honor Terrain’s collision group” be under Fixes rather than Improvements?
This throttles events from client to server. The goal is to provide a basic anti-DOS mechanism to all games. You can still send events to your clients at any rate that you deem acceptable.
The goal is to avoid impact to most places. Simply spamming remote events doesn’t always result in a DOS attack. (in the non-exploited client case specifically.) It is possible some places are currently spamming remotes at a high rate for no useful purpose. This is why we are trying to gather stats and inform devs about the upcoming changes.
If I’m planning on manually replicating player positions (client -> server, sending some cframe data) at the maximum rate, will this affect it at all?
What if we had access to an event that would let us push data whenever the client is ready to send it?
You could fire the remote event 60 times a second and I’m sure (assuming) you won’t even scrape the limit. Firing an event 60 times a second isn’t enough to crash the server alone, but of course firing an event 60 times a second isn’t even necessary to replicate player movement.
I feel like it would be considered a bug if it was so sensitive it triggered a positive just by firing a remote on a RenderStepped event, and I can’t see how anyone would need to fire an event more than that.
Yes, the goal is to have a global rate limit that is much greater than 60 events per second. Greater than 61 events per second even.
And as always, if you want some control over this, please make a feature request. The main benefit of the global limiter is that it allows some limiting of events that aren’t exposed to gamescripts.
Found it!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.