Game changing - queries
Game changing - queries
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...?
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...?
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.
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.
Re: Game changing - queries
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.mh wrote:I'm wondering though if anyone has any better ideas...?
Nothing special is going on there ...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) );
Give command difference.host_cmd.c(1546): // MED 01/04/97 added hipnotic give stuff
host_cmd.c(1547): if (hipnotic)
List hipnotic maps and episodes in the menu that no one uses.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) );
Draw the HUD differently.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)
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
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!Urre wrote:/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.
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.
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.
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!metlslime wrote: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.)
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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Game changing - queries
Alternate idea ... after poking around the ZQuake source code ...mh wrote:I'm wondering though if anyone has any better ideas...?
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;
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");
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.
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.
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
How would you draw inv_laser for someone using com_hipnotic 1 if the hipnotic gfx.wad isn't being used?mh wrote:I don't see checking in gfx.wad as a viable solution. It will only work if the correct gfx.wad is loaded
I believe the order of prioritization that any engine uses is id1, <mission pack>, <gamedir> ... whichever is found last is what is used.how do you tell the engine to load the correct one in the first place?
Anything in the gamedir overrides all, etc. etc.
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).Baker wrote:How would you draw inv_laser for someone using com_hipnotic 1 if the hipnotic gfx.wad isn't being used?mh wrote:I don't see checking in gfx.wad as a viable solution. It will only work if the correct gfx.wad is loaded
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.Baker wrote:I believe the order of prioritization that any engine uses is id1, <mission pack>, <gamedir> ... whichever is found last is what is used.how do you tell the engine to load the correct one in the first place?
Anything in the gamedir overrides all, etc. etc.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for