Pace of movement and other useful c-vars


I find the dynamic pace of movement in ‘Quake’ a little bit too much for myself, especially with the autorun mode turned on, but even with the autorun turned off, it is still somewhat distracting for the purposes of my style of gameplay. I am rather an explorer; a tourist, if you like. I like to play meditatively, taking a good look at the environments, breathing the feel, absorbing the ambiance.

Besides, moving too fast all the time can make platforming aspects actually harder, casually speaking.

Notwithstanding, common high pace of movement is good for combat - it is even necessary for effective combat in ‘Quake’, minding the rhythm and the speed of enemy attacks.

That is why, I would like to set myself two kinds of “console variables” [c-vars] - introduced in a custom “config” or “autoexec” - standing for:

walking pace, which would be slower than the current walking pace;
running pace, which would about keep the current running pace.

By “current”, I mean default QSS ‘Quake’ setup, for the version of 2021-05-11.

Following up, I have done my share of googling and guessing and here are the findings:

The movement speed, appears dictated by the following c-vars, albeit I doubt the list is complete; but I do suspect that the running pace, is either missing or unaffected:

cl_forwardspeed ; default “200”
cl_backspeed ; default “200”
cl_sidespeed ; default “350”
cl_upspeed ; default “200”
cl_rollspeed ; default “200”

I am uncertain about the exact meaning of “cl_rollspeed”, but if it is out of whack with the other parameters, the movement - particularly the strafing - becomes janky. The “cl_upspeed” must perhaps refer to some underwater exclusive movement, probably bound to a separate key, thus rarely ever used in practice; that is my guess.

We can see how the “cl_sidespeed” is significantly higher than the other parameters; infact, multiple ‘Quake’ pros would often mention that in order to move faster, one ought to somehow employ strafing to it, in a way.

My proposition was to cut everything down to 150, but once I have done that, I realized: wait, this is not ‘Quake’. ‘Quake’, is about speed, about dynamics of combat, not about sightseeing and soft stuff. Besides, if aiming for some slower pace and more meticulous approach to gameplay, why not already implement some zoom function - to get a better look at the details? The point is, ‘Quake’, does not have either any precision weaponry that should make any use of zoom, nor maps proper for the zoom to make any better sense. It would probably require some coherent, total conversion on such a massive scale, that for now, it remains a pipe dream.

That having been said, I do not want to change the pace anymore. Problem solved.

For the theory, I have noted that “sv_maxspeed” i set to “320”, which - if working as I guess it does, but it could bear different meaning - makes little sense in the face of “cl_sidespeed” parameter set to “350”.

When you strafe in Quake, it tilts the camera a small amount. You can control this behaviour using cl_rollangle and cl_rollspeed. cl_rollangle is simply the angle, in degrees, that the camera will rotate. I couldn’t tell you exactly how rollspeed works, but I know it’s related. I believe cl_upspeed refers to +moveup, which makes you go up when swimming and noclipping (there’s also a +movedown), but most modern ports do the same thing with +jump, so it doesn’t matter.

It seems like there is a cvar, cl_movespeedkey (default 2.0), which changes your speed but doesn’t do anything when set above the default. Not sure what its purpose is meant to be, but it could probably do what you’re asking.

It should be possible to set up both changing player speed and fov (for zooming) using advanced binds, but I don’t know the commands off the top of my head and I don’t really feel like figuring them out myself right now. Keep in mind that changing (particularly increasing) player speed outside of the existing +speed (i.e. sprint) command can be considered cheating, not that it’s relevant in most contexts.

I do agree with you that there’s not much reason to make the player slower in vanilla Quake.

