Possibly for QSB - Identifying mod dependencies

[mh]

I'm posting this here as it seems most appropriate for Engine Programming, although I'm going to put a link to it in the main QSB thread.

How do we go about identifying mod dependencies in a nice clean and compatible fashion? I'm talking about a mod that requires 1 or more of Hipnotic, Rogue, Nehahra or Quoth to run. Try to run without them and you'll most likely crash.

There are also mods that actually crash if one of these is used. I've seen ARWOP for example crash if Quoth is used with it.

Currently the only thing we have is a readme.txt, but people in general don't read documentation. There must be a better way.

This needs to be in the engine; it can't be QC because not every mod has a progs.dat: it's possible for a mod to require the Hipnotic progs.dat but not provide one of it's own, for example.

Any thoughts?

[frag.machine]

We could create some sort of optional manifest file to declare dependencies. A simple key=value file, much like the good ol' .ini files on the mod root folder. The engine parse it and resolve any dependencies.

Code: Select all

requires=hipnotic,rogue


[mh]

Better yet, rather than inventing yet another new format and having to write yet another new parser for it ( ), something that can be parsed by COM_Parse.

Code: Select all

"key" "value"

[Teiman]

I think the existence of a float variable in progs.dat can be enough.

float REQUIRED_HYPNOTIC = 1;

...but compilers may "optimize" this constant removing it, so I dunno.

The rationale of having a contant in the progs.dat is that new engines can detect the contant and warn the user "This mod requiere Hypnotic, pack you are not using" or something like that, possible try to fix it silently if possible.

Old engines will just ignore the constant.

Maybe the idea of a manifest is better, since this manifest can be added to old mods, distributed separatelly,..etc.

[mh]

I think the existence of a float variable in progs.dat can be enough.

float REQUIRED_HYPNOTIC = 1;

...but compilers may "optimize" this constant removing it, so I dunno.

The rationale of having a contant in the progs.dat is that new engines can detect the contant and warn the user "This mod requiere Hypnotic, pack you are not using" or something like that, possible try to fix it silently if possible.

Old engines will just ignore the constant.

Maybe the idea of a manifest is better, since this manifest can be added to old mods, distributed separatelly,..etc.

The mod may not have a progs.dat...

[frag.machine]

Better yet, rather than inventing yet another new format and having to write yet another new parser for it ( ), something that can be parsed by COM_Parse.

Code: Select all

"key" "value"

Only if you want, since there are Windows API that already does this work for you, right ? And even in the case of other platforms, parsing a key-value file is not exactly a daunting task.
Anyway, it's just an implementation detail, the main idea of a manifest file in the root of the mod not only works to solve this problem but can be extended to add more lacking required setup functionality (like required command line parameters).

[Teiman]

Better yet, rather than inventing yet another new format and having to write yet another new parser for it ( ), something that can be parsed by COM_Parse.

Code: Select all

"key" "value"

Only if you want, since there are Windows API that already does this work for you, right ?

The OS dependant part of quake is really small, It will be good to stay that way, since It able to migrate the game to new platform, new OS's, and new windows versions. Any code "OS neutral" is prefered.

Another reason to want as less OS dependant code, is that there must be a game that work on all computers of the world, and such game is Quake. Quake must stay has the last resort for gamers in anything that resemble a computer and can compile C.

[frag.machine]

Better yet, rather than inventing yet another new format and having to write yet another new parser for it ( ), something that can be parsed by COM_Parse.

Code: Select all

"key" "value"

Only if you want, since there are Windows API that already does this work for you, right ?

The OS dependant part of quake is really small, It will be good to stay that way, since It able to migrate the game to new platform, new OS's, and new windows versions. Any code "OS neutral" is prefered.

Another reason to want as less OS dependant code, is that there must be a game that work on all computers of the world, and such game is Quake. Quake must stay has the last resort for gamers in anything that resemble a computer and can compile C.

As I stated in the non-quoted part: "And even in the case of other platforms, parsing a key-value file is not exactly a daunting task. ". So, consider the use of the INI Windows API only a lazy man option

[mh]

Even so, I'd still vote for Quake's COM_Parse API. Why? Quite simple - it's the standard format for all text files in Quake; configs, entities, maps, saves and everything goes through it. Any new text file should use the same standard format unless there is a really good reason not to (and preferring ini file or any other format is not a really good reason).

[frag.machine]

As I said before, using COM_Parse() or not is secondary here - the important part is the manifest file at mod root folder. So, if nobody has nothing against the main idea here, we should define:

1) a standard file name ?
2) the key(s ?) to define the required mods (and loading order maybe) ?
3) should support command line parameters (overriding user defined ones or not) ?
4) anything else not covered ?

[Spike]

1: $quakedir/$moddir/mod.qmd
$quakedir/$moddir/maps/$mapname.qmd
is my vote.

