a + b ≠ b + a [difficulty level setup]

Quake
1

In some custom maps - particularly those missing the ‘Quake style’ “organic”] difficulty level selection - the difficulty level, has to be set up through the engine command console; unless otherwise solved through assistant software of sort. It came to me that certain maps slightly differ in details, depending on what kind of difficulty level was selected for them to work with. Namely, some maps on “hard” difficulty level, will spawn more enemies, than it would be the case if the difficulty was “normal” or “easy”.

If the difficulty level is selected after the map has already been loaded, with high probability the map standard - in terms of enemy spawns - will respond to default difficulty level, given for that map; the manually selected difficulty level, will only affect present enemy capabilities, I suspect. Therefore, either the difficulty level ought to be selected before the map is loaded; or the map should be reloaded, if the difficulty was selected afterwards.

By the way, this is not my first post on the ‘Quaddicted’ portal - I have posted as a guest thusfar - but hi folks anyway.

2

Yes, usually if map has no skill selection, you’re supposed to set skill in the console by typing “skill X”, then “map mapname” to play it.

The other way is to add these to command line, usually like so: “quake.exe -hipnotic -game gamename +skill X +map mapname”, where:

-hipnotic - optional command if the map/mod requires Scourge of Armagon (I’m not familiar with any maps requiring Dissolution of Eternity)
gamename - name of the mod directory, if different from id1 (some maps were released like that but still lacked the ‘start’ map, for example alk15 “Brumal Quest”)
mapname - name of the map file
X - skill level value; 0 = easy, 1 = normal, 2 = hard, 3 = nightmare.

Some maps don’t even support different skill settings at all or are designed for single particular skill setting, in that case it’s generally mentioned in the readme or supplied TXT file. And yes, skill must always be set before loading a map, that’s how the game’s engine works.

Skill setting affects only the entities that spawn - like monsters and items, and once the level is loaded and entities are spawned in it, they can not be changed until level is restarted. In rare cases, several triggers are also affected by skill level. A good example would be E1M3 in base game with the Nailgun room where the bars behind you close and ceiling starts to descend to crush you. On Easy skill the game displays “Shoot the button!” message, but on higher skills it does not. In some other places a monster closet or two will open on higher skill settings.

Skill setting does not change enemy’s health or damage they do, and does not change the amout of ammo player gets from items. The only skill that affects monster behavior is Nightmare - the monsters with ranged attack basically become turrets and will fire continuously as long as player is in their line of sight. You can test this. Observe ogre behavior at beginning of E1M2 on skill 0-2, then set skill to 3 and reload the map. Ogre will now fire grenades non-stop. Now set skill back to 0-2, reload the map, and set skill back to 3 without reloading the level. Ogre behavior will not change to Nightmare.

3

Thanks for the thorough explanation, @Gila. Now it is clear to me that unless the difficulty level is selected before loading up of a level - or having the level restarted - then what applies, is the default difficulty level, even if the engine confirms the newly picked difficulty level by name; which could be misleading. I thought, though, that the enemy stats would change nonetheless - apparently, that was a false assumption; as I doubt there would be any exception in how does the engine behave, between having chosen any common difficulty level and between having chosen a “Nightmare”.

The corrected commandline pattern I use now, looks like that:

[QSS] -heapsize 2097151 -game W -game X +skill Y +map Z

I use “double” game parameter for maps which require custom base of assets, such as ‘Arcane Dimensions’ base or ‘Quoth’ or ‘Copper’. In this case, that base, comes first, then the custom game folder; assuming that both of these are placed parallel to an ‘id1’ folder. Then comes the skill. For the note, ‘Arcane Dimensions’ allows for the skill level of 4, the “Evil”, as an extra. Finally, comes the map name, as recognized by the name of most “telling” BSP entity within the custom game folder - it is always good to read the map description [TXT file], for instructions, per habit.

Earlier, I used to define the skill as the last part within the pattern, which now I know mostly to be wrong. I say “mostly”, because not all the custom games require the map to be selected by name specifically; even though it should be true that if the introductory map - with skill selection - is missing, then also the starting map needs to be pointed to manually; alongside with it, the difficulty level - in correct order.

