Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

I imagine that would be Albert's change in 8618.
 
The UNIT_MAPINGUARI_STONE has two UnitCombats used as UnitClasses inside UnitClassDefenseMods that is wrong. I'am not sure how to fix this one because i don't know what whoever did this wanted to do.

Code:
			<UnitClassDefenseMods>
				<UnitClassDefenseMod>
					<UnitClassType>[COLOR="Red"][B]UNITCOMBAT_MOUNTED[/B][/COLOR]</UnitClassType>
					<iUnitClassMod>20</iUnitClassMod>
				</UnitClassDefenseMod>
				<UnitClassDefenseMod>
					<UnitClassType>[B][COLOR="Red"]UNITCOMBAT_MELEE[/COLOR][/B]</UnitClassType>
					<iUnitClassMod>25</iUnitClassMod>
				</UnitClassDefenseMod>
			</UnitClassDefenseMods>



@Thunderbrd

You have added the marked condition to fix some OOS error. But now you have a memory leak instead in case the MPOPTION_SIMULTANEOUS_TURNS is on. This is because m_pabHasVicinityBonusCached is now allocated every time that function is called.

Code:
bool CvCity::hasVicinityBonus(BonusTypes eBonus) const
{
	PROFILE_FUNC();
	
	if ( m_pabHasVicinityBonusCached == NULL[COLOR="Red"][B] || GC.getGameINLINE().isMPOption(MPOPTION_SIMULTANEOUS_TURNS)[/B][/COLOR])
	{
		m_pabHasVicinityBonusCached = new bool[GC.getNumBonusInfos()];
		SAFE_DELETE_ARRAY(m_pabHasVicinityBonus);
		m_pabHasVicinityBonus = new bool[GC.getNumBonusInfos()];

		for(int iI = 0; iI < GC.getNumBonusInfos(); iI++)
		{
			m_pabHasVicinityBonusCached[iI] = false;
		}
	}

You have to find another way to fix that OOS.
 
The UNIT_MAPINGUARI_STONE has two UnitCombats used as UnitClasses inside UnitClassDefenseMods that is wrong. I'am not sure how to fix this one because i don't know what whoever did this wanted to do.

Code:
			<UnitClassDefenseMods>
				<UnitClassDefenseMod>
					<UnitClassType>[COLOR="Red"][B]UNITCOMBAT_MOUNTED[/B][/COLOR]</UnitClassType>
					<iUnitClassMod>20</iUnitClassMod>
				</UnitClassDefenseMod>
				<UnitClassDefenseMod>
					<UnitClassType>[B][COLOR="Red"]UNITCOMBAT_MELEE[/COLOR][/B]</UnitClassType>
					<iUnitClassMod>25</iUnitClassMod>
				</UnitClassDefenseMod>
			</UnitClassDefenseMods>

Mine. Those units are supposed to be great defenders against all mounted and melee units. I did ask when I was doing it! In fact the whole line is supposed to have that attribute not just stone. Maybe I fixed it on the others in the line but forgot the stone one. I'll check.

No it is commented out on the others. So I will ask the question again.

How do I make a unit defend against a combat class with a modifier to that defense?
 
CTD, last thing i did was use a spy to "Aid rebel faction" if that helps??

I use Dangerous Animals, and a few extra civs also/

The minidump is interesting. Certainly shows a lot of the code leading up to the crash and some flaws taking place. Looks like a unit has been sent to move to a map location that is invalid. I could be wrong. This is taking place in a region of processing I've never been able to sort out the purpose of a lot of the steps. I would ask Alberts2 to look into this one if and when time allows.

I can't say for sure but I don't think it was YOUR unit that caused a problem. Looks like it may have been an AI unit determination. Unless you were using an automation or had the spy grouped with another unit perhaps.



Edit:
In fact, it appears that pathing is the biggest unhealthy spot in this mod at the moment. And there's not much I can do about it. I made a change there recently to try to resolve an OOS but not only did it not help, I don't think it has much to do with the root of the problem. There's other issues at hand there causing meltdowns.

In a single player game evaluation under debugging I get this:
FAssert(!newNode->m_bIsKnownRoute || node->m_iCostTo + iEdgeCost == newNode->m_iCostTo);
causing a breakpoint in
> CvGameCoreDLL.dll!CvPathGenerator::generatePath(const CvPlot * pFrom=0x71bb3a04, const CvPlot * pTo=0x71d008e8, CvSelectionGroup * pGroup=0x701d4bc0, int iFlags=1, int iMaxTurns=25, int iOptimizationLimit=6600) Line 2922 + 0x58 bytes C++

When I asked Koshling about this a while back he said it was an extremely difficult area to debug and hell yeah he's right about that. It would help if I understood each part of what was actually happening here but I must admit I don't understand the intention behind 80% of the variables in play there. Something isn't right.

Now, a while back, Afforess changed the pathing mechanism in AND. I don't know how that project ended but perhaps we need to follow his example? I don't know. I just know that movement issues are causing crashes, Out of Syncs, throwing asserts and creating obvious rule problems and I can't seem to figure out how to address any of them. Very frustrating that something so central to the mod is causing problems I feel powerless to resolve. Sorry guys.

OOS and crash portions that relate to this:
1) My wife took Seafaring as a trait which gives a promo to all her naval units that add +1 movement. Soon as she did, her computer's units weren't moving at their full capacity but on my system it showed they had.
2) A Neanderthal goes one way on her system and another way on mine and the difference was somehow generated in the pathing determination.
3) When a unit attacks and withdraws, it often then goes on to go a different direction on one computer than another or perhaps has been charged for the movement for the attack on one system and not on the other but regardless the problem has been pinned down to this generatepath function by special logging indicators.
4) This particular bug that SO reported took place in generatepath.
5) Afforess reported stack overflows taking place here... that seems to be the case when you look at some of the values in this particular assert break. Either that or uninitialized variables where I'm not even sure where they were supposed to be initialized in the first place. Uninitialized variables are a sure fire way to create an OOS as well.