@‘h4724’, thanks for your points on. The case is, majority of such parameters as discussed in this thread, rarely ever work alone - they are typically synergistic with other of like, forming a coherent bundle, therefore it is not only the question of applying a change to a complete set of parameters, responsible or otherwise participating in a function in question, but also, making sure these are maintained properly tuned together, so as to achieve proper effect. First problem is to know all the parameters of interest. Second problem, refers to their corresponding balance. It is reasonable to believe that the original image of an engine - the engine defaults - contains properly balanced set of such parameters, therefore, copying the proportions of values between given parameters and applying own changes to these parameters only within the realm of said proportions, should bring the best spectrum of outcomes. The question is, though, what if not really - what if the best outcome is actually outside of the exemplary proportions, that is, outside of the continuum implied by the original engine defaults? It takes grand experience and a fair bit of knowledge on the technology of interest to work with that, which is why, I simply rather keep it the way it is, for myself. Besides, pace of movement is a major change and may drastically alter the game experience. Early ‘id’ games are notorious for their fury, therefore, it simply may not be the same thing, if to slow it down - or maybe accelerate - just like that. Eventually, a product, is a product; if we want to confront our opinions on it, we have to make sure that the matrix for our experiences, does match - then, possible difference in opinion, could be considered an individual matter.

For the zoom mode, I have prepared myself once a two-step zoom in ‘Quake 2’, using only ‘autoexec’ commands, therefore I am certain it should also be doable under the QSS. The method was based on aliases and bindings, which involved FOV manipulation, crosshair toggle and weapon visibility toggle.

Speaking of the zoom mode; such as it does make little sense to slow the pace of movement down in the vanilla ‘Quake’, does it also make little sense to implement any zoom function. Here is my line of reasoning behind it: ‘Quake’, is transconventional - within the boundaries of own design principles, it trespasses the borders between fantasy and future, abstract and concrete; without changing the gameplay formula anyhow. The element, binding all these conventions together, is the very persona and presence of the Ranger; the main protagonist. Most fights in ‘Quake’, happen only when all the involved opponents, can see the face of each other. This, fulfills certain martial ideal of combat; even though chaotic, having own sense of honour - to fight in an aware manner. Sniping down medieval knights with fancy type of railgun, using triple-step zoom, could actually bring ridicule to the very notion of such resolution. It does feel absurd. That is why, if to move towards slower pace, zoom mode and other fancy changes, we already talk about a different game altogether, which remains within the realm of speculation. But I do like the modern feel the improved engine technology does offer to ‘Quake’ mappers; it works inspiring.

Further ahead in this forum post, I share a fairly simple way on how to implement the zoom mode into ‘Quake’, under the QSS engine.

First of all, should I note that personally, I do not like the idea of zoom - not in ‘Quake’, that is. Combat dynamics and spatial design in ‘Quake’, make the zoom mode redundant, if not downright handicapping to the proper experience. In case though someone wanted to go in the direction of a conversion with their ‘Quaddicted’ related creativity, perhaps this could be of some use.

Basic design principle is that in default view mode, the field of view is somewhat wider as compared to the engine default, there is also no crosshair, but the weapon model is visible. In the first step zoom mode, the crosshair is visible, but the weapon model disappears - ideally speaking. Second step zoom mode shares characteristics with the first step zoom mode, only that the zoom is deeper.

In the mechanism presented further ahead, the command for weapon visibility is missing - for I know it not - but if someone knows the c-var for weapon visibility, let me know and I will update. // missing link found

The tool, does use custom “MOUSE2” and “L-CTRL” bindings. In order to enter zoom, press and hold “MOUSE2”. In order to enter second-step zoom, press and hold “L-CTRL” while having been pressing “MOUSE2” already. The “L-CTRL” does not work without “MOUSE2” being active. In order to exit zoom mode, release.

I tried to use relative means to obtain the effect - such as “inc fov -20%” - but then, minding possible combinations of two separate keys for the zoom operation, it could produce anomalies, such as permanent field of view malformation. In the end, calling to absolute values, was necessary. Command to “reset” the field of view on “MOUSE2” release, did solve some possible issues, albeit it did not respect custom “fov” setup; always turning to the engine default of 90. Option to change the engine default via the use of “setrom” command, did not work, perhaps due to the lack of further skill required on my part.