Thanks for explaining the “hipnotic” parameter. I have noticed that a lot of ‘Quoth’ based maps from around the year 2010, use it; unfortunately, I do not have the ‘Scourge’ expansion pack, therefore I guess it is beyond my reach. But actually, what does it do?

In the end, one can always just use the ‘Quake Injector’ tool. I need to try that thing sometime, even though I am a minimalist when it comes to all the software in the world.

4

I don’t think that works. Only one game parameter is supported. For example, I just tried -game ad -game eoe, and then when it loaded up, you can check this value by typing “game” in console. It resulted in “ad” only value. Quake can not combine mods.

And even if some mod is based on another mod, usually parts of the base mod are included. For example, Dwell1 and SMEJ2 are based on Copper mod, but they already include everything needed from Copper, so you don’t need to use double -game parameter.

Quake had two official Mission Packs - #1 is Scourge of Armagon (by Hipnotic Interactive), #2 is Dissolution of Eternity (by Rogue Entertainment), both released in 1997. In addition to new weapons/monsters/levels, both also featured new HUD elements. For example, SOA relocates key icons to a different place to make room for more items and weapons. Since stuff like HUD was (and still is) hardcoded into the executable file and author of Quoth decided to use HUD from that mission pack, that’s why you needed -hipnotic key when running Quoth stuff - it enables proper HUD. Modern engines, certainly Quakespasm, should have -quoth command line parameter to launch Quoth and related releases.

Basically, the only 3 “base game” parameters are -hipnoic (use SOA as base), -rogue (use DOA as base), -quoth (use Quoth as base).

5

I don’t do this much myself so I can’t tell you everything about it, but I know that it does work. To my knowledge, it was added to QuakeSpasm when Quoth was released, and is necessary to run some packs based on Quoth, such as Func Map Jam 9. For that, you can either do -quoth -game jam9 or -game quoth -game jam9. It won’t let you just mix progs though, and will only work properly if the maps are made with compatible progs (e.g. Copper and AD are both compatible with id1 but not with each other).

So if you wanted to run dopa with AD, you would launch with -game ad -game dopa. You can also use this for organising episodes into their own game folder instead of sticking them in one maps folder. If, for another example, you wanted to keep the udob maps outside of the copper folder, you could put them in Quake\udob\maps, and then when you wanted to run them use -game copper -game udob.

You are correct about SMEJ, Dwell and Pun being packaged with copper, and not requiring this to work.

6

I figured the reason why I said that more than one “-game” switch doesn’t work. Because it doesn’t work in regular Quakespasm, where I tried this. Regular Quakespasm does support “-quoth” parameter, however.

But in QuakeSpasmSpiked, double “-game” command parameters indeed do work! Interesting.

7

If you prefer a certain skill level as the default to play on, you can just add it to a custom .cfg file in ID1, call that file from default.cfg in ID1 and not have to deal with it ever again. It will take effect in every game folder unless overwritten by the game folder’s own .cfg files, which you might want to delete or overwrite in a quake.rc file. I have a custom configuration file (mycfg.cfg) with dozens of commands that set up from zero everything the way I like it. I use that file to override any other configuration file. Everything loads the way I want it in every game folder and I don’t have to worry about it. If I want to modify something or add a new command I just edit mycfg.cfg and it takes effect everywhere. If you have multiple configurations that you like, you can set up aliases for them and cycle through them at the press of a key.

You can get the Hipnotic pack here, along with the Rogue pack and other good stuff:

http://quake.speeddemosarchive.com/quake/guide.html

under Step 1: Download and install Quake.

Note: bind “impulse 225” to a key for the Laser Cannon in Hipnotic.
You can also bind, using aliases, multiple weapons to the same key and toggle between them (for case you want to bind the Laser Cannon together with the Lightning Gun).

8

QSS is partially based on FTE, that’s where the multi-game support comes from. Note that it will only work for some parts of those mods/directories. It will of course not automatically manage to merge the code logic from them.

