When I use this function, the engine takes 3-4 seconds to close down the debug mode, if i remove it, it works normally. Any suggestions why? Code below
func _on_track_body_exited(body):
get_tree().reload_current_scene()
Hi Frid44y,
To be honest with you as its an signal it seems like the issue is in the godot engine installation itself or the machine you are running it on if the issue is around the 8 minute mark in the video as we are not doing anything really intensive.
Its simply detecting the body exiting the area and then reloading the scene.
I cant imagine its the machine specs that are at play as godot is a very light engine and as previously stated we are making a simple signal to reload the scene.
Unless you of course have a very heavy scene that could cause the delay but that i would expect in a larger 3D game and not a simple 2D game.
Maybe just rebooting the machine and restarting the project will be a possible solution
I tried restarting, it only worked normally once i unlinked the signal and removed the code.
This is definitely quite strange. Marc is right, insufficient specs seems out of the question, so more data-gathering is needed to see what’s really going on. There are some advanced things I would check, but first, add a print statement before get_tree().reload_current_scene(). This should only output once each time you exit the maze, and not at all when you close the game down. Either way, let us know what happens when you try that and we can go from there.
the print statement outputs just once indeed, specs wise, not really as I run UE5.4 no problem, The script is attached to the level scene, i don’t understand. It seems like something so trivial, yet there is no clear cause for it. as you can imagine it is frustrating, waiting for the play mode to close 5 sec each time
Have you tried commenting out (or deleting the line of code) that is reloading the level and just using a print statement there instead and seeing if it has the delay there as well.
I am trying to see if the issue lies in the signal calling the method or if its the reloading of the scene that causes the hanging issue.
Also can you let me know which version of the godot engine you are using as we have another student that their project seems to want to run the scene twice in 4.2.2 and i wonder if its this version that is really buggy.
If this still causes a hanging issue i would try disconnecting and reconnecting the signal to see if the issue lies there
Let us know how you get on
So i deleted the line you suggested, and there was no delay at all on closing the window. why could that be? the print fires once.
Yesterday, I was tempted to suggest using breakpoints to check for looping code or other bottlenecks, but the print test more or less rules all of that out. If code is looping here, it’s clearly the C++ underneath everything, not the GDScript you’ve written.
It’s worth noting that I’ve had problems with get_tree().reload_current_scene() before. Different problems to be fair, but problems nonetheless. I have downloaded Kaan’s final commit of Speedy Saucer and run it in 4.2.2, but I couldn’t reproduce the problem. I’d be interested to see if this also happens on your end, which would suggest some sort of configuration problem in your project (very unlikely). Here’s a direct link to the github for your convenience - just click the blue “Code” button and download the .zip: GameDev.tv / Godot Complete 2D / Speedy Saucer · GitLab
There is also a problem with Kaan’s code that he doesn’t actually fix because it doesn’t break the game, and this has to do with calling get_tree().reload_current_scene() “unsafely”, before the frame’s physics processing is finished. If Kaan’s commit doesn’t work, then as a test, replace get_tree().reload_current_scene() with get_tree().call_deferred("reload_current_scene")
I’m pretty sure there’s a cleaner way to write this syntax (EDIT: fixed. I had a bit of a brain lapse earlier XD ), but it does fix Kaan’s error. There is a possibility that what was once fine in 4.0 is no longer fine in 4.2.2
Best of luck and please keep us updated =)
Deferring the reload until after the physics call was the right… call. (SOLVED! <3)
hope i worded that correctly, I’m so new to writing scripts and all, more of an art guy 
2 Likes
Ha! Nice! =D
Nice job! I had completely forgot about needing to use call deferred in 4.2.2 as it was only a suggestion in 4.2.1 so its now seemingly become needed in this update.
1 Like
Needed, unless you don’t mind waiting 5s each time you test the game
Jokes aside, what implications aside from the ones mentioned above could we expect if not using call_deferred?
Basically what is happening is that its trying to close the window whilst there are physics calculations still being processed by the engine so its hanging and waiting for it to end causing the delay in closing.
The other issue that can arise that we have encountered is when you change scene and the calculations are still taking place it causes a delay as its still trying to calculate and switch the scenes.
Using call_deferred means it waits until the end of that physics frame to call the method rather than at the start of it so we can be sure those calculations are done and nothing is holding it up to close/load the next scene.
I am sure there are other issues that can arise from it and we do use call_deferred in our 3D course and also our multiplayer course that is in a more up to date version.
I have messaged Kaan on this to see if its worth adding a note in this lecture to mention this and avoid issues in the future.
1 Like
awesome, thank you for your answers!
2 Likes
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.