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

triple_agent
Member

Pace of movement and other useful c-vars

Hello,

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

triple_agent
Member

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

h4724
Member

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

triple_agent
Member

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

triple_agent
Member

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

triple_agent
Member

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

triple_agent
Member

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

triple_agent
Member

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

triple_agent
Member

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

triple_agent
Member

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, 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', kind of rapes the vibe, to my taste.

Last edited by triple_agent (2021-06-15 13:55:27)

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

triple_agent
Member

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.

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