v 25, Bugs/Crashes reporting thread

[calvitix]

Same save as comment 456, under SVN 3491 (from about an hour ago), the huge inflation value is gone, but there's still a huge overcharge somewhere. When I loaded the save, it indicated I had a surplus of 71 gold per turn, which went hugely negative (-350ish with 0% research) after recalculating, so maybe there's some issue with the recalculation (still)?

What do you mean by Overcharge ?

in your save, the next turn (2269), IA 13 choose Tech : same issue as Joseph and Questdog game - it take more than 4 min to evaluate all building/Units that can be build with each Tech (~70 different ways). after that turn 2270 is better, but for turn 2271, the same IA choose again another Tech.

on my Computer (SVN 3489):

Turn 2269 : 12 min 52
Turn 2270 : 5 min 56
Turn 2271 : 8 min 56


About Gold per turn, the inflation goes from -268 to 0, and the civics cost rise from 35 to 82. That's why you go from +71 to - 267 gold per turn (with 100% research).

 

[Thunderbrd]

I didn't change anything in the wrappers page nor variable or game options. My modifications are quite light.

@strategyonly : could we have an example of savegame ?

Yeah, I could find little to no useful info from the minidump alone (may have been that I did not have a completely identical version setup though.) From what I could tell it seemed the problem was a crash during a dll process.

Calvitix... did you adjust anything that may have reported to the core? This might've caused an issue like that. But then, it would also mean that no game would run for long either, not just savegames.

 

[strategyonly]

Yeah, I could find little to no useful info from the minidump alone (may have been that I did not have a completely identical version setup though.) From what I could tell it seemed the problem was a crash during a dll process.

Calvitix... did you adjust anything that may have reported to the core? This might've caused an issue like that. But then, it would also mean that no game would run for long either, not just savegames.

Sorry about that guys, now everything is working again, must have been a graphics glitch??

 

[Koshling]

@calvitix:

Nice work there, although I am not familiar with the grouping AI at all, that is one of the things Koshling has made many changes to. I'll ask him what could be causing an infinite loop there.

Edit: dang, his PM box is full, I'll have to hope he sees this.

This is likely not a new problem. Most WFoC bugs turn out to be unitAIs 'arguing' like this with a net no-result that never resolves. I presume it's just been seen in the one save game? If so please make sure the save is still available in a couple of weeks time and I'll do something about it.

For reference the way t debug that sort of thing once you know the unit involved is to breakpoint the main unit ai routine (I forget the name, but the one wi the bug switch based on ai type hat all the rest branches off in CvUnitAI.cpp) with the breakpoint being conditional on the unit I'd matching the one you are interested in. Thejust walk through the code and see what's happening. Sounds like that's more or less what you did here and that would get you as far as the conclusion you reached above about one stack trying to group and the groupers not want to pla ball. The evantual fix will be to make the logic in the tw different ai routines (the one that wants t group oth units, the e othe that wants to ungroup) consistent with one another.

 

[Koshling]

Same save as comment 456, under SVN 3491 (from about an hour ago), the huge inflation value is gone, but there's still a huge overcharge somewhere. When I loaded the save, it indicated I had a surplus of 71 gold per turn, which went hugely negative (-350ish with 0% research) after recalculating, so maybe there's some issue with the recalculation (still)?

Is this your first recalculation since the new civics were added? If so you can expect a lot of extra costs from some of those I think. Whe does the apparent overcharge show up in the financial advisor?

 

[Koshling]

Great work guys. The Civic upkeep seems to be back to normal. D/L'd the 3485 fix this morning will D/L the new one asap.

Thanks calvitix and ls612.

JosEPh

Edit: Meant to mention earlier when I saw ls612 had disabled The Great Wall. It's not so much that it floats but rather it shifts when you border expands to match the cultural border. I have northern area of my island unsettled for animal harvesting and as my border cities cultural influence expands the GW moves along with that expansion.

That behavior is intentional. It's discussed in the viewport thread. It can be turned off by setting DYNAMIC_GREAT_WALL to 0 in the global defines IF you a not using viewports, but it is necessary for viewports or it cannot reliably display the wall a all. Note that ere is no functional effect - the GW always has expanded with your border, in terms of it's effects, this just makes the graphic match the effect.

 

[Stormwind]

Newest SVN (3493) quits on me without error while loading the main game with this minidump.

View attachment 330107

Edit: Neither reboot nor deleting the cache does allow me to start CIV.

 

[Flinx]

Seconded, rev 3491 is running fine.

The Great Wall does not obsolete, is this intended?

 

[JosEPh_II]

@Stormwind,
Does 3492 work okay?

JosEPh

 

[Stormwind]

@Stormwind,
Does 3492 work okay?

JosEPh

