`
I implemented a design where enemies emit a signal when attacking or dying to create damage Area2Ds. After creation, I use GetOverlappingAreas to process overlapping objects, then destroy the area. However, I found it wasn’t detecting any overlaps.
After adding await ToSignal(GetTree(), SceneTree.SignalName.PhysicsFrame), the areas created on death started working properly, but the attack areas still didn’t work (no overlapping targets detected).
After various tests, I discovered that adding one more await (waiting for a second physics frame) made it work.
I’ve already switched to using onAreaEntered to solve the problem, but I’m curious why waiting for two frames was necessary.
Both cases use the same signal for triggering. Here’s the position triggering logic:
Attack:
Please put your code between ``` on the lines above and below your code so it is easier to read,
Your problem is related to the fact that you are trying to create something that detects collisions and are expecting it to do so the same frame it is created - which is cannot always do. If you use call_deferred() on the creation it might help, but I do not know how to do that in C#.
Thank you very much for your reply.
I tried using callDeferred, but it didn’t work. Later, through testing, I found that it only works by waiting for physics frames. The AI told me that Godot processes physics at the very end of the frame, so when the program executes, the physics information hasn’t been updated yet.
However, what confuses me the most is why, when attacking, I need to wait for two physics frames, whereas the death zone transmitted through the same signal only requires one.
You are really kind and helpful. Thank you.
This diagram shows the overall structure, in which two of the three areas below are for attacking, and one is for when death occurs.
Ok, so I think if you’re trying to do a death explosion type of effect, you’d be better off using a ShapeCast2D rather than an Area2D. This may solve your problem of multiple frames.
OK, thank you. This indeed fits my needs better.
However, I’m still curious about why it takes two physics frames to obtain the physics information. Could it be that it fails to be included in the calculation during the first physics frame?
May I ask if there are any methods to directly access information from the physics engine?
I’m encountering this same issue. I need to wait two physics frames before recieving up to date overlap information from Area3D. I’ll also note that I’m using Jolt Physics.
I collected some information from the AI’s responses. I took a quick look and think it should be correct.
You can refer to this for a careful check. I don’t know much about Jolt
When having Area report collisions on its own, there will be a delay of several frames due to communication with the physics server. Godot’s recommended solution for this is to use direct_space_state or the ShapeCast2D node.
Jolt must work within Godot’s framework and therefore cannot bypass Godot’s PhysicsServer communication mechanism and inherent synchronization delays.
Again using a RayCast2D/3D or ShapeCast2D/3D node allows you to process collision information every frame. Area2D/3D works just fine for most things, but if it doesn’t, you’re better off using one of those.
Thank you for continuing to follow this topic. However, you might have misunderstood my meaning.
The main purpose of my statement is to respond to Greeb — it seems that the latency of this method is unavoidable due to architectural issues — and to provide the suggested usage. My primary reason for consulting the AI is to find out the causes and supporting evidence.