So yeah, this issue is really getting under my skin and it is because I don't know how to fix it. Makes me wonder why and where C2C started using different pathing to standard CivIV in the first place. I suppose it was to save on processing time? Not worth it if it's going to create crashes and OOS errors. At this point I'm seriously considering comparing the whole process to the original CivIV version and seeing if I can surgically re-insert the original back in place. However, there's a lot of moving parts to this issue - a mind numbingly complex array of moving parts.

There's some #ifdef isolated bits of code with a variable of USE_OLD_PATHING or something to that extent but apparently not all the old pathing portions work properly either, aka, trying to generate a def for this variable only causes crashes right away.


EDIT:
@Alberts2: Ok, I just read back and saw your last post. I can see what you mean and it doesn't solve the OOS anyhow. TBH, the whole pathing issue, as stated above, is really giving me endless grief trying to solve OOS and other errors.

EDIT:
@Alberts2: Actually, that's not the pathing portion that I tried using a similar method with that didn't work. I'll make sure to get rid of the method there too. As for the function you pointed out, without using that, the caching was causing a problem and apparently I addressed it in the wrong way. I can see a better way to bypass the caching entirely. Thanks for pointing that out. I'll have the new code and dll on the svn here shortly.
 
Mine. Those units are supposed to be great defenders against all mounted and melee units. I did ask when I was doing it! In fact the whole line is supposed to have that attribute not just stone. Maybe I fixed it on the others in the line but forgot the stone one. I'll check.

No it is commented out on the others. So I will ask the question again.

How do I make a unit defend against a combat class with a modifier to that defense?

You're trying to add a modifier to a unitcombat opponent with a unitCLASS modifier tag. I believe you almost have this right if you were to use the unitcombat modifier tag instead.
 
