Order of operations for actually grabbing an object

[dysfunctional_os_0]

This is specifically about grabbing an object that is currently attached to a triggercomponent.

Just to be clear on context, my game works without issue currently but I am just wondering in a wider scope of implementations/use cases is there an importance in the order of these things (perhaps in a multi-threaded context, it seems there might be):
-setting physics simulation to true
-waking all rigid bodies
-adding “Grabbed” tag
-Detaching

Specifically, what are the orderings of importance and what are their implications? For example, I would think that since the grabbed tag is undone after setting physics simulation to true, then in a multi-threaded context, you could have the trigger component in a different thread set the physics simulation back to false between then and the “Grabbed” tag being assigned.

[DanM]

In a multithreaded context you would be using synchronisation primitives like mutexes to prevent multiple threads from modifying the same data.

[dysfunctional_os_0]

Hey @DanM thanks. While that makes sense for a multithreaded context, does this still have some single threaded implications? For example, what would happen if physics simulation was enabled after detaching or if rigid bodies were woken before physics simulation was enabled? I assume at that point, it’s just a matter of trying to order the operations in a logical way.

[DanM]

Well waking rigid bodies before simulating physics would be a bug but I’m pretty sure you don’t need to manually wake them anymore when you simulate physics or release the component. Not sure about the other scenarios, have you tried them?