''cg_allowTaunt ''1'' Personally I was overjoyed when this cvar was implemented and made it 0 the second I heard about it.'' ahahaha

This cvar has never actually worked for me for some reason

The animation is there but the sound is gone I think

Yes that is how it works.

I wish the animation could be disabled as well but this would probably be really difficult to code since then you would have a model motion that would be seen by some players but not others.

Maybe the same technique used to make playerlean could be used on it. Hard to say.

They might have to go out of their way to make it happen but I wouldn't call it "really difficult".

I reckon the biggest command every Quaker needs to know is /cvarlist *[put name here]*

This allows you to find commands on your own instead of asking people. So say you wanted your lightning gun to do that wobbly thing but you forgot the name of the command, you'd just go /cvarlist *lightning* and it will spit back all the commands that contains the word lightning somewhere in it.

Looking through your commands, here are 2 cents.

I find cg_drawFragMessages 1 is pretty helpful in TDM or team modes like iCTF where spawn frags are important. You don't need to put your crosshair on spawn locations until you see someone on the other team die.

Fraze uses cg_screenDamage to tell the direction of people attacking him.

I use cg_railTrailTime of less than 1500 (think mines on like 1350 or something) and I use this to help my rail dodge. I use a smaller value than the reload time because of the time it takes me to start moving again and be on the other side of the opponent's crosshair.

I totally recommend r_dynamiclight 1 as you can see flag carriers and power-up carriers around corners and through walls/ceilings. You can literally see a quad carrier's aura through a thick floor.

r_subdivisions 80 is very useful for learning and do some movement tricks consistently. For example, on Campgrounds doing a Rail to bridge jump from various points along the curve is easy since it breaks up the curve into points you can you start from.

Setting r_teleporterFlash 0 adds a tiny advantage when playing people in the same room. From experience I can tell you that duelling someone on ztn in the same room you both know when someones gone through teleporter since the room suddenly turns white for a sec haha. Making it black prevents giving this information to that person.

One command you've left out is net_restart. This command actually changes my ping to some servers. I'm guessing different routing is found to the server. It's basically the same thing as just reconnecting but it's just quicker to do it in game with net_restart.

Thanks for the input. Some comments:

I find cg_drawFragMessages 1 is pretty helpful in TDM or team modes like iCTF where spawn frags are important. You don't need to put your crosshair on spawn locations until you see someone on the other team die.

drawFragMessages just draws the "You fragged such and such" in the center of the screen. It does not affect the obituaries part of the hud which is in the top left by default.

Fraze uses cg_screenDamage to tell the direction of people attacking him.

I can't imagine that he actually needs this, especially as a duelist.

I will reevaluate my position on it though. I just think all things considered it will still end up being better off.

I use cg_railTrailTime of less than 1500 (think mines on like 1350 or something) and I use this to help my rail dodge. I use a smaller value than the reload time because of the time it takes me to start moving again and be on the other side of the opponent's crosshair.

Well the default is 400 so that would be the 'normal' setting, and that's less than 1/3rd the reload time.

I'm a little confused by "the time it takes me to start moving again". Are you standing still when you rail or somt? I'm sure you meant something different. I apologize for not understanding but can you clarify?

I totally recommend r_dynamiclight 1 as you can see flag carriers and power-up carriers around corners and through walls/ceilings. You can literally see a quad carrier's aura through a thick floor.

I did mention exactly this. I just find that this doesn't justify how distracting it can be. I think I gave it a fair shake in the recommendation.

r_subdivisions 80 is very useful for learning and do some movement tricks consistently. For example, on Campgrounds doing a Rail to bridge jump from various points along the curve is easy since it breaks up the curve into points you can you start from.

Ok. I will consider working something along these lines into the recommendation text.

Setting r_teleporterFlash 0 adds a tiny advantage when playing people in the same room. From experience I can tell you that duelling someone on ztn in the same room you both know when someones gone through teleporter since the room suddenly turns white for a sec haha. Making it black prevents giving this information to that person.

No, teleporterflash is entirely client side. It is simply a visual effect. It makes the screen entirely white when set to 1, or entirely black when to 0 for that split second that you're in the transition between points.

It can be seen best in devmap, setting timescale to a low value like 0.1 and going through a teleporter, for example the one on vertical vengeance. This makes all events take longer and so the transition can be seen.

It can also be seen sometimes on a laggy server, or if you happen to lag right when going into a teleporter.

One command you've left out is net_restart. This command actually changes my ping to some servers. I'm guessing different routing is found to the server. It's basically the same thing as just reconnecting but it's just quicker to do it in game with net_restart.

I agree with you. I will seriously consider adding it.

What I have a hard time believing is that it actually lowers a ping time. I think it is much more likely that there is some issue with how the ping is being displayed, and this gets affected by net_restart.

It does however sometimes allow a client who has a very high lag spike to start moving again when they've been immobilized by the lag and have the phone jack icon showing. It kind of asks the system to "reconsider" its connection, possibly fixing something that is out of sync.

Again, thanks for the feedback.

You misunderstood the teleporter flash thing, it's pretty much only useful when the two duellers are in the same physical room. :P As for the screendamage, Fraze has come over my place before and was wondering what was so different about his config on my system, then he realised his screen damage wasn't on xD As for the rail time the way I dodge and the time I have it fade it's at a perfect balance so as soon as I see the rail fade my reflexes kick in and dodge the right way.

And lastly the net_restart, I have a few pings I can get to Sydney server, 59, 65 or 70. Doing net_restart changes the ping to one of them. It's not a text error too because Western Australia has a direct line to Singapore so we get 59 ping there but randomly we get >200 ping. So many WA'ers had to leave and come back till it was 59. But doing net_restart just does the same thing.

You misunderstood the teleporter flash thing, it's pretty much only useful when the two duellers are in the same physical room. :P

I don't understand.

Per update that added the cvar:

Added the option of a simpler black frame fill rather than the white flash that occurs when teleporting (r_teleporterFlash 0).

If it's an entirely client side graphic then what difference does it make who is in a room?

If you see it in other places can you give me a screenshot? Or perhaps I am still misunderstanding you.

lol. I'm saying if it's set to 1 so that it flashes white it illuminates the room your body occupies with a white colour. The room I speak of is not in Quake but in real life!

Mind = blown.

Ok :-P

:)

i remember a discussion, that some players have a binding, thats like "r_gamma 10 ; wait ; r_gamma 1" to FAKE a teleporting

rapha: 5 binds ahead

Wow, that's incredibly devious! Cool though!

Why did I never think of this :()

subdivisions 80 is a must, anything else draws walls where there are none (= you can shoot but not see through 'walls').

