Game changing - queries

[mh]

OK, I've just written game changing.

Right now though I'm interested in how folks think -rogue, -hipnotic (and any other add-ons) should be handled. Looking at the QRack 1.90 source, for example, I see that -rogue etc are loaded only once at startup, and games are added after that. Obviously because these require a special flag to be set for content to be loaded.

That doesn't bother me too much as I reload all content (including palette, colormap and wad) on a game change.

Way I'm doing it is I have cvars: com_rogue, com_hipnotic, etc, which are set at startup (based on the command-line params) and can also be set during play. Issuing a "game" command will then cause the correct content to be loaded. They're not stored in your config, so if you want to start up in them you can still use the command-line, but you can also switch to them at any time.

I'm wondering though if anyone has any better ideas...?

[metlslime]

I've been planning something similar for a future version of fitzquake. I have come up with two most likely options:

1. game command accepts multiple parameters, loads gamedirs in that order. E.g. "game hipnotic masque" would add id1, then hipnotic, then masque folders to the searchpath. Under this plan, the presence of a mission pack in the search path would also enable the special / alternate code such as HUD layout, and protocol weapon bits. I think darkplaces does this, though the command is called "gamedir" instead of "game".

2. the idea you suggested: add "rogue" and "hipnotic" cvars, these function like -rogue and -hipnotic command line switches. This appeals to me more because it's simpler and corresponds closer to what people understand and expect. It also doesn't involve confusion about the order of gamedirs searching, which could cause some weird bugs. (a file in hipnotic overriding a file in masque, but things seem to work, so a user assumes he did it right)

(Also, while the original game allows -rogue -hipnotic, i think this might be a situation to actively prevent, by setting one cvar to false whenever the other becomes true.)

So, i'm probably doing 2, but i haven't commited yet. Also, since these commands would be used often, i would leave off the "com_" prefix to save typing.

[Baker]

I'm wondering though if anyone has any better ideas...?

As much as we like to think of hipnotic and rogue as special games, it only affects the drawing of the HUD. And menu if you dig deep down, but no one uses that.

common.c(56): qboolean standard_quake = true, rogue, hipnotic;
common.c(1112): if (COM_CheckParm ("-hipnotic"))
common.c(1114): hipnotic = true;
common.c(1781): if (COM_CheckParm ("-hipnotic"))
common.c(1782): COM_AddGameDirectory (va("%s/hipnotic", basedir) );

Nothing special is going on there ...

host_cmd.c(1546): // MED 01/04/97 added hipnotic give stuff
host_cmd.c(1547): if (hipnotic)

Give command difference.

menu.c(2436): //MED 01/06/97 added hipnotic levels
menu.c(2437): level_t hipnoticlevels[] =
menu.c(2505): //MED 01/06/97 added hipnotic episodes
menu.c(2506): episode_t hipnoticepisodes[] =
menu.c(2622): //MED 01/06/97 added hipnotic episodes
menu.c(2623): if (hipnotic)
menu.c(2624): M_Print (160, 112, hipnoticepisodes[startepisode].description);
menu.c(2632): //MED 01/06/97 added hipnotic episodes
menu.c(2633): if (hipnotic)
menu.c(2635): M_Print (160, 120, hipnoticlevels[hipnoticepisodes[startepisode].firstLevel + startlevel].description);
menu.c(2636): M_Print (160, 128, hipnoticlevels[hipnoticepisodes[startepisode].firstLevel + startlevel].name);
menu.c(2734): //MED 01/06/97 added hipnotic count
menu.c(2735): if (hipnotic)
menu.c(2757): //MED 01/06/97 added hipnotic episodes
menu.c(2758): if (hipnotic)
menu.c(2759): count = hipnoticepisodes[startepisode].levels;
menu.c(2760): //PGM 01/06/97 added hipnotic episodes
menu.c(2821): if (hipnotic)
menu.c(2822): Cbuf_AddText ( va ("map %s\n", hipnoticlevels[hipnoticepisodes[startepisode].firstLevel + startlevel].name) );

List hipnotic maps and episodes in the menu that no one uses.

