Just reformat it, you're not going to steal your own data, are you?
Remove all partitions, make a single big one, format with NTFS or whatever floats your boat, and you're done.

I already got downfragged because people don't understand sarcasm on the internet.

Maybe it's because top IM scout mains offclassing to medic are clearly not the same skill level as mid IM medic mains (they're obviously much better), maybe it's because their teamleader knows an RGL admin. Could be either one, really.

I'm not sure what's funnier, the idea that medic is so easy that any scout could play it at at least the same level, or the notion that an IM team is so afraid of an offclassing medic ringer that they have to deny him because he can surf.

Would you feel better if all shots on targets less than 2000 units away automatically hit dead center?

I think even those who have never seen assembly can tell that to round a number a single instruction with "round" in its name is preferable to a giant wall of asm that needs a comment to even identify the instruction that does the rounding.

But I'm glad it's at least amusing to those who don't have to suffer through it.

No, servers have ECC.

#5 is correct, we've been over this.

Yeah, you're arguing about two different things.
Expecting users to have an SSD and optimizing for that because HDDs just aren't going to get you optimal performance these days is reasonable.
Being an unoptimized piece of shit that is so much of a resource hog that it desperately needs the increased performance of an SSD just to get back where we started is not.

#15
NVMe is a lot better than SATA for SSDs and Windows 11 would still be a shit OS if it couldn't boot from anything but NVMe. It's the same thing.

Or a better comparison: Everyone got at least two cores these days. No one should be buying a single core CPU anymore. Does that mean it's acceptable for an OS to be so bloated that it needs at least two cores because even in idle a single core would be at 100%? Hell no.

Ah, misinterpreted the "why I listed what I did", my mind immediately went to that actual list.
Thanks for confirming those things!

You just can't appreciate a good mystery.
Also engie is clearly the most important class, since an engie main owns RGL.

Yes, consistent on the same server. But that doesn't mean that windows servers, linux servers, windows clients, linux clients, and different versions of any of them would behave the same.

Yes, it also happens with 0.2 as a float, then multiplying as a double. https://ideone.com/8OGbDL
Yes, virtually all CPUs support SSE2 nowadays, but it's not mandatory for TF2 as far as I know. r_sse2 exists so I assume both an x87 and SSE codepath exist in the binary. Should, for whatever reason, not all servers use the same path you can get different results.

