Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Possibly for QSB - Identifying mod dependencies Goto page 1, 2 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Wed Mar 17, 2010 9:33 pm Post subject: Possibly for QSB - Identifying mod dependencies |

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?
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 12:17 am Post subject: |

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:
requires=hipnotic,rogue

_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Mar 18, 2010 4:04 am Post subject: |

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:
"key" "value"

_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Thu Mar 18, 2010 9:46 am Post subject: |

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.

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Mar 18, 2010 10:11 am Post subject: |

Teiman wrote:
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...
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 12:10 pm Post subject: |

mh wrote:
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:
"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).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Thu Mar 18, 2010 1:01 pm Post subject: |

frag.machine wrote:

mh wrote:
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:
"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.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 2:41 pm Post subject: |

Teiman wrote:

frag.machine wrote:

mh wrote:
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:
"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
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Mar 18, 2010 2:48 pm Post subject: |

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).
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 4:19 pm Post subject: |

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 ?
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Mar 18, 2010 5:25 pm Post subject: |

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.
_________________
What's a signature?

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Thu Mar 18, 2010 6:37 pm Post subject: |

liblist.gam is my vote. _________________

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 8:11 pm Post subject: |

Spike wrote:
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>

Spike wrote:
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"

Spike wrote:
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.

Spike wrote:
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.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Thu Mar 18, 2010 8:47 pm Post subject: |

"$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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Mar 18, 2010 11:44 pm Post subject: |

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. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group