Pace of movement and other useful c-vars

Quake
21

‘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: https://www.celephais.net/fitzquake/
Reference: https://www.quaddicted.com/reviews/copper_v1_16.html

22

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.

23

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.

24

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.

25

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.

26

Some may say it is a nitpick and if you play ‘Arcane Dimensions’ with ‘Darkplaces’ particle system the majority of time, probably this is not your kind of an issue, but I saw the default particles that current ‘Quakespasm’ does recommend, to be of circular shape. I thought, it was odd. ‘Quake’, is such a wonderfully blocky game, the circular particles, do and do not fit it - maybe to underline some kind of difference, I do not know. Anyway, I found there is way to revert the particles to a square shape, as God intended:

r_particles "2"

Voila!

Changing the topic:

I guess so; who at the pro level would use a default gun config and be efficient with it.

27

The ‘default’ look of OpenGL-driven Quake was always blurry textures and circular particles ever since 97. It is also present in Quake II when using OpenGL accelerated graphics. And it was in all the 3dfx/OpenGL/Console/Arcade games back then and considered cool new smooth look or something. But yes, a lot of people these days I see are asking for a setting to have non-blurry textures but they often ‘forget’ to change the particles to squares as well.

Speaking of particles, I recently found out that in GL variants they are rendered differently than in the Software mode of the original. I noticed this after playing some classic mods and map packs in Mark V WinQuake and then switching to QuakeSpasm to play some new release. Immediately I was missing the “chunkiness” of the original version’s particles. And that is not just their form (I use r_particles 2). In original DOS version and in WinQuake go really close to the wall and fire the shotgun. You will see particles are pretty small. Then start moving away backwards and keep firing the shotgun. You will see particles actually getting bigger at certain distance. In GL variants it’s sort of the other way around - bigger particles up close, way smaller particles in the distance.

28

I remember vaguely something like that in the ‘Quake 2’, also in the matter of difference between the GL and the software rendering; the particles in the software mode, were big at the distance. It is actually something I thought of as being better with the GL, where particles, would seem properly smaller.

29

Returning to the case of the axe in ‘Quake’, I think it is terrible crime that the weapon originally lacks a sound effect - not to even mention a beefy sound effect - upon a solid chop. Perhaps it was quasi deliberate design choice, suggesting the axe, should have some “stealth” value; an afterglow of ‘Quake’ as an RPG notion, I speculate. No make sense. Good that ‘Copper’ mod does a great job fixing the issue, alongside minor balancing things out. The axe in ‘Copper’, as far as I recognize, is roughly an equivalent to the primary rifle, in terms of pace and damage. Fine in terms of damage, I would say - making such and such amount of clean hits per enemy a guaranteed frag - but in terms of pace, the axe, should be just a little bit more effective - a little bit swifter - than the rifle.

The ‘Arcane Dimensions’ Shadow Axe, is a noteworthy example of the axe, making a functional return beyond just the damage; but even solely in terms of damage, it is a major perk. I am not entirely satisfied with the feel of the warhammer in ‘Quoth’; the animation, appears faint and lacking. Enemies hit by the warhammer, should have higher chance to gib upon being fragged, maybe.

30

Mouse sensitivity, to my experience, is relative to the field of view: the bigger the FOV, the higher the mouse sensitivity, should be.

Understandably, the controls - including the mouse sensitivity - have many systemic dependencies and could vary, relative to those; while the ultimate evaluation of the outcome, is the user experience. That is why, the customizability of controls, is of such importance.

I have a theory, nevertheless, regarding “SDL2”-compliant environment; that the arguably good mouse sensitivity, equals FOV divided by ten.

31

For the cosmetics, here are a bunch of c-vars that I use regarding the onscreen makeup:

scr_showfps "0"

crosshair "1"
scr_crosshairscale "1"

scr_conspeed "3000"	// speed of engine console manifestation

scr_centertime "4.5"	// lasting of narrative feedback
con_notifytime "1.5"	// lasting of engine feedback

scr_printspeed "12"	// speed of final credits roll

