No problem and no need to feel bad about it. I appreciate your curiosity.

This command isn't in your config, but can you please explain what this does:
cl_pred_optimize
The default value is 2, but felix set it to 1 on his config, claiming better hit reg.

Also will you be documenting every cvar in the game, even if they are not used in your config?

Thanks and great work on the comfig!

my game crashes when i change these three settings and try to load certain maps like cp_coldfront

edit: actually something in the config now consistently crashes my game on map load
i deleted my custom folder, stuck the config in the way i had it before and the game continued to crash
edit2: i tried rolling back to other versions of this config, even tried a comanglia one, but to no avail. the game simply crashes to desktop with no error

No, prediction doesn't really affect hitreg, it just increases the smoothness and responsiveness of what info you send to the server (like weapon firing and movement).

cl_pred_optimize 1 reuses prediction info from the last time your client predicted if the server didn't update you yet about what's going on.

cl_pred_optimize 2 does 1 and also something similar to 1 if the server gives you an update and the prediction turns out to be true.

Most of the time, these optimizations will happen most often when your frames are higher than your updaterate but can also happen when the server legitimately doesn't have anything to tell you about where you are or that you were wrong on a prediction.

Could you set con_logfile console.log and then share tf/console.log (after you crash)

and I assume you've tried the default config?

i actually had not tried the fully default config:
launch options: your default recommended and -high -w 800 -h 600

log appears to be exactly the same for all crashes

