Is there any reason for that particular order?
There’s probably a reason, but I dig into the code too seldom to quickly figure it out. Maybe @Ragnar_Svensson or @sven knows?
I’d like to counter with another question though: Is there a reason the order of messages is important to you? If yes, then please try to rethink your design, as there is no guarantee that the order of things will remain constant over time.
If we can get “ray_cast_response” first, we can then use this results in “contact_point_response” handler, and decide to separate objects or let them fall through. For now, we always on one frame behind.
I can’t imagine reverse situation.
That why we need immediate raycasts, but not deferred.
There are practical reasons, but I need to think about this for a while to answer it properly. It might make more sense to do ray casting before simulation, but I don’t have a clear answer right now. Poke me if I haven’t replied in 24 hours.
Well, can we change the order of messages? And if not, will that order remains constant?
I think, we need clear order of things in frame time, and not “there is no guarantee that the order of things will remain constant over time.”
This only applies to ray casting and collisions (which is a result from physics simulation). Everything else in the engine has a well defined update order on the system level. The problem with ray casting and collisions is that there is not a clear (natural/intuitive) order. Some people might expect that the ray casts happen on the current state (since that’s the time of the ray cast requests), while some might expect them to happen on the result of the simulation that frame (since they are in fact deferred). Personally I think the first case is the more common, but the best solution would probably be to add a config setting for this in game.project.
I think so too. And please add “nothing is hit” response.