9

@‘Gila’, had the method not worked, I would have not been using it; unless I fell victim to some false conclusions about how things are.

Interesting that the trick with double “-game” parameter, works only under ‘QSS’ - good to know, before calling it a ‘Quakespasm’ universal kind of trait. Also, does it underscore the difference between the ‘QSS’ and the original ‘Quakespasm’ - after all, it appears these are not practically the same thing, just with one of them having some extra sparkles on.

‘Underdark Overbright’, is an example where I needed to load the base ‘Copper’] and the campaign separately. The campaign, would not work without the base properly - even though, the introductory map in this unique case, did appear; which could be somewhat misleading; for if the base had been loaded improperly, the starting map would have been simply unsolvable; which could turn some people away, wondering. Notwithstanding, plenty of mods requiring some custom base of assets, simply do throw out an error in the engine console, if started without the required base.

Mingling folders is not always the most handy or optimum way out. I have downloaded plenty of maps that require, for example, ‘Arcane Dimensions’ or ‘Quoth’, so I have one folder per each of these bases - placed parallel to an ‘id1’ folder - with all the maps, jams and campaigns, located simply next to them, respectively in own separate directories. To call out a base folder and a map folder, is eventually easier than building ladders of inclusive directories, which either do take unnecessary amount of disk space with repeated content, or require constant micromanagement. The latter is based on assumption that if one puts the content of a map folder in the directory of the map-required base, it should be enough to call out just that one inclusive folder; even though I have not tried it personally.

@‘I Like Quake’, I do have some little experience with ‘autoexec’ in ‘Tech4’ and ‘Tech2’. For what I know, the ‘autoexec’ itself cannot be overwritten - unlike the basic, machine-made ‘config’ - therefore any change to ‘config’ issued during the gameplay continuum, would be only temporary; since as soon as with the next engine start, the changes are again imposed by the ‘autoexec’. Good idea to throw a skill level setting there, in the ‘autoexec’, if one wishes to always play with the selected one by default. What if, though, one has selected a different difficulty level the “organic” way - in an introductory hall - does the ‘autoexec’ then influence this decision, or does the game save file own the last word?

For the ‘quake.rc’ file, I have seen that it is kind of an ‘autoexec’, certain way, but I do not know anything further about how it works - it seems to have no clear equivalent in any later iterations of the ‘idTech’ engine.

10

Autoexec.cfg is just a config file that the engine automatically executes upon loading. You can delete that. I can’t test it right now 'cause I uninstalled my OS, but from what I remember, you can put stuff in there and it will stay there. But in order to avoid confusion with other autoexec files that different Quake releases might have it’s best to put your custom settings in a different config file with a custom name (just create a new .txt file and change its extension to .cfg), and if you want it to take effect everywhere you ought to put it in the ID1 folder and place the line “exec [name].cfg”, where [name] is the name of your custom config file, at the end of default.cfg in ID1 so the engine would know to execute it everytime upon loading. You should see a message at the start of the engine that the config file is being executed. Make sure it is executed last so as not to be overwritten by other config files. You can also call for the execution of the file manually in the engine with the same command, “exec [name].cfg”. You gotta watch out for quake.rc files though in Quake releases. If you don’t delete them or edit them to call the execution of your own config file, they will overwrite it with the author’s configuration files that come with the pack. I usually look through those to see if I’m not missing any settings (if I am, I add them to my own .cfg, eventually retweaked) and then I delete the host files or, if they have interesting data, I keep them but make sure they are not executed, by deleting their calls from quake.rc and calling for the execution of my config file instead. Now that I think about it, I could also just change their extension to .txt.

If you go through a skill selection hall, the skill level changes per the skill portal chosen and the game continues with that skill level, which is the one memorized in the .sav file, so when you load a saved game you get the skill level you saved with.

Quake.rc is a text file, just like .cfg files. It’s the file where you mainly call for the execution of .cfg files.

11