The “crosshair”, works as a toggle - either “0” or “1” - while the “scr_crosshairscale” value, can be escalated.

The “scr_printspeed”, could perhaps be slightly further increased - say, to a value of “16” - from the default of “8”.

In the end, according to my trajectory of thinking, every mod, should respect the player config - represented, in a customary way within the ‘idTech’ engines, under the “autoexec.cfg” file - as the final say over negotiable matters. This, roughly means, the “autoexec.cfg”, should be executed only after non-critical setup, not before. If a mod does introduce some specific, critical setup, requiring to override possible player script, it ought to be made transparent in a mod description, as already mentioned somewhere before in this thread.

For the fast-setup of new maps and mods under the ‘Quake’ folder umbrella - when these are put apart from the “id1” directory - I guess the most efficient way, is to copy-paste a trusted “config.cfg” into the newly installed folder.

32

The “quickaxe” function, mentioned before in this thread - https://www.quaddicted.com/forum/viewtopic.php?pid=5213#p5213 - appears to work most well with more modern engines and environments. The eventual, possible collision, appears on the line of trying to - function-wise - constantly invoke the axe weapon - repeated “impulse 1” - while simultaneously, demanding to be executing an attack with it. The engine, must have polished patterns of prioritization or task logistics, in order to flawlessly execute this perplexing, but script-wise simple demand.

Unless, I am estimating the engine behavior wrong - since the two tasks in question, are separated by a semicolon and thus given proper, linear order - therefore, the trigger-button press, could just once invoke the “impulse 1”, afterwards passing to the “+attack” phase, which lasts as long, as the trigger-button, is being continuously pressed. In such case, the problem, appears resolved, since there is no simultaneous call for two separate tasks; but if so, why the occasional issues?

I was thinking on how to break the “quickaxe” script down into more simple chunks, in order to possibly eradicate the mechanical confusion of two parallel demands being sent. The problem is, the entire deal, has to be focused around the use of only one trigger-button.

For now, the trigger-button in question, has two parallel actions bound to it; the weapon switch and the attack. I was thinking if perhaps, the weapon switch, could be initiated first and separately, in order to then rebind the trigger-button, to an attack action only:

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

The problem with this way out, is that the fluency of action, suffers - after the trigger-button initiation, the weapon will change to axe, as well as the rebinding will be done; but in order to attack, another initiation of the same trigger-button, will be demanded - making it effectively a double-tap-and-hold type of action; not as swift as originally intended. In fact, this pseudo-sequencing of taps and holds, is simply a virtual way of creating more than one input-trigger, out of just one input-trigger.

For the note, in the case discussed, common “+attack” function - bound to primary key of choice - can also be used, once the weapon changes to an axe - it makes no difference, since the action in question, is anyway the “+attack” from then on.

For theoretical completion, in order to restore the function of “quickaxe” to original state after having it rebound to “+attack” only, every weapon switch away from an axe - either by traditional key or inventory scroll - should additionally involve the following part, as parallel:

bind MOUSE2 quickaxe

Making it look like something of sort:

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

bind "MWHEELUP" "impulse 12; bind MOUSE2 quickaxe;"
bind "MWHEELDOWN" "impulse 10; bind MOUSE2 quickaxe;"

Potential problem with this clunky but more bulletproof solution, is that, if the player finds way to switch weapon to another, outside of the foreseen pathways, the function of “quickaxe” and ultimately an access to the axe, becomes disabled, until any of the familiar triggers, are invoked.

33

I may have drawn the incompatibility conclusions, regarding the “quickaxe” function, too early - the case seems more mod-related. Anyway, still good to have an alternative, just in case.

Regarding the case of double-taps and holds, once I have had an idea for weapon reloading mechanics in the FPS games; adding to “realism” factor, hopefully. Not particularly a ‘Quake’ thing, but it has to do with pacing the gameplay, quite a big time.

The idea, is that in order to reload a gun, there would be two ways to choose from: either sparing the ammo remaining in the gun, which is the slow way - or to discard the ammo remaining in the gun, which is the fast way.

