You could use any CPU frequency monitoring utility. The in-game one is just a convenience to be honest.
Account Details | |
---|---|
SteamID64 | 76561198046110893 |
SteamID3 | [U:1:85845165] |
SteamID32 | STEAM_0:1:42922582 |
Country | United States |
Signed Up | August 8, 2017 |
Last Posted | April 23, 2024 at 9:59 PM |
Posts | 1531 (0.6 per day) |
Game Settings | |
---|---|
In-game Sensitivity | |
Windows Sensitivity | |
Raw Input | 1 |
DPI |
|
Resolution |
|
Refresh Rate |
Hardware Peripherals | |
---|---|
Mouse | |
Keyboard | |
Mousepad | |
Headphones | |
Monitor |
ZestySo I'm pretty sure internally that small health kits used to (and small ammo kits possibly still do) give 20.5% of max health/ammo respectively rather than 20. With metal, this would be 40 or 41 metal depending on which way the rounding goes. Wondering if there's something going on somewhere that uses the 20.5% code/does the rounding inconsistently and however that's decided happens on loading the map or starting the server? I'm pretty sure small ammo kits always used to give 41 metal? Or am I remembering this wrong.
I doubt this is solely a villa issue but maybe somehow you can specify the percentage for ammo kits and it's set to 20.5% for small ones on villa (don't use hammer so idk about this one). Then when the map is read by the server it could be doing some sort of inconsistent rounding?
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:
- the floating point multiply operation between MaxMetal and PackRatio
- the ceil implementation, which is implemented using hand crafted assembly, of which there are many implementations for (UCRT, glibc, etc)
- 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)
- 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.
quintoshwhy are metal footsteps still included in this? players caught using them receive a 1 year ban
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.
This release took 5 hours to produce. If you like the work I do, consider supporting me!
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.
This release took 5 hours to produce. If you like the work I do, consider supporting me!
AimIsADickIt's just as I feared the answer would be: The order of commands is up to preference. I'm just not good at personal preference decisions, and can't decide on any of them. Still this is a nice question to ask, as I couldn't find any other posts here or on r/tf2scripts asking the same question.
You can randomly order your scripts. Let fate decide.
9.5.0 released with app updates and config enhancements.
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.
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.
No love for the homie DirectX 8.0
Just for future reference: https://docs.mastercomfig.com/en/latest/customization/custom_configs/#game-overrides
9.3.3 released with performance optimizations, bug fixes, and new utility features.
This release took 3 hours to produce. If you like the work I do, consider supporting me!