Client Difference Log
API Changes
Added Property bool Studio.Debug Client In APS Mode
Added EnumItem ConnectionError.DisconnectRaknetErrors : 279
Added EnumItem ConnectionError.DisconnectWrongVersion : 280
Added Tag [Deprecated] to Function BadgeService:IsDisabled
Added Tag [Deprecated] to Function BadgeService:IsLegal
Removed Function Studio:FindTheme
How much of an improvement can we expect for our games with StreamingEnabled?
Servers will reject Touch events from Clients that do not own the interacting parts.
So both parts need to be owned by the client? If I have a client owned part A and it touches server owner part B, does the server get the event?
I found this weird, as you seem to as well (correct me if Iâm wrong). If this is how it sounds, then I really donât like it.
I know the issues that lead to this decision, and I find this to be a silly solution to the issue. As developers, we have the resources to check which playersâ clients own what parts, and applying this fix in all our Touched logic would have been really simple. When it was reported that some players are abusing the current faulty behavior, Iâm sure the expectation developers had wasnât that Roblox was going to force a change like this on us.
With some parts not firing Touched (as it seems it will be), we now have less functionality with the event, because (again) Roblox is adding an easy, very strict sanity check which we could have added easily ourselves. I get it if there was no better solution, though we could have been informed of that, and told to use this sanity check if it works for us.
I really hope Iâm misunderstanding this change. I donât want Touched events to not exist for parts not owned by the same client.
Someone should test it! My guess is that explicitly registering a Touch event connection would override the new behavior. At least I would hope so.
Sadly itâs pending still. It seems unusual if it is how the update note makes it sound, since normally Roblox leaves it up to use to do what we can already do.
Come to think of it, I wonder if some games might need updating to account for this. Doesnât nearly every tycoon game rely on an unanchored object (possibly auto network owned by a nearby player) rolling down a conveyer to eventually touch a âcollectorâ brick that is anchored? If Iâm interpreting this right, wouldnât the server never get the touched event?
I wonder what the reasoning is behind these, it seems like there is no way to check whether a badge is legal for the current game otherwise. So youâd have to attempt awarding the badge even though it might be invalid, which will throw warnings.
Looks like there may be several replication-related regressions in the latest update.
This doesnât make sense if thatâs the case, then every script for things like lava would break (the client owns their character). Assuming I found the FFlag for it, Iâm testing it right now. The FFlag I found doesnât seem to be the one used to patch the exploit.
BadgeService:IsLegal doesnât do anything anymore. It immediately returns true and doesnât check anything.
At least one of the interacting parts has to be owned by the client who is sending the touch event. This prevents an exploit from triggering server-side Touched on parts that the exploiter doesnât own.
Another regression (seems like this one is related to r15 character loading?).
Ran out of time for my lunch break so donât have great minimal repro.
Oh ok at least one
That clears it up lol
Such a seemingly small update. Such a big impact.
Makes you think.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.