Im in the process of improving performance in a game, and need to connect GetPropertyChangedSignal() to a parts “Position”.
after doing some checking I found out that it will only fire if the part for example was moved in the studio, however if the part was unanchored and falls, it wont fire.
this is problematic because I want to do something to that part when it begins to fall.
why not use a while loop to constantly check the magnitude of that part? well, this is what I was trying to avoid in the beginning. theres going to be a LOT of blocks, and all of them are managed by “CollectionService”. the game became really laggy when I checked magnitude by a loop.
only checking when the part begins to fall would make things a lot better.
is there something im doing wrong or is there something I should be using to detect position changes even if the part is physically moving?
This event does not fire for physics-related changes, like when the CFrame , Velocity , RotVelocity , Position , Orientation and CFrame properties of a BasePart change due to gravity. To detect changes in these properties, consider using a physics-based event like RunService.Stepped or BasePart.Touched . A while-true-do loop can also work.
I believe that this rule also applies to GetPropertyChangedSignal(), since it is a type of Changed event. After my own testing I found that .Changed and GetPropertyChangedSignal() acted in the same exact way, so I believe that it is the case. You may just have to use a loop instead since Position is a physics property.
using a loop as stated above is out of the question, its why im looking into this.
the loop was causing lag as it would be constantly looping through all the parts tagged in collectionservice.
what about runservice.stepped, would I be able to use this to detect when a part starts to fall?
I also read up on something called GetAttributeChangedSignal, and the example mentioned in the wiki had the string “InitialPosition” in it.
Stepped would work, but then be advised that using RunService would probably not be any better than using a while loop. It does look nicer in code since you can connect and disconnect it, but it also runs twice as often as an inneficient wait() loop. I would probably look into optimizing the amount of parts you are looping through, i.e. tagging only the parts that you know will be moving. as for magnitude, you could make a region3 if you’re trying to detect whether or not a part is within a certain location.