Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing (highmemory) scene cause GDscript to force to run next line and crash? #9253

Closed
Qws opened this issue Jun 18, 2017 · 4 comments
Closed

Comments

@Qws
Copy link

Qws commented Jun 18, 2017

Operating system or device - Godot version:
Windows 10.
Godot 2.1.3
Pure Node2D

Issue description:
Code of the old scene keeps going even after I call this function:

get_tree().change_scene("res://Game/Credits.tscn")

Steps to reproduce:

So I've SceneA and SceneB

SceneA use 1.5 GB ram when it's running (contains heavy assets made in DragonBones). So when I change from SceneA to SceneB with "get_tree().change_scene()", GDscript just continue the code of SceneA till it crashes, doesn't even have time to load SceneB.

When I test the same code again in HTML5 version it works... the scene does change, but according to the debugger the code in SceneA kept going till it crashed (just almost immediately). But at least it loads the SceneB and game is still functional.

This function I cast from SceneA:

func goodcredits():
	print("==============starting the credits===============")
	var nodesingroup = get_tree().get_nodes_in_group("WelcomeMap")
	nodesingroup.empty()
	nodesingroup.clear()
	get_tree().change_scene("res://Game/Credits.tscn")
	print("================================================")

Is this a bug? Or do I have to destroy/clear SceneA somehow before I change to SceneB?

@Zylann
Copy link
Contributor

Zylann commented Jun 18, 2017

I had a problem too when I reached 1gb of RAM allocated in Godot: #8279
it just crashes beyond that point, which is too bad because computers have more memory than that these days^^"

@Qws
Copy link
Author

Qws commented Jun 19, 2017

Well, I started a new project, to test with nearly no MB usage. And yes, the code of the old scene didn't kept running when it changes to a new lightweight scene. So, problem doesn't exist in low usage of RAM...

Ehm... does Godot really get overall unstable when scenes starting to use 1GB+ RAM? We have slightly different troubles but I guess both problems are in the end about high memory usage, and I guess not reproducible on low memory usage.

It seems for this case that "get_tree().change_scene("")" with not block the current thread but instead it starts new thread skipping "get_tree().change_scene()" code whenever loading the next scene takes too long. Similar like Async code... but I'm sure Godot is not fully async..?

I guess I have to work around it... for now...

@kubecz3k
Copy link
Contributor

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

@akien-mga
Copy link
Member

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

As there was no update since the previous post, we close this issue.

If it is still relevant in the way it was described and discussed above, please comment to ask for it to be reevaluated. If it is only partly relevant, or if the original issue has changed, it would be better to open a new issue (potentially referring to this one) focused on the current state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants