Possibly for QSB - Identifying mod dependencies

[mh]

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.

No, I understand what you meant, that's cool.

Where I'm coming from is the perspective of a player who's not so familiar with stuff. This hypothetical person might be using TurboUtterMegaNutterBastardQuake version 13.666 which won't be on the list of engines (99% of which will be Enhanced GL or Fitz) and might therefore get the idea that TUMNBQ can't run the mod.

[frag.machine]

player who are not familiar with stuff are unlikely to peek on configuration files unless something is not working, you know - and sometimes, not even on this case. But it's ok, we are just throwing ideas around here.

[dreadlorde]

Too bad we can't statically link mods.

[Teiman]

Too bad we can't statically link mods.

You can, on these that are GPL in all his files. But is something that work differently in Linux and Windows, seems, as a windows exe somehow has teh limitation that can't open itself, so can't read from itself the pack.

[mh]

You can embed it as a binary resource though; only needs 4 lines of code to load it:

Code: Select all

int Sys_LoadResourceData (int resourceid, void **resbuf)
{
   HRSRC hResInfo = FindResource (NULL, MAKEINTRESOURCE (resourceid), RT_RCDATA);
   HGLOBAL hResData = LoadResource (NULL, hResInfo);
   resbuf[0] = (byte *) LockResource (hResData);
   return SizeofResource (NULL, hResInfo);
}

Of course platform-independent code would be preferable, but sometimes you just gotta roll with what works.

[frag.machine]

So, regarding the mod.dep... Are you going to implement it or will wait for DN4, I mean, QSB 1.0 to arrive ?

[Team Xlink]

Most PSP Quake engines already have something that resembles this.

It is differn't but it could be adapted.

Psp Quake cant run a batch file to use command line parameters like windows can.

To fix this the engine calls for a file called quake.cmdline and uses that nstead of a batch file.

It could be adapted.

Quake.cmdline can be opened in notepad as well. Its essentially justy a txt fiel with a differn't file extension.

This way would be OS neutral.

[r00k]

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?

I was thinking at first you meant engine features required by the mod and how the engine could determine if said requirements are available, yet you are also asking to encompass media from other mods, that are also depended apon. Sheesh! Maybe a mod.req file in the gamedir, that is parsed by the engine at load time if gamedir isn't id1? This can be a tokenized ascii file that could create a check list for the engine to tally up requirements and what to do if something errors out. For example:

mod.req:

%%rouge //tells the engine we need this mission pack to proceed
%%mymod //tells the engine to double check to use this gamedir for the progs.dat (etc.)

##max_edicts 1024
##max_dynamic_lights 1024
##max_temp_entities 1024

^^movetype_follow //define engine extension requirements (via check extension ?)


I dunno, i'm just rambling at the top of my head.