2:
depend "quoth/pak0.pak" "http://quoth.com/getquoth.zip"
depend "hipnotic/pak0.pak"
depend "hipnotic/"
says: use quoth's pak0.pak (but not random quoth files), hipnotic's pak0.pak, the entire hipnotic gamedir (ignoring pak0.pak as that's already loaded but including pak1 etc), and the default stuff in $enginedir and id1.

fullname "Scourge of Armagon"

Yes, COM_Parse but with each newline terminating the command.

3: Quite frankly, commandline arguments must die. List cvar values, by all means - give it a set+seta directive. I suppose you can add a commandline directive for engines that still require one, but it shouldn't replace one entirely if any arguments were given, append it if one is supplied, as quake generally uses the first argument found for such arguments.

4:
Custom cvars, and which are saved or not
Custom command bindings (for menu).
Additional default bindings?
Where to get the mod from (in the case of clients that don't have it connecting to servers that do, including mirrors).
Where to get dependancies from, including mirrors.
Which protocol to default to, for standard servers.
Which master server to use/or default public servers.
Current version.
Oldest compatible version.
Where to get other maps from (they're large and you may not wish to download all at once).
Required extensions (matched to a list of other clients that are able to run the mod if the current one cannot).

Consider, using a specific mime-type/extension for it and registering it with your browser. The user clicks a link, browser downloads it, and opens it up with the client (app). The client then goes and uses libcurl/wget or whatever, downloads+installs the bits the mod needs but doesn't yet have, and starts it up (note that maps would need to work without requiring their own gamedir, but still depend/suggest upon other mods for progs etc).

But yeah, they should be 'executable' and clickable from your system's application(start) menu. Easy installation is just icing on the cake.

[leileilol]

liblist.gam is my vote.

[frag.machine]

1: $quakedir/$moddir/mod.qmd
$quakedir/$moddir/maps/$mapname.qmd
is my vote.

I'd vote for fixed location and filename, the first because even for mods without a progs.dat is reasonable to assume they have a separated folder, and for the second... let's keep things as simple as possible:

$quakedir/$moddir/<for_god_sake_any_fancy_but_simple_and_unique_name_and_extension_you_guys_think_is_good_enough_LOL>

2:
depend "quoth/pak0.pak" "http://quoth.com/getquoth.zip"
depend "hipnotic/pak0.pak"
depend "hipnotic/"
says: use quoth's pak0.pak (but not random quoth files), hipnotic's pak0.pak, the entire hipnotic gamedir (ignoring pak0.pak as that's already loaded but including pak1 etc), and the default stuff in $enginedir and id1.

fullname "Scourge of Armagon"

Yes, COM_Parse but with each newline terminating the command.

I'm fine with all of that, although COM_Parse can handle multi line entries. I specially liked the idea of hints about the mod webpage and display name, these are cool to have in a mod management menu option. Could be added to this:
author-name "joeblow"
author-contact "joeblow@aol.com"

3: Quite frankly, commandline arguments must die. List cvar values, by all means - give it a set+seta directive. I suppose you can add a commandline directive for engines that still require one, but it shouldn't replace one entirely if any arguments were given, append it if one is supplied, as quake generally uses the first argument found for such arguments.

I dunno. While people hates them, they're useful in a couple situations - for example, defining engine memory limits using this file may become complicated. Also, we should define which configuration source overrides the other, since we are not really dropping command line arguments here.

4:
Custom cvars, and which are saved or not
Custom command bindings (for menu).
Additional default bindings?
Where to get the mod from (in the case of clients that don't have it connecting to servers that do, including mirrors).
Where to get dependancies from, including mirrors.
Which protocol to default to, for standard servers.
Which master server to use/or default public servers.
Current version.
Oldest compatible version.
Where to get other maps from (they're large and you may not wish to download all at once).
Required extensions (matched to a list of other clients that are able to run the mod if the current one cannot).

Consider, using a specific mime-type/extension for it and registering it with your browser. The user clicks a link, browser downloads it, and opens it up with the client (app). The client then goes and uses libcurl/wget or whatever, downloads+installs the bits the mod needs but doesn't yet have, and starts it up (note that maps would need to work without requiring their own gamedir, but still depend/suggest upon other mods for progs etc).

But yeah, they should be 'executable' and clickable from your system's application(start) menu. Easy installation is just icing on the cake.

That's a lot of options, I need to think about.

A very essential thing:

engine_supported "Darkplaces" "DirectQ" "FitzQuake"

The mod could give hints about the expected external texture support behavior by the engine, like this:

texture_required_exts "tga" "jpg" "pcx"
texture_map "gfx/maps"
texture_sky "gfx/env"
texture_model "gfx/skins"
texture_luma_mask "%s_luma.%s"
texture_alpha_mask "%s_alpha.%s"

In other worlds, no more mods tied to engine X because all textures uses its engine naming and path conventions.
The same idea can be used with other artwork resources, like non-standard models formats (.md2, .md3), soundtracks, etc.

[mh]

"$quakedir/$moddir/mod.dep"; "mod" because it's a mod, "dep" because it's short for "dependencies".

I don't see a reason for having a map dependencies file, unless someone is putting all of their stuff into ID1. Actually scratch that, I do see a reason.

Great idea about the external texture name formats notification, that seems probably the best way to work around all the non-standard practices we currently have.

Maybe include a recommended -heapsize, so that the engine can warn the player "you don't have enough memory to run this".

Instead of recommended engines I'd just include binary flags indicating if large map support or other special behaviours are required. Reason why is that engines evolve, and "engine A" that doesn't support a mod today might well support it in 6 months time. Plus I suspect that a high percentage of a mappers recommendations might be based on personal preference rather than actual capability.

[frag.machine]

The engine thing wouldn't prevent one running the mod in a non-listed engine, I imagined something in the line of a warning stating "this mod is guaranteed by the author to run in the following engines" and that's it.