#Area2D Collision Errors

1 messages · Page 1 of 1 (latest)

sudden sluice
#

Hi guys, I'm currently using an Area2D node that switches scenes on collision and I'm getting <C++ Error>, <C++ Source>, and <Stack Trace> errors that I don't understand.


extends Area2D

@export var target_level : PackedScene

func _on_body_entered(body):
    if body.name == "CharacterBody2D":
        get_tree().change_scene_to_packed(target_level)

this is what the code for the collision logic looks like. So all it's doing is once my CharacterBody2D player touches the Area2D collision box, it ensures the Player is touching it (the first if-statement), then it changes the scene to a packed scene which I have declared above.

  <C++ Error>    Condition "locked" is true.
  <C++ Source>   scene/2d/area_2d.cpp:328 @ _clear_monitoring()
  <Stack Trace>  door_collision.gd:7 @ _on_body_entered()```


```E 0:00:20:0556   door_collision.gd:7 @ _on_body_entered(): Removing a CollisionObject node during a physics callback is not allowed and will cause undesired behavior. Remove with call_deferred() instead.
  <C++ Source>   scene/2d/collision_object_2d.cpp:98 @ _notification()
  <Stack Trace>  door_collision.gd:7 @ _on_body_entered()```

And these are all the details for what the error is saying. Is this enough informtion to get help with? I don't know how to fix these errors or why exactly they're happening. I notice they're C++ errors, but I'm writing in GDscript. Can someone help me out please? Thank you :)
bitter lark
#

You're trying to change scenes while physics are being processed.
Use get_tree().change_scene_to_packed.call_deferred(target_level) to delay the call to a safer moment in time.

sudden sluice
# bitter lark You're trying to change scenes while physics are being processed. Use `get_tree(...

if I were to use the same Area2D element in the scene that I am changing to in order to switch back to the scene that I was just in, would I have to switch around the logic a bit? If that question was confusing, imagine this Area2D collision box to be the same node element to act as both an exit and entrance to and from a house, but the interior and exterior of the house are different scenes. because when I just put the same element down again, I get this error:

  <C++ Error>    Condition "p_scene.is_null()" is true. Returning: ERR_INVALID_PARAMETER
  <C++ Source>   scene/main/scene_tree.cpp:1409 @ change_scene_to_packed()
#

I would have to start keeping track of what scene I'm in and which one I'm trying to get back into in order to know when to use unload_current_scene(), right?

bitter lark
#

To use the same object in the new scene, you'd have to first remove it from the scene tree. Then store it in a Singleton.

If you want to use an object of the same class then yeah, you can. Generally it wouldn't be necessary to change the logic, but it depends on what you're doing.

The error here complains that the scene you provided is empty.

sudden sluice
warm flare
#

when in doubt and physics are involved, call_deferred() is your trusty companion.

I don't spend enough time digging around in the physics frames to know why your scene is empty for you; the only guess I have is that if you're trying to change the scene while loading something from the existing scene, it may be looking for something that suddenly becomes unavailable the moment the scene changes?

#

I second the Autoloader/Singleton suggestion. Having a global source that is persistent across scenes is extremely helpful.

sudden sluice
#

I am going to have to look into what an autoloader/singleton is 🤔

#

I appreciate you guys, thank you! 😎

warm flare
#

They're super useful!!! They're basically scenes that get loaded automatically no matter what scene you're in.

I have a number of them dedicated to storing specific packedscenes and other methods for easy access. Others store the gamestate, and allow me to pause from anywhere.

So like, I could just say GameManager.pause_game() from any script, and I know it will work because GameManager is an autoloader that's always in my scene tree.

image.png
#

But uh, as you can see, it can get out of hand if you rely on them too much. So, you know. 💦 Do as I say, not as I do

#

Best of luck!

sudden sluice
#

that looks super helpful