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?

checking tftv

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

Not sure what you're referring to. Could you give me an example?

No, because all 3 are useless and just used for debugging/testing. Rhapsody's comments are completely wrong.

Used for the envmap command to get a sample cubemap screenshot, except the value is ignored and set to 512.

Image size of the cubemap snapshot taken using the envmap command.

Size of the debugging texture for water, when using the debugging CVars mat_showwatertextures or mat_showcamerarendertarget.

just r_rootlod 0. r_lod should be -1. but lod also control the quality of other models like characters, rocks, buildings, etc

as for OP, there isn't a way to do that without modding probably

Also, you should use r_shadowrendertotexture 1

thanks!!! <3

No, it isn't. The only thing that would be specific to SSDs and HDDs is snd_async_minsize but you should only use higher sizes if you are getting problems like audio stuttering.

It checks for an NVidia GPU before using mat_aaquality, so it shouldn't affect image quality on other GPU makers.

It should help. 1 checks if you have threads available in the thread pool or something like that, while 2 ignores that availability and forces a threaded frame order. 1 is the best/safest value, imo.

Just run the timedemo at the settings you would play the game at.

width,height,windowed,vsync,MSAA,Aniso,dxlevel,cmdline,driver name,vendor id,device id,Reduce fillrate,reflect entities,motion blur,flashlight shadows,mat_reduceparticles,r_dopixelvisibility,nulldevice,timedemo_comment,

Hm, that's unfortunate, I thought it had a chart of frame times, or at least it used to.

mat_queue_mode has to do with the graphics card as much as it as to do with the CPU, don't use a low resolution for it.

No, but there might be some more data in tf/sourcebench.csv

Oh, I forgot to update the comments and values for that. Thanks for the catch.

EDIT: 4.4.6 released with this fix and others, as well as some file cleanup.

It isn't used if mat_software_aa_strength and mat_software_aa_strength_vgui are set to 0, so it isn't very useful to be changed in the base config. It is, however, adjusted in the maxquality preset.

The config sets these two values to 0, however, mat_antialias is commented out because it apparently affects some Mumble overlays. The more AA you do, the more work your GPU has to do. CSAA only works on NVidia I think, but it is more efficient than the MSAA that mat_antialias does.

It isn't supposed to activate any animations, only to force cycles in the animation controller. Sort of magic.

Anyway, I have updated the code in the OP to add the default event contents as well as to adjust the time delay to try to make the bug less common.

As in it doesn't decrease the occurrence of the bug or that it breaks m0rehud?

If you launch with only -default in the launch options, does this problem still happen?