Godot version:
3.0.5
OS/device including version:
MacOS High Sierra
Issue description:
As the title says, removing an Area2D that is overlapping another Area2D spit out this error:
0:00:30:0687 - Condition ' !area_in && !E ' is true.
----------
Type:Error
Description:
Time: 0:00:30:0687
C Error: Condition ' !area_in && !E ' is true.
C Source: scene/2d/area_2d.cpp:262
C Function: _area_inout
And if it's overlapping with a physics body:
0:00:30:0687 - Condition ' !body_in && !E ' is true.
----------
Type:Error
Description:
Time: 0:00:30:0687
C Error: Condition ' !body_in && !E ' is true.
C Source: scene/2d/area_2d.cpp:161
C Function: _body_inout
Steps to reproduce:
For some reason, I can't reliable reproduce it in a new project, but it happens without fail in my main one. Just remove an Area2D that's overlapping with another Area2D or a KinematicBody2D.
I should mention, this doesn't crash the game but it get's pretty annoying since I don't see why doing this should output a warning. Also, some weeks ago I had found a similar issue that was fixed for the 3.0 release if I recall correctly but I think it was only fixed for 3D and not for 2D; unfortunately I can't find that issue now. If I do I'll link it on an edit or on a comment.
Ah, immediately found it. It's #17132. Also, not sure if it matters but physics engine is set to DEFAULT
There's only one physics engine for 2D, so the option makes no difference.
I had this issue when implementing transporters; I could prevent the error from occurring if I turned off monitoring before freeing the area(s), though I'm not sure if the error prints if it's turned back on (since I'm changing scenes, I don't have a chance to check.)
Removing or freeing areas? if removing, try call_deferred.
@vnen Really? I thought there was Bullet and then the one we had before 3.0. Still, the issue is there anyway.
@eon-s I'm freeing the areas though I'm pretty sure the issue indeed happens at the moment they are removed from the tree. Using call_deferred does not fix the problem. Again, it's just a warning, everything works as intended mechanics-wise, it's just kind of annoying and doesn't seem like something worth warning the user for IMO.
Really? I thought there was Bullet and then the one we had before 3.0.
Only for 3D. Bullet is not used for 2D physics.
ERROR: _body_inout: Condition ' !body_in && !E ' is true.
At: scene/2d/area_2d.cpp:161
In 3.0.6, I get this error by dozens everytime I finish a level. This never happened in 2.1.5. In my game, the "end" is an area that "catches" the player like a portal, and the next level is loaded as the player node is still inside (destroying current level, waiting a frame then instancing next one).
However I also have areas throughout the level for things that "grab" the player and shoot it out (like cannons), and I noticed I get way more of these errors the more cannons I have in my level, even though the player definitely exited them for a long time when the end is reached.
At the end of the day, when I finish a test session the debugger is filled with hundreds of that, and dropped others^^"
I am trying to fix it, but I honestly can't reproduce it with a simple example. If you can create a simple project that would be appreciated, else I will have to close it.
It reproduces in 3.1 alpha2 too. I started getting a redux of my project to narrow it down.
So far I found that if I finish a level without taking any pickups, switching to the next level does not cause the error. My pickups have areas.
Here is a mega-redux of my project, which reproduces the error:
wallrider_test_godot31.zip
Just start the project: the character will catch a pickup, then wait until the Next Level button appears. As soon as you click, the error will appear in the console.
Hoping it's simple enough
Most helpful comment
Here is a mega-redux of my project, which reproduces the error:
wallrider_test_godot31.zip
Just start the project: the character will catch a pickup, then wait until the
Next Levelbutton appears. As soon as you click, the error will appear in the console.Hoping it's simple enough