Resaving a game causes floating point numbers to shift#332

I’ve been trying to setup a mod to be version controlled, but every time you save the game there are like 1000 floating point numbers that have subtly shifting 0.199977368 is now 0.199977309. This means that either my commits and version history is clogged up with like 90% meaningless changes, or i have to go in and revert 100+ files every single time.

As far as I can tell the in game UI generally only supports 2 decimal points, so maybe it’s fine for these values to get rounded off, or at least have these values be consistently the same.

If needed I can give you some diffs/commits that showcase this as well

With some objects the shifts are actually too big to be explained by floating point rounding errors (eg. every save consistently adds 0.02 to a coordinate value).

This is a big problem for multi-person projects, parallel work on the save becomes impossible because VCS can’t work with all these superfluous changes

Just want to underscore that Fabio is correct - these shifts are too big to explain away with “floating point”.

I believe some of these shifts are explained by the objects resettling due to gravity in your game. They’re literally in different places :-), ever so minutely, with slightly different rotations. Others (especially differing color tints) are harder to explain.

I can’t find the link, but someone wrote a small tool to round the numbers in TTS save files for source control. It would also sort specified containers.

Floating point precision issues are real and especially bad when serializing the data. Throw physics on top of that and it’s only going to get worse. If you guys can find anything causing this besides computers handling floats poorly let me know.

I added a comment on #335 with a couple of save files explaining that bug is actually a about different issue.

This issue I’m pretty sure is happening because of physics. Can you guys confirm if the issue does not also happens to locked objects?

I can confirm that it does happen to locked obejcts. The following mimized example shows both rotation changes and ColorDiffuse changes on every save->load.

Ran into this same problem. The problem wasn’t there for an object but adding a new legacy input field (via self.createInput) to it caused it to start moving when saved.

To everyone dealing with this. @Knil @Tom Prince @KarasuGamma @Nabbydude @romanticfool @kinithin aka ikegami @Fabio Lopiano @Jeff Dolan There is a workaround for this that I found. Simply go back to the main menu, closing out of any active table. The issue only starts happening after a few saves/loads so it can be worked around by doing that.

Well, it may work around the problem, but it would certainly play hob with my dev workflow to exit to main menu every time I make changes…

Oh it’s definitely a problem that needs fixing, but having a workaround until that point is good.

Found out a real workaround for this. This happens for some unlocked objects that are not perfectly vertical. In my case it was because the objects were stabilized but had a collider that let them tip over very slightly. Setting the x/z rotations to 0 and adding a collider that had a flat bottom so it wouldn’t fall over slightly fixed the problem. Some part of the saving logic moves the objects actual position when they aren’t fully vertical.