InsideQC Forums

You've got a mod ...

And it supports single player and maybe a bots version and if you are particularly creative maybe a 3rd version that supports who knows.

Do you want to distribute awkward zip files with 3 gamedirs ... because standard Quake would require 3 different progs.dat in 3 different gamedirs?

Adding sv_progs capability to GLQuake/WinQuake

DarkPlaces has had this for over 4 years, no doubt some others.

1. sv_main.c

a. Right after "server_static_t svs;" at the top, add:

Code: Select all

cvar_t  sv_progs = {"sv_progs", "progs.dat" };

We need to define the new cvar.

b. Right after "Cvar_RegisterVariable (&sv_maxspeed);", add:

Code: Select all

Cvar_RegisterVariable (&sv_progs);

This registers it.

c. Find this and add the yellow

// load progs to get entity field count
PR_LoadProgs (sv_progs.string);

We aren't just calling PR_LoadProgs anymore, but telling it what the "progs.dat" name is.

2. progs.h

Find this and insert the yellow text replacing the word "void":

void PR_LoadProgs (char *progsname);

3. pr_edict.c

Goto PR_LoadProgs and make yellow changes:

void PR_LoadProgs (char *progsname)
{
int i;

// flush the non-C variable lookup cache
for (i=0 ; i<GEFV_CACHESIZE ; i++)
gefvCache.field[0] = 0;

if (!progsname || !*progsname)
Host_Error("PR_LoadProgs: passed empty progsname");

CRC_Init (&pr_crc);

if (!(progs = (dprograms_t *)COM_LoadHunkFile (progsname)))
Sys_Error ("PR_LoadProgs: couldn't load %s", progsname);

Con_DPrintf ("Programs occupy %iK.\n", com_filesize/1024);

for (i=0 ; i<com_filesize ; i++)
CRC_ProcessByte (&pr_crc, ((byte *)progs));

// byte swap the header
for (i=0 ; i<sizeof(*progs)/4 ; i++)
((int *)progs) = LittleLong ( ((int *)progs) );

if (progs->version != PROG_VERSION)
Sys_Error ("%s has wrong version number (%i should be %i)", progsname, progs->version, PROG_VERSION);

if (progs->crc != PROGHEADER_CRC)
Sys_Error ("%s system vars have been modified, progdefs.h is out of date", progsname);

pr_functions = (dfunction_t *)((byte *)progs + progs->ofs_functions);

All we did was replace the instances of "progs.dat" with "%s" and sprintf the progsname in there.

Plus an empty progsname check.

In Closing

Now you could create a readme.txt with

=============
My Readme.txt
=============
glquake -game mycastle +map mycastle
...
( description of mod )
...

We also included a bots version and a dmsp version. Just type "bots" or "dmsp" in the console to run those.

Requires DarkPlaces or <insert name here>

[Those bots/dmsp aliases would be in the autoexec.cfg, i.e. alias bots "sv_progs bots.dat; disconnect; maxplayers 4; map dm6", etc.]

good, is it also possible to have a command line switch?

AS usual +sv_progs should work?

Spirit wrote:AS usual +sv_progs should work?

That'd work, yes.

c:\quake\<your quake>.exe -game whatever +sv_progs bots.dat

Is it possible to change it through the quake.cmdline file?

If you read the code, you would know the answer is yes.

After a lot of consideration, I think sv_progs is a *bad* idea.

A save game saves to a gamedir. A save game does not know what progs created it.

We currently have a circumstance where aside from DarkPlaces, an engine can't save or load a multiplayer game. So the argument can be made that sv_progs is useful for multiplayer (you could have DM, CTF, CA, Rocket Arena, etc. all as different progs.dat in the same dir).

However, the fact that multiplayer games cannot be saved currently by very many engines is shortsighted. And may not persist as mainstream for any future length of time that will be relevant.

The proper way to re-use content would probably be:
1) Multiple gamedir support where the first gamedir represents the mod and the second gamedir represents the progs.
2) sv_progs if such were stored in a save game file. However, someone would have to devise a backwards compatible save game.
3) This is ignoring the fact that demos don't even know what gamedir or mod they are. Well --- maybe Quakeworld demos do?

Not too certain what the purpose of saving a multiplayer game is - there is just so much that can go wrong on reload that it seems quite a hairy process.

That aside, my humble proposal: instead of a user-settable progs (which may still be retained as an option for modders to switch between progs while testing and without needing to restart the engine - maybe only allow it if developer 1) try for <mapname>.dat, if you don't get that fall back on progs.dat. That seems to make all of the problems go away - the save game knows what map it used, so by default it also knows the correct progs to use, and likewise for demos.

Thanks, Baker. I've implemented this, but with some adjustments to print a console warning and make the engine load the default progs.dat if the specified sv_progs isn't found.
Of course, if progs.dat is also missing, the engine will Sys_Error, but using the sv_progs name in the message.

mh wrote:try for <mapname>.dat, if you don't get that fall back on progs.dat. That seems to make all of the problems go away - the save game knows what map it used, so by default it also knows the correct progs to use, and likewise for demos.

Good idea, but would get messy on map packs, because using the same custom progs on multiple maps would require an individual copy of it for each map. Also, it wouldn't allow for the same map to use different progs for different game modes. Let's say, the mod author could want to make a progs for single player, a progs for multiplayer, a progs for a in-game "start screen" menu (like the one in TAoV), a progs for machinimas, and even stuff like different progs for different difficulty settings.

Saving the current progs name in the saves seems to be a good idea.

multiplayer saving is nice for coop (especially hexen2 with levels and stuff).
fte loads multiplayer games just fine (after I last fixed the thing). it matches players by names, and has to reorder player slots to match the mod to ensure nothing is broken. it is quite hairy (hence why it was broken), so really its only worth it if you support hexen2, but it is possible.
its pointless for deathmatch.

there's a lot of cvars that are easily broken by cvars when saving the game. all those for-the-gamecode cvars will all break over the course of save+quit+newgame+reload.
'sv_progs' really isn't special in that regard. imho my opinion is that the only real issue is that you refuse to change the saved game format. the question is which other cvars do you save?

I would thinK loading a saved multiplayer game would help dev teams bug test
Another task would be to load a demo and run through the measures to test for cheaters
But that would be more in depth...

Typed this only iPhone sorry forteh typoz

mankrip wrote:Thanks, Baker. I've implemented this, but with some adjustments to print a console warning and make the engine load the default progs.dat if the specified sv_progs isn't found.

Baker: I've changed my mind this bad.
MK: Thanks, Baker! I put this in my engine!

I like it

mh wrote:Not too certain what the purpose of saving a multiplayer game is - there is just so much that can go wrong on reload that it seems quite a hairy process.

Some players would kill for this feature. For example: Trying to coop Travail isn't a 30 minute ordeal. Even on LAN, it isn't gonna happen. Multiplayer it could open the door to "scenarios" or the ability to restore a recently disconnected player without foobaring the game and their stats.

Now I'm not pretending this would be easy. It would be extremely hard.

ktpro restores disconnected players. pauses the game and everything. though it is still subject to a timeout (clones the player in clientdisconnect and restores them again if they reconnect. the pausing part is a nasty painful hack though, as the server isn't technically paused).
that doesn't require saved games of course.

Spike wrote:ktpro restores disconnected players. pauses the game and everything. though it is still subject to a timeout (clones the player in clientdisconnect and restores them again if they reconnect. the pausing part is a nasty painful hack though, as the server isn't technically paused).
that doesn't require saved games of course.

Interesting.