i would also recommened to use a low railtrailtime and to not use switchtoempty 1, you should be able to tell when running out of ammo and switch to the weapon you want, not the one next in line.

i would also recommened to use a low railtrailtime

What for? I can think of reasons but what is the reason that you would give?

and to not use switchtoempty 1, you should be able to tell when running out of ammo and switch to the weapon you want, not the one next in line.

Did you mean switchOnEmpty instead of switchToEmpty?

Switch to empty is handy, for example on furiousheights if you are out of rockets at red armor, you can switch to RL, then go through the YA tele and pick up the rockets and start shooting immediately instead of picking up the rockets first, then switching, and _then_ shooting.

As for switchOnEmpty I will reevaluate it. I believe my original experiments revealed that it was faster for it to auto-switch to some weapon so I could at least shoot with something than for me to decide what to switch to/switch to it.

railtrailtime? with this set to over one second i realized i'd line up the second railshot in a row in comparison to where the trail of the first one was, but that's a bad habit imo, you should just aim at the opponent and press attack :)

it's confusing you with an unreliable (ping/prediction) source of information that's not that useful to begin with.

i meant switchOnempty, switchToempty is important too but i see no reason for anyone to disable that in the first place.

switchOnemtpy 1 isn't faster than 0 btw. as a human you will know in advance when you're going to run out of ammo and switch right before that happens.

with 0 you're going to run out and then let quake switch to a random weapon that may or may not be useful to you in that situation, not something you want. it's just a bad habit too (imo) ;) learn to do the right thing etc. instead of relying on crutches.

with 0 you're going to run out and then let quake switch to a random weapon that may or may not be useful to you in that situation, not something you want. it's just a bad habit too (imo) ;) learn to do the right thing etc. instead of relying on crutches.

Ok, I will consider giving it a fairer shake.

switchtoempty is very important in duel. often you are out of lg ammo , but enemy afraids attack you, when he hears bzzzzzzz.

yea, same thing in tdm: overlooking a room with rail out makes little green enemies disappear in fear, wether you got ammo or not :p

oh and btw, i'm pretty sure you are wrong about the hitbeep/network lag connection, that does not make any sense ;) the client receives the information from the server with either setting.

hitbeep 1 is simply the much less annoying sounding beep, especially for lg/mg because of the high firing rate and low damage output (in comparison to hitbeep 2, the default setting afaik).

/edit: typing is still hard right now :S

oh and btw, i'm pretty sure you are wrong about the hitbeep/network lag connection, that does not make any sense ;) the client receives the information from the server with either setting.

I'll reword this to be more objective.

The delay might not be caused by the server/client connection, but instead by the extra processing involved as it needs to grab this info from memory at least to decide what sound to play as opposed to playing the sound immediately.

I would still like to run the tests to prove that there is a delay.

what do you base this is on, any source you can give?

if it's just a hunch you had after taking a look at some of the configs posted on esr than i'm rather sure that what i wrote is true (people using hitbeep 1 coming from q3 and being annoyed at hitbeep 2).

No it's not just a hunch. I tested it, and it definitely seems to result in faster repetitions. I agree with you though that I should have something with more scientific rigor.

As for a source I don't have one, but it is true that the game must process this extra information with hitbeep 2 or 3. So there most certainly is a delay. The issue is proving that this delay is not negligible.

Another theory is that the sound itself is somehow perceived more quickly. I hope this isn't the case since it will take a lot of work to show that.

I admit that at this point I don't have enough evidence to disprove a placebo outright, but I am working on gathering the tools necessary for a rigorous analysis. Please be patient.

maybe i'm completely missing something here, but afaik the information gets processed anyway, the sound played will simply be different depending on the setting.
remember for the 'pain/hit sounds' to be correct the same information is needed.

'player x gets hit by y damage resulting in z health/armor left' needs to be processed for both?

There are four settings for cg_hitbeep.

0 is off.

2 - Plays a high pitched tone for low amounts of damage, low pitched tone for high amounts of damage.

3 - Plays a high pitched tone for high amounts of damage, low pitched tone for low amounts of damage.

1 - Plays the same pitched tone regardless of damage. It does not need to consider damage information before being played.

yea, i know that.
when 2 was first introduced 3 was missing (iirc) hence some people reverted back to 1 for lg/mg while still getting the benefits of 2 for other weapons.

but whatever, it's your guide. i personally wouldn't include settings for which you don't know anything definitive and base your recommendations on "feel". that's exactly the kind of stuff newer players do not need in their configs.

yea, i know that.
when 2 was first introduced 3 was missing (iirc) hence some people reverted back to 1 for lg/mg while still getting the benefits of 2 for other weapons.

Per Quake Live September 2009 update:

cg_hitBeep
This replaces the old hitBeep based on the ammount of damage dealt. A very popular setting is cg_hitBeep 3, which makes low damage have a low pitched beep, while high damage playing a high pitched beep.

So perhaps something akin to hitbeep 2 was forced (no hitbeep cvar) in a previous update (I remember noctis saying, why is no one freaking out about this?) over the old hitbeep which just beeped if there was a hit or not. This way players had an option.

but whatever, it's your guide. i personally wouldn't include settings for which you don't know anything definitive and base your recommendations on "feel". that's exactly the kind of stuff newer players do not need in their configs.

Your "protest" is duly noted and is being taken seriously. I have already gathered the tools and am in the early stages of analysis. It is more difficult to analyze sound than I thought it was.

Yes I am taking a risk that I will be incorrect. I think the theory at least is sound if the evidence a bit shaky. Time will tell.

I don't think hitbeep 1 will do any harm to anyone's config, after all I've only recommended it for weapons that do not have a variable damage. I understand your concern that players having cvars in their configs based on false info is a bad thing though!

i don't think you understood what i meant with 'pain sounds' btw, those have nothing to do with hitbeep but also need the same damage information to function correctly.

No I sure don't.

The "pain sounds" such as keel's sounds here:

http://www.youtube.com/watch?v=n7n1xxZCyEg

Involve enemy health information and not damage information.

The damage test is going to be different from the health test.

yep, needs same info though. enemy health - damage = new enemy health, right?

for both you need a registered hit and the server decides if a hit is a hit (backwards hit reconciliation). it's not like the pain sound is delayed or anything like that.

do your tests though, prove me wrong :)

yep, needs same info though. enemy health - damage = new enemy health, right?

Enemy health might not be fully known to the client. For example if you record a demo, and watch the other pov in wolfcam, health is not shown. It isn't shown presumably because it doesn't have that info. You could argue that the client does have this info, but that it is not saved in the demo however.

