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

Inconsistent calling of setter between running in editor and standalone #84378

Open
beev1s opened this issue Nov 2, 2023 · 5 comments
Open

Comments

@beev1s
Copy link

beev1s commented Nov 2, 2023

Godot version

v4.2.beta4.official [93cdacb]

System information

Windows 10

Issue description

When exporting my game from the editor, certain setters are not being called which leads to unset values and references. I have been able to reproduce the problem in a test project.
Here I set the value of an exported integer in the editor. When I run the program from the editor I can see that the value is being set.
in_editor

When I export the program and run the standalone version, I am not able to see the same output.
standalone

This is not a problem with the print statement, as I can see other print statements in the output of the standalone program (I deleted them to reduce the sample as much as possible) and the value is also set to the non-default value.
I have noticed that when I delete the .godot folder in this test project, restart the editor, export the program and then run the standalone version, the output is as expect. However, this solution does not seem to work on everything in my main game.

Steps to reproduce

Open the attached project. Run in the editor for the normal output. Export The program with default settings and run the program via the console to see no output.
Please note: The attached project specifically includes the .godot folder as it seems to be linked to the error.

Minimal reproduction project

GetSetBugStandaloneSmall.zip

@beev1s
Copy link
Author

beev1s commented Nov 7, 2023

I did some debugging in the engine code and figured out what is happening here. The setters for the 'missing' values contain a if not inside_tree(): await ready before the assignment of the value, i.e.

func setter(v):
    if not inside_tree(): await ready
    value = v

When Godot creates the built, all scenes get initialized and nodes (including scripts) get instantiated. In order to transfer the values from the scene file to the node, the setters get called. However, the scenes are never 'ready' and thus the non-default value will never be set in the script instance of the nodes. Therefore Godot only sees the script members with their default values and doesn't write them into the exported built and binary scene caches (Apparently I changed the function unknowingly and thus it works again when the .godot folder is deleted in my example).

I don't know if this is intended behavior though the easy fix for this is to change the order of operations.

@RebelliousX
Copy link
Contributor

I have similar issue, except that I discovered that the default value of the exported variable in a @tool mode NEVER calls the setter function at all. Any other value that is not the default calls the setter function. As a workaround, I had to assign the variable to itself in the _ready().

This sucks.. It costs me an hour or 2 to figure what is going on in my large project. Because I had some nodes working, and some are not, and they were driving me crazy. I never thought the setter for the default was never called.

@RebelliousX
Copy link
Contributor

I created issue #86494 that might be related to this.

@Nitwel
Copy link

Nitwel commented Mar 20, 2024

Would love to see some attention on this issue. This is really frustrating to debug when you come across this the first time and causes a lot of unexpected behavior.

@djrain
Copy link

djrain commented Jul 27, 2024

Still valid in 4.3 RC1, super frustrating. I had it working (without really understanding) and then the behavior seemed to randomly change today.

EDIT: deleting .godot folder seems to have fixed it.

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

5 participants