Rounding will help with determinism in X% of the cases, and exacerbate the nondeterminism in 100-X% of the cases. That is, if the implementation is nondeterministic, anything from 2.0000 to 2.9999 rounds to 2, but 1.9999 rounds to 1 (for example) even though it may be 2.0001 on the other side. (Doesn't matter where you put the rounding rule, there will be some two values that will be very close but round differently.)

That being said, doing rounding of all your physics variables between each physics tick is actually a good way of achieving better determinism. If both client and server rounds to network precision after each simulation step, it won't matter whether a state was initially derived from a "network checkpoint" or from a "previous step's output."

We did this for There.com; the tool that generated the network marshaling for our object structs also generated code that rounded the same way that the network would round when packing/unpacking the data. We ran this on all state that changed after each simulation tick. It actually was a not insignificant fraction of our math budget at the time ?

("the time" was 800 MHz Pentium III days)

Quote

If I say round 5.1999 to the 2nd decimal place, one machine may say it's 5.20 and another machine may say it's 5.10

If you set the floating point control word correctly, they will round to the same value. And when you say "decimal place," the values possible are "5.20" (round to nearest, round up, round to even) or "5.19" (round down, round towards zero.)

The floating point rounding mode, and how it treats things like denormals, and which instruction set it uses (SSE, SSE2, SSE3, SSE4, AVX, AVX2, ...) matters, and should ideally match between client and server.

Using integer-based fixed point math may be a good idea to achieve 100% determinism. This is even more important when you want to have clients on cell phones and chromebooks (ARM CPUs) talking to servers in a datacenter running x86_64 architecture.

Unity, however, doesn't do any of this for you. It's not really possible to build a fully deterministic simulation on top of Unity, and it's really hard on Unreal. (The built-in Unreal simulation doesn't even support fixed time steps.) You have to go write your own physics and simulation code for this. At least with Unreal, you get the source code ... When you use Unity, you're better off making design choices in your game (when you play different sound/visual effects, for example) that work best with "it may sometimes be wrong."