Consider Dual License under MIT?

[playmer]

Hi there, I'm looking to document the File Formats of Sonic 06 and contribute some serializers/deserializers to the community projects (in particular Marathon). Somewhat unfortunately this repo seems to be the "Spec" in terms of the file formats at least as far as I'm aware. Unfortunate only in that most of the 06 community work seems to be MIT and this is GPLv3, so it's not possible for me to simple understand your code to write the spec and produce serializers/deserializers and contribute it back to them without GPLv3 kicking in for them.

So I'm hoping you'd be amenable to consider dual Licensing this repo under MIT. If you're not I can simply produce specification documentation for the community to be able to write code against, I'd just rather be able to produce both as I'm writing some code myself to test out my understanding of the formats.

Please let me know either way, thanks for reading!

[DarioSamo]

Hey there.

I don't think it's in the interest of the project to maintain the 06 formats library.

The GPLv3 was mostly intended for the level editor application and the Generations' file formats library. The 06 "library" is just an experiment, but I never had any intention of making them part of the application. However, since it's using some of the LibGens functionality to read and write the files (File class), it's not possible to just grab the files and drop them in another project without it breaking.

Rather than a dual license, I think it'd be best to just re-license those files under another project that uses its own classes for handling the I/O, and remove the files from this project. Nobody actually made any contribution to those files, so I don't need to consult to re-license them if we'd rather choose that option.

[playmer]

Relicensing "LibS06" with changes to remove the LibGens dependencies sounds good to me. What would that process ideally look like to you? Someone grabs those files to make their own Library but removing File (or whatever else is dependent)? Forking this repo, but removing everything else + dependencies and renaming?

Just want to make sure this is as easy as possible for you, I really appreciate the consideration.

[DarioSamo]

Someone grabbing the files under the LibS06 folder and making it its own library and reworking the dependency to the File class sounds good to me.

[playmer]

Great, thanks! I'll work on that when I have time and ping back when it's looking ready. (Probably sometime in the next few days)

[playmer]

I'm still very much in testing, so this will take more time, but I did a first pass at replacing the File.h stuff in the above linked repo/PR. I wasn't sure if you wanted LibGens to eventually start consuming LibS06 from a separate source, so for now it's not replicating things such as FBX loading or DAE loading that I suspect the level editor requires. Please take a look if you have a chance, primarily I'm interested in you being comfortable with File.hpp, as I did have to study bits of FIle.h and File.cpp from LibGens to understand the calls LibS06 was making.

Thanks!

[DarioSamo]

I've had a brief look at your issue, not the code yet. You mention having trouble with the address table, so I'll just give you a brief explanation in case it helps.

The address table in these formats is merely for compatibility with the game, but it's not actually required for LibS06 to read the files properly. This table is the mechanism which the game uses to direct memory loading: Once it loads the entire file into memory as a block of bytes, it (supposedly) casts the block of bytes to the struct/class it represents directly. These structs have pointers inside them, but the addresses inside the file are relative to the start of the file, and they're obviously not pointing to the right address if loaded in memory. The game uses the address table to know all the offsets in the block of bytes that it needs to go to and add the base address of where it is in RAM. We've verified this is how it works in the past with emulators, since extracting the files directly from RAM when they're loaded has all those addresses with way bigger than what the files normally have.

Whether it's necessary to write an address into the table was mostly a matter of just looking at the files and seeing if the offsets were present in the table, but this will only be important if you wish to use your exported files inside one of the games that supports it. LibS06 itself ignores it entirely when parsing the file.

[playmer]

Whether it's necessary to write an address into the table was mostly a matter of just looking at the files and seeing if the offsets were present in the table, but this will only be important if you wish to use your exported files inside one of the games that supports it. LibS06 itself ignores it entirely when parsing the file.

Yeah that's of particular interest to me. So this information is very helpful, I can add some more debugging info with this, thank you!