You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue description: No current editor option to generate ".gde" files (encrypted GDScript) despite having functionality for reading it in the source code.
Apparently, Godot 2.0 had an option to export .gd files as .gde, but I don't see that anywhere in Godot 3.0 nor 3.1. I'm suspecting this could be a bug (missing settings option in the editor).
[Off-topic] My reason why I find that important:
The reason why I want to encrypt gd files is to make it harder for players to do simple tweaks that would give them more rewards than they should get (eg: changing a reward from 2 gems to 200000 gems). This can be achieved with encrypted gd files. But tbh, I think it would be more efficient if there was a non-blocking method in the source-code to get the crc hash of all assets upon loading the game. With the crc hash, I could upload it to my server and every player login I would check if the hash matches to allow them access to participate in the leaderboards. If they change any asset, they would get a hash mismatch when sending scores to the server and would not be trusted in the leaderboards.
The text was updated successfully, but these errors were encountered:
I compiled Godot with and without encryption key and exported my game. Run md5sum check against binaries and pack files. The binaries are different, while the checksum of packs remained the same... So it does nothing at the moment, but at least scripts are compiled. Tested in Godot 3.1 alpha 3.
I suspect the functionality is there but somehow it got lost during ExportPlugin rewrite or something.
i'm just curious myself. is the difficulty of editing a value in a compiled script (your gem reward example) easier than an encrypted one? i assume the player would have to extract the .pck file and re-insert the modified .gde or .gdc back to the .pck file?
That put aside, Godot does compile GDScript to bytecode by default in exported projects. You can also encrypt it with a 256-bit key.
if gdscript is compiled to bytecode already, how long would it take to decompile it as compared to encryption code? decompiling encryption code is FAR longer and more "secure"? if i got that right?
problem is, i don't understand the level of divergence here. when does it become "takes 100 years to decompile compared to 100000 years", but the developer must spend tons of more time just to do the latter, when the former is more than enough for a human lifetime? when does it become worth it, and when does it become not worth it?
Remotely related to #2131
Godot version: 3.0 and 3.1
OS/device including version: Any
Issue description: No current editor option to generate ".gde" files (encrypted GDScript) despite having functionality for reading it in the source code.
More details:
You can compile the editor with a SCRIPT_AES256_ENCRYPTION_KEY env variable. This is used in the source-code as a key to open ".gde" files. You can go here for more details: https://godotengine.org/qa/14680/can-we-ship-compiled-gdscript-files
Apparently, Godot 2.0 had an option to export .gd files as .gde, but I don't see that anywhere in Godot 3.0 nor 3.1. I'm suspecting this could be a bug (missing settings option in the editor).
[Off-topic] My reason why I find that important:
The reason why I want to encrypt gd files is to make it harder for players to do simple tweaks that would give them more rewards than they should get (eg: changing a reward from 2 gems to 200000 gems). This can be achieved with encrypted gd files. But tbh, I think it would be more efficient if there was a non-blocking method in the source-code to get the crc hash of all assets upon loading the game. With the crc hash, I could upload it to my server and every player login I would check if the hash matches to allow them access to participate in the leaderboards. If they change any asset, they would get a hash mismatch when sending scores to the server and would not be trusted in the leaderboards.
The text was updated successfully, but these errors were encountered: