#get_overlapping_bodies returning empty array in _ready

1 messages · Page 1 of 1 (latest)

pine river
#

get_overlapping_bodies returning empty array in _ready

iron kite
#

This isn't the best solution, but a down & dirty fix to get it running would be to have damage_enemies return a boolean and then place it in your _physics_process, setting it to some variable like initial_damage and checking if initial_damage is true before executing

#

Can provide pseudocode if that didn't make sense 😛

iron kite
#

You'll want to make the return value something like: return not enemies_in_hitbox_area.is_empty()

#

so it only returns true when you succesfully have grabbed the overlapping nodes

#

doing that will essentially turn it into the one-time thing you're looking for

#

or I guess I don't know the full context of what you need it to do

#

if you call get_overlapping_bodies() in _ready there might not be any other bodies yet is where the issue lies

elfin wind
#

I believe physics_process() runs before the physics engine so it can't detect bodies either on its first call

also call_defered() just waits for the end of the curent frame

#

it needs the physics engine to run once

#

you could use the body_entered signal

iron kite
#

There is await but I don't really use it so can't show you how to best use it

elfin wind
#

I can offer you this workarround but i think it's kinda stupid

func _ready() -> void:
    await get_tree().physics_frame
    await get_tree().physics_frame
    damage_enemies()
pine river
#

oh yeah that worked

#

is there no cleaner way lol

elfin wind
#

yeah, that's my problem with it

iron kite
#

probably. would need more context

#

like why is this thing that is apparently just spawning also checking for collisions already with other things that aren't _ready yet?

elfin wind
#

are the other things not ready?

pine river
#

the other things are enemies that were already added to the tree so they're ready

elfin wind
#

the area2d needs to go through a call of the physics engine to detect things

iron kite
#

hmm. what is the reasoning behind it only colliding on the first frame and never afterward?

elfin wind
#

are you talking about the signals it emits?

pine river
#

its like an aoe attack

elfin wind
iron kite
#

oh sorry I was just asking his thought process behind why he wants that behavior 😛

#

I have an aoe attack that spawns and hits enemies in a game, will check the code out

elfin wind
#

if it's an aoe attack it would probably feel better if it existed for a little longer than just 1 frame

pine river
#

yeah but in the case that i only wanted it to exist for 1 frame

#

i just want the damage hitbox to be out for 1 frame, but the sprite animation is a second or so

elfin wind
#

isn't this mismatch a problem?

iron kite
#

if you want to avoid await (which I agree with avoiding), you could just use that timer to disable the collision shape. and keep the collision in _physics_process

elfin wind
#

i don't agree with avoiding await

iron kite
#

agree to disagree 😛

elfin wind
#

but i still like that idea more

iron kite
#

await causes more problems than it fixes imo

#

it's amazing in javascript though 🙂

elfin wind
#

'-'

pine river
#

what does that idea look like

elfin wind
#

add a timer to your aoe attack scene that disables the Area2D on timeout

#

have you used signals before?

pine river
#

how would i make that only on the first frame after physics?

#

yes

iron kite
#

this idea wouldn't be only first frame, it would be for X seconds. like 0.1 seconds in your earlier example

#

which might as well just be 1 frame

pine river
#

why is that better?

iron kite
#

to avoid await, which basically pauses the active thread

#

feel free to just use await tho haha

pine river
#

i thought it only blocks if it's in _process or _physics_process, not _ready

elfin wind
#

i thought too

iron kite
#

if that was the case it wouldn't work in _ready

elfin wind
#

anyway i don't mind await but idk, the vibes are off on the other solution