[BUG]BULL Destroys Multi-Player

[Afforess]

I've found that BULL causes and OOS error when you attack or defend in BTS. To test this, I just grabbed BUG 4.2, installed the multiplayer version, then added the BULL assets. I did the same thing for both computers, and I played, declared war on a nearby player, attacked them, and got an OOS.

Any ideas on what causes this? This is a fairly critical bug, since causing OOS's kinda defeats the Unaltered Gameplay Mantra.

I'm going to start looking at the BULL code and start commenting sections of it out, and re-compiling. Any suggestions where I should begin?

Update:

I replaced the CvGameTextMgr, CvDLLWidgetData, and CvPlot with BTS unaltered files and did a full recompile. I still got an OOS in combating.

 

[EmperorFool]

I need to dig into this more, but I can say that people have said that the pre-release (before 1.0) version of BULL--the one with the Stack Attack bug--did not cause the OOS error. I suspect that my fix for the SA bug caused the OOS bug.

If you want to see what's changed, look at the SVN commit log (click on any revision number in the browser) for where I fixed that issue. I'll do the same tomorrow.

 

[Afforess]

I need to dig into this more, but I can say that people have said that the pre-release (before 1.0) version of BULL--the one with the Stack Attack bug--did not cause the OOS error. I suspect that my fix for the SA bug caused the OOS bug.

If you want to see what's changed, look at the SVN commit log (click on any revision number in the browser) for where I fixed that issue. I'll do the same tomorrow.

Want to fill me in? What exactly was the stack attack bug?

I'm afraid I've neglected these forums for far too long, I'm behind on all the cutting edge work you've done.

 

[EmperorFool]

I introduced a bug that crashed the game if

• You had Stack Attack turned on in Civ4's options screen
• You attacked with a stack of at least 2 units
• You destroyed the last enemy unit on the plot

 

[Afforess]

I introduced a bug that crashed the game if

• You had Stack Attack turned on in Civ4's options screen
• You attacked with a stack of at least 2 units
• You destroyed the last enemy unit on the plot

Okay, any idea where it got introduced? You mentioned that you "fixed" it. How?

 

[EmperorFool]

There was a null pointer case I wasn't checking. I just checked for it.

I think I introduced the problem when adding the Safe Moves feature which is some code I extracted from Sentry Moves and expanded upon. What it does it keep you from attacking a unit in a tile you hadn't revealed when you made your move order. The same for unloading on an unrevealed land tile.

What I added to the original code from Pep is that it handles game loading now. It stores a new "is my endpoint unrevealed" flag for each unit that gets set when you issue the order and checked before attacking/unloading. If it is true, it aborts the mission. Pep's code would leave this flag false when the game was loaded which meant existing move orders would be aborted or not (I forget which).

My change was not to the save the flag (that would break saved game compatibility) but instead to check the endpoint of each unit with a move order when it was loaded.

I explain this, but I think this wasn't the problem. I suspect the problem was introduced when I added Pep's Go To While Sentry and other new Sentry orders. Again, I rewrote some of the code since I wasn't taking everything and was enhancing some stuff. This is probably where I added the Stack Attack bug.

 

[Afforess]

There was a null pointer case I wasn't checking. I just checked for it.

I think I introduced the problem when adding the Safe Moves feature which is some code I extracted from Sentry Moves and expanded upon. What it does it keep you from attacking a unit in a tile you hadn't revealed when you made your move order. The same for unloading on an unrevealed land tile.

What I added to the original code from Pep is that it handles game loading now. It stores a new "is my endpoint unrevealed" flag for each unit that gets set when you issue the order and checked before attacking/unloading. If it is true, it aborts the mission. Pep's code would leave this flag false when the game was loaded which meant existing move orders would be aborted or not (I forget which).

My change was not to the save the flag (that would break saved game compatibility) but instead to check the endpoint of each unit with a move order when it was loaded.

I explain this, but I think this wasn't the problem. I suspect the problem was introduced when I added Pep's Go To While Sentry and other new Sentry orders. Again, I rewrote some of the code since I wasn't taking everything and was enhancing some stuff. This is probably where I added the Stack Attack bug.

Great. So, if I reverted to Pep's Sentry Actions, would that fix the issue? Save compatibility isn't an issue for my mod.

Of course, that's not a real fix. Really, it would be best to fix it in BULL. IMHO, Multiplayer is fairly important. If you *don't* think the issue was Stack Attack, and instead think it's Sentry Orders, why didn't you say so!?

I'm curious as to how OOS errors are introduced to the game. Aren't they when the two clients generate different game "seeds"? How exactly did you manage to get them to generate different game seeds? Did you use a random number?

 

[EmperorFool]

OOS happens when two or more computers execute different actions that affect the game state that the OOS detector cares about. It doesn't always relate to randomness. The code I added has nothing to do with random numbers.

And no, the problem isn't likely to be the Sentry Actions changes because those were in before the OOS problem started. The OOS problem started when I fixed the Stack Attack bug. I need to look how what I did there when I have a good chunk of uninterrupted time. I can hopefully do that this week.

 

