I have worked on a custom shiftlock script for mobile and I can say that MouseBehavior is NOT what we need for enabling/disabling shiftlock.
EnableMouseLockOption is on by default, so if you want to disable shiftlock, you need to set the property with the command line (which is stupid to have to do). There is no other good way to disable it (or recreate it yourself, if you want to keep a deprecated feature).
Why? Because all parts of shiftlock—the player automatically rotating due to camera rotation, the mouse being locked, and the camera being offset to the right—have no easy way to disable them. You could attempt to override the MouseBehavior and the UserGameSettings.RotationType, but these conflict with first person, which also sets these values. The CameraScript can get away with it as it knows if you are in first person or not, but there is no good way of checking for being in first person outside of it. Even then, you would still have the issue with the shifting to the right.
As for recreating shiftlock, similar issues occur. This time, there is no concern with conflicting priority with MouseBehavior or RotationType, but when shiftlock is disabled RotationType can pose a problem. MouseBehavior is always set back, but depending on the current version of the CameraScript (this behavior seems to change sometimes), RotationType may not get set back to MovementRelative, meaning you will continue to rotate even after disabling shiftlock. You could try to set RotationType to MovementRelative when shiftlock is disabled, but (also depending on the version) it may not be set back to CameraRelative if you were in first person when shiftlock was disabled. Finally, it is pretty easy to offset the camera a few studs to the right, but since there is no good way to detect if you are in first person, it will continue to offset in fist person, which doesn’t happen with vanilla shiftlock.
The deprecation of EnableMouseLockOption is ultimately negative for all developers, whether you want shiftlock enabled in your game or not. I sincerely hope the engineers consider reversing this deprecation, as it removes something that is impossible to recreate without bugs.
Hey, I was wondering if there is an estimate time frame for when Instance:HasTag(tag) and the other Instance Tag methods becomes enabled? I am really looking forward to using this feature.
Behavior critical engine features which may be used on the client like that generally have to wait a few weeks for the next mobile force update after they ship, because until a mobile force update there’s still some clients out there in the wild without the feature.
The short answer is that the deprecation was planned many years ago, with the intent that there wouldn’t be a loss of functionality, and various parts of the replacement functionality were implemented over time but enough things changed in the meantime that some stuff fell through the cracks with no single person keeping a close enough eye on the overarching effort.
Thanks to the feedback here there’s now some people looking into a proper resolution to the situation.
Unfortunately, there was an issue with Instance:HasTag and related methods, so it will have to wait a few extra weeks for the new fix to roll out to all mobile clients.
I see, that’s pretty unfortunate, but I’m still just happy that an update like this is even coming out.
You guys at Roblox have really been stepping up your game with the recent updates, especially a lot of the stuff on the Creator Roadmap, lots of great things in there that I’m really looking forward to using. Thank you guys for the work you all are putting in.
Was the behavior of :GetPartsInPart() supposed to change with the new optimization? It seems to now also return parts that aren’t inside of the queried part, but just touching, and even returns parts that aren’t touching at all, if they’re within a certain threshold (seems to be about 0.01 studs).
This can be reproduced easily - place two parts next to each other (floating above the baseplate so it doesn’t mess up results), and query one of them with :GetPartsInPart(). :GetPartBoundsInBox() seems to have a similar problem, but not to the same extent.
I set up a chart of various test cases and their expected (pre 576) results to demonstrate this:
I can upload the .rbxl file of this test place if needed. I hope this change isn’t intentional, as it breaks a few of the use cases I had for this method previously, which relied on only returning intersecting parts and not surface touches.
I’ll flag this to someone but likely it won’t be changed back. Thanks to floating point error your code should always be robust to small amounts of positional imprecision: “Exactly touching” isn’t a well defined concept in a world based in floating point positions, there’s always some slop factor one way or the other.
Run/walk/climb behavior is now fully functional for character models with any Scale between 0.1 and 10.
If this refers to the weird sliding that happens when your character is too small… it still happens?! It’s already been 2 weeks, surely this rolled out… right?
The use cases in question (intersection welding in a build game, checking if functional parts such as reactors, lasers, engines were clipped into each other) already tolerated minor errors, but the new (unannounced) behavior changes required some pretty invasive changes to those systems to make them work like they did before.
For example, the building games I work on support part surfaces. We use a combination of :MakeJoints() and :GetPartsInPart()-based intersection welding to allow for surface welding, surface joints (hinges), and complex shapes all in one system. With the new behavior of :GetPartsInPart(), parts that are touching are now detected as intersecting. For now we’ve reverted to :GetTouchingParts(), but this is much slower, less reliable, and does not use OverlapParams, making it more annoying to restrict what it returns.
I’m happy the method is now much more performant, but I’m not particularly excited about the unannounced changes to its behavior. Would it be possible to still have the old functionality under a flag, similar to OverlapParams.BruteForceAllSlow?
Alternatively, the slop factor you mentioned - WorldRoot:ArePartsTouchingOthers() supports a threshold before parts are considered touching. If it’s possible to have this functionality in OverlapParams or wherever it makes the most sense, it would be a good replacement for the old functionality, as developers could tune this threshold to best fit their use cases.
Is there some other change you’re trying to get at here? Because like I said before, there is no hard dividing line between “touching” and “intersecting”, at the end of the day it’s all just fuzzy thresholds.
I understand that the line between touching and intersecting doesn’t really exist. The change I’m talking about is the behavior of :GetTouchingParts(), which I showed in a screenshot above. Before 576 it did not return parts that were touching the surface (or at least, not very often), and definitely did not return parts that weren’t touching at all but were still less than 0.01 studs away from the surface. This was not an issue until 576 released. I posted a chart above showing the expected (pre 576) behavior with all of the cases shown. The expected chart lines up with what was observed in the mentioned building game until 576 released.
The new behavior for :GetPartsInPart() is not only too sensitive around normal part shapes, but seemingly ignores the outer parts of meshes. My first thought was this could be a mesh issue with our game (our meshes are pretty janky) but I tested it with various trapezoid meshes I found around the marketplace and they all had the same issue.
I’ve attached both the mesh issue and original chart repro place. Is there any chance we could get a response on this? I understand that there’s no easily drawn line between touching and intersecting in cases like these, but the previous version of this method seemed to handle those cases reliably enough. All of these test cases worked fine (with the occasional issue, but nothing like this) since the Spatial Query API released 2 years ago, with no noticeable change in behavior until 576.
I listed some potential solutions above: a flag (similar to OverlapParams.BruteForceAllSlow) would let us use the old behavior in cases where it works better (most of them) or alternatively exposing the mentioned slop factor in more methods, or as a property of OverlapParams. A solution would be nice, the alternative is to go back to :GetTouchingParts(), which also handles the above cases just fine, but doesn’t have OverlapParams and is generally much slower and less consistent.
