Godot Version
v4.5.stable.official
Question
In my journey to make a platform fighter with rollback using Godot (novel idea I know), I have encountered the issue of physics bodies registering late. With code (shown at the end) I am spawning hitboxes using call_deferred() and then connecting their signals directly to a hitbox collision function.
The issue lies in how the hitboxes (Area3D’s) register a hit one frame after colliding with the opponent’s hurtbox (Area3D’s). I am aware that it takes one whole physics step to reach the internal server and update collision, but I am really unsure of how to handle that. I thought perhaps call_deferred() would fix the issue by spawning the Area3D before the next physics step, but that hasn’t changed the outcome of late hitbox registration.
Am I approaching this wrong? Is there anyone who has made a fighting game with Godot that has found a way around these issues?
(P.S. If you’re going to comment about Shapecast3D’s, I have tried that as well. They don’t even allign with the player on the first frame! At least the Area3D’s were in the right place. And forcing an update with their built in function doesn’t seem to work the way I’d expect)
Going to organize the code tree by what I feel is most relevant first:
-
call_deferred() function to spawn a “two hitboxes” scene I made, while passing in the information about those hitboxes (size, rotation, knockback, etc.)
-
The "SMARTcreate_2hitboxes() function referred to by the last image
-
The twoHitboxes scene I’ve created (this was done to prevent sweet spots & sour spots from independently hitting the victim, causing double damage)
-
SMARTset_parameters as seen two images ago. (Forgive the copy paste code on this one, I’m sure there’s a better way to do this but I’m not going to optimize until it works the way I want it to)
-
update_sizes() function to directly change the Area3D geometry after dumping the hitbox info
Some final notes about my code structure: I have my custom State Machine class running inside physics_process(). Each character will extend this class with their own custom implementation of a State Machine. State Machine is just a node I attached underneath the parent node of the character so it can access its parent’s attributes (speed, frame data, etc.) to perform the right actions within each state.
If you made it this far, thank you very much for taking the time to read. I’m sure you saw a couple funny comments inside my code (gotta keep everything well documented!) I want to make this post before I give up on using the built in functionality of Godot. I’m not opposed to coding my own AABB system, but it feels like reinventing the wheel especially when Godot has these built in features. Let me know what you think!







