serialize into ModData and ModDetails

[Qubus0]

for better type safety and convenience

this is only internal, nothing needs to be changed in mods.

@ithinkandicode check if this works for you to also integrate the config stuff

also closes #54

[ithinkandicode]

What's the difference between mod_details.gd and mod_data.gd? It looks like there's code for validation in both, would all the mod-specific stuff be better in a single file instead of split across two?

It might also be helpful to include a comment at the top of those files stating what their purpose is. Generally I think all funcs can benefit from comments, esp. if you're not familiar with the codebase.

For static funcs, would they be better being visually separated from the non-static funcs? Ie. you could move them down the file into their own section with comment headings. Eg. I used this approach throughout mod_loader.gd (eg here):

# Static Funcs
# =============================================================================

[Qubus0]

oh totally forgot to sort them again. will also add comments
ModDetails stores and validates all the content from the manifest, while ModData stores and validates everything needed to properly load the mod

[ithinkandicode]

This is amazing work, well done Ste! 🏆

I only have a few minor points: Potentially change a class name, and make the logging consistent

[ithinkandicode]

Is it possible to show the mod name? That would make debugging much easier, esp. for logs like this which atm don't tell you which mod they're for

[Qubus0]

good point, will do

[Qubus0]

will wait with merging until we have a logger class with static methods to log from, as those seem to work in engine and exported and with automatic setup.

[ithinkandicode]

Looks good to me. Like you said, there's a few bits left to do, but they can be raised in a subsequent PR

[ithinkandicode]

@Qubus0 I don't think we should use godot 4 documentation comments yet. The VS Code plugin for Godot already shows comments, but it doesn't handle the ## version correctly.

Eg this uses the normal # comment:

But it becomes this if you use ## for comments:

So I think we should hold off on using them until the plugin is fixed

comments issue

[Qubus0]

hm that's a bummer. I guess it also doesn't handle the bbcode references to classes and methods? Looks like it's treating two ## as markdown heading

[ithinkandicode]

I think everything I mentioned before has been sorted here

And again, really great work Ste :)

[MythicManiac]

Does this account for leading zeroes? e.g. 01.01.01 should probably be disallowed

[Qubus0]

@MythicManiac not yet, but I can add it. Probably should also disallow numbers over 999, since right now versioning a la LaTeX is still possible (0.3.1415, adding a digit of pi for every update)