The third is an external cause. I have to clarify, it's about which rounding mode is set during the MaxMetal * PackRatio multiplication before the ceil. Yes, the wrong rounding mode during ceil would turn it into a floor and result in 40 no matter what, but first we need the rounding after the multiply to round up to get 40.something or what FRNDINT does doesn't matter since 40.0 isn't affected either way.
Anyway, in a perfect world you set your rounding mode, your calculations run, and everything is done like you wanted it to be done. In the real world TF2 is not the only thing running on that CPU and execution might be interrupted at any point. When control is returned to this function the FPU should have been restored to the exact same state. But sometimes people write code that isn't quite correct and don't clean up after themselves. They changed the rounding mode and forgot to change it back, or they changed it to the default (but yours wasn't the default), or many other things they should never, ever do, but did for whatever reason. That basically means that if some 30 year old code with a single line missing is run at the wrong time your result changes and there's nothing you can do about it.
Granted, you have to be exceptionally unlucky for it to happen if you set the rounding mode and literally the next instruction is what depends on it (like in __ceill), but if you've been running with the same rounding mode for a while, never changing it, then it could absolutely happen and would persist until the next time the control word is changed. Most calculations wouldn't be noticeably affected, just the rare ones like this where a tiny error ends up being amplified.
It can't happen with SSE because those instructions always use round to nearest, ties to even. Though on the newer ones you can set it (like for ROUNDSD), but it's via an immediate so it's guaranteed to use whatever mode you set.

Given that Zesty is consistently getting 40 and I'm consistently getting 41 this can't be the main mechanism. Even if it happened (and you can see why that would be bad for so many reasons) it should be inconsistent and rare.

Also, I don't claim that it has to be any of those options, those are just what I could think of off the top of my head. I can only guarantee that it's not ceil working differently depending on the environment (the rules are pretty clear cut on what's larger than 40 and what isn't. that's not left to the implementation) or a multiplication by 1 gone horribly wrong (2 and 3/4 in mastercoms' list).

EDIT:
#32
mastercoms alt?

So I decided to look at the glibc source code like mastercoms told me to. I mean either I prove I'm right or I get to see some super secret x86 assembly implementation of ceil that is faster than a 1 cycle ROUNDSD.

And look what I found:

ENTRY(__ceil_sse41)
	roundsd	$10, %xmm0, %xmm0
	ret
END(__ceil_sse41)

For SSE4.1 (same with ROUNDSS for float) and

ENTRY(__ceill)
	fldt	4(%esp)
	subl	$32,%esp
	cfi_adjust_cfa_offset (32)

	fnstenv	4(%esp)			/* store fpu environment */

	/* We use here %edx although only the low 1 bits are defined.
	   But none of the operations should care and they are faster
	   than the 16 bit operations.  */
	movl	$0x0800,%edx		/* round towards +oo */
	orl	4(%esp),%edx
	andl	$0xfbff,%edx
	movl	%edx,(%esp)
	fldcw	(%esp)			/* load modified control word */

	frndint				/* round */

	/* Preserve "invalid" exceptions from sNaN input.  */
	fnstsw
	andl	$0x1, %eax
	orl	%eax, 8(%esp)

	fldenv	4(%esp)			/* restore original environment */

	addl	$32,%esp
	cfi_adjust_cfa_offset (-32)
	ret
END (__ceill)

in various variations for x87. x86/x64, float/double, all pretty much the same, all FRNDINT, slightly different x87 bullshit surrounding it.
I think now everyone can understand why I ... dislike x87.

Who could've seen it coming that glibc would use rounding instructions to round? Wait, I did!

They used exactly what I said they would! What a surprise! It's almost as if I knew what I was talking about.

Of course, absence of proof is not proof of absence. Maybe this is all a diversion and someone just wrote that code to distract everyone from the super secret hand crafted assembly implementation that doesn't use those instructions, but I haven't found it so far. Maybe Microsoft reinvented the wheel for UCRT. But until mastercoms can show me those mysterious assembly implementations of ceil that give different results, I'll continue assuming that they don't exist.

Neither of us thinks it's a specific map, even if we disagree about the mechanism because mastercoms doesn't quite get how fucked up floating point arithmetic is.

It's more likely to depend on the server. See Zesty getting 40 and me getting 41 on a local/listen server.

I haven't checked whether it's 20% of 20.5% though. If it is 20.5% then you should be always getting 41 on some servers and might get 41 or 40 depending on whether the number you started with was odd or even on others.

If you want my theory on why it was "discovered" on villa it's that engie positions are usually next to medium or larger ammo packs.

Honestly this thread peaked when this guy got it right without having a clue

Show me.

My issue here is that this

is wrong.

There is not a single implementation of the C standard library where ceil behaves differently. I guarantee it. Any ceil that does not return 41 when you put in 40.something is fundamentally broken.

No, this depends entirely on the compiler and optimization settings and you will get exactly the same result regardless of which C stdlib implementation you've used.

You've also identified a multiplication by 1.0 as a source of floating point error. We know mult_metal_pickup has to be 1 or it wouldn't be 40/41 metal. Multiplying by 1 does not affect the floating point error in any way. It never has and never will.

So you have identified two wrong causes (2 and 3 in your list) and one that is somewhat close (1) but still misses the mark with no explanation for why it actually happens other than "this just happens sometimes" and failed to mention the actual cause.
So forgive me for assuming you did not know what you're talking about.

Since you asked nicely I will tell you why the error introduced by converting 0.2 to binary float propagates and is finally amplified enough by ceil to become visible.
There are two main mechanisms controlled by the compiler to get either 40 or 41 permanently and one nasty exception that you have absolutely no control over.
The first is quite simple, you do all your math in float and rounding is entirely controlled by the compiler. The compiler sees a ceil following the multiply and for good or bad the compiler decides that that means the multiply should round up to not invalidate the following ceil. Because 40.00000059604644775390625 does not actually fit in a float. You either get exactly 40 or 40.000003814697265625. Should the compiler not bother to analyse that deeply or otherwise decide to go with a rounding mode that ends up rounding down (the default, round to nearest, would, since the "true" result is closer to 40 than the alternative) then the floating point error becomes 0, it disappears completely. That's pretty much floating point arithmetic in a nutshell, just hope the rounding errors cancel each other out.

The second (and third for that matter) is, most likely, because, bear with me, x87 is an ancient piece of shit that needs to die. x87 does not possess any 32-bit registers. It's 80-bit or bust. Now you might think that a higher precision format can only improve accuracy, but it does not. It makes things so much worse. Because now 40.00000059604644775390625 actually fits as a result, at least partially. Regardless of rounding mode you will now always get 40.something and ceil does with that what it should. This doesn't happen if you put 0.2 in a double and the result is a double, then it behaves like the first one (float to float), but I think even with double to 80-bit the error is large enough to make it through the rounding. So if PackRatio is a double then we know it's this one.
However, should an SSE(2) path exist then servers running that (r_sse2? no idea if that actually does anything) then you get to use actual, real-life float and double registers which should result in 40 since SSE instructions would round down (unless they make the same mistake of putting 0.2 in a float, then multiplying as double). So that's another mechanism for different servers to produce different results. Again, the library implementation doesn't matter.

And the third. The third is nasty. Because x87 is you-know-what the rounding mode is controlled by a special register. And sometimes, some people butt in via interrupt or other means and for one reason or another do not restore the control word like they should, nor is it done for them. And then you end up with the rounding mode randomly changing with no way to prevent it and no way to know it happened other than that your results keep changing on each run. This is not fun. At all.

So yeah, none of this is on the operations. All the errors happen in rounding (and not with ceil, ceil is the only innocent one, it only reveals the sins of others) and how you round is all that matters. Both the rounding mode and to what precision, which depends on the format of your intermediate result(s).

EDIT:

This is also dead wrong. Just because data has already been rounded once does not make it immune to further rounding errors. Multiplying two 23-bit mantissas (plus their implicit leading 1) leads to a 48-bit result (minus the implicit 1). Unsurprisingly this does not fit into the new 23-bit mantissa. If any of the lower 24 bits are set there will be a rounding error.
In this case there can't be any further error introduced because the mantissas contain 23 and 21/18 trailing zeroes respectively. But this is completely unrelated to how "old" the data is. If there was no ceil forcing a lot of trailing zeroes and if the other was something more interesting than 1.0, like for example 0.8f, then you absolutely would get another rounding error, despite "no new data being involved".