with mat_dxlevel 95 as default:
-with your base launch options: no crash
-with the above + compquality and igpu (i'm on an integrated graphics laptop): insta crash
-just compquality: crash
-just igpu: no crash

switching to mat_dxlevel 81:
-default config, no compquality or igpu: no crash
-with compquality as the only change: insta crash
-with igpu as the only change: no crash

looks like it's the compquality preset

then i made some changes i thought prudent to my laptop, as it has 2 physical cores

// core related:
r_threaded_client_shadow_manager 0
r_queued_ropes 0 
snd_async_minsize 262144
snd_mix_async 0
phonemedelay 0.1
// shadows related:
r_shadows 1
r_shadowrendertotexture 1
cl_blobbyshadows 0
// etc
r_drawtracers_firstperson 0
sv_allow_point_servercommand always

on dx 81:
-with the above changes: insta crash
-reverting just the shadows changes: no crash

dx 95
-switching directly to dx 95 with the above changes but the shadows as you had them default: no crash
-turning shadows on: no crash, interestingly enough

so my conclusion is that shadows on dx 8 crashes and compquality crashes on both dx 8 and dx 9

for now i guess i'll just run mat_dxlevel 95 so i can have shadows or switch back to mat_dxlevel 81 no shadow if the look is something i can't get used to, because i don't really like the way rockets look in dx 9

i also appear to be able to safely turn off gibs and stuff so i'm ok for now, but i do want to know what's wrong

edit: not sure what's wrong, i was pubbing and shadows on were ok,but i joined a pugchamp on product and instantly crashed every time i joined until i turned off shadows

I found a small snip in reddit about cl_pred_optimize 1/2 debate I though it is worth reposting it there:

https://www.reddit.com/r/truetf2/comments/51h73b/how_much_does_interp_affect_projectiles_also/

Kairu927:

wareya's recommended settings:
...
..
cl_pred_optimize 1 // Slightly improve hitreg in certain situations at high framerates at expense of an extremely slight performance reduction (default is 2)

kk_64:

wait cl_pred_optimize 1, don't most people recommend cl_pred_optimize 2? I tried to find out exactly what this does but all I could find was: 
Official cVar documentation* : - Optimize for not copying data if didn't receive a network update (1), and also for not repredicting if there were no errors (2).
Surely 2 is better since it doesn't bother repredicting when there are no errors?

Mao-C:

technically "no errors" refers to new data being close enough to old data that it can just reuse the old data for prediction; rather than actually being perfect.
i guess technically it would make prediction more accurate, but the game will only switch to prediction when it doesnt recieve network frames, which means its not gonna be accurate anyway. So making sure that the game adjusts for some 5 degree turn for a single frame which wont be accurate in the first place doesnt really help much.
Edit: actually i found this(https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/client/prediction.cpp) and it seems like it adjusts entities to their predicted locations if, after prediction, the actual location is close enough. So it might cause some desynchronization.

So based in your explanation pred_optimize 1  does recycle the usage of last  sended network data to client received from server when client its not actually receiving from srv.

kk_64:

That's actually pretty interesting, sounds like 1 is better if you can handle the extra work from repredicting since it would make things more accurate, if I understood everything correctly.

wareya comment on tftv on cl_pred_optimize 2 from http://www.teamfortress.tv/25553/a-way-too-detailed-networking-config#6

//This is fine but I want to note that lowering this can THEORETICALLY improve hitreg (by imperceptible amounts), particularly in obscure computing situations, at the expense of framerate.

(Q :: What would happen in cl_pred_optimize 0 ,Would it fail to obtain network data in these "client-server offline moments " and missaccurately represent the game frames in each of these events causing jittery jerky gameplay ,how prediction would be delayed or affected?).
I guess it would be less resource intensive and could release some frames.

A Mix read between the reddit snip and your declaration makes me think proviosionally the idea that since :

and this:

That the optimizations that takes place when frames are higher than updaterate(66) are way more accurate representations of current game than the optimizations that occur when client is not getting network packets from server and reusing recent packets as per pred_optimize 1 bcoz packets from frames in the 1st situation contain more legitimate positional info.

->

So now cl_pred_optimize 2 :

Valve documenation : Optimize for not copying data if didn't receive a network update (1),  , and also for not repredicting if there were no errors (2).

So based on Mao-C (reddit):

What I understand is that "no-errors" in cl_pred_optimize 2 means that the reused old packet with cl_pred_optimize 1 is considered to be in the range to be closely accurate to the new data and accepted, skipping prediction and itself prediction resulting to be true as pointed , although still considered a bit innaccurate representation, well atleast based of what I understand in the reddit conversation. So what would happen if the last packetinfo is considered not-error free? In other words ,How repredicting works ? So following reddit post , Forcing to repredict even though its still fps expensive allows to get more "perfect-close position wise-" information that might be acquired with cl_pred_optimized 1 ,but based on your cl_pred_optimized 2 statement it does what .._optimize 1 does and when server does send packets, I though cl_pred_optimized 2 was based as added condition to pred_optimize 1 where only in the situation that the server does not send packets . Kinda confused.

Thanks for the detailed report. I'll look into this, but it would help if you could share your dxdiag info (search for dxdiag, run it, then click the save all information button at the bottom.

cl_pred_optimize doesn't affect if you predict or not, it controls how much prediction data you reuse if there's no new information from the server, even if the server sends you an update. If you have it at 0, it will repredict everything all over again, even if it has no new information from the server to change the prediction result. 1 will prevent repredictions when you don't get new server information, and 2, in addition to enabling 1, will also prevent repredictions on information that confirms your prediction had no errors. And no, setting this to 1 will not resynchronize with the server, because it only does that if you have errors, regardless of prediction optimizations. So in the cases where 2 would occur, it would not resynchronize if you had 2 off.

Also, I think you misunderstand prediction, and my bad for not fully explaining it earlier. It isn't used for when you lose connection to the server or anything, it is used so your player and weapons react instantly to your keyboard and mouse, and the resultant actions are smooth (like moving forward, your player will move forward smoothly instead of the increments you receive data from the server), because ping and server update rate will delay when you get new updates. And I should emphasize, this only affects your player, no one else.

It isn't about accuracy, it is about repredicting with the same information again, which isn't very useful. So, the optimizations skip repredicting based on unchanged information.

Prediction optimization 1 and 2 are two different cases that don't happen together. 1 happens when the server doesn't give you new information about your player's position/state. 2 happens when it does give you new information about your player's position/state but it doesn't tell your client that its prediction was wrong. What I meant by 2 doing 1 is that when you have pred_optimize 2, it also enables pred_optimize 1.

What Mao-C said is wrong. Synchronization is not done with new data if there were no errors anyway. So, with cl_pred_optimize 1, you would be repredicting with the same data, if you had no errors.

If there are errors, prediction optimization does not apply and does not affect it.

Thanks again,
dxdiag

If it turns out to be too much of a time sink to figure out, I can live without the shadows, at this point I'm just glad the game works.

classic tf2 tbh

Sorry, I missed this question. I've been thinking about having in-depth explanations about CVars, commands and engine mechanics in TF2 on the mastercomfig wiki. However, I'm going to wait until after the next major update before I consider actually doing it.

Hm, maybe it is some memory allocation issue. Try r_flashlightdepthtexture 1 in addition to the commands listed before. Not sure if it will allow for bleeding shadows, though.

I've also released 4.4.7, quite possibly the most boring release of all time.

I'm anticipating the Pyro Update to come soon and for it to change things in terms of cvars and optimization, as every major update usually does, so I'm trying to refrain from doing bigger changes to my config until then.

The Pyro Update will probably result in a bigger update for my config and thus the release of 4.5.0, or if we get a new engine (volvo pls つ ._. ༽つ giff source 2), 5.0.0.

i love you mastercoms

thank you so much for all your great work <3

i really don't know what to say, but this makes me so happy!!!!! thank youuuuuu soooo much <3 love you too

im confused as to what dxlevel override is, is it as simple as just just putting mat_dxlevel 95 in your config but with -dxlevel 81/running dxlevel 81 in your launch options or is it something else, also what does dxlevel override do performance-wise

You shouldn't have conflicting dxlevels for -dxlevel and mat_dxlevel, and I don't recommend using DX8 for performance reasons on anything except old cards. DX9 is a much more efficient renderer that takes advantage of hardware better and has a bunch of performance optimizations Valve has not ported to DX8. Though, I totally understand if you're using it because you like the look and feel of it.

The dxlevel overrides reduce particles more aggressively. They will be applied on dxlevel 80, 81, 90 and 95.

With those performance optimizations you mentioned that dx9 has over dx8 - would any of those affect rocket jumping in any way?

Because I have tested your config on both DX8 and DX9, and dx9 feels a lot smoother and easier to jump with. It could be placebo, but I tried the same jump map on both dx levels, and I had an easier time completing the map on dx9. I do prefer the looks of dx8 though.

That's entirely possible.

-swapcores seems to be a bit bad for the previous gen AMD processors (FX series)

AMD FX-8350 (stock, no turbo), GTX 970, comanglia cfg, mat_queue_mode 2
-dxlevel 95 -w 800 -h 600 -refresh 144 -novid -nojoy -nosteamcontroller -noff -nohltv -softparticlesdefaultoff -reuse -primarysound -snoforceformat
2639 frames 25.155 seconds 104.91 fps ( 9.53 ms/f) 6.595 fps variability
2639 frames 25.080 seconds 105.22 fps ( 9.50 ms/f) 6.009 fps variability
2639 frames 25.242 seconds 104.55 fps ( 9.56 ms/f) 6.077 fps variability
-dxlevel 95 -w 800 -h 600 -refresh 144 -novid -nojoy -nosteamcontroller -noff -nohltv -softparticlesdefaultoff -reuse -primarysound -snoforceformat -swapcores
2639 frames 25.221 seconds 104.64 fps ( 9.56 ms/f) 7.145 fps variability
2639 frames 24.812 seconds 106.36 fps ( 9.40 ms/f) 6.287 fps variability
2639 frames 25.031 seconds 105.43 fps ( 9.48 ms/f) 6.103 fps variability

also what should i take away from the fps variability info? i never paid much attention to it
edit: also i get the feeling going from dx8 to 9 that dx9 has less input lag. might have to do with video drivers but it feels way more responsive.

mat_dxlevel 95

2639 frames 22.010 seconds 119.90 fps ( 8.34 ms/f) 10.408 fps variability
2639 frames 22.104 seconds 119.39 fps ( 8.38 ms/f) 10.490 fps variability
2639 frames 22.192 seconds 118.92 fps ( 8.41 ms/f) 10.123 fps variability

mat_dxlevel 81

2639 frames 22.328 seconds 118.19 fps ( 8.46 ms/f) 10.228 fps variability
2639 frames 22.328 seconds 118.19 fps ( 8.46 ms/f) 10.228 fps variability
2639 frames 22.179 seconds 118.99 fps ( 8.40 ms/f) 10.331 fps variability

dxlevel 81 no longer gives better fps.

Config: comfig.cfg + comp.cfg
Launch Options: -threads 6 -novid -nojoy -noff -nohltv -softparticlesdefaultoff -reuse -primarysound -nosteamcontroller -nostartupsound -nogammaramp -snoforceformat -swapcores -full -w 2560 -h 1440

CPU: AMD FX-8350
GPU: NVIDIA GTX960

Don't see how it's bad

The lower the value, the most more consistent/stable the framerate.

There's a lot of factors that go into that. Video drivers are more mature and maintained for DX9, DX9 itself has a lot of optimizations and improvements to resource control and GPU commands, and Valve has improved its DX9 renderer a lot more than DX8. It's hard to pin down any one thing that has the most effect, since there are a variety of improvements that make it better.

Thanks for these benchmarks.

I've re-tested net_queued_packet_thread 0 on windows but this time around on sniper and there's very noticeable delay. I'd say it's around a frame or so. Sometimes the dmg text won't even show up and you'll only see a blood spray(if enabled).

net_queued_packet_thread 1 + -NoQueuedPacketThread feels fine. No idea if the switch has any negative impact on the former cvar.

Ok, thanks for the testing.

Don't use the -NoQueuedPacketThread launch option with anything but net_queued_packet_thread 0.

4.4.8 released with some minor tweaks to net settings and occlusion.

Trying exactly the same settings than Hopps but on my resolution, config untouched.
CPU: AMD FX-8350 (turbo disabled)
GPU: NVIDIA GTX970
Config: comfig.cfg + comp.cfg
mat_dxlevel 95
Launch Options: -threads 6 -novid -nojoy -noff -nohltv -softparticlesdefaultoff -reuse -primarysound -nosteamcontroller -nostartupsound -nogammaramp -snoforceformat -swapcores -full -w 800 -h 600 -refresh 144

2639 frames 25.869 seconds 102.01 fps ( 9.80 ms/f) 6.549 fps variability
2639 frames 25.672 seconds 102.80 fps ( 9.73 ms/f) 6.013 fps variability

theres probably something messing with my performance in Win7 even if i dont apparently have anything in the background or in task manager. guess its time to reinstall ?

2639 frames 25.869 seconds 102.01 fps ( 9.80 ms/f) 6.549 fps variability
2639 frames 25.672 seconds 102.80 fps ( 9.73 ms/f) 6.013 fps variability

Perhaps try without the -full -w 800 -h 600 -refresh 144 launch options and set your preferred resolution from the video options menu.

.

You may want to use the maxperf preset with the dxsupport_override to help with FPS issues. You may also want to try the -nouserclip launch option. However, I'm assuming this is an integrated graphics card so there's not much we can do for frames.

As for the mouse lag, are you using raw input?

4.4.9 enables host_thread_mode by default again.

This command improves FPS by a lot, and I had it enabled by default before but then disabled it due to people asking for help with their local servers, which host_thread_mode 1 breaks.

I've decided that it is best to keep it on because the majority of people probably wouldn't remember to turn host_thread_mode on, but will remember to turn it off if they're in a local server that isn't working.

Hey Mastercoms loving the work your doing man keep it up !

Quick question I wanted to find out if you would recommend the use of certain mods like:

• No sound scapes
  
• No hats mod
  
• Those mods that alter the way rocket/sticky explosions (link)
  
• And mods that that alter tf2's particles (link)

All of those should help. The less things the engine has to render, the better your performance will be. The biggest performance hindrances are particles and player models/animations so focus on getting those kinds of mods.

Particle Limataion Pack doesn’t work with sv_pure 2, that is with most competitive servers and all Valve servers.

mastercoms, it seems that I cannot only use mat_dxlevel to change dxlevel.

If I set -dxlevel XX in the launch options (even after removing it), it will change to that dxlevel every time I launch tf2.

So if -dxlevel and mat_dxlevel has conflicting values, it will cause texture bugs and resetting of some graphical commands (e.g. motion-blur, and color correction)