In order to reload a gun the slow way - sparing the remaining ammo - one would have to hold the reload key, for a certain time; possibly depending on the amount of ammo left.

In order to reload a gun the fast way - discarding the potential remaining ammo - one would have to tap the reload key, two or three times, depending on the settings assumed; albeit certainly more than once, lest mistakes.

The purpose, is to make the player strategize more in the way of how the fights are being approached; to make the player take concern in practical state of equipment wielded by the protagonist; as well as to apply situational, systemic or mechanic pressure in fights going wayward.

34

For the footprint, the issue in question, emerged in trying to play the following maps with a ‘Copper’ mod version “1.16”: https://www.quaddicted.com/reviews/event.html, https://www.quaddicted.com/reviews/cda.html. Both maps, by ‘Jean-Philippe Lambert’, do not require ‘Quoth’ mod to be properly loaded, even though the author, seems to mostly employ the ‘Quoth’ foundation for most of his creations. The issue mentioned, is that the axe, would “freak out”.

35

Returning to the case of strategic unbinding of certain abilities in ‘Quake’ - such as unbinding of the jump function for the map related circumstances - if the engine parses an error, that the requested key, is unbound upon the calling of, there is an alternative to unbinding: the key, can become bound to a neutral function - a function, such as “impulse 0” - in order to practically void it.

36

The newer ‘Quakespasm’-compliant engines - past version “0.93.2” - introduce a property of separate field of view for gun model rendering, which makes the gun model look the same, regardless of the common “fov” value. That is certainly useful for some users, who may have otherwise suffered the effect of relatively malformed gun vista on “fov” values well beyond the default “90” - even though it may depend on the hardware display properties, therefore could differ for different users.

I have found though that if to tinker with the c-vars of “scr_ofsx”, “scr_ofsy” and “scr_ofsz”, the new property mentioned, becomes interrupted and the global “fov”, does affect the gun model rendering - to a certain lesser degree - regardless. That is why, I have given up the search of angled gun setup for the “fov” of “90” - which ideally should have worked with every “fov” setup, if the isolation of gun model rendering, was consistent enough. Anyhow, my default in majority of games employing ‘Quake’-compliant field of view scale, is “105” and I am happy enough with it, minding the hardware I have.

Method to reconnect the gun model rendering with the common field of view characteristic - the way it was before ‘Quakespasm’ version “0.94.0” - is to disable the “cl_gun_fovscale” c-var, which by default, is enabled.

I think it ultimately remains the question of personal preference, who chooses what and what works for whom; if someone is fond of very high “fov” implications, then certainly the “cl_gun_fovscale” with newer ‘Quakespasm’ versions, is beneficial to have enabled - if someone though likes to tinker with various c-vars to personalize the game - such as myself - then I find it simply easier and more consistent to deal with, having the “cl_gun_fovscale” disabled; perhaps because I am simply used to such way of function.

My preferred gun positioning setup is tailored to the “fov” value of “105”, simply because it works well enough for me; it may not be good enough for someone with different hardware or different deal of expectations.

For the notion of “angled gun setup”, I do realize it is not a novel idea - not even in ‘Quake’ - nor any tech achievement to complete; if I can do that, anybody fairly reasonable, could. I have seen plenty of mods doing the same thing, albeit few of them openly embracing the “autoexec.cfg” form. My way is not original in terms of uniqueness, but it is genuine, as I have come to my conclusions, myself.

EDIT:

The outcome of non-conventional “scr_ofsx” seem unaffected; the affected outcomes relate to custom values of “scr_ofsy” and “scr_ofsz”.

37

The “cl_upspeed” c-var with increased value - the value of “350”, taken after the “cl_sidespeed” parameter - responds only to “+moveup” function, with “+jump” being unaffected underwater in terms of resurfacing speed. Which means that apparently the “swim up”, remains a detached movement function from the “jump”, when it comes to underwater application, despite what the controls section descriptions say in the game, about their possible situational interchangeability.