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

Ok I understand now. But we must wait for DH. Myths are his field.

The cause of the bug is in my realm but I'd fixed this before so I'll just have to figure out how it got broken again and repair it again.
 
any word on the modern fishing boats bug? the construturs have the same error to.


ggm

fishing boats and constructurs cant build fishing boats. its says something like unit must be of same size to build improvement on plot.

Thanks again for this save!

I was in a debugging mood so I looked into this deeper. Apparently this is NOT just a bug for Size Matters at all... there's numerous places this COULD be causing an issue. Apparently the problem exists in the new way CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) has been restructured. Mid-game it comes up with false for all unitcombats and that is a serious problem that manifests in this manner but probably numerous other issues.

I recognize the need we had to restructure this function for speed, don't get me wrong. But if it doesn't work this way it needs to be re-structured once more. I can try my hand at a new method here. This has also prompted me to restructure the way the tracking mechanism works to make sure units have their original base group size to qualify for actions like these and anything else that would sacrifice them which should speed up the load process for a tradeoff in hardly noticeable delays in-game.


EDIT: Ok, so this is fixed. Alberts2 and I had a discussion on how to get that function to work better a while back and there were 3 options that emerged from that discussion. I selected to use one that's a little heavier on memory but works well for a number of reasons. Perhaps converting to option 2 (if you recall Alberts, that was your concept of putting all unitcombats into the one subcombat vector) might be the way to go eventually but for now, that would have some potential consequences in some displays and such - probably just requiring a little restructuring here and there, so I used option 1 (defining a new vector to hold all subcombats AND the primary combat class) for now.

I'm thinking really, ultimately, there's no further NEED for the primary combat tag anymore but that would require a LOT of XML adjusting and I'd want to rename the tag and the list of tasks to get into this goes on for a full day's worth of work at least so it's something I'll put on the heap of things to do when I get to trying to streamline the unit data further - a project I have not forgotten about.

I don't know why your solution wasn't working as it was because I've not worked with memset or mutables enough to understand the method BUT regardless, it proved to not work for units, perhaps only if playing a saved and reloaded game - it must've worked for initialized games that hadn't been closed and reopened yet or I'd think we'd have found this problem much sooner.
 
I am promised 11 exp for my Spy units but only get 3. It is obvious that some of the pluses are wrong but I expected at least 5.

This is with my espionage tweaks that no one has bothered to look at:lol:. They are only new buildings so it should not be affecting the display. This problem has been reported before for spies but with out a save
 
I am promised 11 exp for my Spy units but only get 3. It is obvious that some of the pluses are wrong but I expected at least 5.

This is with my espionage tweaks that no one has bothered to look at:lol:. They are only new buildings so it should not be affecting the display. This problem has been reported before for spies but with out a save

I'll certainly look into it later when I can but do you have the specialist XP option on or off? It may be displaying the specialist XP incorrectly if the option is off perhaps.
 
Thanks again for this save!

I was in a debugging mood so I looked into this deeper. Apparently this is NOT just a bug for Size Matters at all... there's numerous places this COULD be causing an issue. Apparently the problem exists in the new way CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) has been restructured. Mid-game it comes up with false for all unitcombats and that is a serious problem that manifests in this manner but probably numerous other issues.

I recognize the need we had to restructure this function for speed, don't get me wrong. But if it doesn't work this way it needs to be re-structured once more. I can try my hand at a new method here. This has also prompted me to restructure the way the tracking mechanism works to make sure units have their original base group size to qualify for actions like these and anything else that would sacrifice them which should speed up the load process for a tradeoff in hardly noticeable delays in-game.


EDIT: Ok, so this is fixed. Alberts2 and I had a discussion on how to get that function to work better a while back and there were 3 options that emerged from that discussion. I selected to use one that's a little heavier on memory but works well for a number of reasons. Perhaps converting to option 2 (if you recall Alberts, that was your concept of putting all unitcombats into the one subcombat vector) might be the way to go eventually but for now, that would have some potential consequences in some displays and such - probably just requiring a little restructuring here and there, so I used option 1 (defining a new vector to hold all subcombats AND the primary combat class) for now.