As Spirit already mentioned, QuakeSpasmSpiked has many other features (some might not be apparent). One of the most mentioned is that graphics in QSS can run at more FPS than 72, since the graphic stuff was separated from the game/physics engine, while most of other sourceports break the game with FPS higher than 72 in Quake.

Yeah, that’s what I’m going to do now.

12

@Gila I use Mark V at 125 fps and I have a few problems with elevators, quite rarely though, and that’s about it. But, ¿what exactly is the difference between a game engine and a source port? Wondered about that.

13

Sourceport is what it is - literally a port/adaptation of the original source code for a certain platform, system, etc. Often adding new features.

14

@Gila The original source code of the engine?, or of the entire game? I’m just asking 'cause I’ve seen the terms “engine” and “source port” being used interchangeably and remember someone correcting that and saying that they don’t mean the same thing.

15

@‘I Like Quake’, interesting idea with switching through multiple config files with the use of dedicated keybindings, even though, that would take some scrutiny to make sure one file overwrites the other in a complete manner; such as with ‘unbindall’ command to reset all keybindings, so that unnecessary changes did not stockpile, perhaps causing confusion. On the other hand, if to address the case of skill level selection with this method, I am afraid it is only little better than simply issuing a command manually through the commandline.

For the ‘quake.rc’ and the risk of ‘autoexec’ instances collision; it is good to mind that mod authors sometimes would carry mod specific content through the unique config parameters, influencing - for example - the speed of movement or certain other gameplay related factors.

Once I thought, y’know, what if to have had all the enemy, weapon, health, equipment and loot stats - maybe even some physics related parameters - in one config file, without having to dig through a billion of scattered files in some PAK or WAD archive of sort, making tweaking and modding simply easier. Under the condition though, that such database, would be very well sorted and described. Such file, would pass the parameters to the engine per each game start. What would change, essentially, even from a loading time standpoint? Albeit, what would change, for the benefit of low level modding?

These are understandably not the same thing; but I am guilty of using the notions you mention, interchangeably.

16

I meant switching through different configurations in the same file. For example, I have two gamma and contrast settings, one for hardware gamma, and one for software gamma, that I switch through, for testing purposes, in my attempts to get the OSs (Windows XP/7), the drivers, and the monitor working together to the maximum use of the monitor’s capacity, which is extremely difficult, maybe even practically impossible in the case of XP, since the monitor only has support for Windows 8 upwards. I’ve been weeks at it.

Yeah, that’s why I read through them, to make sure I take into consideration mod specific commands and integrate them into my .cfg.

I know I’d like to have a command that sets corpse_time to 0, 'cause in Warpspasm the corpses disappear after a few seconds, and I find that essentially-multiplayer feature artificial in a single-player campaign.

Well, if you know the difference between them let me know.

17

Source port and engine are two terms for the same thing as far as people are using them nowadays: Something that can run Quake. It’s weird and to me the term “source port” sounds stupid but that’s what most newbies are introduced to them I guess. Probably from the growth of the Doom scene.

18

@Spirit Okay, thanks.

Love the site!

19

The way I see it, there is one primary difference between the sourceport and the engine; namely, the engine is an original creation, while the sourceport, is a derivative creation; meant to forward the applicability of the engine by adapting the engine to standards it was not ready for; usually due to age of the original technology. One could speculate that the engine is a proprietary work, made public, while the sourceport, is originally a public effort; but these assumptions, are far fetched. On the other hand, if a proprietary owner does a modern release of a classic game, they would rarely advertise with terms such as “sourceport” - they rather simply tell the engine has been upgraded. If so, the sourceport, could therefore be understood as something external to the original engine, built to encapsulate it.

But we have come to an offtopic here with this one.

For the ‘autoexec’ or multiple instances of these, the rule of thumb is to understand how does overwriting of data work; which is a basic principle for how most mods operate, in particular around the ‘idTech’ scene. It is very simple. It is literally all about who says how things are meant to go. Overwriting bases on the order of issuing, which means, the first thing is going to get compromised by the second, the second by the third and the final thing gets the last word. There are nuances to it, but in short, the order of things, is crucial - likewise with selecting a difficulty level before the map loading in ‘Quake’.