Notwithstanding, the “fov” reset on “MOUSE2” release, accompanying the relative means to “fov” manipulation, did not solve all the meanwhile possible “fov” related issues emerging from the incidental “L-CTRL” action influence on the “MOUSE2” setup. Therefore, calling to absolute values at every step of the procedure, appeared the most effective way - as well as the most simple.

How to test the tool:

  1. Navigate to your “id1” folder
  2. Backup your “config.cfg” file
  3. Copy your “config.cfg” file within the “id1” folder
  4. Rename the new file to “config2.cfg”
  5. Open the “config2.cfg” in a simple text editor and clear all content
  6. Save the following into the emptied “config2.cfg” file":
cl_bob "0.0005"
set fov "105"
set crosshair "0"
alias +mode "set fov 55"
alias -mode "set fov 80"
alias +zoom "set fov 80; set crosshair 1; r_drawviewmodel 0; bind CTRL +mode"
alias -zoom "set fov 105; set crosshair 0; r_drawviewmodel 1; unbind CTRL"
bind MOUSE2 "+zoom"
  1. Run ‘Quake’ under QSS engine
  2. In the console, execute the following:
exec config2.cfg

Warning: the “config2.cfg” will likely overwrite some of your original “config” data, therefore once you are done with testing the tool, restore the original “config.cfg” from the backup you have made.

// mechanism edited for “cl_bob” and “r_drawviewmodel” c-vars

Great news for nerds. I have found a website with thorough explanation of multiple c-vars. Link

Thanks to that, I have updated the post regarding zoom mode, with the missing link for gun model render. The missing link, was “cl_drawviewmodel”. I have additionally added the “cl_bob” c-var to the pattern, so as to make the gun look less phallic in wider field of view.

Furthermore, I have found the c-var responsible for pace of running. It comes out the pace of running affects only forward and backward movement, without affecting the speed of strafing. This, would explain the disproportionately high value of strafe speed - or sidespeed - as compared to regular forward and backward movement, according to engine defaults. It does make sense, notwithstanding, as the strafe, is usually associated with dodging projectiles, therefore, the target strafe speed value, could oscillate around the emergent speed of running; for both, are a defensive or combat related pattern of movement. One could theorize the strafe movement does have running function built-in, even though it is not perfect way in my opinion.

The c-var for running movement speed is “cl_movespeedkey” and it is a value, through which the “cl_forwardspeed” and “cl_backspeed” are multiplied, when the “+speed” function key is being pressed. Default value of “cl_movespeedkey”, equals “2”. Which is why, theoretically, the ideal pace of “cl_sidespeed” - or strafing - is about twice the value of “cl_forwardspeed” or “cl_backspeed”.

It also comes out that indeed, the “sv_maxspeed” does dictate the ultimate available speed of movement, therefore any direct or emergent value exceeding this parameter, will simply be cut down to it.

For the “cl_rollspeed”, it comes out to be responsible for the protagonist returning to a straight position after strafing action. Low values appear to give janky movement impression.

Another c-var associated with movement, is “cl_anglespeedkey”. It is declared as being responsible for the ability of a protagonist to swiftly turn while running, but having tried to test various values of it, I did not notice much difference. Perhaps it could make better sense in correspondence with acceleration or in lower friction conditions.

For the little bit of continuous movement and organic flow on the screen - which some perhaps like to associate with the weapon bob - I find the “v_idlescale” to be suitable with a value of “1”. It gives that little bit of a swing, natural for a human under common conditions. It may cause, however, the edges warp effect.

Regarding the weapon positioning, some are fans of the old-school center focus, while some are more fond of the more modern approach, emphasizing the attitude of being either lefthanded or righthanded. ‘Quake’ does not particularly offer any choice in this regard, but there is way to alter gun positioning via screen offset manipulation. The c-vars helpful in that, are:
scr_ofsx // weapon positioning on the axis of depth
scr_ofsy // weapon positioning on the horizontal axis
scr_ofsz // weapon positioning on the vertical axis

One could try such setup, for example, in order to achieve slight righthanded emphasis:

scr_ofsx "0.8"
scr_ofsy "-2"
scr_ofsz "1"

