[BUG]BULL Destroys Multi-Player

[BladeLakem]

I happened to run into this bug last night and had a save file from right before I attacked. I tried all of the revisions in that archive file, and all got the OOS as soon I attacked a unit.

Edit: For what it is worth, I dropped in the dll from the Unofficial 3.19 patch and that seems to work so far.

 

[EmperorFool]

@Fuyu - If you get a chance, could you please checkout and build r37 and r38 and post them for BladeLakem to test on that save? r38 added the rest the Sentry Actions mod, but I rewrote part of it to be non-optional: the part that keeps your units from attacking/unloading into plots that were unrevealed when you issued the order.

Everything before that seems pretty safe: all interface work, but there was one feature (Governors Build Workers) and a new event (UnitCaptured). Neither of these should come into play when attacking units.

 

[Fimbulvetr]

Ok, that sounds exactly what you were looking for. And there I thought all sentry code was optional.. (And I honestly think you should make it so) edit: or maybe my misunderstanding was simply that safe move is part of sentry while it isn't?

You could just make it a seperate cflag: _MOD_SAFE_MOVE
The only question here would be if sentry depends on safe move

edit2: rev37 attempt ended in: CvGameInterface.cpp(1010) : error C2039: 'onlyUnitTypeGroup' : is not a member of 'CvSelectionGroup'
I don't speak C so this is as far as I go.

I'll try my luck with rev112 without safe move. If all parts are marked with // BUG - Safe Move then even I should be able to remove it.

 

[Fimbulvetr]

This is revision 112

Spoiler :

without the mysterious collateral damage code (I called it rev113 in the 7zip before),
and more importantly,

without the safe move parts. One dll with sentry actions, one without. the other options are always on.

Have fun testing.

 

[EmperorFool]

Sentry Actions had the functionality of what I termed Safe Moves in it. The reason I extracted it alone first is because it doesn't require new XML that would break saved games, and it is totally unrelated to acting as a sentry. I just thought it was a Good Idea (tm). I expanded upon Pep's work by making it work when loading a saved game without changing the saved game format.

The reason I made it non-optional (not even a game option) is that it makes total sense. Why would you ever want your boat to unload on a tile that you didn't even know was land simply because you clicked once instead of for each tile to get to your destination. Same for attacking in unrevealed tiles. This is unrelated to fog of war--I'm talking about unrevealed tiles (land? sea? forest? enemy? friendly?).

Yes, every part is commented AFAIK, and you should be able to remove it all as you've done, but I'm not 100% positive. If not, I tend not to leave the complete original code, figuring I can just diff against the previous revision. If it compiled, though, it's probably safe.

As for that compile error, I'll have to grab that revision and check. If I commit code that breaks the build (won't compile), I will immediately commit code to fix it (with a comment), and I saw no such commits. Maybe I missed something. Are you doing rebuilds, removing all .obj files in between compilations? This is why it takes so long.

 

[ruff_hi]

I'm available for some (what sound like) quick MP games after Thursday.

 

[ZippyDan]

i'm available to help too since i am very eager to see a resolution appear quickly

 

[BladeLakem]

This is revision 112

Spoiler :

without the mysterious collateral damage code (I called it rev113 in the 7zip before),
and more importantly,

without the safe move parts. One dll with sentry actions, one without. the other options are always on.

Have fun testing.

Sorry for the delay. I finally got a chance to come back to this. I tested both of these out with my save file. Neither of them give me the OOS when attacking. So whatever changes that are in both of these seem to isolate the issue.

 

[EmperorFool]

Okay, I'll take a look at the Safe Moves code to see what's causing this problem. Thanks for testing this and building the DLLs guys!

 

[Fimbulvetr]

Congratulations for that right guess.
You don't really have to look, do you? It's Safe Move and Simultanious Turns, they hate each other, and all you need to do is wrap a "if (isSimultaneousTeamTurns())" around it. Right?

 

[EmperorFool]

Maybe, but I don't see how simultaneous turns could be the cause of the problem. It would have to make one computer move the unit and the other unit not move the unit. But in these tests all the plots involved are revealed (right?) so Safe Moves shouldn't even come into play.

I'll produce a version that checks for ST and we can test again. Stupid multiplayer games!

 

[EmperorFool]

@BladeLakem - Can you please describe the exact scenario you're testing?

• Simultaneous turns? (my guess is yes)
• Stack Attack option?
• Attacking with a stack or single unit?
• Does it matter whether or not the attacker wins?
• Do both games look OOS tio the player? IOW, does the winning unit move in one player's view but not the other's?