Maybe the server just sends something to the effect of "health is in this range so this pain sound applies".

Really though the pain sounds are played very rarely in comparison to the hit sounds. With the kind of ranges we're considering it can be a bit delayed and no one would notice or care.

If the client does not wait for the server to confirm a hit, then you could have hit sounds being played when there wasn't a hit. So far no one has reported such a thing. That tells me that it waits for a Yes from the server on whether a hit occurred or not.

This would also apply to what type of hit. For example with the rocket, if it is a direct or just a splash. Let's say that the client gets this information regardless of its hitbeep (extremely likely).

It still has to run a test. Let's say for purposes of discussion that a miss is a 0, a splash is a 1, and a direct is a 2.

Hitbeep 1 just needs to do like a boolean test, if hit > 0 then play hit.

Hitbeep 2/3 needs to do like a switch/case type thing. If hit 1 play this, if hit 2 play that. Default 0. This is slower than a simple yes/no test. There are actually 3 or 4 tones so it needs a case for each one.

It could definitely be argued that all of this is so fast that there's no chance of a delay, but this extra processing must exist.

do your tests though, prove me wrong :)

I'm working on it! :-)

Small update:

I haven't tested it online yet, and I'm still working on the sound analysis part, but I found something interesting.

I set con_timestamps to 1, then used s_show on localhost and examined each hitbeep. They appeared to be the same, but I was surprised to find that with 100 % LG they weren't all played at exactly 50 ms intervals which is what it should be since the LG hits every 50 ms. (it did show that 10 hits = 10 sounds regardless of beep though, and I am confident that it behaves this way online.)

Instead it fluctuates, 44 ms, 60 ms, 54 ms. I believe it fluctuates in a predictable pattern though. I don't really trust con_timestamps to millisecond accuracy, and also s_show is devmap only so I cannot use this technique online :-/

However, some very tenuous (and very possibly incorrect) analysis of the spectrogram seems to indicate that this fluctuation does in fact exist, giving it a kind of "rolling" sound. This makes analysis of the latencies between beeps more difficult to analyze.

Like I said earlier, IF I cannot see a latency, I might try to show that the beep is somehow "percepted" better/earlier/whatever. I believe I have one very small chip in the scale on that if you take a look at these spectrograms:

http://img844.imageshack.us/img844/3750/hbspectrograms.jpg

These are each exactly 6 second intervals of each hitbeep at 100 % LG on localhost. The white part represents the actual beeps. The larger gaps are part of the oscillating sound of the LG firing. I don't know why they are so covered up in the first graph, but pay them no mind.

Notice though that the tiny gaps however can actually be seen with hitbeep 2 and 3, but not with hitbeep 1 which tells me that hb 1 seems more continuous to the spectrogram, which might mean it gets percepted as being more continuous in the brain.

It's a very tenuous link I know, but I thought it was worth mentioning/showing.

if you can, don't do your tests on localhost (a listen server). atleast go through the trouble of setting up a small lan and a dedicated one. latency on a listen server could be anything, as you are client and server in the same process.

i thought the question was rather, what does the server send to the client and when does it do that? in other words: can we exploit the sound system in a way that does give us an advantage over other players?

you can't prove that on a listen server. good work though, don't stop :d

if you can, don't do your tests on localhost

I said I haven't tested it online yet! I plan to!!

It's just that if localhost shows a delay it's a strong indication that the theory is true.

In fact assuming the client already has the information when online, and then does the processing locally, it would render the localhost test very likely similar if not congruent to the online test.

Also, testing localhost first is handy for me to get accustomed to all the annoying quirks of the tools.

i thought the question was rather, what does the server send to the client and when does it do that? in other words: can we exploit the sound system in a way that does give us an advantage over other players?

I suspect that the hit yes/no, direct hit/splash info is sent in the same snapshot such that the delay would come from the extra processing involved in having it choose the sound with hitbeep 2/3. It could turn out not to be the case I suppose.

please keep us updated! :)

Another issue is that I am using s_mixahead 0.07, as opposed to the default of 0.140.

I am not sure how this effects the results. I'll have to retest with 0.140 and compare them :-/

It might be worth noting that in the hit.wav, there is about 55ms of silence before the sound actually plays. if the quake engine generates different pitches by slowing down or speeding up playback rate (very common and inexpensive way to achieve this), then the delay between the sound being triggered and it being audible will vary with the amount of damage done when hitbeep is 2 or 3.

This will also mean that at higher pitches, you will have less delay between doing damage and hearing the hit sound, and there will be more time between each sound as the length has decreased.

It might be worth noting that in the hit.wav, there is about 55ms of silence before the sound actually plays.

The evidence I have says that this is not true.

The files are:

hit1.ogg (hitbeep 1)
hit0.ogg (hitbeep 2 for LG)
hit3.ogg (hitbeep 3 for LG)

Analysis of these samples shows that they are 140 ms in length, with ~15 ms at the end being silent. The first 2 ms of the track is also inaudible.

if the quake engine generates different pitches by slowing down or speeding up playback rate (very common and inexpensive way to achieve this), then the delay between the sound being triggered and it being audible will vary with the amount of damage done when hitbeep is 2 or 3.

It doesn't do this on the fly since with s_show you can demonstrate that different sound files are being accessed. It very well may work this way in terms of how the sound files were created though, and this is a very important point!!

The sound samples aren't exact in length!

hit1.ogg is 139 ms
hit0.ogg is 124 ms
hit3.ogg is 175 ms

Of course without analyzing their silence and distance between one another the issue is still unclear. However this may be a very important thing to consider in the coming analysis.

Thanks for this info! I am surprised I didn't notice it before.

This will also mean that at higher pitches, you will have less delay between doing damage and hearing the hit sound, and there will be more time between each sound as the length has decreased.

A brilliant approach! I think it requires more careful analysis though. The tracks have different amounts of silence, and I am not certain just how they are played yet, as my original idea that HB1 is played with less latency could still be true.

Thanks for this information!!

Ah sorry. I just looked in the q3 pak assuming ql used the same resource.

No, this is important info even if it doesn't work the way you might have thought.

I thought they were all the same length (125 ms with 15 ms silence) but they aren't.

So we have 3 different sound files, with 3 different lengths, with 3 different amounts of silence, being played at intervals that fluctuate albeit likely in a repeating pattern.

Sheesh! I'm afraid of what complication comes next!

why are you playing with mixahead this low? i know noctis uses 0.12 and i did play for a while with 0.1, but that's about as low as i'd go.

I set it as low as it would go just in case it causes any sound delays :-)

Also I like the fact that timedemo scores skyrocket :-)

0.07 is the lowest I can go without getting crackling or worse.

