GDScript support - Githubissues

kaitai-io / kaitai_struct

Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby

https://kaitai.io

4.03k stars 198 forks source link

GDScript support #1016

Open Ithamar opened 1 year ago

Ithamar commented 1 year ago

I've started experimenting with adding GDScript support, the scripting language used by the Godot Engine.

Specifically, the GDScript implementation in the 4.0 version of the engine, since that has had many performance improvements over the 3.x branch, making it useable for doing more then basic game scripting. And before someone mentions it, I'm aware there is C# support for Godot and Kaitai, but GDScript is the default and very popular with Godot users.

I've done a basic proof-of-concept implementation in the compiler, and a minimal struct implementation. I'll need to clean it up before posting a pull request, but I'm hoping to do that soon.

Just posting this issue to raise awareness that this is being worked on.

Ithamar commented 1 year ago

So I have a good amount of functionality working, lots of my game asset ksy's load fine. The main issues I've encountered so far are:

I have not found a good way to do error handling. It looks like GDScript has no concept of "exceptions" or something similar. The best I've come up with so far is keeping an error state is KaitaiStruct / KaitaiStream, but I'm still hoping to find something better.
Many, many naming conflicts. It seems I happily used typenames like animation, texture, vector3i, etc, which ends up colliding with standard Godot classes/types. Since there is no namespace support in GDScript, I've resorted to adding a (KT) prefix to all generated classnames.

These are the biggest issues I've found so far, I'm sure there'll be plenty of smaller ones to sort out before it is really ready, hoping to start looking at running the test suite over the weekend, so I can get a proper overview of the amount of issues left.

GreyCat commented 1 year ago

Sounds like a real good progress! For error handling — you can always opt to return an error code rather than throwing an exception. Sure, the code will be bulky, but given it's all generated, probably nobody cares. You can take a look at how it's implemented in golang.

Resolving conflicts with prefixes/suffixes also seems to be a good idea.

Ithamar commented 1 year ago

Sounds like a real good progress! For error handling — you can always opt to return an error code rather than throwing an exception. Sure, the code will be bulky, but given it's all generated, probably nobody cares. You can take a look at how it's implemented in golang.

Thanks for the pointer, I'll take a look! My main worry here is performance, with an extra check for every read, but I'll do some profiling and see how that turns out. Had profiling on my TODO list anyway ;)

Resolving conflicts with prefixes/suffixes also seems to be a good idea.

Yeah, really the only way I guess. Would it be acceptable to have a configurable, but default prefix for all classes? I see most namespace options for other languages are optional, but I think in this case making one default just makes sense, as I'm sure anyone using GDScript would hit the issue anyway, and then has to figure out how to fix it manually.