OOS problem in A New Dawn

[45°38'N-13°47'E]

I know this is C2C forum but I've imported most of the C2C code into AND2 dll and I need your opinion, if possible; and hopefully it might be useful for C2C too. Recently I've tried a MP game with my wife and we were getting frequent OOS problems. After some research, I think I've found the codelines responsible for this particular OOS. The problem was that when my capital was building a specific unit or building and inside the city screen I was adding something else to be built ON TOP of the current production (ctrl+click), the game was instantly going OOS. 100% repeatable. So I started looking at previous AND revisions where this problem wasn't present and i've found that the problem disappears if I delete the following lines in CvCityAI.cpp

		//	Don't mess with plot assignments while the user is in the city screen as
		//	current assignments might be transitory
		if ( isHuman() && gDLL->getInterfaceIFace()->isCityScreenUp() )
		{
			//	Also assume when they leave the city screen they will leave a state
			//	they are happy with
			AI_setAssignWorkDirty(false);
			return;
		}

I don't know if this is what's causing the OOS problem; it might be that I've missed some other part of the code I should have imported from C2C. But if I delete these lines, that specific OOS doesn't happen anymore. Any idea about it?

 

[Koshling]

I know this is C2C forum but I've imported most of the C2C code into AND2 dll and I need your opinion, if possible; and hopefully it might be useful for C2C too. Recently I've tried a MP game with my wife and we were getting frequent OOS problems. After some research, I think I've found the codelines responsible for this particular OOS. The problem was that when my capital was building a specific unit or building and inside the city screen I was adding something else to be built ON TOP of the current production (ctrl+click), the game was instantly going OOS. 100% repeatable. So I started looking at previous AND revisions where this problem wasn't present and i've found that the problem disappears if I delete the following lines in CvCityAI.cpp

		//	Don't mess with plot assignments while the user is in the city screen as
		//	current assignments might be transitory
		if ( isHuman() && gDLL->getInterfaceIFace()->isCityScreenUp() )
		{
			//	Also assume when they leave the city screen they will leave a state
			//	they are happy with
			AI_setAssignWorkDirty(false);
			return;
		}

I don't know if this is what's causing the OOS problem; it might be that I've missed some other part of the code I should have imported from C2C. But if I delete these lines, that specific OOS doesn't happen anymore. Any idea about it?

Interesting. That code is fairly recent. It was added because previously each time you adjusted specialists that would set assign work dirty (indirectly) and on the next time slice (i.e. - call to CvGame::update()) it would re-assign specialists. The result was that when you told it to stop using a specialist that the AI liked (so it transiently becomes a citizen specialist until you reassign it) the game would immediately reassign it before the user got the chance to do so (often back to what you just deselected!).

Having said that, I cannot see how adding to the build queue interacts with plot assignment! What exactly goes OOS? Do the OOS logs show you what part of the city state winds up different?

 

[45°38'N-13°47'E]

Interesting. That code is fairly recent. It was added because previously each time you adjusted specialists that would set assign work dirty (indirectly) and on the next time slice (i.e. - call to CvGame::update()) it would re-assign specialists. The result was that when you told it to stop using a specialist that the AI liked (so it transiently becomes a citizen specialist until you reassign it) the game would immediately reassign it before the user got the chance to do so (often back to what you just deselected!).

Having said that, I cannot see how adding to the build queue interacts with plot assignment! What exactly goes OOS? Do the OOS logs show you what part of the city state winds up different?

