#1 2021-05-25 10:59:27


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.

#2 2021-05-25 15:21:43


Re: Pace of movement and other useful c-vars

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".

Last edited by triple_agent (2021-05-25 15:30:35)

#3 2021-05-25 16:49:21


Re: Pace of movement and other useful c-vars

triple_agent wrote:

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.

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.

#4 2021-05-26 02:11:57


Re: Pace of movement and other useful c-vars

@'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.

Last edited by triple_agent (2021-05-26 16:13:14)

#5 2021-05-29 00:53:46


Re: Pace of movement and other useful c-vars

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.

#6 2021-06-02 07:42:43


Re: Pace of movement and other useful c-vars

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"

7. Run 'Quake' under QSS engine
8. 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

Last edited by triple_agent (2021-06-03 06:49:50)

#7 2021-06-03 06:08:01


Re: Pace of movement and other useful c-vars

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

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.

Last edited by triple_agent (2021-06-03 07:49:16)

#8 2021-06-03 08:15:46


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-06-03 17:09:24)

#9 2021-06-03 17:27:12


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-06-03 18:16:48)

#10 2021-06-15 04:18:51


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-06-19 20:29:45)

#11 2021-06-15 13:56:37


Re: Pace of movement and other useful c-vars

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

#12 2021-06-23 17:53:37


Re: Pace of movement and other useful c-vars

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".

Last edited by triple_agent (2021-06-24 10:49:19)

#13 2021-06-24 05:11:25


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-06-24 05:17:31)

#14 2021-07-17 06:33:50


Re: Pace of movement and other useful c-vars

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.

#15 2021-07-18 06:57:21


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-07-18 10:32:18)

#16 2021-07-20 12:18:58


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-07-20 16:00:17)

#17 2021-07-20 13:36:24


Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-07-20 13:59:44)

#18 2021-07-21 09:34:37

Alex Ros

Re: Pace of movement and other useful c-vars

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...

Last edited by Alex Ros (2021-07-21 09:39:47)

#19 2021-07-21 13:18:35


Re: Pace of movement and other useful c-vars

Alex Ros wrote:

I'd be also happy with the crouch ability since it could add a lot to gameplay

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.

Alex Ros wrote:

Did you check if it's possible to slower the player with triggers?

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.

Last edited by triple_agent (2021-07-22 02:03:53)

#20 2021-08-02 03:35:51


Re: Pace of movement and other useful c-vars

@'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.

Last edited by triple_agent (2021-08-02 04:07:07)

#21 2021-08-07 00:18:01


Re: Pace of movement and other useful c-vars

'Quakespasm' - after the 'Fitzquake' engine - has inherited an interesting feature of the environmental fog. The fog, is controlled by a simple-to-remember c-var named "fog". Values of the "fog" - speaking of density - seem to operate in terms of a percentage number, written decimal style; in which the value of "1", is a blind fog, while the value of "0.035", for example, is a proper light mist.

I saw that the 'Copper' mod, uses some advanced technique of fog cycling, handled in the "quake.rc" file the mod brings. The "fogcycle" script, however, does not kick in with the new game, unfortunately. I did manage, though, to invoke the various shapes of mist the 'Copper' mod proposes, using the commands of "fog1", "fog2", "fog3", "fog4" or "fog5" in the engine console - "fog 6" is a no-fog option. The "fogcycle" command works as well, if repeated. Unfortunately, the "fog" function, in the vanilla game, gets reset with each map change.

Looking up the 'Copper' in the case discussed , from what I recognize, the 'Lunaran', has assumed a custom parameter of "fogcycle" to be a premier variable, having the values of "fog#" shifting for it in the cycling process; that is why, the re-aliasing of main "fogcycle" condition.

There is also another interesting function in the 'Quakespasm', that it has inherited after the 'Fitzquake' engine - the "cycle", allowing to oscillate between values of a c-var. Intuitively, I thought the "cycle" function would be dynamically defined within the conditions of a specific stage, resulting in fluent outcome. In my world of expectations, such script as one given further, should work as well, but the case, seems very puzzling; what the engine would keep repeating, is that the "fog" c-var, does not match a variable type in the "cycle" function:

alias fog1 "0.03 0.3 0.15 0.2;"
alias fog2 "0.02 0.33 0.33 0.5;"
alias fog3 "0.04 0.3 0.3 0.3;"
alias fog4 "0.03 0.3 0.2 0.1;"
alias fog5 "0.03 0.15 0.22 0.12;"
alias fog6 "0;"
cycle fog "fog1 fog2 fog3 fog4 fog5 fog6"

In the realm of "fog", it is furthermore possible to tweak the colors of an effect - as partially mentioned in the 'Copper' "fogcycle" case. After stating the fog density, follow up with three successive values in the RGB spectrum. Hit "fog" in the 'Quakespasm' engine console for some intel.

There is also another c-var, valid in the realm of "fog". That c-var, is the "r_skyfog". The "r_skyfog", tells how much the sky image is affected by the fog. Default value of the "r_skyfog", is "0.5" - the 'Copper', stays with it.

