#Collision Detection Delayed (Devs, PLEASE fix this!!!)

13 messages · Page 1 of 1 (latest)

exotic hazel
#

Hey guys.

I'm facing a major issue, and I've done quite a bit of research about it. If you look at the 2 gifs in the thumbnail, the first is the actual behavior I'm experiencing, and the second is what I want. The reason this is happening is because as the red enemy charges the player, it intersects, but then only next frame (when it's still intersecting) is the first collision reported and the knockback (once again, shown in the second gif) applied. However, it's still overlapping by now, which means a second, false report is being generated which causes damage and knockback to be applied twice, and this causes the sudden decceleration I'm experiencing in the first gif.

Having done quite a bit of research on this, my understanding is that there's not really any good options to have instant collision detection---at all.

What I've tried

  1. I've been told using shapecast (with force_shapecast_update) works, and it did... with a stationery area2D on the receiving end. The moment the area2D started moving, the shapecast, even with force update, would detect it one frame late. Since both the enemy and the player are going to be moving frequently, this is not an option.

  2. I've also seen that using Rect2 is a good option, but the issue with this is that it's axis-aligned, and only in the rectangle shape. In my game, I will need more complex shapes than a rectangle, and I will need to be able to rotate them. Rect2 is not a good option for me (I've seen some stuff about combining it with a transform2D to rotate it... but when I tried, it did not rotate at all. Let me know if there is something more I'm missing here though)

  3. I've also tried other hacky workarounds in my code... none of them worked, nor would I really want hacky workarounds in my code in the first place.

#

I've heard that interacting with the physicsserver directly is an option, but I can't seem to find any relevant functions that seem like they would help me, and when I was checking out the docs, it said that it was not recommended to retrieve any information from the physicsserver directly without knowing what you're doing. Which, I don't.

#

It is VITAL that devs work with instant collision detection, especially when situations like this come around. Instant collision detection is the only thing that will work for me. I'm a little taken aback that in order to have instant collision detection, you basically need to implement your own physics engine or interact with the existing one at a depth that is so far out of the wheelhouse of the average developer, me included. This is not viable as a game engine.

#

I understand that the 1 frame delay is necessary for the physics engine, and that's fine...

#

BUT PLEASE GIVE US AN ALTERNATIVE.

#

If there's something I'm missing, please let me know; progress on my game is kind of halted until I get this figured out, and I'm not the only one:
https://www.reddit.com/r/godot/comments/1dztg6w/collisions_happening_1_frame_or_physics_tick_late/

https://forum.godotengine.org/t/why-are-area2d-collisions-triggered-1-frame-late/37354

Reddit

Explore this post and more from the godot community

exotic hazel
#

how did no one suggest this

#

thanks bro

sullen shard
#

I only found it years after I started using godot

exotic hazel
#

it also doesn't match the rect2 overlapping() naming convention either