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:FindThemeHow 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.