Prerelease 1.009L (AI Voice Taunts -- Last 1.009 Prerelease).

[x4000]

Okay, here's a new version for you to try.  I'd love to know how this does with that game that was previously desyncing so quickly, if you have a chance:  http://www.arcengames.com/share/AIWar1009K.zip

In all of my changes from floating-point to fixed-point, I actually discovered one that slipped through and that was potentially gameplay-affecting.  If the floating point numbers were the issue, this should solve it unless I missed another one.  The other advantage of fixed-int math is that it is faster, so this should actually be a (very minor) performance boost.  Let me know how it goes!

[Admiral]

OK, the problem recurred about a minute after load. We did NOTHING whatsoever; just let it run. It seemed to desync shortly after some enemies attacked (player name beginning with "R").

I will e-mail DXDiag output. Maybe that will help.

[x4000]

Can you send me new copies of the desyncing save files?  With the fixed-int changes, there should be no "chaff" to get in my way of seeing what the real issue is.  Fingers crossed, anyway.

[Admiral]

Can you send me new copies of the desyncing save files?  With the fixed-int changes, there should be no "chaff" to get in my way of seeing what the real issue is.  Fingers crossed, anyway.

I will re-run and save after desync, yes. Give me a few. DX Diag output is in your gmail.

[Admiral]

Can you send me new copies of the desyncing save files?  With the fixed-int changes, there should be no "chaff" to get in my way of seeing what the real issue is.  Fingers crossed, anyway.

Attached. It desynced very quickly this time, although I did "zoom out" on each computer to see what's going on to tell you. No actual actions were taken, though.

[x4000]

Bingo!  I was finally able to duplicate this, so looks like it wasn't a problem with your computers after all.  The problem surfaces only with the original savegame, not with the two desync files you later sent.  This is interesting.  This suggests that if you wait until the desync, save, and then load that save and continue from it, you might not encounter the desync at all (I didn't).  Now I've got an excellent starting point for finding this desync, though, since I can now both reproduce it, and I have a chaff-free version of your desync data.  Thanks!  I'll be back in touch shortly (hopefully), once I have this sorted.

EDIT:  Turns out there is just as much chaff in these new ones as in the old.  Evidently an extra call to random is occurring somewhere, and that's causing a lot of minor things to get slightly off.  This could be due to other factors like an extra ship dying, or the position of a ship getting off quickly, etc.  Now that I can thankfully duplicate the issue, I can see what's going on, though.  Thanks for all your help with this, and your patience -- there is nothing more frustrating than a desync bug, I have to say.

EDIT2:  I am able to watch the desync in action, so it's just a matter of time until I find it.  Some of the ships are moving differently while in free-roaming defender mode.  On one machine they finish off the sniper and then start heading east, while on the host they just sit near the wormhole and kill the sniper (these are both on the green home planet).  The desync then happens when the next wave comes in and the ships are all in the wrong positions on the client.  This save file that you provided me could not be more perfect for hunting this thing down, I must say.  So don't worry about hunting up anything more for me now, I have absolutely everything I need.

[Admiral]

I am losing my engineering fleet, which seems odd that they can't repair each other under any circumstances. What's the idea behind that? Thanks.

Glad the save helped.

Cheers!

[x4000]

I am losing my engineering fleet, which seems odd that they can't repair each other under any circumstances. What's the idea behind that? Thanks.

Glad the save helped.

Cheers!

They should be able to repair each other, just not simultaneously, and not if they were damaged within the last 3 seconds.

[x4000]

Okay, at long last, this desync is fixed:  http://www.arcengames.com/share/AIWar1009L.zip

As it turns out, this wasn't even a real desync per se -- it only happened with older files that were loaded in newer versions of the game, and if you resaved the file and then loaded the game again, it wouldn't desync anymore.  Thus why you were the only pair to find this, it's pretty specific conditions.  The root cause is now fixed, so you can now load your other savegame without it having any desync at all now. 

*Whew* This one took forever to find, like most desyncs, but I'm glad it wasn't something more central.  Ah, well. 