I know, I updated AND2 almost to the latest revision of C2C, but I also don't see any connection with the OOS problem in this part of the code. I also have the log of both players (attached), if you want to check but I really can't see the problem (well, I'm not an expert in checking oos bugs to tell the truth); as you can see in the BBAI.log, the problem appears when I put a barracks on the top of the building queue in Moscow: it instantly makes the game oos. It doesn't happen in other cities in this turn; but it happens in other cities as well when I play a few turns. So in some cases (but not always!) adding something to the top of the building queue, puts the game OOS. It happens when adding both units or buildings. And if I get an OOS warning but I delete what I've just added to the queue, the OOS warning disappears. And it doesn't happen adding units or buildings at the end of the building queue or changing production. But doesn this problem occur in C2C too? Hasn't anyone tried or reported a similar problem?

 

[Koshling]

I know, I updated AND2 almost to the latest revision of C2C, but I also don't see any connection with the OOS problem in this part of the code. I also have the log of both players (attached), if you want to check but I really can't see the problem (well, I'm not an expert in checking oos bugs to tell the truth); as you can see in the BBAI.log, the problem appears when I put a barracks on the top of the building queue in Moscow: it instantly makes the game oos. It doesn't happen in other cities in this turn; but it happens in other cities as well when I play a few turns. So in some cases (but not always!) adding something to the top of the building queue, puts the game OOS. It happens when adding both units or buildings. And if I get an OOS warning but I delete what I've just added to the queue, the OOS warning disappears. And it doesn't happen adding units or buildings at the end of the building queue or changing production. But doesn this problem occur in C2C too? Hasn't anyone tried or reported a similar problem?

C2C has OOS problems too, and nobody currently working on the mod is much of an expert in that area, so currently they are outstanding issues. However, I'll take a look at your logs and see if I can think of anything.

 

[45°38'N-13°47'E]

C2C has OOS problems too, and nobody currently working on the mod is much of an expert in that area, so currently they are outstanding issues. However, I'll take a look at your logs and see if I can think of anything.

Thank you Koshling, really appreciated

 

[Thunderbrd]

Well... I can say one thing on this. When you have the city screen up you're running async right there. So anything done (or unusually specified as NOT done) during this 'state' will be done async. So in this case, one computer finds that the city should run AI_setAssignWorkDirty(false); while the other computers on the network would not. I'm not 10000% sure what exactly is taking place in that command but only the computer with the city screen open is running it so that seems like ripe ground for an OOS to me.

The cure? Doing it through a message system perhaps but I'm not so sure how that would be done in this sort of case.

 

[Koshling]

Well... I can say one thing on this. When you have the city screen up you're running async right there. So anything done (or unusually specified as NOT done) during this 'state' will be done async. So in this case, one computer finds that the city should run AI_setAssignWorkDirty(false); while the other computers on the network would not. I'm not 10000% sure what exactly is taking place in that command but only the computer with the city screen open is running it so that seems like ripe ground for an OOS to me.

The cure? Doing it through a message system perhaps but I'm not so sure how that would be done in this sort of case.

The fix in this case is probably to use some other technique (than preventing the assignment being marked dirty) to inhibit unbidden changing of specialists. The reason it was done this way is that it was simple, but it may need a more explicit mechanism to cause the auto specialist setting to be inhibitted when the city screen is up. At its simplest just try adding a new boolean bInhibitSpecialistSetting to the CvCityAI class, and have that set when the city screen is brought up, and reset when it is closed, and checked before trying to do any auto-setting of specialists. Should be pretty easy, since you have a good to-hand test case.

 

[Thunderbrd]

The fix in this case is probably to use some other technique (than preventing the assignment being marked dirty) to inhibit unbidden changing of specialists. The reason it was done this way is that it was simple, but it may need a more explicit mechanism to cause the auto specialist setting to be inhibitted when the city screen is up. At its simplest just try adding a new boolean bInhibitSpecialistSetting to the CvCityAI class, and have that set when the city screen is brought up, and reset when it is closed, and checked before trying to do any auto-setting of specialists. Should be pretty easy, since you have a good to-hand test case.

Sounds fairly easy actually yes... provided that I can figure out where all that is taking place. Would take a while. So it's on 'the list' anyhow.

 

[Koshling]

Sounds fairly easy actually yes... provided that I can figure out where all that is taking place. Would take a while. So it's on 'the list' anyhow.

I meant for 45 to try actually, since he has a ready test case, but sure.

 

[45°38'N-13°47'E]

I meant for 45 to try actually, since he has a ready test case, but sure.

I'll try and see what I can do, thank you for your advices Koshling.

 

[Thunderbrd]

Cool... just let us know the exact code to alter cuz this affects us too right?