[ZScript] Custom libraries - handling "class already exists"

[Gutawer]

So, I'm building a GUI system in ZScript which I plan to use in a few projects that should be compatible with each other. My current approach is to create a folder for the library inside the mod archive, and #include it in the main ZScript file, which works fine for singular mods.
However, I've run into a problem regarding multiple archives using my library - If archive 1 contains my library, and so does archive 2, archive 2 will contain identical class names to 1, causing GZDoom to not load with a "class name already exists" error. So I'm trying to work out a reasonable workaround for this problem, which also needs to keep backwards compatibility (i.e. if archive 1 contains 2.0 of my library, but archive 2 contains 1.3, archive 2 cannot use 2.0 as it will have breaking changes).
If anybody's got any ideas, please put them here. Any solutions would be much appreciated!

[ZippeyKeys12]

Honestly, the only solution I see right now is having the GUI system as a separate archive.
If it is possible to execute arbitrary lumps or conditional #include, then I would have a lump(GUTAGUIVERS with a header with the version name) in each archive and cycle through them, find the compatible version and execute the rest of the file.

[Major Cooke]

Have to agree here. You'll pretty much be giving this to all mods and instructing them to include a copy. You can use the auto load feature inside the gameinfo to at least save them the hassle of having to load it themselves at a minimum, but that's all you can do.

Although this makes me wonder if other mods will attempt to load it again once it's already loaded, should it find

Code: Select all

Load = "ZForms.pk3"

in multiple archives...

Alternatively, you hand out instructions for everyone to go through the files and apply a prefix of some kind to all the classes. I.e. when you release it, it's prefixed with ModName_

Then just instruct everyone to replace that ModName part with something else and incorporate the whole thing in. That will guarantee removal of incompatibilities for that particular scenario.

[Gutawer]

Alternatively, you hand out instructions for everyone to go through the files and apply a prefix of some kind to all the classes. I.e. when you release it, it's prefixed with ModName_

Then just instruct everyone to replace that ModName part with something else and incorporate the whole thing in. That will guarantee removal of incompatibilities for that particular scenario.

This is what I ended up planning to do, though I'm planning to automate it with a python script rather than ask people to add a prefix manually.

[Graf Zahl]

I think one option would be to flag a lump if it already got included and refuse to process it a second time. That would allow two libraries to pull in the same code without a collision.

[Major Cooke]

That is, if they don't take the contents and put it in their own mods. That would indeed allow a redistributable to work with the 'load' GAMEINFO command.

[Gutawer]

The major issue I can see with that would be backwards compatibility (or a lack of it). If mod A needs version 1, but mod B needs version 2, loading mod A's version of the lump and ignoring mod B's version will cause a startup error due to stuff like API differences. Of course there's a solution in "be completely backwards compatible" but I think what we can all see with Doom source ports' own struggles to maintain that is enough to discard it if its not completely necessary .

[Graf Zahl]

If you create a dependency issue there's no way to combine two mods. This has been an unsolved problem for operating systems which had decades to think about the issue - and so far no good solution has been found.