I've looked over all of the Safe Move code, and AFAICT it should be safe for MP and simultaneous turns. It only operates for humans, and it all operates in startMission() and continueMission(), and it always looks at the unit's owner--not the active player (though that shouldn't matter because the active player is always human).

Here is a new DLL with just one line of the code commented out--the line that stops a unit from attacking a plot that it doesn't think was visible when it was issued to move order. Can you please try with your test game? Thanks!

 

[BladeLakem]

@BladeLakem - Can you please describe the exact scenario you're testing?

• Simultaneous turns? (my guess is yes)
• Stack Attack option?
• Attacking with a stack or single unit?
• Does it matter whether or not the attacker wins?
• Do both games look OOS tio the player? IOW, does the winning unit move in one player's view but not the other's?

I've looked over all of the Safe Move code, and AFAICT it should be safe for MP and simultaneous turns. It only operates for humans, and it all operates in startMission() and continueMission(), and it always looks at the unit's owner--not the active player (though that shouldn't matter because the active player is always human).

Here is a new DLL with just one line of the code commented out--the line that stops a unit from attacking a plot that it doesn't think was visible when it was issued to move order. Can you please try with your test game? Thanks!

This DLL works fine on my save.

Simultaneous turns? Yes
Stack Attack? No
Attacking with single unit.
I haven't tested a loss - I'm at an overwhelming advantage

As for both being OOS, the other player can't see what I am doing. The land is revealed, but they don't have any units or cities close, so they don't see any of what is happening there.

 

[EmperorFool]

As for both being OOS, the other player can't see what I am doing. The land is revealed, but they don't have any units or cities close, so they don't see any of what is happening there.

I love making stupid assumptions. In this case I assumed the OOS was happening when one human attacked another human.

m_bLastPlotRevealed = pPlot->isRevealed([B][COLOR="Red"]GC.getGameINLINE().getActiveTeam()[/COLOR][/B], false);

Wrong! Stupid mistake. Please try this new DLL.

 

[Fimbulvetr]

Maybe, but I don't see how simultaneous turns could be the cause of the problem. It would have to make one computer move the unit and the other unit not move the unit. But in these tests all the plots involved are revealed (right?) so Safe Moves shouldn't even come into play.

I know little about what causes OOS or what it could be that is causing it here, so I just made a very uneducated guess and was probably wrong anyway -_-;

I still stand by my point though, if making Safe Move multiplayer compatible isn't trivial, which I assume, then the easy solution is the one you should use. !GC.getGameINLINE().isNetworkMultiPlayer() should do the trick (the trick being just to disable it for multiplayer).

 

[EmperorFool]

I did find a trivial bug in Safe Moves where I was checking getAcivePlayer() instead of getOwner(). I posted a fixed DLL to the testing thread a few days back but haven't heard any results yet. I'll post the fixed code when I get home tonight, but I need to have someone do a test to verify it fixes the problem before we can consider it solved.

 

[ZippyDan]

i did find a trivial bug in safe moves where i was checking getaciveplayer() instead of getowner(). I posted a fixed dll to the testing thread a few days back but haven't heard any results yet. I'll post the fixed code when i get home tonight, but i need to have someone do a test to verify it fixes the problem before we can consider it solved.

omg bladelakem, tell us if it is fixed ((((

 

[EmperorFool]

omg bladelakem, tell us if it is fixed ((((

Uh oh, the natives are getting restless!

 

[ZippyDan]

Uh oh, the natives are getting restless!

A barbarian uprising is imminent

Emperor, I'd be willing to test a few hundred turns using your new DLL in a multiplayer game if you are reasonably sure the problem is solved.

You also mentioned there was a problem with the Graphics causing crashes in 2.1, and that there was a version of 2.2 available to solve this.

Is there anyway I could test both the new 2.2 BAT mod and the new DLL you posted in the thread concurrently?

I am scheduled to start a 10-player pitboss game on Saturday and I want to use BAT mod, hence the impatience. I'll have all-day tomorrow to test, but if I'm not reasonably sure that the problem is fixed then we'll have to play mod-less.

 

[EmperorFool]

BAT 2.2 will be a while. First, we need to make sure that BULL is fixed. Second, we need to get the installer completed. Third, we're all pretty slammed on time.

That DLL is ready to go, and AFAICT the problem should be solved. The bug I found and fixed would definitely cause the OOS problem being seen. Now, is that the only cause of the problem? I dunno; that's why we need more testing. People have said that the OOS happens as soon as any human attacks any rival AI. If you can test that tomorrow, that would help a lot.