#26 2021-08-08 06:43:02

triple_agent
Member

Re: Pace of movement and other useful c-vars

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:

Gila wrote:

This is a config I got familiar in 97 or 98 when I finally switched to mouse.

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

Last edited by triple_agent (2021-08-08 06:44:29)

#27 2021-08-08 08:12:39

Gila
Member

Re: Pace of movement and other useful c-vars

triple_agent wrote:

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.

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 2021-08-08 17:11:27

triple_agent
Member

Re: Pace of movement and other useful c-vars

Gila wrote:

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.

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.

Last edited by triple_agent (2021-08-08 17:27:30)

#29 2021-08-09 06:52:29

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-08-09 07:56:34)

#30 2021-08-17 03:22:16

triple_agent
Member

Re: Pace of movement and other useful c-vars

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 2021-08-18 05:21:03

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-08-18 17:38:42)

#32 2021-08-24 16:32:41

triple_agent
Member

Re: Pace of movement and other useful c-vars

The "quickaxe" function, mentioned before in this thread - post link - 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.

Last edited by triple_agent (2021-08-24 17:57:10)

#33 2021-08-25 03:51:46

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-08-25 05:11:40)

#34 2021-08-25 18:15:43

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

For the footprint, the issue in question, emerged in trying to play the following maps with a 'Copper' mod version "1.16": Event Horizon, Castle of the Dark Ages. 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".

Last edited by triple_agent (2021-08-25 18:18:14)

#35 2021-09-29 07:49:32

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2021-09-30 05:00:15)

#36 2022-01-31 21:14:01

triple_agent
Member

Re: Pace of movement and other useful c-vars

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

Last edited by triple_agent (2022-01-31 22:16:19)

#37 2022-02-26 22:16:34

triple_agent
Member

Re: Pace of movement and other useful c-vars

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.

Last edited by triple_agent (2022-02-26 22:18:25)

Board footer