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.

The installer doesn't give you the option to use metal footsteps. So someone has to go out of their way to include it.

9.5.2 released with performance optimizations and bug fixes.

Changelog
Support me

This release took 5 hours to produce. If you like the work I do, consider supporting me!

https://docs.mastercomfig.com/en/latest/next_steps/troubleshoot/#ragdolls-arent-instantly-disappearing

Unfortunately, fully disabling ragdolls has a bug but I have been hearing feedback that this change has been undesired so I am trying to figure out a good solution. In the meantime, please refer to the above fix.

9.5.1 released with bug fixes.

Changelog
Support me

This release took 5 hours to produce. If you like the work I do, consider supporting me!

You can randomly order your scripts. Let fate decide.

9.5.0 released with app updates and config enhancements.

Changelog
Support me

This release took 7 hours to produce. If you like the work I do, consider supporting me!

Order doesn't matter since at usage time, everything you set will be there. For aliases, aliases are looked up when the alias is executed, so you can bind even before defining an alias. The cmdline is just strings when you assign values, aliases, binds, etc. For convars, an exec will run synchronously to the main thread of the game, so there is no race condition when changing multiple values.

If you are concerned about material system convars with the material system thread, those are "uploaded" to the material system after an exec in complete, so same thing there. And keep in mind that at initialization, TF2 runs the material system synchronously anyway, so autoexecs are safe either way. The threaded material system is only started after you join a game (or the frame after you set mat_queue_mode 2).

As for commands, they will obviously execute in order as you put them, but there is no general practice for ordering these, since there are possibly hundreds of commands with their own functionality, and you will have to determine the correct ordering for your intention on a case by case basis.

9.4.0 released with networking improvements, bug fixes and download page updates.

Changelog
Support me

This release took 10 hours to produce. If you like the work I do, consider supporting me!

Oops! Forgot about that, thanks for catching it. It's fixed now.

Hey all, I refreshed the download experience with a style update, layout changes, and a version selector + update checker. Please let me know what you think! There will be some more updates coming soon to help further with more advanced customization.

https://mastercomfig.com/download