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.
1 Like
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.
GetPartsInPart-repro.rbxl (52.5 KB)
GetPartsInPart-meshes.rbxl (45 KB)
3 Likes
Both issues have been fixed, let us know if you are still experiencing problems.
2 Likes
Fix seems to have worked, everything’s back to normal and test cases are working as expected. Optimization seems to still be present as well - awesome! Thank you!
@FinnMcNuts @StrongBigeMan9 @funwolf7
Hello,
After discussing internally, our team has decided to revert the deprecation of shiftlock related properties, including EnableMouseLockOption. We will be working on a better approach to provide support for these features in the future.
However, we would like to encourage you to utilize MouseBehavior if you only require mouse lock functionality.
The reversion is expected to take place within the next 1-2 releases.
We apologize for any confusion caused during this period and appreciate your patience.
7 Likes
Great this is just what we needed, I really don’t see why you deprecated it in the first place? But whatever, I wont complain.
1 Like
The MouseBehavior API is far superior as it’s easier to add new functionality.
2 Likes
MouseBehaviour API doesn’t change shiftlock state
that’s why you add those as a feature?
1 Like
What I originally meant is, MouseLock and MouseBehavior are entirely different.
You can test this by working with MouseBehaviour, if you set it to locked it doesn’t change the image. This doesn’t mean it’s terrible or anything, I support this as MouseLock has always been weird (considering DevEnableMouseLock was only server-sided, even though it could still be exploitable, and there was no good way around to setting MouseLock state without modifying the PlayerModule).
Ever since MouseBehavior has been added, everything has been made better. My point was that MouseBehavior and MouseLock have nothing to do, and you can see this by checking the camera modules, you’ll notice it (both behave exactly the same but MouseBehavior is far superior because it can be customized, unlike the preset MouseLock image, for example).
TL;DR: If you add a local script that sets MouseBehavior to a locked state, and go to the roblox menu, as an example, you could have shiftlock off and mousebehavior locked:
you can see both do not have anything to do between them in these pictures, because even with shiftlock off its still locked, which is good, because developers should disable DevEnableMouseLock and add their own functionality
ignore the output
FYI–I’ve seen some people nervous about the deprecation of the CollectionService methods here and interpreting it as a deprecation of tags as a system entirely. This is definitely not the case! The new methods are just more convenient ways of accessing their respective methods (Instance:GetTags() is CollectionService:GetTags(instance)).
7 Likes
This QoL update was one I’ve been wanting for the longest!
Does this mean CollectionService:GetTagged will be deprecated as well?
@DataSigh Yes, that looks correct.
@2jammers No, as that wouldn’t be sane as a method on instance. :HasTag, :RemoveTag, :AddTag, and :GetTags are what are now on Instance and no longer need to be pinged through CollectionService.
2 Likes
Ok that makes sense, but would this break games if CollectionService is inherited from Instance? I like the new methods, but it looks like the new Instance methods would just override CollectionService methods.
Nope, we’ve had these enabled for a while and haven’t heard of any breakages. CollectionService’s implementation takes priority.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.