I’ve learned that unlike get_position()
, get_world_position()
returns the value of the position from the previous frame:
It’s good that this is documented, but there are some nuances that aren’t documented that are important if you’re doing precise fixed-timestep physics. If anyone could answer these, it would prevent me having to run a bunch of experiments! I volunteer to open a PR to capture these answers, if anyone already knows:
-
At which component lifecycle hooks, if any, should I expect
get_world_position
to matchget_position
for a moving object? Or willget_world_position
universally return data that is at least 1-frame stale? -
What is meant by “frame” in the docs? Is it a physics frame, or a render frame? ie in
update
, isget_world_position
reliably 1-frame delayed? Infixed_update
is it unknown N-frames delayed? -
For a given object in a single frame, which is called first,
fixed_update
orupdate
? -
For other API functions, like
physics.raycast()
, that take world coordinates as input and return them as output, what state of the physics world are they working with? Will a raycast hit or miss an object that was moved into its path just in the last frame? When it returns a worldhit.position
, does that point reflect the currentget_position()
of the object, or theget_world_position()
of last frame, or is the answer unreliable? -
Is there any mechanism of ordering physics? I’ve learned that for certain very limited situations, if I want say a single type of game objects (like players), to update after the rest of the world has updated, I can
msg.post("#", "deferred_fixed_update")
and handle the message myself. However, I don’t know if this means that multiple “deferred_fixed_update” messages will be queued up and passed in the “message delivery” part of the lifecycle if for instance a frame fit multiple physics ticks within it (imagine a 120Hz physics game running on a 60Hz monitor), and if they’d still be in order.
Cheers!