@Alberts2:
Would this portion cause a similar problem? If so, I'm not sure how to resolve it since the processing has been made to REQUIRE the caching here:
Code:
	if ( GC.getGameINLINE().isMPOption(MPOPTION_SIMULTANEOUS_TURNS) ||
		 m_cachedPlayer != getOwnerINLINE() ||
		 m_cachedMissionaryPlotset == NULL ||
		 m_cachedMissionaryPlotset->find(plot()) == m_cachedMissionaryPlotset->end() )
	{
		SAFE_DELETE(m_cachedMissionaryPlotset);

		m_cachedMissionaryPlotset = new CvReachablePlotSet(getGroup(), MOVE_NO_ENEMY_TERRITORY, MAX_INT, false);

		m_cachedPlayer = getOwnerINLINE();
	}
This is in bool CvUnitAI::AI_spreadReligion()
 
You're trying to add a modifier to a unitcombat opponent with a unitCLASS modifier tag. I believe you almost have this right if you were to use the unitcombat modifier tag instead.

Nah, that doesn't work since they are only supposed to get bonuses when defending verses those units not attacking. I'll make them
  • defense only
  • very poor in city defense
  • with increased unitcombat modifier against those combat types

that should make them used in the field as defensive units in a stack.
 
CTD, last thing i did was use a spy to "Aid rebel faction" if that helps??

I use Dangerous Animals, and a few extra civs also/

The minidump is interesting. Certainly shows a lot of the code leading up to the crash and some flaws taking place. Looks like a unit has been sent to move to a map location that is invalid. I could be wrong. This is taking place in a region of processing I've never been able to sort out the purpose of a lot of the steps. I would ask Alberts2 to look into this one if and when time allows.

I can't say for sure but I don't think it was YOUR unit that caused a problem. Looks like it may have been an AI unit determination. Unless you were using an automation or had the spy grouped with another unit perhaps.


.

alberts2, can you pls take a look at this thx. post 2063) . . SO

EDIT:

Dont know IF this is the same as the other one or not, as i had to go back a few saves to get it to work again, but alas it CTD'ed again :mad:

I was placing Priest this time to cities??
 
Nah, that doesn't work since they are only supposed to get bonuses when defending verses those units not attacking. I'll make them
  • defense only
  • very poor in city defense
  • with increased unitcombat modifier against those combat types

that should make them used in the field as defensive units in a stack.

