I think on official servers, you get kick immunity for some time if you survive a few vote kicks. So they either got that through a server or figured out how to fake it.

sv_lan doesn't prevent it, your public IP is still registered with Steam. You can see this in the console log. I think Steam profile privacy settings will prevent it, though they may still be able to scrape from some list and match player list names.

https://docs.mastercomfig.com/9.5.2/next_steps/troubleshoot/#lightingshadows-are-blocky

Probably textures=low in modules.cfg

I didn't mean to post that to the recommended launch options! I thought I removed it from there, but thank you catching this, it's removed now!

https://docs.mastercomfig.com/dev/next_steps/quick_fixes/#viewmodels-are-not-visible

Can you show screenshots of your tf/cfg, tf/cfg/user and tf/custom folders?

mastercomfig has built in functionality for this, with the snapshot_buffer=auto module level.

https://docs.mastercomfig.com/9.5.2/customization/modules/#snapshot-buffer

I welcome improvements to single player and offline experiences!

What version were you using before? Also, I have heard reports of the latest TF2 update causing performance issues for some people, so it may also be that. See if you can revert to your last version and see if the issues still come up.

some effects require a viewmodel_fov 54 or above

edit: shit i didnt read your whole post, sorry

I don't like being used in comparisons like that, it just doesn't seem right

what did i do wrong? :(

I am not totally sure about this, but I think the command jumpers have said fixes this is hud_reloadscheme?

Setsul, idk why you assumed I thought this is a lottery, thinking that I claimed floating point arithmetic was random. You completely misunderstood me if you think I claimed something so obviously wrong, and I am not sure why you would invest so much time into disproving this false premise rather than understand what I said better.

Now, let's look back at the whole point of this discussion, which in your many paragraphs, you granted only one sentence to: "Why that happens is a different rabbit hole.", where there is some kind of variation that causes some servers to grant 40 and on others grant 41.

If you actually look at the source code for glibc (or UCRT, if you reverse engineered it), you'll see they don't use the instructions you mentioned. This is why in my response, I expected this to be the most likely cause of that difference, and then put a very, very low chance on some other system. These implementations are constant on any one system, but vary based on what implementation is on that system. Far from the "random" you somehow interpreted.

Anyways, to make it more clear: when I laid out every single aspect of the system which computes this value (notice how I listed out operation (4) but did not identify it as a cause, because there was no new data involved in the operation), and talked about error, I was talking about the IEEE 754 representations of those values, but I didn't bother to actually check the representation as you did, so thank you for that. To be even more specific:

"combined with the result of (1). Given that this is a ceil, you wouldn't need a huge error for it to bump up to 41."

I was talking about the representation of 0.2f, which I did not look at exactly, but suspected was the cause.

"it is likely the attribute manager causing it (3), but I find it extremely unlikely it could create an error large enough to see this discrepancy."

I was talking about the representations of the various numbers used in the attribute manager system, which again, I did not bother to look up.

Given that "floating point error" is a standard term, I struggle to see what really tripped you up here and caused you to so confidently write up this response without a single doubt. Looking forward to your reply. Hope this finds you well.

You could use any CPU frequency monitoring utility. The in-game one is just a convenience to be honest.

Small packs have always been set to give 20%, not 20.5%, and there is also no way for the map maker to change this. Floating point error, especially dependent on the C implementation of the system is likely the cause here. The full calculation for this is:

ceil(MaxMetal * PackRatio) * (1.0f * mult_metal_pickup)

So, we have:

1. the floating point multiply operation between MaxMetal and PackRatio
   
2. the ceil implementation, which is implemented using hand crafted assembly, of which there are many implementations for (UCRT, glibc, etc)
   
3. the floating point operation between the base metal pickup multiplier and the metal pickup multiplier attribute (this is cached, it will only run once per player)
   
4. the floating point operation between the metal give count and the metal pickup multiplier

Since you say this happens consistently, but depends on the server, I would suspect it mostly depends on what the server is running on, and the implementation of the C standard library (2) combined with the result of (1). Given that this is a ceil, you wouldn't need a huge error for it to bump up to 41.

But if you can reproduce different results on the same server, just for different sessions (different players, maybe on reconnect, map change or server restart), then it is likely the attribute manager causing it (3), but I find it extremely unlikely it could create an error large enough to see this discrepancy.