Much depends on the weapon models though and these vary in display qualities.

On a final note, some mappers use text intel to inform a player; similarly to how the difficulty settings are being announced at choice. Times, I find the text disappear before being able to fully take it in. It is useful then to simply bring in the console, which stores all text data appearing throughout the game, thus allowing the player to read the text with game being paused - convenient. Notwithstanding, if someone wanted to have an uninterrupted game experience, it is possible to prolong - or shorten - the duration the text remains on the screen, with the c-var of “scr_centertime”. Default value for it, is “2”; the higher, the longer the text remains on the screen.

Two interesting c-vars associated with surfaces and precipices, are “sv_friction” and “edgefriction”.

The “sv_friction” defines how slippery the common surface is, therefore dictating the effective grip of protagonist movement. Description provided on the earlier mention website notes that if the value is negative, the protagonist will gain speed while moving, but an overt value - on the other hand - may restrict the speed of movement.

The “edgefriction”, particularly handles just the precipices - creating an artificial grip around these, allowing the protagonist to more effectively stop, rather than accidentally slip and perish.

The c-var responsible for sharpness of the protagonist movement, is “sv_stopspeed”. It tells simply how fast the protagonist will be able to stop at will. The “sv_stopspeed” may affect the available speed or dynamics of movement. Negative values do not differ from “0”.

One more c-var associated with movement, is “sv_accelerate”. It tells how fast the protagonist reaches full movement speed. Lower values of this parameter, may give an impression of a heavy start, as if moving with some burden. Low values of “sv_accelerate”, may synergize with “sv_friction”, causing permanent movement speed handicap, if the “sv_friction” dominates.

Default value of any c-var can be checked in the console by typing the name of that c-var, without any argument to it. In case the c-var was modified, executing the “reset” command should help before the name of a c-var, in order to restore the engine default value for it.

Here is my early swing at the movement pace parameters:

sv_maxspeed "315"
cl_movespeedkey "1.5"
cl_sidespeed "210"
cl_forwardspeed "210"
cl_backspeed "210"
cl_rollspeed "210"
cl_upspeed "315"

These emerge from speculative principles, therefore some artistic or “feel-based” fine tuning, would be welcome.

I thought as to explain here how did I come to these, but first of all, it is not definitive edition, second of all, this is a rant that neither do I really want to write, nor anyone perhaps seriously wants to read. You can just see yourself whether you like the organic outcome or not.

I think an stamina bar - such as the one in ‘Doom 3’ - would actually fit in, rendering the running function, to be reserved for combat and related combat or platforming mechanics. That is, in order to make one use the walking function a bit more, to embrace the environments such way, better.

Current speed of ‘Quake’, under constant running function, kind of rapes the vibe, to my taste.

It seems I made a mistake, the “cl_sidespeed” does actually seem affected by the “cl_movespeedkey”, therefore, the update value.

I do not like the “cl_upspeed” or the “swim up” function effect, the way it was implemented. The “swim up” movement, seems slower as compared to regular, walking pace, forward or backward movement underwater, which in turn is slower to running speed forward or backward movement underwater. What I mean by that, is: underwater, if you press “jump” or “swim up”, you will ascend the slowest. If you just face the surface and forward move to it - walking speed - you will ascend with mediocre speed. You can also face the surface and forward move to it in running speed, which will let you ascend the fastest.

I doubt whether running speed, should apply underwater at all. Everything underwater, should be walking speed, arbitrarily. Furthermore, the effective speed of “swim up”, should match the regular speed of forward movement underwater. It seems now that there is different physics applied to regular forward movement and “swim up”.

It would be good if oxygen bar appeared when underwater, perhaps replacing the suggested stamina bar, which the latter one, in turn, does occur on the surface.

The reason for that, is, since the running mode underwater is proposed to disable, there is not need for stamina bar submerged - yet, there is functional need for an oxygen bar under such circumstances.

