I’ve just migrated a physics-heavy project to 1.12.1 and it’s working well. Thanks for these improvements!
A question that arose when migrating, related to recent 1.11 features:
What exactly does go.update_world_transform impact? I’m using it for custom physics, like when comparing the world-space positions of two objects. Is the only downstream effect of calling it making sure that go.get_world_position is accurate? Or does it also impact physics? For example:
physics.raycast(start_pos, end_pos, groups) -- hit obj_a
go.set_position(new_pos, obj_a) -- move out of the way of the ray
-- go.update_world_transform(obj_a) -- is this necessary?
physics.raycast(start_pos, end_pos, groups) -- does this hit?
I’m trying to mitigate the “view of world-transform physics is always a snapshot that’s one-frame back” issue, so that ideally regardless of whether I’m using physics.raycast or go.get_world_position, my view of the physical state in world coordinates is consistent and up-to-date.
A separate question about handling input now:
When will on_input be called, relative to fixed_update, update, and late_update? Are repeated inputs guaranteed to be sent at least once per update callback? My current input handler tracks state internally:
- on_input → manage internal input state (and be sure to never miss a release, must get this bookkeeping right)
- fixed_update → use the stored input state to update physics
I would love to delete a bunch of code, and to instead simplify to:
- late_update → clear all input state
- on_input → build up input state
- fixed_update → use single frame of input state to update physics
Editing to add a third question I just ran into:
Similar to the input question, relative to the new lifecycle callbacks, when are physics messages like “contact_point_response” sent?
