GDC compilation

[UserUnknownFactor]

It needs patched ustring.cpp and ustring.h on a7d0e1. I put modded versions to the patches folder. This seems to work in general but I saw unexplained 1 byte defference that modifies Dictionary to explicit type when recompiled. IDK what causes that, I'm not that well versed in Godot. It'd be nice if someone who knows their GDScript checks it later.

This also ignores non-critical utf-8 errors during decompilation. There were games before that had unpaired surrogate error while properly decompiling if it's ignored.

[UserUnknownFactor]

The compiler is from the current latest version of 3.5 branch. So while it's limited it's better than nothing, right? And it can possibly be modded to produce other versioned bytecode...

[nikitalita]

The compiler is from the current latest version of 3.5 branch. So while it's limited it's better than nothing, right? And it can possibly be modded to produce other versioned bytecode...

I'd definitely like to have this, but in this case, limited can be worse than nothing. The usefulness of the feature vs potential for user confusion here is untenable if we only supported one bytecode version. This was the reason why it was removed a while back in the first place.

There are a some things you'd have to address in order for this to be merged:

• Refactor the tokenizer such that the function names and token enums can be overridden, so that additional versions can be implemented. You could potentially model this on how we implement the bytecode decompilers.
• Refactor the tokenizer to not use the old VMap
• Support for compiling at least back to 3.0. I wouldn't require that you implement support for the dev versions, so that would just be 054a2ac, 1a36141, 514a3fb, 5565f55, and a7aad78
• Remove the out-of-tree ustring patches. I have successfully avoided requiring any out-of-tree Godot patches for GDRE tools because it becomes a huge pain in the ass to maintain, and I don't want to start now. I am not certain why these are required; can you please explain so that we can come up with a potential workaround?

[UserUnknownFactor]

I'm kinda newbie at C++ programming so I'm not sure if I ever go that far as you suggest. If it's like this I'd better close this PR and only reopen it if I ever find a chance to do the refactoring... (not highly probable though).

[UserUnknownFactor]

I still consider it not a bad idea to be able to recompile scripts at least to the current latest Godot 3 version since there are many games using it now and GDRE supports full project decompilation so many older games can be moved to that version instead without hassle and necessity to recompile the entire game each time...

[nikitalita]

I still consider it not a bad idea to be able to recompile scripts at least to the current latest Godot 3 version since there are many games using it now and GDRE supports full project decompilation so many older games can be moved to that version instead without hassle and necessity to recompile the entire game each time...

The main issue here is that nearly all the different bytecode versions (there are 50+ that we have support for) are mutually incompatible. If you compile a script with the incorrect bytecode version for the game executable, it will likely be interpreted as garbage by the engine.

However, thinking about it, the bytecode for 3.5 is actually one of the few versions that is compatible with the previous version (3.2). That would still get us a big chunk of games.

So, how about this: If you can do these two items

• Remove map.h (I don't think you actually need it here, I don't see anything that actually uses it)
• Remove the out-of-tree ustring patches

Then I'll take this. I can refactor the class for different versions at a later date.