I'm thinking really, ultimately, there's no further NEED for the primary combat tag anymore but that would require a LOT of XML adjusting and I'd want to rename the tag and the list of tasks to get into this goes on for a full day's worth of work at least so it's something I'll put on the heap of things to do when I get to trying to streamline the unit data further - a project I have not forgotten about.

I don't know why your solution wasn't working as it was because I've not worked with memset or mutables enough to understand the method BUT regardless, it proved to not work for units, perhaps only if playing a saved and reloaded game - it must've worked for initialized games that hadn't been closed and reopened yet or I'd think we'd have found this problem much sooner.

I wish my real life would leave me more time to work on C2C.

I left CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) like it was because of the slowdown other solutions caused.
Are you really sure that CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) always returned false for all UnitCombats? If that is the case i know how that could happen but it should only in case of other coding errors.

To rule out other coding issues i have two questions:

  1. There was CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) called and giving the false return values?
  2. Is it possible that CvUnit::isHasUnitCombat(UnitCombatTypes eIndex) must be used in that place instead of CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat).
 
I wish my real life would leave me more time to work on C2C.

I left CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) like it was because of the slowdown other solutions caused.
Are you really sure that CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) always returned false for all UnitCombats? If that is the case i know how that could happen but it should only in case of other coding errors.

To rule out other coding issues i have two questions:

  1. There was CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat) called and giving the false return values?
  2. Is it possible that CvUnit::isHasUnitCombat(UnitCombatTypes eIndex) must be used in that place instead of CvUnitInfo::hasUnitCombat(UnitCombatTypes eUnitCombat).
1) Can't verify for sure that it was returning false on everything - only that it was returning false 'falses' in some cases. In some, perhaps early in processing, it would seem to return a correct response.


2) No. The problem as I followed it was encountered by the function that sets the base unit's base group volume. At some point it would find no valid group volume combat classes so all that could be happening to make this take place was that it was getting a false read from hasUnitCombat when it was attempting to set this. That the changes I made corrected it was proof of diagnosis. That function calling for hasUnitCombat was from within CvUnitInfo, not CvUnit.cpp so it could not be a call to isHasUnitCombat anyhow.
 
1) Can't verify for sure that it was returning false on everything - only that it was returning false 'falses' in some cases. In some, perhaps early in processing, it would seem to return a correct response.


2) No. The problem as I followed it was encountered by the function that sets the base unit's base group volume. At some point it would find no valid group volume combat classes so all that could be happening to make this take place was that it was getting a false read from hasUnitCombat when it was attempting to set this. That the changes I made corrected it was proof of diagnosis. That function calling for hasUnitCombat was from within CvUnitInfo, not CvUnit.cpp so it could not be a call to isHasUnitCombat anyhow.

1)It was working a few months ago this means something changed! If the first call to that function happend before all the subcombats where loaded it would fail and return false. Your solution returns false if it is called to early but return the correct value later after everything is loaded. But it should never get called before everything is setup and the UnitInfo combats should not change midgame.

The other possible cause would be a memory corruption.


2) There is that call located exactly.
 
1)It was working a few months ago this means something changed! If the first call to that function happend before all the subcombats where loaded it would fail and return false. Your solution returns false if it is called to early but return the correct value later after everything is loaded. But it should never get called before everything is setup and the UnitInfo combats should not change midgame.

The other possible cause would be a memory corruption.
I was thinking along similar lines. It's very confusing as to how it could've been going wrong when in so many cases it showed to go correctly. Additionally, I was thinking the same thing about timing but indeed it was on game load, not mod load, where the data was failing. A memory corruption seemed like the only real possibility EXCEPT that this was completely replicable from one system to another and showing up with a fresh rebuild so I kinda figured it HAD to have something to do with syntax.


2) There is that call located exactly.
Assuming you're asking 'where' ;) then I'll have to answer this question when I can look at the code later tonight but I do promise I looked deeply into that mechanism first. Look at how the value in getBaseVolume (I think) in CvUnitInfos is assigned and you'll find what I'm talking about. Additionally, you can try to retrace my own debugging steps by evaluating how the Constructor ship in that posted save is being denied the ability to build the fishing boats. You'll start by looking at everything BUT hasUnitCombat and will find that this is the ONLY place where there could be a problem and WHY there is a problem is terribly confusing - yet it's solved by using the vector approach I implemented so proves it IS the source of the issue.
 
