Incompatible battle replays across OSes

[PhilD]

In my first email game, I had the same problem twice: the battle replay I watched (on a Linux machine) was very different from the one announced in the Messages. The second time around, I took the time to watch the replay under Windows, and it was much more accurate.

This seems to indicate that the method used to store the replays is NOT compatible across platforms. I'd heard of replay errors before, but if my guess is correct, this will most probably kill my enjoyment of PBEM; I believe it's a serious bug.

I've read that the .trn files only store the random generator seeds, and the replays are recalculated by the game. If so, then it might be a simple inconsistency in random number generators, and reasonably easy to fix (add the same random number generator to all Versions instead of using libraries that might be incompatible).

Did anybody else notice this trend? I suppose most players are using Windows, but there must be a reasonable number of Linux/MacOS/Solaris Users too...

[Saber Cherry]

Yes, it is VERY annoying!!! Watching your troops win a glorious victory, then looking at the casualty list to see that you actually lost, and all your leaders were killed. I didn't realize the problem was OS differences. Dumb C - that's why I like Java. Well, one reason.

-Cherry

[PDF]

Hi Phil,
The OS "bug" would explain the strange things we observed in our game replays indeed
Did you notice oddities in the Last turn's battles ? I was present in 3 of them and observed another between you and Abysia. On my Win machine the battles were consistent with the results (on the first battle the end of the battle was quite strange, with your winning troops suddenly all killed ...).
Anyway you should send the trn files to IW people so they examine what happens.

[Johan K]

The OS inconsistency is not related to the random number generator (hopefully) as Dominions uses its own random number algorithm. But something sure seems to be weird.

[Pocus]

and cant it be related to the rounding of some results, which would vary depending of the OS or the processor. Dunno how your algorithm works, but if it takes for example the 25th decimal of a number at a given time, like say

ln(0.123456789)
=
-2.091864070778393122967989 *7* 441961
on windows (being 7 there)
then perhaps it will be slightly different in linux.
?

[Johan K]

The random number generation itself should be foolproof. Only table lookups and some xor. Unfortunatelly the random number generation is only 0.0001% of what might go wrong, so your idea might still have some merit. The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

[talos]

Originally posted by Johan K:
The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

If you are using gcc, the trig functions should all be implemented to the IEEE standard, which is to say that they should produce the same results across platforms.

This is not true if you use other C compilers, or if you use -ffast-math with gcc, as this allows the compiler to use the hardware trig functions, which in may cases (intel for one) do _not_ quite meet the ieee spec. Of course --ffast-math speeds gcc up quite a bit, as it avoids software Versions of trig functions (maybe sqrt as well?).

Of course, such differences should be tiny, so they should only affect actual results with miniscule probability (like one in a few hundred thousand).

[Karacan]

For me (a windoze user), a game running on a linux server results in about approximately every eight to tenth battle being completely different in outcome - the others look vaguely correct (including the numbers of creatures fled into neighboring provinces, etc).

Annoying, but then again, it's time for me by now to stop watching every battle replay and just go for the numbers...

[PhilD]

Originally posted by Johan K:
The random number generation itself should be foolproof. Only table lookups and some xor. Unfortunatelly the random number generation is only 0.0001% of what might go wrong, so your idea might still have some merit. The battles use sinus (sinf()) calculations and those might just be bad if those calculations should be significantly differnt on different machines. Definitely worth some thought...

If you give me an email address, I'll send you my latest turn file, where under Linux, my Arcoscephale army gets eaten alive by Hoburg-backed Abysian Infantry, whereas under Windows, the very same Abysian Infantry routed pretty quickly (and the naked Hoburg Crossbows were no match for Arcoscephale's armies, even ineptly commanded by me).

There were a lot of things that could go wrong in this battle - some arrows and bolts, some trampling, some spells...

Also, bear in mind that any tiny different result, if it means "die rolls" are then scheduled differently, can mean the whole battle's outcome is different. One arrow landing in a different square, once, could mean one unit is now dead, or has a different number of hit points, or takes a morale check, so that the same dice rolls will be used for something different from now on. You cannot accept any variability in functions that are used during the battle replays.

[PrinzMegaherz]

I might add that I encountered this problem today in single player.

The review showed me a clear victory without any losses, the summary sais one of my commanders died.
And I'm very sure he is alive at the end of the replay

I'm using XP.