RevolutionMP

The way I understand it (could be wrong or missing some subtlety), is that the MP code only goes OOS if there is a divergence in the way two networked machines run through the code, thus producing non-identical game states and thus an OOS. If the revindex sorting list behaves exactly the same on all machines, with the same ordering sequence for cities with the same revindex, I thought that would be safe in terms of MP and OOS because it is entirely deterministic, identical on all machines.

The conclusion I came to which could be wrong, is that only non deterministic data needs to be transmitted across the network, and the only non-deterministic data are humans executing the user interface. Not even the random numbers need to be transmitted across the network, because the soren random number generator produces the same number so long as each networked machine gets the same initial seed and executes the generator the same number of times in the same portions of the code. All of that is deterministic and the game state faithfully reproduces on each machine....in theory. Yeah in theory!!!

This is my understanding. I will try to help any way I can by blurting out random thoughts at you Lemmy, hopefully not going OOS in my head while I cannot actually work on the code myself :)

Cheers
 
Hmm seems like there were a lot of OOS opportunities from Win7 64bit vs Vista 32bit due to how python was handling integer values in complex Rev Index calculations. I was getting cases where the same values were being put in both players and the result value was different for each one, like there was a rounding error or something.

I've changed all these calculations to use floating point and casting to int when setting the new rev index. Fingers crossed. I've actually made it to turn 420 with increased rev events on autoplay, something I don't think I've ever managed before.
 
glider1 said:
The way I understand it (could be wrong or missing some subtlety), is that the MP code only goes OOS if there is a divergence in the way two networked machines run through the code, thus producing non-identical game states and thus an OOS. If the revindex sorting list behaves exactly the same on all machines, with the same ordering sequence for cities with the same revindex, I thought that would be safe in terms of MP and OOS because it is entirely deterministic, identical on all machines

Cheers
Click to expand...

This is correct for the most part, but is also an assumption that can also sometimesnot be the case. See my above post for an example, different OS's, 32bit vs 64bit are a perfect example of how identical code can happen differently on two different machines. :)

This is undoubtedly the true cause of the random event issue on Win7 vs non Win 7 machines. In fact I found the same list sorting method done in some of the plot choosing stuff for random events. Will look into this as it may be the cause.
 
Yeah I see what you mean 32bit v 64bit. Holly molly. However the DLL is compiled in 32 bit for all machines? and so python is the weird culprit for each operating system perhaps?
Cheers
 
Holly @#$@# I just realised that my test lab that cannot connect RevDCM at all, uses one 64bit machine and one 32 bit machine at least, as well as one 64 bit version of windows and one 32 bit version of windows.
 
Eh Lemmy shouting across the corridors of space and time, Jdog5000 the author of Revolutions and head man on RevDCM just PM'd me and would be happy to have you contribute straight into the SVN as a developer if you want. Feel free to become the the fourth member, to form the fab-four team for RevDCM development if you want.
Cheers :goodjob:
 
:D sign me up!!! thanks! :)

pm me log on details I'll merge in when I'm happy. Would like to ask Jdog a few questions actually about some of the code. I had to comment out a couple of bits I'm not entirely sure what they're there for to make it MP compatible and am worried they're something important. :)
 
Yep ok. Will organise details. In terms of when you update, there is no time-line, it is simply clear and concentrated moments of adhoc contribution by a lot of people mainly (Jdog and EmperorFool) that has brought RevDCM to the stage it is at now (almost totally bug free in single player). I mean, these MP issues have been hanging around for a long time (smack my hand).
Cheers
 
Hello all. :)

Here's a version of what I have on RevolutionMP at the moment, it *may* be completely fixed for multiplayer, save for the 'on death' one which is being a bit tricksy... but then also the easiest to live with. Will look into fixing that soon.

http://theindiestone.com/lemmyandbinky.com/RevolutionMP.rar

Though it's possible another OOS issue still languishes about someplace I've not been able to find any, but then I can't do 3 player at the moment so perhaps there are issues just a'waiting to present themselves... Otherwise, in the immediate, AIAutoPlay and ALL of the Rev events work as intended. Whether there are subtle OOS issues later down the line is another matter only increased testing can determine.

AIAutoPlay now works player independently, so player 1 could be on AIAutoPlay while player 2 plays, vice versa, or both at the same time. To ensure it stays in sync, AIAutoPlay will start the turn AFTER you enable it. So when it doesn't happen immediately don't worry, just click next turn and it'll start on its way.

Thing is I don't know, but there *may* also be some new bugs introduced into single player, or slightly modified game logic due to my changes. Probably not, but just to be safe, I was hoping I could put it out here for a little test before submitting to SVN see if anyone spots anything awry. I've been playing it so long with massively increased revolution frequency I can't tell now if my changes to the index calculations (floating point stuff) has altered the revolution stuff any...

Also the abdicate throne event may need a bit of tweaking, it doesn't seem to pick up a new leader properly so it just slaps AIAutoPlay on for X turns and has done with it for now.
 
Thanks Lemmy. I'll give it a go on three PC's when I can as well. Ok so this is where it is at:
1) EDIT: HUMAN on death OOS
2) Abdicate may not be switching leader correctly (check)
3) Could be other issues with single player interactions (check)
4) Other OOS's not yet realised (check).
5) EDIT: Barbarian civ was turned off for testing.

When I can I'll see whether I can add you as a developer on SVN or whether Jdog has to do that. The RevolutionMP branch will be all yours and mine at that point. If you think you have MP fixes for RevDCM that branch will be yours. As for merging in RevMP into RevDCM and releasing a new version 2.72, that hackwork is usually my mouse clickin job.

RevMP:
https://revolutiondcm.svn.sourceforge.net/svnroot/revolutiondcm/branches/RevolutionMP

RevDCM:
https://revolutiondcm.svn.sourceforge.net/svnroot/revolutiondcm/Trunk

Feel free to PM Jdog the chief developer whenever you want about anything. He is most helpful but I think he is pretty busy to help much until April. Is the SVN repo browser as slow as a wet week or is it just me?

Cheers
 
I doubt it. You may have found something. Some rebels do not have any territory and simply roam under a warlord. Perhaps this is what you are seeing? When you are debugging, perhaps it is not easy to distinguish between the rebels that have territory and those that do not.
Cheers
 
You must log in or register to reply here.

Similar threads

Crezth
In the Beginning Was Napoleon: Background Thread
2
Replies
26
Views
5K
Traveller76
Traveller76
Crezth
In the Beginning Was Napoleon: Game Thread
7 8 9
Replies
166
Views
19K
Plains-Cow
Plains-Cow
Pfeffersack
Review: Some late early impressions
Replies
3
Views
2K
Pfeffersack
Pfeffersack
Thunderbrd
  • Sticky
Player's Guide to Complex Traits
11 12 13
Replies
256
Views
59K
Mega Nix
M
phungus420
RevolutionMP beta testing
Replies
0
Views
2K
phungus420
phungus420
Back
Top Bottom