sbar.c(61): //MED 01/04/97 added hipnotic items array
sbar.c(198): //MED 01/04/97 added new hipnotic weapons
sbar.c(199): if (hipnotic)
sbar.c(590): // hipnotic weapons
sbar.c(591): if (hipnotic)
sbar.c(686): if (!hipnotic || (i>1))
sbar.c(694): //MED 01/04/97 added hipnotic items
sbar.c(695): // hipnotic items
sbar.c(696): if (hipnotic)
sbar.c(958): // keys (hipnotic only)
sbar.c(960): if (hipnotic)

Draw the HUD differently.

I slightly oversimplified, but what would be better is to get this removed out of the engine and into the "game logic" where it belongs.

In an ideal world ... but I guess we have to work with this one

[Urre]

/me wonders when someone dares to do a Tenebrae, and just ignore all backwards compatibility, and do their own thing...

I'd support that just for the heck of it.

[leileilol]

/me wonders when someone dares to do a Tenebrae, and just ignore all backwards compatibility, and do their own thing...

I'd support that just for the heck of it.

yeah, because 'no one uses' hipnotic and rogue for anything obviously. not a concern to all those quake 'fans' :roll: all that extra code just wastes space!

[metlslime]

I don't think an engine like that would become more than a curiosity unless enough custom content was created for it, because the only point of an engine (from a user's point of view) is playing content.

[Baker]

I guess to flesh out the rest of what I was saying ...

You can modify models, maps, the QuakeC within a gamedir.

But the HUD remains an engine hard-coding issue unless someone is using CSQC.

And it is a client-server issue, the client doesn't really know what the server is using or what HUD to display. I think the standard sbar is displayed when, for example, a Quakeworld client connects to a server playing a mission pack. A hacky workaround would be for the client to choose the HUD based on the gamedir, but that is also "wrong" because it isn't data neutral. (Even CSQC isn't data neutral unless the client progs is being downloaded when connecting and I don't believe it is).

I understood my post was far out of the scope of what you and MH are thinking.

Things like Kurok and the Solitude project, as well as the 12 different games with hardcoded HUDs and sometimes menus in DarkPlaces plus Nehahra cross my mind.

[mh]

2. the idea you suggested: add "rogue" and "hipnotic" cvars, these function like -rogue and -hipnotic command line switches. This appeals to me more because it's simpler and corresponds closer to what people understand and expect. It also doesn't involve confusion about the order of gamedirs searching, which could cause some weird bugs. (a file in hipnotic overriding a file in masque, but things seem to work, so a user assumes he did it right)

(Also, while the original game allows -rogue -hipnotic, i think this might be a situation to actively prevent, by setting one cvar to false whenever the other becomes true.)

I have this up and running at present, and so far it seems fine. Agreed in principle on the "com_" prefix, but at the same time I'm wondering if (1) a prefix of some sort would be of assistance to the player in terms of making it easier to identify what the cvar does, and (2) any decent autocompletion system would alleviate the typing burden. No matter though, I'm not exactly militant about cvar naming!

Your second point is interesting and is something I had considered also. In the end I decided to just do what the original engine did, purely on account of the fact that there may be mods somewhere that depend on it (e.g. for mixed rogue/hipnotic content such as mdls).

[Baker]

I'm wondering though if anyone has any better ideas...?

Alternate idea ... after poking around the ZQuake source code ...

Determine if the mod is hipnotic or rogue by trying to load an sbar element out of gfx.wad.

I saw that ZQuake stops trying to load hipnotic sbar elements if the first one fails ...

Code: Select all