I also fixed your other two bugs that you found (see the original post in this thread, which I've updated).  I was able to duplicate the pausing issue after some fiddling, and that is now fixed.  I was never able to update the planetary summary issue, though I think you aren't the only one to report this.  I've made some code adjustments that will hopefully resolve that issue one way or the other.

Okay, unless people find anything more, this L version is now going to be the final version for release tomorrow.  Any and all testing is welcome, especially in light of all the fixed-int changes that I made tonight.  I am happy with those changes, and want to keep them, but that was a lot of guts replacement so it makes me nervous with the release coming up tomorrow.  The more eyes that can pass over the game in that time, the better.

And with that, I'm off for the night -- it's incredibly late, and I have an early appointment with the dentist.  I'll respond to any issues that crop up after that.  Thanks!

[darke]

Interesting that that would be a problem... IEEE math should return the same on two machines, unless they are using different precisions. I thought the Intel chips all did 80-bit internal before rounding to 64-bit or 32-bit external, using one of the rounding modes.

Actually, they can be highly inaccurate, even between intel machines.  In the past, before I switched to fixed-int math (early in alpha) for most calculations, I was getting small rounding differences between 64 and 32 bit machines in multiplayer.  These differences were extraordinarily tiny, but when compounded they would eventually be large enough to cause a desync.  I'm no expert on why that happens, but it definitely does happen.

They do the calculations in 80bit mode, but the problem is when the data is transferred from the floating point registers into memory (say to save it in a value), it gets crunched down to 32/64bit. Then if the value was saved to float (32bit), then multiplied with a double (64bit) things get even messier.

The issue possibly relates to the fact the code is in C# and as a result the JIT will optimise the code different depending upon different architectures. The reason that due to floating point rounding (A+B)+C == A+(B+C) is not necessarily true, so if the MSIL optimiser swaps code around (or just feeds the different calculations to different cores to increase parallelism or something?), it will likely slowly get out of sync.

Way too much information (and way too much math is here): http://docs.sun.com/source/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"

This gives a quick explanation: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

[x4000]

They do the calculations in 80bit mode, but the problem is when the data is transferred from the floating point registers into memory (say to save it in a value), it gets crunched down to 32/64bit. Then if the value was saved to float (32bit), then multiplied with a double (64bit) things get even messier.

That sounds like what I read a while back, yes.

The issue possibly relates to the fact the code is in C# and as a result the JIT will optimise the code different depending upon different architectures. The reason that due to floating point rounding (A+B)+C == A+(B+C) is not necessarily true, so if the MSIL optimiser swaps code around (or just feeds the different calculations to different cores to increase parallelism or something?), it will likely slowly get out of sync.

This would be true if I was compiling for "Any" architecture.  In that case, ints are actually 64bit on 64bit machines, and 32bit on 32bit machines, which cumulatively can even cause some severe performance problems with a game of this scale.  It also causes problems when doing interop with 32bit native dlls, such as the ogg vorbis files.  So I'm compiling for strictly 32bit, which keeps everything consistent, performing well, and able to talk to the vorbis.dll and associated files.  I think the issue is below the JIT level, therefore, though I have seen that cause problems in the past before I updated my project config (this was way back in alpha).

Way too much information (and way too much math is here): http://docs.sun.com/source/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic"

This gives a quick explanation: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Yeah, these look a lot like the resources I was seeing back when I was first creating a fixed-int implementation, too.  There weren't any previous C#-based fixed-int implementations, so I had to create the first based on some Java code.  I open sourced that so other people can use it, if they are interested:  http://stackoverflow.com/questions/605124/fixed-point-math-in-c

[Admiral]

My space docks seem to get stuck at 00:00 a lot, especially on tech III ships, and just sit there (for quite a while) before they turn out a ship. Not sure why.

Save attached. (NOTE: It says upload folder is full, so can't attach it.)

Cheers!

[Admiral]

It seems as if this is what's going on with the ship building bug:

1) It begins building a ship (e.g., a starship, but any ship will do)
2) It deducts the metal & crystal
3) When the ship is complete, if you are out of metal or crystal, it just sits at 00:00
4) When you have enough metal for the ship AGAIN (or maybe the next ship), it releases the current ship and then deducts the metal for the next ship

Unless the way it works is it deducts the metal AFTER the countdown...?

Cheers!

[PhilRoi]

I believe it deducts the resources after the completion of the craft.   I notice this when building starships especially.

[darke]

Odd bug: Running at +70% resources for the player, I researched the entire of my home planet (says 2000/2000), but my knowledge is at 2997 (+0/s). Looks like there's a rounding bug somewhere.