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

Using enum inside export value gives error in 3.0.1. #17025

Closed
Gyrth opened this issue Feb 25, 2018 · 12 comments

Comments

@Gyrth
Copy link

commented Feb 25, 2018

OS: Ubuntu Linux 17.10
Godot version: Godot_v3.0.1-stable_x11.64

I use my own enum inside a script that gets loaded into a bunch other scripts. So I use this file as my source for global values. However in the latest version of Godot this doesn't seem to work anymore. I don't know if this is me using it wrong or this is a bug, please tell me. 😄

image

image

Example project:
BugReport.zip

@hpvb

This comment has been minimized.

Copy link
Member

commented Feb 25, 2018

Hi! Thanks for the bugreport and sorry about this. This is exactly the sort of breakage I'm trying to avoid in the stable series. I'll figure out why this is happening and make sure this gets fixed in 3.0.2 or at least documented if this is somehow unavoidable.

@hpvb

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

So the good news is that it appears to be cosmetic. The functionality still works so it's a problem with the editor. It won't actually break your game. So this can be fixed in 3.0.2. If this is too annoying to work with please revert to 3.0 for the moment :-/

@hpvb hpvb added the topic:editor label Feb 26, 2018

@hpvb

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

Caused by b7faa76

@x1212

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2018

Oh, I'll see if I have time to have a look at what my commit broke when I get home.
My guess right now would be that due to GDScript no longer forgetting if it was called for autocompletion/validation some bug elsewhere was exposed but I can't say for sure without doing some debugging.

@hpvb

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

@x1212 Instead of calling clear() in _parse_bytecode() and parse() duplicating all of clear() except clearing the already data seems to solve this issue.

	completion_type = COMPLETION_NONE;
	completion_node = NULL;
	completion_class = NULL;
	completion_function = NULL;
	completion_block = NULL;
	current_block = NULL;
	current_class = NULL;

	completion_found = false;
	rpc_mode = ScriptInstance::RPC_MODE_DISABLED;

	current_function = NULL;

	validating = false;
	for_completion = false;
	error_set = false;
	tab_level.clear();
	tab_level.push_back(0);
	error_line = 0;
	error_column = 0;
	pending_newline = -1;
	parenthesis = 0;
	current_export.type = Variant::NIL;
	error = "";

instead of clear() I also put the clear() back in _parse() as I couldn't quite figure out why it had to be removed.

@x1212

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2018

If I remember correctly calling clear in _parse resets too much information too early.
It leads to all those checks for validating and for_completion failing. Those would be set when the parser is called from the editor, but that clear reset those before they could be used.
That's why I think there is a high possibility that the issue might be some wrong check for those flags that didn't have any effect before.

@x1212

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2018

You can also fix this by replacing the !validating with true in line 456 of modules/gdscript/gdscript_parser.cpp ... so I guess the problem is that now that the validating member works, some optimization in the parser supposed to make validating faster breaks validating?
The part that isn't executed now is supposed to load preloaded scripts ... and the errormessage is caused by the parser not understanding that target_types is a const member of the preloaded const script.

@x1212

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2018

Just saw that 3.0.2 already got it's first rc ...
I wanted to look for a better solution but I guess I'll create a pullrequest today that removes that !validating condition for parsing preloaded scripts.

@akien-mga

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

Well for 3.0.2 we simply reverted the commit that created the regression, as the previous state was functional. It still needs to be properly fixed in the master branch though.

@Gyrth

This comment has been minimized.

Copy link
Author

commented Mar 4, 2018

Tested it in 3.0.2 and it seems to be fixed! Thanks!

@Gyrth Gyrth closed this Mar 4, 2018

@akien-mga akien-mga modified the milestones: 3.0, 3.1 Mar 5, 2018

@akien-mga

This comment has been minimized.

Copy link
Member

commented Mar 5, 2018

It's still valid in the master branch though.

@akien-mga akien-mga reopened this Mar 5, 2018

@DleanJeans

This comment has been minimized.

Copy link

commented Aug 19, 2018

Why is this merged into the 3.1 master branch? I'm waiting for so many new features and bug fixes in 3.1.
My workaround is to create a duplicate enum in the file you wanna use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.