I'll certainly look into it later when I can but do you have the specialist XP option on or off? It may be displaying the specialist XP incorrectly if the option is off perhaps.

Specialist XP should be off but it still does not add up with that taken out. It was failing before there were specialist XP. The display has been wrong for a long time. ;)
 
Specialist XP should be off but it still does not add up with that taken out. It was failing before there were specialist XP. The display has been wrong for a long time. ;)

So there's multiple factors. That's one - that the display shouldn't be giving the specialist XP. I'll have to try to sort out the rest.
 
I was thinking along similar lines. It's very confusing as to how it could've been going wrong when in so many cases it showed to go correctly. Additionally, I was thinking the same thing about timing but indeed it was on game load, not mod load, where the data was failing. A memory corruption seemed like the only real possibility EXCEPT that this was completely replicable from one system to another and showing up with a fresh rebuild so I kinda figured it HAD to have something to do with syntax.



Assuming you're asking 'where' ;) then I'll have to answer this question when I can look at the code later tonight but I do promise I looked deeply into that mechanism first. Look at how the value in getBaseVolume (I think) in CvUnitInfos is assigned and you'll find what I'm talking about. Additionally, you can try to retrace my own debugging steps by evaluating how the Constructor ship in that posted save is being denied the ability to build the fishing boats. You'll start by looking at everything BUT hasUnitCombat and will find that this is the ONLY place where there could be a problem and WHY there is a problem is terribly confusing - yet it's solved by using the vector approach I implemented so proves it IS the source of the issue.


My remote diagnosis was right it was called to early in case of modular changes to existing units.

The error is here:
Code:
void CvUnitInfo::setHealAsTypes()
{
	m_aiHealAsTypes.clear();
	for ( int i = 0; i < GC.getNumUnitCombatInfos(); i++)
	{
		if ([B][COLOR="Red"]hasUnitCombat((UnitCombatTypes)i)[/COLOR][/B] && GC.getUnitCombatInfo((UnitCombatTypes)i).isHealsAs())
		{
			m_aiHealAsTypes.push_back((UnitCombatTypes)i);
		}
	}
}//Next Step: Figure out if this needs some kind of initiating (I think it's fine), set it up in save and load streams, and set this to be set in the appropriate spot.

This is there hasUnitCombat was called to early in case of modular changes.

Example:
Code:
		<UnitInfo>
			<Class>UNITCLASS_TRIBE</Class>
			<Type>UNIT_TRIBE</Type>
			<Capture>UNITCLASS_CAPTIVE_CIVILIAN</Capture>
		</UnitInfo>
In that case the UnitCombats are only in the main xml definition of the unit so the first call to hasUnitCombat during the xml loading sets all the UnitCombats to false. This is only a problem if the main xml definition was already loaded.

The correct way would have been:
Code:
void CvUnitInfo::setHealAsTypes()
{
	m_aiHealAsTypes.clear();
	for ( int i = 0; i < GC.getNumUnitCombatInfos(); i++)
	{
		if ([B](getUnitCombatType() == i || isSubCombatType(i)) [/B]&& GC.getUnitCombatInfo((UnitCombatTypes)i).isHealsAs())
		{
			m_aiHealAsTypes.push_back((UnitCombatTypes)i);
		}
	}
}//Next Step: Figure out if this needs some kind of initiating (I think it's fine), set it up in save and load streams, and set this to be set in the appropriate spot.
 
I can upgrade captive Neanderthal into a Neanderthal Warrior and the neanderthal culture has not yet been built by anyone. Is that right?
IMO, it should allow upgrading only if YOU have the neanderthal culture... but this is probably first time I noticed I can do it even when no one has it.

edit: on the other hand, its a great fun this way, I gave him Great general and he is leading my spike army :) And it still costs money, some 76 gold or so, so it may remain as such.

Another issue is that the money cost when upgrading a captured unit (human or neanderthal) into anything is not displayed in the text when hovering above the icon (like with a normal upgrade).
 
My remote diagnosis was right it was called to early in case of modular changes to existing units.

