Replay bug- again !

[Zooko]

No offense, Johan K, but if your C code runs differently on different systems, then there must be a bug in your code, such as reading uninitialized memory, making unportable assumptions about the size of an integer, etc. It is traditional for C code to have lots of these bugs.

You could try using the "valgrind" tool on Linux. It is an excellent tool that gives very few false alarms but catches lots of actual errors.

(Of course, if your code is depending on the system for something, such as networking, file system usage, interprocess communication, etc., then maybe it isn't a bug but a legitimate difference of behavior. But I can't see how such a system-level behavior would change the outcome of battles, except via race conditions.)

[Johan K]

Zooko almost said:
No offense, Johan K, but if your C code runs differently on different systems, then there must be a bug in your code, such as reading uninitialized memory, making unportable

Sure there have been plenty of those bugs. But there have been compiler bugs and inconsistencies too. The Dominions battles are oversensitive to these things, otherwise the compiler shortcomings would probably never have been noticed.

[sushiboat]

I am confused about how the replay bug occurs. My (obviously faulty) understanding of a Dom2 battle is that the host machine runs it and writes the series of events (call them A, B, C, etc.) to the Turn file. When I replay the battle, my machine reads the file and displays A, B, C, and so on. How does my mental model differ from what the game really does?

[Oversway]

For size, I don't think the battles store every event - like every unit movement/death/etc. They just store the initial state and random number seeds, and then the algorithm is such that every battle with those conditions should turn out the same. But if the conditions are somehow different (like intial version number), or due to compiler/os/etc. issues where the state gets off, then each battle could wind up widly different.

Thats because they are cycling through a big, big list of random numbers... but if you have 1 more or less attack in one version of the battle, that throws off the entire cycle.

btw All the above is an educated guess.

[Johan K]

Yup, that's how it works Oversway.

[Graeme Dice]

Zooko said:
No offense, Johan K, but if your C code runs differently on different systems, then there must be a bug in your code, such as reading uninitialized memory, making unportable assumptions about the size of an integer, etc. It is traditional for C code to have lots of these bugs.

The classic replay bug was caused by this code:
(get_a_random_number() < get_a_random_number())
which is not evaluated in the same order by every compiler.