I reverted back to 3491 and did not test 3492.

EDIT: 3492 does not work

 

[JosEPh_II]

@Stormwind,
Reason I asked because Hydro and Praetyre's Building Updates are those 2 versions. And Hydro wanted Praetyre to add a building's changes into the Core. From the SVN it doesn't look that it was added in that way.

Note that ere is no functional effect - the GW always has expanded with your border, in terms of it's effects, this just makes the graphic match the effect.

I thought as much but as other ppl have commented on the GW I thought I'd add in my observation too.

I wonder then does SO's recent update 3494 work?

JosEPh

 

[Stormwind]

@Stormwind,
Reason I asked because Hydro and Praetyre's Building Updates are those 2 versions. And Hydro wanted Praetyre to add a building's changes into the Core. From the SVN it doesn't look that it was added in that way.

I retested and 3492 does not work either.
From what I read about when this happens I think it is related to an error in the xml or schema file. I could be mixing up this with other errors though.

 

[ls612]

That behavior is intentional. It's discussed in the viewport thread. It can be turned off by setting DYNAMIC_GREAT_WALL to 0 in the global defines IF you a not using viewports, but it is necessary for viewports or it cannot reliably display the wall a all. Note that ere is no functional effect - the GW always has expanded with your border, in terms of it's effects, this just makes the graphic match the effect.

calvitix determined that a repeatable CTD that some were experiencing was due to an AI building the GW on that turn with Viewports enabled. Disabling Viewports allowed the turn to complete without a crash, but I still figured it would be better to remove the graphic entirely until a fix is found.

 

[ls612]

Newest SVN (3493) quits on me without error while loading the main game with this minidump.

View attachment 330107

Edit: Neither reboot nor deleting the cache does allow me to start CIV.

It's crashing in the XML loading code, so that supports the theory that it may be related to Hydro's and Praetyre's changes. Could you please post a save so I can see if I can repeat it?

 

[calvitix]

This is likely not a new problem. Most WFoC bugs turn out to be unitAIs 'arguing' like this with a net no-result that never resolves. I presume it's just been seen in the one save game? If so please make sure the save is still available in a couple of weeks time and I'll do something about it.

For reference the way t debug that sort of thing once you know the unit involved is to breakpoint the main unit ai routine (I forget the name, but the one wi the bug switch based on ai type hat all the rest branches off in CvUnitAI.cpp) with the breakpoint being conditional on the unit I'd matching the one you are interested in. Thejust walk through the code and see what's happening. Sounds like that's more or less what you did here and that would get you as far as the conclusion you reached above about one stack trying to group and the groupers not want to pla ball. The evantual fix will be to make the logic in the tw different ai routines (the one that wants t group oth units, the e othe that wants to ungroup) consistent with one another.

That's effectively what I did. But just a quick alk through. I need a little more experience with the whole AI Units update behavior to find out and apply modifications. I'll check this week-end if I have some time.

 

[Stormwind]

It's crashing in the XML loading code, so that supports the theory that it may be related to Hydro's and Praetyre's changes. Could you please post a save so I can see if I can repeat it?

It's crashing even before I get to the start screen of the game, so a save is not needed.

 

[calvitix]

Sorry about that guys, now everything is working again, must have been a graphics glitch??

Don't worry

is the last SVN (3494) working now ?

 

[ls612]

	if( !(plot()->isOwned()) )
	{
		 //Fuyu: could result in endless loop (at least it does in AND)
		if( AI_groupMergeRange(UNITAI_SETTLE, 2, true, false, false) )
		{
			return;
		}
	}

This routine in CvUnitAI::AI_counterMove looks awfully suspicious in terms of being the culprit for the WfOC error Questdog had. My question is, would it be safe to just comment out this whole routine, or would that severely hurt the AI in some way?

 

[ls612]

@Hydro:

You caused the XML load crash, you aren't allowed to have more than 6 OR prereqs under the <PrereqBonuses> tag! The Church of State has 7 OR prereqs, and that is causing the load crash everyone's been having. I removed the Bamboo prereq for now to fix the crash, but you should really change it to use the Expression System's ConstructCondition tag for prereqs.

 

[calvitix]

	if( !(plot()->isOwned()) )
	{
		 //Fuyu: could result in endless loop (at least it does in AND)
		if( AI_groupMergeRange(UNITAI_SETTLE, 2, true, false, false) )
		{
			return;
		}
	}

This routine in CvUnitAI::AI_counterMove looks awfully suspicious in terms of being the culprit for the WfOC error Questdog had. My question is, would it be safe to just comment out this whole routine, or would that severely hurt the AI in some way?

Yes, I saw the comment, but it was not in that method that the problem was : the plot was owned by the barbarian, so it didn't go inside that method.