The error is here:
Code:
void CvUnitInfo::setHealAsTypes()
{
	m_aiHealAsTypes.clear();
	for ( int i = 0; i < GC.getNumUnitCombatInfos(); i++)
	{
		if ([B][COLOR="Red"]hasUnitCombat((UnitCombatTypes)i)[/COLOR][/B] && GC.getUnitCombatInfo((UnitCombatTypes)i).isHealsAs())
		{
			m_aiHealAsTypes.push_back((UnitCombatTypes)i);
		}
	}
}//Next Step: Figure out if this needs some kind of initiating (I think it's fine), set it up in save and load streams, and set this to be set in the appropriate spot.

This is there hasUnitCombat was called to early in case of modular changes.

Example:
Code:
		<UnitInfo>
			<Class>UNITCLASS_TRIBE</Class>
			<Type>UNIT_TRIBE</Type>
			<Capture>UNITCLASS_CAPTIVE_CIVILIAN</Capture>
		</UnitInfo>
In that case the UnitCombats are only in the main xml definition of the unit so the first call to hasUnitCombat during the xml loading sets all the UnitCombats to false. This is only a problem if the main xml definition was already loaded.

The correct way would have been:
Code:
void CvUnitInfo::setHealAsTypes()
{
	m_aiHealAsTypes.clear();
	for ( int i = 0; i < GC.getNumUnitCombatInfos(); i++)
	{
		if ([B](getUnitCombatType() == i || isSubCombatType(i)) [/B]&& GC.getUnitCombatInfo((UnitCombatTypes)i).isHealsAs())
		{
			m_aiHealAsTypes.push_back((UnitCombatTypes)i);
		}
	}
}//Next Step: Figure out if this needs some kind of initiating (I think it's fine), set it up in save and load streams, and set this to be set in the appropriate spot.
Ah... yea that would make sense - the data for hasUnitCombat being cached when checked basically. I can't remember quite when setHealAsTypes was called but that could also have perhaps been called at a better juncture as well.

So from a memory use perspective, does the original method for hasUnitCombat save more or less data than the vector method?

NVM, I know that you set it up the way you did for this reason so it's a silly question really. I guess I was wondering just how much memory a vector really takes. I've spent some time reverting the 'fix' to work more with the method you expressed along with some general improvements to the location of where to place a post-load process CvUnitInfo update based on some things learned from the effort here. Keeps things a bit more orderly mostly.
 
Assert Failed

File: CvArtFileMgr.cpp
Line: 100
SVN-Rev: 8142
Expression: false
Message: ArtInfo: '' was not found
 
The Bard can do a Educate mission but its upgrade the Entertainer can't. Design or bug?
Are you asking about a mission or about the promotions? Or is it the 'base' values to educate that the Bard has but it doesn't continue for the Entertainer that you're talking about? I'm not aware of a 'mission' for educating. (But this is probably a bug so it's important to address ;) )

Why can't I take the Spanish city of Saville? None of my siege or city attack or mounted can attack the city!
I'll have to take a look later tonight.
 
Assert Failed

File: CvArtFileMgr.cpp
Line: 100
SVN-Rev: 8142
Expression: false
Message: ArtInfo: '' was not found

What civ you playing?
Any more info about this bug?

I looked on my last updates and all veterinary/mechanics units looks ok. Maybe its a some older bug or smth...
 
Are you asking about a mission or about the promotions? Or is it the 'base' values to educate that the Bard has but it doesn't continue for the Entertainer that you're talking about? I'm not aware of a 'mission' for educating. (But this is probably a bug so it's important to address ;) )

I upgraded a Bard to an Entertainer. It had the Educate II promotion. The only actions it could do did not include the Educate mission. The Bard had been on Educate in the city.

Also I keep healers in cities to combat disease but they only have a mission to Establish a Base which improves healing. Not very useful.
 
I upgraded a Bard to an Entertainer. It had the Educate II promotion. The only actions it could do did not include the Educate mission. The Bard had been on Educate in the city.

Also I keep healers in cities to combat disease but they only have a mission to Establish a Base which improves healing. Not very useful.

All you do to educate is put the unit to sleep on the tile you want to aid as the benefit transfers from the unit to the city its in by simply being there. Did you have a mission that enhances this for bards that I'm not aware of?

Or are you saying the entertainer lost the Educate promotions? That'd be an issue.

We've discussed what I need to do to give healers additional sleep benefits for disease control. Workin' on it. And a similar educate mission could go along these lines.
 
Back
Top Bottom