Speculatively speaking, the vacuum conditions, ought to combine the simultaneous appearance of both the oxygen bar and the stamina bar. Even though, possible correlation between oxygen consumption and stamina consumption - which means, what kind of strategy do you choose: fast but short lived or slow but long lived - does render such option of rather inadequate level of complexity for the moment given.

It would be useful if to make a “quick-axe” strike available in ‘Quake’. The technology, would simply work on the basis of an instant, temporary switch to an axe - from any other wielded weapon - to carry out exactly one strike per each button-trigger instance, then to switch back automatically to the last used weapon. Basing on my efforts within the ‘Quake 2’ engine that I remember, I know similar solutions employing config-commands only, are highly vulnerable to confusion, especially if to bring toggle weapons technology along the way. Infact, any fixes involving config-commands only, attempting a complex solution even of basic nature, are highly vulnerable to confusion.

The weapon autoswitch on collect, should be offable, although introduction of such option, is a task for an engine maintainer. In the current version of ‘Quakespasm’ - that is “0.93.2” - the option, is not yet available. Because it does not exist in the original ‘Quake’, does not all mean it is a bad option to have.

Within the terms of “fov” matching “105”, the “cl_bob” of “0.0013”, seems to give a less floaty or “swimmy” appeal to the gameplay, compared to the value of “0.0005”; without the gun drawing too much eye attention, yet “rubbing” the player awareness notwithstanding with subtle movements. That is, combined with the gun positioning setup of:

scr_ofsx "0.8" scr_ofsy "-2" // alter to positive value for lefthanded emphasis scr_ofsz "1"

Speaking of the “sv_aim” parameter - default at “0.93” - I assume it has to do with the hitbox area, associated with the size category of an opponent entity? The parameter values, range between “0” and “1”, through which I understand it means that “1” equals hitbox exactly matching the basic size category of an opponent - as well as the adequate opponent model, fitting sensibly the related hitbox field - while values lesser than “1”, mean that the hitbox, is being enlarged, allowing for loose shots to land even if they would not, if the “sv_aim” was at “1”?

For the “cl_sidespeed” - the strafe speed characteristic - I got some inconclusive results with the “quakespasm” and the “vanilla” running modes under the ‘QSS’ engine; speaking of the way how a parameter in question reacts with the “cl_movespeedkey” value - which is, the running mode multiplier. Which is further why, I abandon this entire case aspect for the favour of vanilla ‘Quake’ compatibility, opting only for the “cl_upspeed” parameter - the speed of resurfacing when submerged - to be elevated to the value of “350”; a value matching the one of “cl_sidespeed” original; even though, I am aware it is a theoretical reference, since the “sv_maxspeed” - protagonist global movement speed limitation - limits both of these to “320”, at least for what it seems. I guess there is way to measure exact speed of movement in-game, if tests in that direction were needed.

Well, apparently I am wrong about the nature of engine behaviours related to the “sv_aim”; as well as plenty of other, I suppose. If the hitbox theorem remains anyhow valid, it rather works like a magnet, automatically redirecting the fire trajectory towards areas of valid frag-lethality. All in all, the related c-var comment suggests to keep the parameter at “1” for most multiplayer games.

The “vanilla” running mode under the “Quakespasm”/“QSS” engine, appears to permanently alter both the “cl_forwardspeed” and “cl_backspeed” parameters, according to how they are multiplied by the “cl_movespeedkey” factor, even though the “cl_sidespeed”, remains independent. However, if to lower the values of “cl_forwardspeed” and “cl_backspeed”, as well as the “cl_sidespeed” all to - say - the value resulting in effective “200”, they are still being processed as regular by the “cl_movespeedkey” upon the initiation of “+speed” function.

To myself, it boils down to an observation, that the original system developers, with some possibility, relied a lot upon the serverside application of “sv_maxspeed”; arbitrarily suggesting values outside of mathematical cohesion, if such a speed limit was to be removed and emerge only organically, through relevant processes. But perhaps this opinion is simply due to my hubris or a fault of certain “Quakespasm” nuances versus the original gamestate.

In the end, I am just confused.