For the usefulness of "fog", even though it may seem cool and fancy to have it on perpetually, I believe there should be an excuse for it. The fog - technologically speaking - may increase the performance through reduction in the line of sight, but for the very same reason, it may handicap certain gameplay elements, in particular those requiring range precision or a clear vista. To some players, it may also be wearing.

Reference: fitzquake
Reference: copper

Last edited by triple_agent (2021-08-07 01:40:38)

#22 2021-08-07 20:16:13


Re: Pace of movement and other useful c-vars

The "cycle", seems a trigger-based function, which makes it mostly useful in terms of a keybinding-based way of operation. Try with "sv_gravity", for example. Map change, could work as a trigger as well [false]. In terms of the before mentioned cycling of the "fog"; if "cycle" was anyhow able to work with the "fog" c-var, it would work the way 'Lunaran' has constructed it. In the end, the most effective way to handle the "fog" problem, is simply to orchestrate it in the map-design, with custom scripts, I guess.

If the "cycle" was a dynamically defined function, switching parameters during the gameplay length and within the conditions of a specific stage, another factor should be introduced, to accommodate for the terms of cycle change. That factor, could relate to the arbitrary time condition, even though the passage of time, is highly imperfect here, for in terms of gameplay, time is relative to progress. It is a matter of perception. In life, our anchor in the realm of time, is the body and organic dynamics; things which are relevant. What would better mimick the actual question of progress in the gamerealm, is the amount of movement done by the protagonist. Still an imperfect criterion, for the gameplay styles may vary, but a player who does a lot of exploration, would see an environmental reaction to it; standing still, is actually an equivalent of time-stop.

Which is why, a function counting the amount of protagonist movement - relative to the arbitrary map-space - having a reset to zero when the parameter value is met; initiating a trigger to all "cycle" conditions in a config-space, as soon as so happens - could be a method.

What about multiplayer and terms of counting the cycle speed for many subjects? First of all, what multiplayer? Second of all, in multiplayer, arbitrary time would do better than movement-related criterion.

Last edited by triple_agent (2021-08-07 20:39:57)

#23 2021-08-07 21:10:33


Re: Pace of movement and other useful c-vars

If to be detailed about it - just for the sake of speculation - the "cycle" function, could also get two complimentary c-vars; one stating whether the change between defined "cycle" values, is to be absolute - other, stating the speed of transition, if the change, is to be relative.

If the change is absolute, the transition speed c-var, becomes nullified in effect - the transition between specific values in the "cycle" pattern, is immediate. If the change is relative, the "cycle", would sweep through intermediate values between a defined pair, within a set length of time, making for a transition period. The c-var in question, would define the length of this transition period.

The problem with the transition period c-var, arises with c-vars in the "cycle" pattern, that could assume multiple dimensions of values - if such existed. It does not take much to imagine there are multiple nuanced problems in the realm discussed, minding the varied nature of c-var values, therefore, the case, seems like a lot of effort for a not entirely well worth it or widely useful outcome.

Last edited by triple_agent (2021-08-07 21:25:27)

#24 2021-08-08 06:10:49


Re: Pace of movement and other useful c-vars

I mentioned the "quick axe" function. Further, is a simple script allowing for an instant switch to axe and an immediate attack with the weapon. The script, does not include a revert back to the weapon of origin, due to lack of a ready tool - that I would know of - equivalent to "weaplast" function in 'Quake 2' engine; if to assume a lack of nuance problems with such fix. The "quick axe", is bound to an exemplary key of "MOUSE2":

alias +quickaxe "impulse 1; +attack;"
alias -quickaxe "-attack"
bind "MOUSE2" "+quickaxe"

The function, is incompatible with toggle mode.

Since the axe, is now attack-bound to a key other than a numeric denominator, it means the slot of "1", becomes free - therefore, all other weapons, can move one step lower in their value of numeric binding. Since I always thought the most powerful guns are way beyond easy finger-access on the keyboard, I suggested them under the keys of "q" and "e" for the thunderbolt and the rocket launcher, respectively:

bind "1" "impulse 2"	// rifle
bind "2" "impulse 3"	// double-barrel shotgun
bind "3" "impulse 5"	// perforator
bind "4" "impulse 4"	// nailgun
bind "r" "impulse 6"	// howitzer
bind "e" "impulse 7"	// rocket launcher
bind "q" "impulse 8"	// thunderbolt
unbind "5"
unbind "6"
unbind "7"
unbind "8"

I do not know what the function of "impulse 0", stands for.

Last edited by triple_agent (2021-08-24 15:37:25)

#25 2021-08-08 06:40:20


Re: Pace of movement and other useful c-vars

I use Q for GL, E for RL, Shift for SNG, MOUSE2 for LG.
Other weapons I can reach by number keys 1, 2, 3, 4.
This is a config I got familiar in 97 or 98 when I finally switched to mouse.

Quick reply

Write your message and submit
Are you human or robot? If you have trouble, mail to spirit åt quaddicted døt c

Checking if this is requested by a real person and not an automated program.

Board footer