Support PK3 files with a different, new extension (e.g. .ojk)

[mrwonko]

OpenJK adds new features for mods to take advantage of - in particular I'm thinking of cvars being from Icarus (only in SP?) - and may add more in the future. Mods using these features won't work in base JKA, but that is usually not obvious to the user.

To mark these mods as incompatible with base, they could use a different extension (while still being zipped like .pk3 files), for example .ojk. To this end, OpenJK would have to actually mount files with this extension.

This would also be an opportunity to introduce some metadata to mods - i.e. have the archive include a file of a specific name containing the mod's name, author, version, license and possibly dependencies and incompatibilities - which could be made mandatory in files with the new extension.

[deepy]

I'd like to see metadata contain what the lowest openjk version required for running it is.
Also nice would be an optional URL entry/object containing author's website and possibly an URL for mod managers to fetch newer versions from.

[mrwonko]

OpenJK version makes a lot of sense.

As for the format, if we don't want to write a parser json is an option, there's dropbox's lean json11 C++11 library for that - although I understand we may still be running on/supporting pre-VS2013? (If so, why? VS2015 is out!)

[eezstreet]

Would the Metadata be built into the format itself, or be a file within the archive itself? (Like .meta or something). Also, /support

Sent via the Samsung Galaxy S® 5 ACTIVE™, an AT&T 4G LTE smartphone

-------- Original message --------
From: Willi Schinmeyer [email protected]
Date: 08/19/2015 4:21 AM (GMT-05:00)
To: JACoders/OpenJK [email protected]
Subject: Re: [OpenJK] Support PK3 files with a different, new extension (e.g. .ojk) (#706)

OpenJK version makes a lot of sense.

As for the format, if we don't want to write a parser json is an option, there's dropbox's lean json11 C++11 library for that - although I understand we may still be running on/supporting pre-VS2013? (If so, why? VS2015 is out!)

---

Reply to this email directly or view it on GitHub:
#706 (comment)

[deepy]

It would be in a file in the archive itself, think of Java's manifest.mf.
On second thought. Maven's pom.xml is probably a better example

[ensiform]

Is there any way we can still have them be normal pk3s but contain the extra metadata maybe?

[mrwonko]

They would still be normal pk3s in all but extension - but since the point is for base jka to not load them, they can't be .pk3.

[ensiform]

Would prefer to keep the extension

[mrwonko]

Why? The point is to be incompatible.

[mrwonko]

Outside of the required openjk version the meta data could also optionally include a required mod & its version (e.g. "this is for movie battles version 2.1+").

Actually, that may cause trouble with forks - maybe opengl style extensions would be better, like "requires icarus cvar support 1.0 and rend2."

[mrwonko]

This actually also is an issue with save games, since the scripts are embedded in them. So there should probably also be a different .ojksav format for those. (Backwards compatibility with normal .sav would of course be required.)

The only question is: do we need/want to save conditionally, using the new format where required and the old format otherwise? That would be quite a bit of work, I'm inclined to exclusive save as .ojksav.

[mrwonko]

So I'm thinking about the capabilities/extensions handling; i.e. a mod requiring certain engine/game/cgame/ui/renderer features. These should really be defined in the appropriate code, like having an export from the cgame library to report its supported extensions.

This would require a VM start during FS_Startup, which seems icky... And we also run into a chicken-egg-problem: What if the libraries are themselves in a .ojk file? That makes sense if they require OpenJK.

The question thus is: How does a mod advertise its extensions? Maybe a better solution is a description.txt-style plain file in the mod directory? But I'd really rather have it in the code, since it describes the code... We could have yet another archive format for the libraries, but that's ugly as well...

[mrwonko]

Maybe a loose file is best after all, that way a possible future mod manager could also easily read it and warn users about incompatibilities.

[mrwonko]

Capabilities should use semantic versioning, so we'd have a mapping from feature to version.