New thread here: https://www.teamfortress.tv/58095/rgl-pugs-technical-alpha

RGL PUGs sneak peek on stream: http://twitch.tv/b4nny

could you share your net settings that didnt have lag spikes?

It's just some fixes to uber cloaking and then some arbitrary/cosmetic cleanup to the materials. https://steamcommunity.com/sharedfiles/filedetails/?id=2188847513

Try toggling combinations of anti-aliasing on or off, and borderless windowed and fullscreen?

Ok, try setting cl_smoothtime 0.1

To give you all an idea, here is the email I sent regarding stunned movement:

Hello! I'm sure you all are aware of the issue where stunned movement is higher than intended when moving diagonally (when forwardmove > 0 && sidemove > 0), as there was a reverted patch which targeted this issue.

I'm not exactly sure what you all tried, but I know that it was reverted due to it causing all stuns to be much slower than intended even in the previously non-broken case, unless I misunderstood the issue. So apologies if the following suggestion is redundant.

I have found that this bug stems from when CheckParameters() is called. CheckParameters() scales diagonal movement down, such that the hypotenuse of forward move and side move does not exceed max speed. However, within ProcessMovement, this is done AFTER StunMove(), in PlayerMove(). So, the stunned hypotenuse of forward move and side move is already lower than max speed, so the extent is not clamped, and thus the player has the "room" to increase their max speed by moving along a hypotenuse (c > a, c > b, c = sqrt(a^2 + b^2)).

So, essentially, the root of the change is to call CheckParameters() within CTFGameMovement::ProcessMovement(), before StunMove() and after ChargeMove(), and add a if !defined guard to CGameMovement::PlayerMove() around for TF_DLL and TF_CLIENT_DLL around CheckParameters() to skip calling it again. I personally didn't see issues calling it before ChargeMove() either, since ChargeMove() forces forward speed to tf_max_charge_speed, it doesn't really matter.

While testing this, I found another bug with the baby face's blaster. Because of how HighMaxSpeedMove() works, it boosts the forward move and side move to be high enough to drive movement at the intended velocity. However, when under stunned movement, forward move and side move change, so HighMaxSpeedMove() never boosts the speed.

To resolve this, you need to call HighMaxSpeedMove() before CheckParameters() and StunMove(), so that the base forward move and side move value can be boosted for further changes by CheckParameters() (to limit the hypotenuse) and StunMove() (to scale down forward move and side move).

With these changes, a 0.6 slow (as applied by the Natascha at close range), slows down a full charge BFB Scout from 520 to 208 in all directions (40% of 520), as intended and proper! And of course, normal Scout speed is slowed from 400 to 160 in all directions (40% of 400). You can still temporarily boost your speed very slightly by circle strafing, but fixing that would require changing max speed and I think that would change the meaning of stunned movement (or else max speed would have probably been changed in the first place). This was also a problem in the previous iteration, so even if unintentional, these changes are an improvement over the previous state as far as I can see.

If you are wondering, the GrapplingHookMove() code does not get affected by this order change, since it sets max speed tf_grapplinghook_move_speed to and forward and side move to 0.

Please let me know if you have any further questions and comments about the fix.

technology confirmed

This is also related to prediction, so make sure that you're not getting prediction errors (cl_showerror 1). Also, could you let me know your values for cl_smooth and cl_smoothtime?

I mean, the GitHub was never meant for Valve. It was a testing grounds for me to test patches which I can email descriptions to them, as I had been doing prior to making the repo public. It also helps me get more community testing of those patches.

I wouldn't want Valve to do that. The changes on GitHub aren't ready and I don't want to cause bugs in the game.

Yeah, admittedly, I could do better than just not mentioning DX8 in the docs. My wish was by not mentioning it, it would be used less by people who don't need it, and the ones that did would find it in their more extensive search for performance, but really, it's better to inform than to hide things.

I'm not sure that was the impression I wanted to make. I was just being lighthearted since I thought that would be the solution. I found it funny that we already have a script for making sure an input is received even if you have the opposing button pressed, and now Rico made a script to make sure of the opposite, where it makes sure an input is not received if you have the opposing button pressed.

But really, given your comments, I doubt you really wanted to say anything constructive and were just waiting to say that to me. Now, I hope it was cathartic and you're relieved of whatever pain you had.

the opposite of the null-cancelling movement script

I feel like it's a misunderstanding of a few variables as well as possibly older FPS configs not working as well:

First, I think the main premise of this was because people associate DX8 with lower quality, while it is much more than that. It changes the entire rendering pipeline to something which doesn't work as well on newer GPUs. The speed boost that people see at all is simply because DX8 supports less features, and thus renders less, but it renders less at a lower efficiency.

Furthermore, many configs in the past did not properly save changes to TF2's video config, which caused the game to reload many times on startup, causing graphics systems to initialize in pathways which could have resulted in glitches and lower performance. mastercomfig saves the graphics options that you select to the video config, so that these reloads are avoided. To completely ensure that this is the case, use modules entirely instead of individual rendering commands (usually prefixed with mat_, also applies to r_rootlod).

Finally, I think that in some cases, people found that their game ran better without a config, and I don't want to disparage the work other people have done, but perhaps people associated a config with only changing graphics quality, while it does much more than that, and thus, can affect the game's performance beyond lower quality graphics.

All of these things can combine together for a community to eventually come to the conclusion that lower graphics are bad for performance on some systems, even though the reality was slightly different. These games of telephone are very common in this community as well as any other community. As information is passed along and reworded, re-understood and re-contextualized, it can gain new meanings which point to new conclusions.

In my time looking at how people have benchmarked each of my presets, I have found that each preset scales in respect to FPS as you would expect from low quality to ultra quality, and it is close to linear (with some softer bumps across the medium presets). So, I don't expect this rumor to do you much good.

I think a good way to think about it is that these sorts of options are rarely part of some zero sum game, where the more quality you stress onto your GPU, the less work your CPU does. Most often, it's a constant amount of CPU work, or more CPU work, in combination with increasing load on your GPU.

There is, however, one case where increasing the quality is a good tradeoff, and that's if your GPU is throttling below its max clock because of power saving measures, since it doesn't realize it needs to render at full capacity for TF2 since it is generally lighter on the GPU than other games. Usually, you can control this in your power options, both in the driver settings (in NVIDIA it is called "prefer maximum performance") and in Windows 10's graphics settings "graphics performance preference". In the vast majority of cases, this will solve the issue, but some cards may still not scale correctly and thus it may be worthwhile to look into the medium high or high presets.