 |
Attention | Topic was automatically imported from the old Question2Answer platform. |
 |
Asked By | DigitalUnity |
E 0:00:12:0395 remove: Condition “p_elem->_root != this” is true.
<C++ Source> ./core/templates/self_list.h:80 @ remove()
I have no idea what this means, but it started filling my error log a couple seconds ago. I’ve combed over my code to try and figure this out, and it’s entirely possible this isn’t the primary source of my woes, but all I’m doing is instantiating a bunch of objects and my game is crashing. The basic code for each involved node is as follows:
Player Firing Code:
if Input.is_action_pressed("Fire"):
shot = bullet.instantiate()
get_node("/root/GameWorld").add_child(shot)
shot.init(player)
The bullet node in question:
extends CharacterBody2D
@onready var calzone
func _enter_tree():
calzone = get_node("/root/GameWorld/Camera2D/EntityManager/ShotCullNet")
calzone.body_entered.connect(cull)
func init(player):
position = player.position
velocity=Vector2(0,-(player.speedCurrent*100+500))
func _physics_process(delta):
move_and_slide()
if get_slide_collision_count()>0:
get_last_slide_collision().get_collider().hp -= 5
queue_free()
func cull(body):
if calzone.overlaps_body(self) && !is_queued_for_deletion():
calzone.body_entered.disconnect(cull)
print("plink")
queue_free()
Additional notes:
The firing code is being run from a state machine and not the player character. I removed all timers from the code to see if frequency of object spawns increased crash rate (Which it might have? I’m not completely convinced but it feels like it did). I can pack my project if anyone would like to take a closer look at the code.
Any advice on this would be great. No sense in making an arcade shooter if I can’t shoot.
You might try using the profiler to track memory and CPU usage.
TRAILtheGREAT | 2023-04-29 06:50
I’m fairly new when it comes to debugging at this level. How would I go about this?
DigitalUnity | 2023-04-29 07:03
You can start the profiler by running your game, then switching back to the editor, clicking on “Debugger” on the bottom of the window, then under the “Profiler” tab, press start to start profiling. You should also try checking for Orphaned Nodes by going to Monitors and selecting “Orphaned Nodes”.
I did some googling and it looks like similar errors are usually associated with multithreading. Are you using any multithreading?
TRAILtheGREAT | 2023-04-29 07:18
Ok, The good news and the bad news:
The good news is that I don’t appear to have any orphaned nodes, and that particular error is no longer showing up for me… The bad news is I’m still crashing. I don’t believe I’m doing any multithreading, mostly because I wouldn’t know how to do that in the first place. If I am, I’m doing it completely by mistake. It’s seeming more and more like I’ll need to dump the whole project for better assistance at this point…
DigitalUnity | 2023-04-29 08:04
Maybe using call_deferred("queue_free") instead of queue_free() will solve the problem?
godot_dev_ | 2023-04-29 15:03
Just gave this a shot, no effect… Very curious, and I still haven’t seen the error message again. What keeps making it crash? Everything’s culling properly, it’s all getting removed from the tree, no orphans… I’m at a loss, I almost wonder if it’s an unhandled input somehow. I’m very new to this forum, how would I pack my project for another user to review it? (additionally, my code might be a bit messy, as a fair warning. I’ve been trying to keep it clean, but there’s still stuff I haven’t gone back to yet)
DigitalUnity | 2023-04-29 17:42
Just as a means of bumping this back up to the top of the heap here. I’ve tried a few more things to debug this, and I’m still confused. all my nodes are removing themselves from the tree properly, the trigger for the crash is inconsistent, but it’s definitely related to spawning bullets. I’ve added lines to remove the nodes from the scene root before queueing them for deletion, but this had no effect. What’s absolutely crazy is that none of my the graphs under monitors seem out of the ordinary. Objects is the only one that seems a little odd, but it doesn’t peak at the crash. I’m at a complete loss.
DigitalUnity | 2023-05-22 23:05
I haven’t seen the frequent occurrence of users packaging/zipping their project to get help, but if you want to do that, I believe you need to upload your project to some public server and provide a link to the project.
Hmm, could the bullet be processing /involved in collisions when you delete it? Maybe disabling all it’s collision shapes and waiting at least 1 frame before the queue_free might solve the issue?
godot_dev_ | 2023-05-23 00:39
That was a clever idea, but sadly it still comes up crashing… I’m noticing my Static memory and static max are very close to eachother at all times, but I’m not sure if that’s related? I’ve never had this kind of problem before, in fact a project I was working on in a previous version of Godot never had an issue like this at all, and it uses more or less the same spawning code… I’ll check how it handles despawning, maybe I’m getting in my own way by trying to cull the shots when they leave the play area…
DigitalUnity | 2023-05-23 02:52
Further inspection baffles me. I almost used the exact same method of deleting entities before in Godot 3.x and it worked FINE. The only difference is I’m removing the shots based on the time they’ve existed as opposed to if they enter an area the dictates their removal. I can’t make heads or tails of why this is happening, and if it’s an issue of collision detection then how am I meant to delete enemies when I eventually move to implementing them? This is very strange indeed…
DigitalUnity | 2023-05-23 03:02
Maybe try avoid deleting the bullets entirely? You could have a buffer of pre-instanced bullets. When you shoot: fetch one of the bullets already created and move them to the correct location, make them visible, activate their animation, and activate their collision areas. When you want to delete them, just undo the steps done to activate them (deactivate collision areas, stop all animations, and hide them). I don’t have any more ideas, but maybe that will help (it is a way to deal with lag)
godot_dev_ | 2023-05-23 13:17