I guess the conclusion is that it is better to choose the “quakespasm” running mode, unless one has a purpose in the “vanilla” option.

Did you check if it’s possible to slower the player with triggers? To manually force a player to move slower, but when the event is done (or player is out of specific zone) bring the speed to usual. All with triggers, is it possible?

I’d be also happy with the crouch ability since it could add a lot to gameplay (shallow low ceiling spaces & an ambush). But ok…

Config tweaking only offers solutions within the existing state of an engine; it is really all about the question: what can we do with what we have, in order to achieve what suits our taste better? I am afraid crouching, is a function that would require grand external fix - a mod. Every mod, if aimed to be well done, is a ton of work, especially minding the hazard of breaching the game integrity - compatibility issues.

It is definitely possible to slow the protagonist down with certain c-var alterations, although since I do know little of mapping at the moment, I am not certain how do you apply those config tweaks dynamically on a map setting. However, since it is possible to alter a difficulty level through the touch of a selected entity in-game - albeit, a difficulty level tweak, may require a map restart, while a common c-var of another kind, unnecessarily - I think similarly one could manipulate the movement-related c-vars, such as:

Name: sv_friction Default: 4 Description: The friction value for the player's movement. Note: You can use this command to lower the amount of friction on the map for the player's movement. If you set this variable to 0 you will turn the map into an ice and the player won't be able to stop. If you set this variable to a negative value, the player will gain speed when he moves. If you increase this variable you can really slow the player down.

The drawback, is that “sv_friction”, will not arbitrarily limit the ability to run, therefore the protagonist - paradoxically - will still be able to move a little bit faster on demand, even though the environment, should not allow him to do so effectively, I imagine.

That is why, the good old “sv_maxspeed”, could actually do the job as well; the limiting of which - if gone down to the level of walking speed only or even below that - would restrict the total speed of protagonist movement, regardless whether it refers to walking or running.

Name: sv_maxspeed Type: Register Default: 320 Description: The maximum speed that the player can achieve through running. Note: This is the maximum running speed for the player. The player can however exceed this speed when he's falling or when he's being thrown by explosions. It is also possible to exceed this speed by running next to a wall and use keys bound to the "+moveleft" or "+moveright" commands in order to achieve a gliding effect with the wall, thus speeding up the player's velocity. There is also a way to increase the player's speed by using the above mentioned keys in quick succession when running on flat ground.

In order to control the jumping ability of a protagonist, you could tweak the gravity value:

Name: sv_gravity Type: Register Default: 800 Description: The amount of gravity on the level. Note: You can have a lot of fun with this variable. If you set it to 0 everybody will become weight less and will start drifting throughout the level, the grenades will also bounce in funny ways. If you set this variable to a negative value, the players will look like hot air balloons and will start rising towards the sky.

The gravity tweak, may arguably not give sufficient results, if to think of actually increasing it, rather than decreasing. Therefore, in case you are using some arbitrary keybindings, defined in a “quake.rc” or an “autoexec.cfg” file of a modpack, you may as well simply unbind the “+jump” ability, but then, you would need to know what key it was bound to specifically, in order to flawlessly restore the ability later.

From what I know, there is no option to cache or save a state of config through the engine, so that to restore the config on demand afterwards. One could, yet, use various config sheets throughout the map, running “exec” command to initiate them on a trigger, maybe. It does not solve the problem of interacting with custom player setup, especially in terms of keybindings, anyway.

I believe a modder, may request to have certain custom, mod-specific keybindings respected, but it should come with a transparent warning, that the mod uses custom config and keybindings, which could - in some cases - overwrite the original gamestate; which is why, a backup or a certain way of mod installation, is suggested, placing the mod folder parallel to an ‘id1’ folder, rather than within it.

That is, at least, how I understand that it works.

On a footnote, what applies to the “+jump” ability, applies also to the “+speed” one, meaning you could still use the “sv_friction” config with the “+speed” function unbound - making sure, though, that the “cl_alwaysrun”, is “0”.