Instead it fluctuates, 44 ms, 60 ms, 54 ms.

tl;dr but isn't it because of mixer's delay? You can see mixer's delay on linux and I remember it was fluctuating.

Can you elaborate on this? Does the mixer fluctuate in similar intervals?

[0:00.000] alsa latency: 65ms
[0:00.000] mixer latency: 568 frames (25ms)
[0:00.000] mixer latency: 769 frames (34ms)
[0:00.000] alsa latency: 57ms
[0:00.000] mixer latency: 257 frames (11ms)
[0:00.000] mixer latency: 419 frames (19ms)
[0:00.000] alsa latency: 72ms
[0:00.000] mixer latency: 419 frames (19ms)
[0:00.000] mixer latency: 603 frames (27ms)
[0:00.000] alsa latency: 64ms
[0:00.000] mixer latency: 603 frames (27ms)
[0:00.000] mixer latency: 772 frames (35ms)
[0:00.000] alsa latency: 56ms
[0:00.000] mixer latency: 260 frames (11ms)
[0:00.000] mixer latency: 441 frames (20ms)
[0:00.000] alsa latency: 71ms
[0:00.000] mixer latency: 441 frames (20ms)
[0:00.000] mixer latency: 623 frames (28ms)
[0:00.000] alsa latency: 64ms
[0:00.000] mixer latency: 623 frames (28ms)
[0:00.000] mixer latency: 781 frames (35ms)
[0:00.000] alsa latency: 55ms
[0:00.000] mixer latency: 269 frames (12ms)
[0:00.000] mixer latency: 465 frames (21ms)
[0:00.000] alsa latency: 71ms
[0:00.000] mixer latency: 465 frames (21ms)
[0:00.000] mixer latency: 621 frames (28ms)
[0:00.000] alsa latency: 63ms
[0:00.000] mixer latency: 621 frames (28ms)
[0:00.000] mixer latency: 794 frames (36ms)
[0:00.000] alsa latency: 52ms
[0:00.000] mixer latency: 282 frames (12ms)
[0:00.000] mixer latency: 530 frames (24ms)
[0:00.000] alsa latency: 69ms
[0:00.000] mixer latency: 530 frames (24ms)
[0:00.000] mixer latency: 662 frames (30ms)
[0:00.000] alsa latency: 62ms
[0:00.000] mixer latency: 662 frames (30ms)
[0:00.000] mixer latency: 829 frames (37ms)
[0:00.000] alsa latency: 50ms
[0:00.000] mixer latency: 317 frames (14ms)
[0:00.000] mixer latency: 578 frames (26ms)
[0:00.000] alsa latency: 64ms
[0:00.000] mixer latency: 578 frames (26ms)
[0:00.000] mixer latency: 776 frames (35ms)
[0:00.000] alsa latency: 56ms
[0:00.000] mixer latency: 264 frames (11ms)
[0:00.000] mixer latency: 439 frames (19ms)
[0:00.000] alsa latency: 72ms
[0:00.000] mixer latency: 439 frames (19ms)
[0:00.000] mixer latency: 596 frames (27ms)


Looks bad but my system is fine tuned for powersaving rather than real-time audio processing. Dunno if it's the same on windows - there isn't such cvar in windows client.

That's very interesting. Those values are a bit higher than what I encounter in-game, which tend to go between 40 and 60.

What were you doing when this log was taken?

Also the intervals according to s_show were unaffected by s_mixahead in QL. The system mixer is something different I know but I thought it was worth noting.

I had some yt video running in the background. When I turned it off the numbers were the same.

This is the output with s_alsa_pcm hw:0 (no system mixer)


[0:00.000] alsa latency: 39ms
[0:00.000] mixer latency: 1903 frames (86ms)
[0:00.000] mixer latency: 2063 frames (93ms)
[0:00.000] alsa latency: 39ms
[0:00.000] mixer latency: 1903 frames (86ms)
[0:00.000] mixer latency: 2064 frames (93ms)
[0:00.000] alsa latency: 37ms
[0:00.000] mixer latency: 1872 frames (84ms)
[0:00.000] mixer latency: 2063 frames (93ms)
[0:00.000] alsa latency: 39ms
[0:00.000] mixer latency: 1903 frames (86ms)
[0:00.000] mixer latency: 2064 frames (93ms)
[0:00.000] alsa latency: 33ms
[0:00.000] mixer latency: 1776 frames (80ms)
[0:00.000] mixer latency: 2064 frames (93ms)
[0:00.000] alsa latency: 42ms
[0:00.000] mixer latency: 1968 frames (89ms)
[0:00.000] mixer latency: 2064 frames (93ms)
[0:00.000] alsa latency: 39ms
[0:00.000] mixer latency: 1904 frames (86ms)
[0:00.000] mixer latency: 2064 frames (93ms)
[0:00.000] alsa latency: 37ms
[0:00.000] mixer latency: 1872 frames (84ms)
[0:00.000] mixer latency: 2063 frames (93ms)
[0:00.000] alsa latency: 39ms
[0:00.000] mixer latency: 1903 frames (86ms)
[0:00.000] mixer latency: 2063 frames (93ms)
[0:00.000] alsa latency: 34ms
[0:00.000] mixer latency: 1807 frames (81ms)
[0:00.000] mixer latency: 2063 frames (93ms)
[0:00.000] alsa latency: 42ms
[0:00.000] mixer latency: 1967 frames (89ms)
[0:00.000] mixer latency: 2064 frames (93ms)


Strange. What does exactly "mixer latency" mean? What mixer? Is this an error because there is no system mixer involved?

Lorfa doesn't know ;-(

lol @ teleporterflash in the same room :DD

I think it's better on 0 anyway... setting it to 1 gives me a fucking headache.

Yeah I agree, I have it on zero for this reason :P

This is relevant to my interests.