There's a (fairly new) generic defense modifier tag that is a general combat modifier only when defending, but there's not a defense vs any particular unitclass or unitcombat modifier tag. We're running up against there being too many tags for units as it is to add such specialized modifiers, particularly since there's some very important new ones to be inserted for Nomadic units. (I've got a few tags that can be removed to make some room there as well.)

You could simply use the idefensemodifier tag and counter it with a penalty to city defense and achieve the same thing but if you want to make sure it's ONLY good against particular unit combat types, then what you have worked out there is about all you could do.
 
There's a (fairly new) generic defense modifier tag that is a general combat modifier only when defending, but there's not a defense vs any particular unitclass or unitcombat modifier tag. We're running up against there being too many tags for units as it is to add such specialized modifiers, particularly since there's some very important new ones to be inserted for Nomadic units. (I've got a few tags that can be removed to make some room there as well.)

You could simply use the idefensemodifier tag and counter it with a penalty to city defense and achieve the same thing but if you want to make sure it's ONLY good against particular unit combat types, then what you have worked out there is about all you could do.

It is an idea from Civ III where they had two combat values, one for attack and another or defense. I'll work something out.
 
The minidump is interesting. Certainly shows a lot of the code leading up to the crash and some flaws taking place. Looks like a unit has been sent to move to a map location that is invalid. I could be wrong. This is taking place in a region of processing I've never been able to sort out the purpose of a lot of the steps. I would ask Alberts2 to look into this one if and when time allows.

I can't say for sure but I don't think it was YOUR unit that caused a problem. Looks like it may have been an AI unit determination. Unless you were using an automation or had the spy grouped with another unit perhaps.



Edit:
In fact, it appears that pathing is the biggest unhealthy spot in this mod at the moment. And there's not much I can do about it. I made a change there recently to try to resolve an OOS but not only did it not help, I don't think it has much to do with the root of the problem. There's other issues at hand there causing meltdowns.

In a single player game evaluation under debugging I get this:
FAssert(!newNode->m_bIsKnownRoute || node->m_iCostTo + iEdgeCost == newNode->m_iCostTo);
causing a breakpoint in
> CvGameCoreDLL.dll!CvPathGenerator::generatePath(const CvPlot * pFrom=0x71bb3a04, const CvPlot * pTo=0x71d008e8, CvSelectionGroup * pGroup=0x701d4bc0, int iFlags=1, int iMaxTurns=25, int iOptimizationLimit=6600) Line 2922 + 0x58 bytes C++

When I asked Koshling about this a while back he said it was an extremely difficult area to debug and hell yeah he's right about that. It would help if I understood each part of what was actually happening here but I must admit I don't understand the intention behind 80% of the variables in play there. Something isn't right.

Now, a while back, Afforess changed the pathing mechanism in AND. I don't know how that project ended but perhaps we need to follow his example? I don't know. I just know that movement issues are causing crashes, Out of Syncs, throwing asserts and creating obvious rule problems and I can't seem to figure out how to address any of them. Very frustrating that something so central to the mod is causing problems I feel powerless to resolve. Sorry guys.

OOS and crash portions that relate to this:
1) My wife took Seafaring as a trait which gives a promo to all her naval units that add +1 movement. Soon as she did, her computer's units weren't moving at their full capacity but on my system it showed they had.
2) A Neanderthal goes one way on her system and another way on mine and the difference was somehow generated in the pathing determination.
3) When a unit attacks and withdraws, it often then goes on to go a different direction on one computer than another or perhaps has been charged for the movement for the attack on one system and not on the other but regardless the problem has been pinned down to this generatepath function by special logging indicators.
4) This particular bug that SO reported took place in generatepath.
5) Afforess reported stack overflows taking place here... that seems to be the case when you look at some of the values in this particular assert break. Either that or uninitialized variables where I'm not even sure where they were supposed to be initialized in the first place. Uninitialized variables are a sure fire way to create an OOS as well.


So yeah, this issue is really getting under my skin and it is because I don't know how to fix it. Makes me wonder why and where C2C started using different pathing to standard CivIV in the first place. I suppose it was to save on processing time? Not worth it if it's going to create crashes and OOS errors. At this point I'm seriously considering comparing the whole process to the original CivIV version and seeing if I can surgically re-insert the original back in place. However, there's a lot of moving parts to this issue - a mind numbingly complex array of moving parts.

There's some #ifdef isolated bits of code with a variable of USE_OLD_PATHING or something to that extent but apparently not all the old pathing portions work properly either, aka, trying to generate a def for this variable only causes crashes right away.

Afforess tried to use the old pathing mechanism but that lead to a few other issues and they are now using the C2C pathing mechanism again. The stack overflows in AND where caused by errors made in the proccess of merging changes from C2C into AND.
 
alberts2, can you pls take a look at this thx. post 2063) . . SO

EDIT:

Dont know IF this is the same as the other one or not, as i had to go back a few saves to get it to work again, but alas it CTD'ed again :mad:

I was placing Priest this time to cities??

The game crashes if you try to move a unit with zero movement points left. But it should not be possible to move such a unit that suggest there might be another issue in the recent unit movement changes.
 
I must have made a mistake in the World Tech code. It appears to work fine for the AI but not the player. I'll try and figure it out later today (it is 2am here;)).
 
I have svn 8628, i make split unit and I fall out in Windows

I'll take a look soon but what unit are you trying to split?
 
Back
Top Bottom