/*
===============
Sbar_RegisterHipnoticPics
===============
*/
void Sbar_RegisterHipnoticPics (void)
{
	int i, j;

	hsb_weapons[0][0] = R_CacheWadPic ("inv_laser");
	// quick check to see if it's the hipnotic wad
	if (!hsb_weapons[0][0])
		return;

So you could test for "inv_laser" and if true, set hipnotic = true.

And for rogue, try to load up "r_invbar1" and if so, set rogue= true.

Code: Select all

	if (rogue)
	{
		rsb_invbar[0] = Draw_PicFromWad ("r_invbar1");

There is little point to trying to trying to draw either of these sbars if the pics aren't in the wad

[Spike]

FTE works out which mission pack is in use for the hud based on which images it could load from the current gfx.wad. If you have the rogue/hipnotic images in there then chances are you want the related hud. Setting the gamedir on the server changes the gamedir on the client, which reloads the gfx.wad/hud, supposedly.

However there are a couple of mods that require '-hipnotic -game blah' in order to work properly. Anything that uses the gremlin model for instance.
Its very tempting to add support for 'gamedir hipnotic:blah' in the same way that telejano supports a datadir type command line argument.

There is only one other difference than hud - protocol. Regular quake sends a bitmask for the active weapon. One of the mission packs sends an index. This isn't relevent in QuakeWorld/Darkplaces due to the revised protocols(specifically stats). But can affect NQ clients with differing gamemodes. This is particularly painful as it affects the server too. But the gfx.wad can be tested there too.

Mission packs are in no other way special.
Checking the wad means your users don't need to remember to change cvars as well as gamedir. Automation is simplification, as far as the user is aware.

[leileilol]

The mission packs have new particle effects builtins too btw

[Spike]

Although those tempentity effects do not alter based on mission pack, and are thus unconditionally available to all mods should they wish to use them.

[mh]

Thinking more about this, what needs to be achievable is a means of allowing the equivalent of "-rogue -hipnotic -game myqchack" from the console, at a bare minimum. It's what ID Quake does, so anything less is a potential breaking change. I'd add "-quoth" to any general purpose engine so that it can support mods which also require Quoth.

I don't see checking in gfx.wad as a viable solution. It will only work if the correct gfx.wad is loaded, but how do you tell the engine to load the correct one in the first place? In other words it's valid as a means of automatically setting the boolean flag, but it's jumping one step ahead of itself. A mod may not even provide it's own gfx.wad but rely on the hipnotic one.

Messing with cvars - accepted, it's something for the user to have to remember to do, but so is adding "-rogue" or "-hipnotic" to the command-line. Sticking them in a menu as toggle-able options seems reasonable enough to me. It could also be accomplished with commands, but we're in the same territory - the user has to remember to either issue the command or set the cvar.

[Baker]

I don't see checking in gfx.wad as a viable solution. It will only work if the correct gfx.wad is loaded

How would you draw inv_laser for someone using com_hipnotic 1 if the hipnotic gfx.wad isn't being used?

how do you tell the engine to load the correct one in the first place?

I believe the order of prioritization that any engine uses is id1, <mission pack>, <gamedir> ... whichever is found last is what is used.

Anything in the gamedir overrides all, etc. etc.

[mh]

I don't see checking in gfx.wad as a viable solution. It will only work if the correct gfx.wad is loaded

How would you draw inv_laser for someone using com_hipnotic 1 if the hipnotic gfx.wad isn't being used?

Easy enough. com_hipnotic 1 is only checked when the filesystem is loaded, and the sbar pics are reloaded along with everything else. Much the same as "-hipnotic" on the command-line only it can happen at run-time as well as during startup (this ain't just theoretical talk by the way, I have this running cleanly in code right now).

how do you tell the engine to load the correct one in the first place?

I believe the order of prioritization that any engine uses is id1, <mission pack>, <gamedir> ... whichever is found last is what is used.

Anything in the gamedir overrides all, etc. etc.

Not quite "override", more that the directories are combined into multiple search paths, which are then searched in order. So the search order is <-game>, then <-hipnotic>, then <-rogue>, finally id1. If something isn't found in the first, it searches the next, and so on until it runs out of search paths. Because they're added to a linked list, they get added in reverse order to that which they are searched in.

Anyway, the question I was asking there was how to tell the engine to load the correct gfx.wad during a run-time game change event. We must assume that whatever was on the command-line at startup is no longer valid, e.g. if the player wants to switch from hipnotic to rogue. We must also assume that the player might want to switch to a mod that requires the hipnotic (or rogue) gfx.wad content but that doesn't provide a gfx.wad of it's own.