i want a cmd that forces enemy names to red and teammates to blue in kill messages :((((((((((

i want a cmd that forces enemy nade colour regardless of uppercolor :((((((

and this and that, but here, have cg_itemfx 1-7!

gee wizz! boy-oh-boy! thanks mr!

that's all right, son. you run along now!

This is the most comprehensive list I've seen so far.

Good job

Pretty solid, it's an extensive source for the important cvars, here's some thoughts:

cg_marks 1
can be useful if you want to determine an nme spam angel while you didn't see the rocket fly, by that you can determine his position 3 seconds ago

the bit about hitbeeps and server confirmation sounds interesting as I struggle with different pings + differently delayed hitbeeps, but don't have the hits (not just the dmg) to be confirmed as well? gonna test later

cg_railtrailtime
after some time of play you should know the rail reload by time, I minimized the cvar to a value that can give me enough information about shooter + target without clutter

cg_projectilenudge
recommendation for this was to set it to your ping value, other opinion is to leave it at 0 because it will give you less time to dodge enemy rockets

cg_truelightning
cg_predictlocalrailshots
both on 1 imo because the delay on both is annoying

r_dynamiclight 1

Using r_vertexlight 1 renders dynamiclights ineffectual. However r_vertexLight 2 renables it.

da fuckk??? gonna try asap

r_lodbias vs. keel/tank
it's not just talk, look at those pictures in that ql forum thread, and try it on the server
use keel with r_lodbias -2
tankjr with r_lodbias 2

r_subdivisions
newer maps are rendered more correctly with 4 and older ones with 80, or so I've heard
also it seems to default to 4 if you don't set it in your autoexec

cg_marks 1
can be useful if you want to determine an nme spam angel while you didn't see the rocket fly, by that you can determine his position 3 seconds ago

That's an excellent point that I should have included. Will include it.

the bit about hitbeeps and server confirmation sounds interesting as I struggle with different pings + differently delayed hitbeeps, but don't have the hits (not just the dmg) to be confirmed as well? gonna test later

It definitely seems more delayed with the LG. As in I can hear the beeps occurring in faster succession at the same accuracy.

I would like to test this with better scientific rigor, but I'm also kind of lazy sometimes.

The way to test would be to record game sounds, have a player dodge back and forth against two solid objects taking care to start moving the other direction the split second they touched the sides of the barrier. Then I LG in the center such that I have a steady accuracy.

Do a bunch of trials, maybe make a 5 round CA server, and make sure to screenshot the damage info at the end. Do this with hitbeep 1 vs. hitbeep 2 or 3.

Then take the game sounds and analyze them with a sound program, find the peaks of the beeps and measure the time between them. Try to consider the weapon accuracy in the experiment for an error margin.

I'm sure this would prove or disprove the theory. Part of me doesn't want to bother with this because I swear I can hear the difference outright. Humans are fallible though and I am no exception. So yeah, would be good if I this experiment were to be run.

cg_railtrailtime
after some time of play you should know the rail reload by time, I minimized the cvar to a value that can give me enough information about shooter + target without clutter

I've personally been using 0 for quite some time now.

cg_projectilenudge
recommendation for this was to set it to your ping value, other opinion is to leave it at 0 because it will give you less time to dodge enemy rockets

This is fascinating. I was under the impression that it only affected the animations shown by your own player. Do you have any proof that it does the same for enemy rockets? It would be very interesting if it did.

The other issue is that it wouldn't shorten the time to dodge, since this is fixed server side by the speed of the rocket. It would in theory make it appear that way if the rocket was drawn further from the player's model upon shooting.

Really, I am on the fence about this cvar about it being placebo or not entirely. I have yet to run at test that proves it actually does anything.

Although recently I thought of a test that should reveal its operation but have yet to run it. Using cl_avidemo and comparing the screenshots of different rocket shots I should be able to determine where the rocket starts being drawn. It's another hassle of an experiment though.

cg_truelightning
cg_predictlocalrailshots
both on 1 imo because the delay on both is annoying

Maybe I could give them a fairer shake but a great many players use tlg/predictlocalrails < 1 and swear by it.

r_dynamiclight 1
Using r_vertexlight 1 renders dynamiclights ineffectual. However r_vertexLight 2 renables it.
da fuckk??? gonna try asap

I thought the same when I found it!

r_lodbias vs. keel/tank
it's not just talk, look at those pictures in that ql forum thread, and try it on the server
use keel with r_lodbias -2
tankjr with r_lodbias 2

Ok, maybe folk wisdom was too strong a word :-)

r_subdivisions
newer maps are rendered more correctly with 4 and older ones with 80, or so I've heard also it seems to default to 4 if you don't set it in your autoexec

The default IS 4.

..and yes I have heard exactly that. Newer maps are more "correct" at 4 than with 80. I think I should include this information.

Thanks for your input!

r_subdivisions
newer maps are rendered more correctly with 4 and older ones with 80, or so I've heard also it seems to default to 4 if you don't set it in your autoexec
The default IS 4.

what i meant is that it's one of the cvars like projectilenudge/tn (?) that get reset every once in a while automatically (bug/intended?) - I'm using an autoexec just for a handful of cvars

Ahh ok.

I've been using an autoexec pretty much the entire time I've played QL, so I am not aware of bugs related to non-autoexec use.

very useful tool for noobs. like me. thanks!

"Therefore increasing m_yaw increases both the base sensitivity _and_ the accel, as they are multiplied by it. So doubling m_yaw doubles the base sensitivity and the accel."

good to know. always felt like increasing the yaw not only upped my sens, but added some accel too. also, if bigger yaw/pitch=bigger sens/accel, then what happens to yaw/pitch when u up the dpi on the mouse? for example i used to use 400 dpi, recently went to 800 dpi on my mouse and ofc halved my sensitivity, the accel i didnt know what to do with, i just decreased it some, but the yaw/pitch i had no idea..

You don't have to adjust yaw when changing cpi.

Just accel/sens:

New sens = Old Sens * (old_dpi / new_dpi)

new accel = old accel x ((old_dpi/new_dpi)^2)

I recommend keeping yaw at 0.022 to keep things simple.

I never really bothered tinkering with pitch across different cpi values.

everyone should just switch to m_cpi imo, will save you lots of trouble when changing your setup in the future.

Something to add is that sens when zooming is not scaled properly when you change aspect ratio, even though you the have fov properly scaled.


Nice job.

Something to add is that sens when zooming is not scaled properly when you change aspect ratio, even though you the have fov properly scaled.

How do you mean? As far as I can tell sens is scaled properly. I assume by "change aspect ratio" you mean non 4:3 resolutions.

There was a bug with it, but that was fixed.

Here is a test I ran:

http://www.quakelive.com/forum/showthread.php...post247253

If I am missing something here please let me know.

What I did was that I made a manual zoom script and used +zoom on both 4:3 and 16:10, the manual zoomscript had the sens scaled properly according to the zoomsens 1 algorithm , and I was using zoomsens 1 also.

So theoretically it should be the same distance ( it would feel faster at x-axis because you see more on 16:10) when moving the mouse which it was at 4:3, but at 16:10 it was weird.

The manual script felt very similar at both aspect ratios and had the same distance in cm360 while +zoom changed as if they used the non-scaled fov value in the zoom algorithm.

or switched 3/4tan with 10/16tan without using the unscaled values.

But I'm quite certain I tested this in late-November - mid-December and I haven't been following dev news for a few months.

I'm almost certain the bug was still back then. It was fixed like recently within the last month or so, although there was no mention of its fix anywhere.

Here was the thread of the guy who found the bug:

http://www.quakelive.com/forum/showthread.php...-when-zoom

Well it's great news if its true, it means I can go back to using my native res instead of ghetto 4:3 using the native res' height :D

If you run your test again let me know the results :-)

it seems fixed from mousepad distance test, the difference in distance used to be quite apparent.

Good to hear it!

good collection. i was messing around with recommended r-settings, and then i had a nice grafic, but i lost it. i cant get it back to this. took some screenshots, because the rocket-ecplosions are a bit buggy. halp, i want this grafiksettingz , best grafix evr D:

http://www.pic-upload.de/view-17783301/shot0022.jpg.html
http://www.pic-upload.de/view-17783312/shot0025.jpg.html
http://www.pic-upload.de/view-17783314/shot0026.jpg.html

r_vertexlight "1"
r_picmip "6"

here you go

that's not picmip 6, probably 16

ohhmergahwd, ignorehwgamma 1, even got my stupid eplsions back :>

http://www.pic-upload.de/view-17785998/shot0032.jpg.html

:< actually not. lg-beam becomes ultrabright now, cant change r_gamma ...
maybe the latest radeon driver is not working properly, dunno, im out

r_ignorehwgamma "1" forces you to vid_restart after gamma changes.
I use it precisely to see my lg beam over some walls, like in Asylum, otherwise it is too bright.

Try decreasing r_mapoverbrightbits.

yeah something like this. r_gamma chages are ignored, but when u join the next game, ur eyes are melted
the problem is, that i cant change r_gamma at all atm get this message "setdevicegammaRamp failed" (if ingore is set to 0)
not sure if the new ati driver is fukked. on some settings it worked for a while, but messed with desctop

ah, i wish i had ignored this thread, now i cant play any more

Not going to read this yet but bang it on the wiki. You're already on

http://www.esreality.com/wiki/Cg_filter_angles

Started to do cvarlist but think it has old commands so started to make a script to get cvars from console dump. Can't remember how far I got but remember console dump being a bit shitty - some cvars over multiple lines cant remember psised.

How do I "bang it on the wiki" exactly? Er, what way would you recommend I do so.

ESR Wiki, 10/10 would bang.

great guide!
maybe add Visual Hud to your suggestions, it's very useful and easy making custom huds with it.

Ok will do!

Thanks for the input!

r_enableColorCorrect "1" - if set to "0" u can no longer change r_gamma! (+get mad n´stuff)

r_enablepostprocess "1" - if set to "0" the keels are no longer bright and shiny. bitches love their keels bright and shiny!

Something ain't right with your settings then. I've always had color correct set to 0 and I can change gamma just fine. I also have post process off and I don't think enemy colors could get any brighter.

http://i.imgur.com/vOizTz6.jpg
This is with post process 0, color correct 0, gamma 0.9, ignorehwgamma 0

Unless they've changed something, color correct only works when you have post process enabled. Now, it could be that if you use post process and set color correct to 0, then you might have a problem changing gamma. I've never tested that setup before. Or you might not be able to change gamma because I'm assuming you have ignorehwgamma at 1?

And as for ignorehwgamma, it would seem to only benefit people that play across different computers, with different settings (possible lan environment). Which I can then understand why there are some pros that have it set to 1. But from what I can tell, for a lot of people, setting it to 1 just complicates things by having to enable other cvars (post process and related). Not to mention taking a performance hit for having post process enabled. Maybe lorfa knows for sure, but I was under the impression that when using post process, it disables ignorehwgamma 1?

hmm, i have no clue actually. my setup was totally fukked up the last days. maybe its all ATI related? i may check it later again, but not now, lol

Are you on linux?

It's because you have r_ignorehwgamma set to 1.
Do a vid_restart after you change gamma.

Unless you have also r_enablecolorcorrect 1 which allows you to instantly change gamma again.

love this graphic, could you please upload your cfg?

no clue how you managed to get such a low gamma (dark surroundings, walls especially) whilst maintaining a bright keel and a not-washed-out crosshair (that's what r_ignorehwgamma does to me)

Here's my full autoexec:
http://pastebin.com/tNg118Hq

Here it is with just video/game settings (no binds, scripts, or anything):
http://pastebin.com/GjRBuHhg

Someone else asked for the hud earlier, so if you want it, here:
http://www.mediafire.com/?sswd72s3et38w90

There's that tox style movement key setup.

CTRL for attack though? How do you have a pinky left?

Why have the index finger set to such menial tasks, or do you hit s and d with the index and middle fingers?

Yeah, my middle finger sits on s and index on d. Haha, when I played regularly my pinky would have a callous on the side. I've tried using shift or capslock for +attack and using my ring finger, but it just never felt right. With my hand resting nauturally, my pinky sits like right between ctrl and shift. Back in q1 I used kb only, the arrow keys to move with my right hand and the configuration for my left has been pretty much the same since then.

Yeah, my middle finger sits in front of you for using a convoluted control scheme :)

lol. It always felt natural to me, from q1 to q3, I just put the right hand from the arrows to the mouse. Left hand was already used to that setup so I never bothered. I've tried WASD in the past, even after getting used to it I never noticed any benefit over my regular setup, so I just went back.

Draws reward symbols such as a yellow skull for excellents (two frags in two seconds), and a rail symbol for excellents (two rails in a row).

I think yuo mean impressive there :)

Oopsie. Fixed.

Thanks for catching that.

Some would say that a smaller crosshair is more precise, others would say that a large crosshair helps you to chunk the geometry of the screen better.

brilliant

I have a problem with my graphics where it's bright in game but when I screenshot or stream it appears very very dark. Would you know how to fix this?

EDIT: Like here I am trying stream but it's all dark :( http://www.twitch.tv/aeol/b/359062568

I see that.

Kinda wtf. Is there no brightness option on the stream?

Well I can add brightness but that would make it look washed out. Like if I take a screenshot of my screen in quake it looks dark like that too, even though it's bright and clear while I play. D:

I believe that is linked to r_ignorehwgamma

r_subdivisions 80

I did a little bit of research and I could only find that r_subdivisions 4 makes all the doorways larger (maps tested: dm6, hub, t7, ztn) and only increases the visibility for concave curves, which are much more rare I believe.

Anyway r_subdivisions 4 makes convex curves more visible while 80 concave, but from what I've seen the effects of 4 seem much more favorable than the effects of 80

Some pictures to illustrate my point.



hub:
http://i.imgur.com/kwgjGjr.gif

dm6:
http://i.imgur.com/iOmxigr.gif
http://i.imgur.com/DxpN7xZ.gif

t7:
http://i.imgur.com/tDbR9W3.gif
http://i.imgur.com/J8pMjK7.gif

ztn:
http://i.imgur.com/L9tJTjs.gif
http://i.imgur.com/j1oYKi9.gif

Someone earlier in the thread said 80 should be better for old maps and 4 for the newer ones, are aerowalk, ztn and dm6 to be considered new?

ez solution: see which one cypher uses :D

he uses 80, would be good to know why.

you did take a look at those comparison gifs? What looks better to you?

After all these years I'm still undecided... I'm aware of the advantages and disadvantages of each. At the moment I'm using 80 because I'm too shit with the rail to take advantage of any potential pixel-rails through door frames that could be facilitated by 4, plus I like to have full visibility when my opponent is above me, such as @ GL platform or RA platform on ztn, since if I'm already above my opponent I'm already at an advantage anyway. Curverd walls @ dm6 is also one of the reasons I have it at 80.

Fair points I guess.

However, I am more inclined towards switching back to 4 as it looks much nicer and bigger doorways and such give a less claustrophobic feel and maybe can give you extra free milliseconds advantage over your opponent.

strenx uses 4, just saying...

strenx also masturbates to pictures of himself

no thx

Because when it's set to 80, it's like the real hitbox of the wall.
When the curves are on, you can hit the invisible wall with your rocket. annoying.

In fact, r_subdivision 80 force the engine to use the lowest amount of subdivisions for curves. If put to 4, r_subdivision then reacts to LoD (Level of Detail, parameter that changes depending on the distance between you and the object). r_subdivision 80 shows the real area where you can shoot through, on the other hand r_subdivision 4 shows the real clipping (invisible walls).

So you're saying that you can see some extra portion, but cannot shoot through it?

4 produces the smoother curves, so surely you mean 80 forces the engine to use the lowest amount of subdivisions for curves?

It's terribly confusing because you would logically suppose that setting subdivisions to 4 would literally make it divide curves into 4 subdivisions, and 80 to 80 subdivisions :s

The way I get my head around it and remember it is to think of the number as an abstract size of an individual subdivision.

Indeed i was a bit tired when i wrote this and inversed it. Fixed.

Wow, this is awesome! Thanks for this analysis.

Ztn is breathing!!

Mind if I put these gif links in the guide?

It really looks like 4 makes the corridors wider here, in fact it's practically proof that it does! The aerowalk one is really blatant.

Feel free to use them, re-upload and rename them. Would be glad to be contributing to your guide.

Ok! It is done, added cited etc.

Ugh, that GL ledge on ZTN.. no me gusta.

But subdivision 4 gives you one more hp, isn't it worth it?

:(

id just need to lock subdivisions at 4. 90% of the time it's better and provides very little overhead on FPS.

I would rather they make it allow any value between 4 and 80 and adjust curved surfaces accordingly.

you mean rebuild maps?

nou

I don't get it... I thought curved surfaces are variable and calculated upon loading the map, defined by r_subdivisons. Are you telling me there is one map file for subdivisions 4 and another for subdivisions 80? I highly doubt that.

do u know what the mouse log file is in the baseq3 folder?

It's probably generated by accidental triggering of cl_MouseAccelDebug 1.

In which case it is just debug info about the mouse and not particularly useful. Leave acceldebug at 0 to prevent unnecessary (albeit extremely minor) IO.

hey could smth in the cfg affect pings? i get different pings on same server upon different reconnects to my isp/diff ips

Only cl_maxpackets, maybe rate.

However those would remain at stable values unless you change them, so it's probably not the case.

Sometimes if you net_restart your ping will change. Like for example you'll get 80 to a server you normally get 50 to, issue a net_restart in console and your ping drops to 50.

This is a confirmed phenomenon, but nobody knows why it happens really. All the q3 code does is ask the OS to close/open the socket. It's odd that this would be different in QL, but at the same time QL is the only game I've ever heard of or experienced this phenomenon in.

I strongly suspected that it's a case of the ping being displayed incorrectly, as it is very difficult to conceive of a scenario in which the ping would actually increase so dramatically and be unrelated to routing/server. However a bunch of players have told me that the higher ping actually feels higher, so I don't know.

Outside of that, If you have different ip addresses, it's possible that at your ISP there are multiple routers/hardware that the connections go through before reaching the outer internet, and one group of ips goes through one set of hardware, and another group through another. It just so happens that one has less traffic or operates better to the other.

There's nothing to say that the same thing couldn't happen elsewhere in the chain, but perhaps it is a lot less likely at major interchanges since they have truly gigantic hardware.

This is mere speculation though. Some traceroutes done with each ip would reveal more information.

Probably I don't have to tell you that if you post some traceroute info somewhere online for others to see that you should probably blank out, or summarize the first few hops as not to give your ip info away since you're someone that people like to ban :-P

thanks for the reply. why would i hide my ip? i change it alot, so i rlly dont have an ip. id knows my ips anyway
well, as far as i can tell, different macs/diff ips=ping difference. i take de as the standard, so i have either 47-50 or 30-35. not other values, just these 2 pings. so when i get ingame and see my ping 50 i now go back and change mac/ip until i see my 30 ping on the server. it's not on the first attempt tho, dunno what's the deal, it's random, i change macs and ips until ping is 30
this started happening few moths back and only after some time i discovered thing with the ip change=my normal usual ping. could be my windows. or just routing like u say

different ip ranges routed differently by your provider

let's say the first 500.000 ips get the good routing and during high net usage, the provider buys just cheap routing

or smth

I would love to ping 50.

I'm 90 ms+ everywhere now except on TX, and nobody will play there :-/

So ya, can't really play this game.

yeah but u live in america:d

Lorfa, for as long as i've seen you in ESR/QL forums, I've always wondered what do you do in life?

Who says I have a life? :-)

Ur superior intellect. Skills in math or whatever its called. (thats what i want to know) .

You do a lot for the community. Thanks.

Is it possible that maxpackets 63 and rate 16000 feels better (5 mbit ADSL)?

What about packetdup 0?

How one should set these settings in your opinion and why?

Is it possible that maxpackets 63 and rate 16000 feels better (5 mbit ADSL)?

It really shouldn't.

maxpackets 63 at 125 fps will send a packet every other frame, as opposed to every frame with maxpackets 125. This feels laggy to me when I've tried it in the past, especially when shooting the plasma. This kind of makes sense since you'd sent a packet every 8 ms with maxpackets 125, every 16 ms with maxpackets 63, so theoretically you could have an extra 8 ms delay on sending the info to the server.

I suppose if your upload was really really slow, you might experience some sort of serious problem with maxpackets 125. I think you'd immediately know something was wrong in this case though.

Rate however is really quite strange. It's hard to imagine that anything other than the max of 25000 would be any good. However it may be the case that the server only sends out 16000 bytes/sec for each client. I don't know. When I watched the UDP transfer rates in a bandwidth monitor, I saw virtually no change in the downstream using rate 8000, 16000, and 25000.

Even so, I ran some tests with rate 8000, and it felt less smooth than 25000, but I recognized no difference between 25000 and 16000. It could have been entirely placebo though.

Still I use 25000, perhaps being a bit superstitious. The idea that other players could be getting more data from the server than me is disturbing :-)

What about packetdup 0?

This one seems to be at great risk of being a placebo. I posted about it here: http://www.esreality.com/post/2111747/is-cl-packetdup-effectual/

It was actually quite hard to tell if it really made any difference in the bandwidth monitor, or if this was just normal fluctuations.

Since packetdup should send more packets the greater the number, it would stand to reason that unless there are problems with packet loss that 0 would be the best setting.

In-game I have never seen any difference with values 0 through 5. Players experiencing packet loss, or warping do not appear to be affected by changing its value in either direction.

I did have a strange report once, that a player had a problem where when he stood still, his ping would increase and he would lag terribly, but when he was moving he was fine. He was a fairly trustworthy person, and a friend of mine verified that this was happening although I didn't see it for myself.

He said that changing packetdup from 0 to 1 fixed his problem. I don't know how credible that is, or what kind of sense that makes but if true it might give some insight into its mechanism.

It would still stand to reason that unless there are problems 0 should be fine. Perhaps though any value is fine, barring the unusual story above, it could be that this cvar either doesn't work, or just has no effect with modern connections.

>>> "What about packetdup 0?"

How about this: with rate "25000" you don't really need packetdup because you are already sending enough packets.

Only with lower rates does/might packetdup be useful to compensate for packet loss.

Back in the Q3 days many people did not have broadband and could not sustain a connection with rate "25000".

Does this make sense?

Except that rate is a downstream cvar, and packetdup is upstream.

Rrrright.

(It's just that in all the old Q3 guides they increase packetdup as they decrease rate. So I suppose the reasoning was that back in those days lower bandwidth tended to correlate with more packet loss, although I would think that ideally the two should be independent from each other.)

For me, it feels random, whether maxpackets 63 or 125 is the better. Kinda weird.

Anyway, thanks for your input.


~a fellow *.cfg-whore ))

cfg whore! :-) Yeah that's me :-P

Me also, since 2006, hehe. : P

how to turn off dead bodies or reduce the time they linger or change colors for corpses?

The only cvars that control this are:

cg_deadBodyDarken "1"

Darkens them instead of leaving them the color of enemy/team model.

cg_deadBodyColor "0x101010FF"

Color of the dead body. Grey by default.

Uses hex color codes.

There is no such cvar to remove dead bodies, or control the time in which they linger.

This is on purpose: sync is opposed to allowing them to be filtered as they are game objects.

tymen

one suggestion though, putting it in a table would be easier to read

If it's not too much hardwork do you think you can list all these cvars in a easy copy paste format with the default values? That way i can paste it into my config and use a duplicate text finder to delete the default cvars and when i exec my config on my bros pc i don't have to go cvar hunting all the time.

actually nevermind, just found out about config reset.

that'll work too probably : )

http://pastebin.com/kYGQ7HzR

Should be 99 % of them. One or two might not be default, as they came from sponge's game. I fixed a few, not sure if there are more. Looking through it everything looked default but it's very possible I missed something since it's such a long list.

I removed the ones that have no set default, the fs_path type ones and a few others that I don't think are typically written to the config.

could you tell me what cmnds to put in cfg to have zoomfov depending on gun and regardless of the buttons i press? just when i switch to THAT gun, i have that zoomfov?
for ex. i want like 80 zoomf for lg and like 60 zoomf for rg and 92 for pg

Bottom half of 'configs part 3' section on

http://steamcommunity.com/sharedfiles/filedetails/?id=315482318

Nice work. Some people give you crap but you put a lot work into helping the community and the game.

nah yakumo is the worst of the worst ;)

Stomping noobs in FFA since 2009. ;)

that didnt help like at all. anyway turns out it's easy u can set it in the menu then find the cmnds upon a quick search in ur cfg.
anywho, do u know how to change the size, fonts etc of the console? like all the cmnds of the console, even better. got some weird font size, cant read stuff in the console (killsen cfg. i changed the r_mode, i play at 800 600)

\con_scale 1 is the largest the font gets for the console.

con_speed controls how fast the console comes down, I recommend a max value so it is instant, like 99 or 999.

con_height controls how far the console comes down. By default it is 0.5, for half way down the screen.

con_timestamps 0/1 controls whether.. timestamps are drawn in the console or not.

con_background 0/1 If set to 1 the normal background to the console is shown, if 0 then it will be a black backdrop, whose opacity is controlled by con_opacity

u the man

lol

I got a question for you Lorfa. I tried for many years to come up with my own config, trying one cvar at a time, and none of my configs have come close to the Superior pro configs. They are superior mostly when playing online. When I use my own configs, I am always scoring very very low. Then I throw in the pro config, and my scores/aim is top notch. Why is that? What is in their configs that makes it so damn good? I play as Wraith in Darkfiber servers.

I don't know as I'm not familiar with Apex Legends, but if someone else's config works for you why not use it?

I am Wraith in Quake Live servers, not Apex Legends. Always was Wraith long before Apex. C'mon man. Was asking a serious question.

It's kind of a confusing question because someone else's config can mean different movement keys, different weapon selection keys, different visual setup (for example, crosshairs, texture quality, lighting, field of view), different mouse sensitivity and possibly mouse acceleration.

There could also be psychological differences, like sometimes when you change settings you have a tendency to think the new setting is better even if the results don't actually show it, or you could have a placebo effect, as in 'I'm using such and such's config so I should feel and aim more like them'.

Without a lot more information regarding what it is exactly you are experiencing as different with these configs, it's difficult to make concrete suggestions.

you look silly trying to troll

Oh sshit, Lorfa's site is gone :/

Yeah I lost hosting : / haven't gotten around to finding new hosting, didn't think enough people were interested even : <

you just have to think abut history.
Practically, ETERNITY.
Put it on Github ! :D

https://web.archive.org/web/20221201090955/ht.../ql/Lorfa/

Thank u, brah

good boy d1z 1z. Lorfa, still do github xD