[Afforess]

OOS happens when two or more computers execute different actions that affect the game state that the OOS detector cares about. It doesn't always relate to randomness. The code I added has nothing to do with random numbers.

And no, the problem isn't likely to be the Sentry Actions changes because those were in before the OOS problem started. The OOS problem started when I fixed the Stack Attack bug. I need to look how what I did there when I have a good chunk of uninterrupted time. I can hopefully do that this week.

It's been a week, so I figured I should nag you about this. I'd appreciate any form of update.

 

[EmperorFool]

The fix for the Stack Attack bug is quite simple; I don't see how it could be the source of the OOS.

I tried setting up a multiplayer game yesterday by using an altroot, and it wiped my CustomAssets folder, profile, and INI in the process. Sometimes I really love this game. I didn't lose anything because I learned long ago never to keep anything valuable in there, but it still sucks. I'll try again.

What I'm trying to do is validate that the problem occurs with BULL alone. And then try successively older and older versions of BULL until I can isolate the revision that caused it. This is going to be a painstaking process of checkout, rebuild, test, checkout, rebuild, test, etc. Using Newton's method I can at least minimize the number of cycles, but it's still going to be tens of hours of labor just to find the offending revision. Yuck!

</self-pity>

 

[Afforess]

The fix for the Stack Attack bug is quite simple; I don't see how it could be the source of the OOS.

I tried setting up a multiplayer game yesterday by using an altroot, and it wiped my CustomAssets folder, profile, and INI in the process. Sometimes I really love this game. I didn't lose anything because I learned long ago never to keep anything valuable in there, but it still sucks. I'll try again.

What I'm trying to do is validate that the problem occurs with BULL alone. And then try successively older and older versions of BULL until I can isolate the revision that caused it. This is going to be a painstaking process of checkout, rebuild, test, checkout, rebuild, test, etc. Using Newton's method I can at least minimize the number of cycles, but it's still going to be tens of hours of labor just to find the offending revision. Yuck!

</self-pity>

Ugh, I hate it when I have to do that. There is a faster way of searching than just a successive search though. Check Revision 50, see if it works. Then jump up 10 revisions. If it doesn't work, hone in on it. Should cut your search time by a factor of 10.

Learned by experience...

 

[EmperorFool]

Newton's method moves by half instead of by 10, but the idea is the same. This cuts your search to log2(n) tests, but it's still a PITA given that each test will require about 20-30 minutes.

 

[Afforess]

Newton's method moves by half instead of by 10, but the idea is the same. This cuts your search to log2(n) tests, but it's still a PITA given that each test will require about 20-30 minutes.

Really? Why? Do you need to recompile for each release? Because in game it takes only 3-4 turns to reveal.

 

[EmperorFool]

This is what it takes:

1. SVN update to revision (gets that version of the source)
2. Full recompile
3. Setup two games (sometime this wipes my CA folder and INI file for some unknown reason)
4. Play until crash (hopefully quick)

#2 takes fifteen to twenty minutes itself.

 

[Fimbulvetr]

Afforess, if you want to do some testing, I compiled rev 48, 66, 84 and the very latest version.
Revision 49 adds some unofficial patch stuff, rev67 fixed the stack attack CTD and there are a lot of changes between 84 and 112..

 

[EmperorFool]

Wow, thanks Fuyu! Yes, if you could set up some tests, Afforess, that would be a huge help. Once I know where to look, I'm confident I could solve the problem quickly.

 

[phungus420]

It would really be nice to get this fix in. This is all I'm waiting for to package a 2.62 RevDCM release (have to get aproval from jdog/glider for an official release, but I'm confident the current SVN with this update and a subsequent fix for inquisitions that has been found is all that needs done), and update LoR. Since the cause of this MP bug is found I figure it shouldn't take too long to solve, and would like to wait for a fix for updating, and obviously I'd like to update fairly soon.

 

[MadmanAtW]

Does that mean the next RevDCM would work in multiplayer, out of curiosity?

 

[phungus420]

Once this is fixed MP will work in RevDCM like it did in older RevDCM versions. Ie it wol't be considered supported, but should function with the caveat that there will be some bugs such as all human players will receive the Revolutions popups etc, just like in old versions. glider is working on fully supporting RevDCM in a future version, but that's a whiles off yet. This bug from BULL utterly destroys MP, rather then just making it have issues, which is why it would be nice to have a fix.

 

[Afforess]

Afforess, if you want to do some testing, I compiled rev 48, 66, 84 and the very latest version.
Revision 49 adds some unofficial patch stuff, rev67 fixed the stack attack CTD and there are a lot of changes between 84 and 112..

Wow, thanks Fuyu! Yes, if you could set up some tests, Afforess, that would be a huge help. Once I know where to look, I'm confident I could solve the problem quickly.

Unfortunately, I'm back at school, I only have access to my laptop again. No MP tests for me. I'd appreciate if someone with multiple computers could test it though.