Also, it just came to my mind that one could use the “sv_friction”, while having simultaneously altered the “cl_movespeedkey” to “1”, in order to simply nullify the running mode multiplier; which the latter one, tends to be at “2” on default. This way, the “cl_alwaysrun”, is not an issue. The problem with “cl_movespeedkey”, however, is that it does not affect the “cl_sidespeed” - the strafing movement speed, which at default value, is higher than the “cl_forwardspeed” and the “cl_backspeed” line movement, at their default. On the other hand, restricting the strafe movement too much, may handicap any ‘Quake’ combat experience.

@‘Alex Ros’, speaking of custom bindings and unbindings, it is good to remember that ‘Quake’ engines we use, allow to bind an action to more than one key. Which means, that even though having a function - such as the “+jump” - unbound from one specific input trigger, the player may still outmaneuver the system through the use of an alternative input, to obtain the result. That is also why, if to have a custom “autoexec.cfg” or “quake.rc” file for the mod - including custom key setup - it is reasonable to begin with an “unbindall” command; that simply clears the sheet of all the thusfar valid bindings. This way, even if the player had had custom key bindings, it will not work for the new mod. Having the old bindings cleared altogether, it cannot though be left like that, since the majority of mandatory functions and utilities - even as plain as getting to the engine console - are rendered inaccessible. Which is why, some rebinding of common functions, needs to be done. Exemplary script in that direction, is presented below. You may notice that the “+jump” ability, is bound to “MOUSE2” key and “MOUSE2” key alone, which secures the result of a possible unbinding in that category.

	// introduction

	// rebinding

	// movement
bind "w" "+forward"
bind "s" "+back"
bind "a" "+moveleft"
bind "d" "+moveright"

	// abilities
bind "SHIFT" "+speed"
bind "MWHEELUP" "impulse 12"
bind "MWHEELDOWN" "impulse 10"
bind "MOUSE1" "+attack"
bind "MOUSE2" "+jump"

	// weapons
bind "0" "impulse 0"
bind "1" "impulse 1"
bind "2" "impulse 2"
bind "3" "impulse 3"
bind "4" "impulse 4"
bind "5" "impulse 5"
bind "6" "impulse 6"
bind "7" "impulse 7"
bind "8" "impulse 8"

	// other setup
bind "TAB" "+showscores"
bind "ESCAPE" "togglemenu"

bind "+" "sizeup"
bind "=" "sizeup"
bind "-" "sizedown"
bind "`" "toggleconsole"
bind "~" "toggleconsole"

bind "F1" "help"
bind "F2" "menu_save"
bind "F3" "menu_load"
bind "F4" "menu_options"
bind "F5" "menu_multiplayer"
bind "F6" "echo Quicksaving...; wait; save quick"
bind "F9" "echo Quickloading...; wait; load quick"
bind "F12" "screenshot"

	// 'Arcane Dimensions' specific
bind "i" "impulse 175"
bind "h" "impulse 178"
bind "r" "impulse 190"
bind "k" "impulse 196"

	// custom bindings; screenshot mode
bind "" "r_drawviewmodel 1; crosshair 1; scr_showfps 1"
bind "]" "r_drawviewmodel 0; crosshair 0; scr_showfps 0"
bind "\" "scr_showfps 0"

For the “quake.rc” file, mind it is the first file loaded by the engine. The “.cfg” extension files, need to be called out from it, with the use of an “exec” command - look up the “quake.rc” file of ‘Arcane Dimensions’ mod for example. The effective order of calling out “.cfg” files, is as follows: “default.cfg”, “config.cfg”, “autoexec.cfg”. The order of calling out, is simultaneously the order of overwriting, which means the last file coming into the equation, has the last word to say upon any issue in question. The “autoexec.cfg”, is an optional entry, though and infact, as plenty of “.cfg” files can be called out from a “quake.rc” entity, as you only want; securing however the privileged position of “default.cfg” and “config.cfg” respectively, which are tightly related to engine clockwork. If you disinclude these, the game setup, may look messed up.