Bug Reports and Discussion

With regard to the gifting permanent summons bug mentioned here: http://forums.civfanatics.com/showpost.php?p=12118199&postcount=1705

I have tested that just checking for IsPermanentSummon() at the canGift() method of CvUnit.cpp is enough to prevent gifting infinite tigers and skeletons. The code with which I tested this change can be seen below.

Code:
diff -r ec3be7e1db43 Assets/CvGameCoreDLL/CvUnit.cpp
--- a/Assets/CvGameCoreDLL/CvUnit.cpp	Fri Jan 04 12:28:05 2013 +0100
+++ b/Assets/CvGameCoreDLL/CvUnit.cpp	Fri Jan 04 13:12:02 2013 +0100
@@ -4116,7 +4116,8 @@
 		return false;
 	}
 
-	if (getDuration() > 0)
+	// Temporal and permanent summons cannot be gifted.
+	if (getDuration() > 0 || isPermanentSummon())
 	{
 		return false;
 	}
 
Upgrading a unit which is the avatar of you leader still causes you to loose your traits.

I just noticed that this code in void CvUnit::convert(CvUnit* pUnit) sets the new unit to be an Avatar, but does not set the old unit not to be an avatar before killing it. Shouldn't it be more like this?

Code:
	// Avatars
	if (pUnit->isAvatarOfCivLeader())
	{[COLOR="Red"]
		pUnit->setAvatarOfCivLeader(false);[/COLOR]
		setAvatarOfCivLeader(true);
	}


I believe your if (!bConvert) lines in void CvUnit::kill(bool bDelay, PlayerTypes ePlayer, bool bConvert) were added to prevent this, as well as to stop the unit passing through def onUnitLost(self, argsList):, but they don't seem to be working. The suggestion above won't deal with def onUnitLost(self, argsList): but seems like a better way of dealing with avatars.
---


In my modmod units of the Cult of the Dragon religion may gain the Rebellious promotion (as can Calabim units of the Empyrean religion), which has <iBetrayalChance>20 and so can make the unit turn barbarian.

I just now noticed that when a unit that starts with a religion in its xml defines but had converted to a different religion, it reverts back to its original religion once it turns barbarian. This isn't exactly a bug, but it does seems odd to me and has caused quite a bit of confusion for at least one player of my modmod.


I see that void CvUnit::betray(PlayerTypes ePlayer) and void CvUnit::upgrade(UnitTypes eUnit) both call void CvUnit::convert(CvUnit* pUnit). I understand why you would want the religion set in XML to override the units actual religion for upgrades (otherwise you might get priests with the wrong religion or no religion), but I don't think this should happen for betrayals.

Would you mind editing void CvUnit::betray(PlayerTypes ePlayer) so that the unit's religion wont get reset?

Changing the religion when trading or gifting a unit (which also use void CvUnit::convert(CvUnit* pUnit)) seems odd too. Maybe it would be better for void CvUnit::convert(CvUnit* pUnit) to pass on the units religion but void CvUnit::upgrade(UnitTypes eUnit) to override this with the any religion the unit is given in the XML?

(Since I have spells to let Great Prophets upgrade to High Priests in my modmod, treating void CvUnit::castConvertUnit(int spell) like void CvUnit::upgrade(UnitTypes eUnit) as far as religions are concerned would be preferred.)
 
issue with the code that places goblin archers on goblin forts at gamestart: take a look at this start ( small pangea ) ... ouch that settler is toast
 

Attachments

  • Civ4ScreenShot0007.JPG
    Civ4ScreenShot0007.JPG
    151.5 KB · Views: 513
Upgrading a Doviello unit by using their conversion spells does not conserve customized names. The following change to void CvUnit::convert(CvUnit* pUnit) fixes this issue:

Code:
diff -r 8d0e013472c7 Assets/CvGameCoreDLL/CvUnit.cpp
--- a/Assets/CvGameCoreDLL/CvUnit.cpp	Tue Jan 08 20:30:24 2013 +0100
+++ b/Assets/CvGameCoreDLL/CvUnit.cpp	Tue Jan 08 23:01:40 2013 +0100
@@ -715,7 +715,10 @@
 	setLeaderUnitType(pUnit->getLeaderUnitType());
 
 //FfH: Added by Kael 10/03/2008
-	if (!isWorldUnitClass((UnitClassTypes)(m_pUnitInfo->getUnitClassType())) && isWorldUnitClass((UnitClassTypes)(pUnit->getUnitClassType())))
+	if (!pUnit->m_szName.empty()) {
+		setName(pUnit->m_szName);
+	}
+	else if (!isWorldUnitClass((UnitClassTypes)(m_pUnitInfo->getUnitClassType())) && isWorldUnitClass((UnitClassTypes)(pUnit->getUnitClassType())))
 	{
 	    setName(pUnit->getName());
 	}

EDIT: Correct code added. It may be desirable to make the code in the "else" to have priority over the customized names. I wasn't sure about in which cases a world unit is upgraded to something that is not a world unit so I just left it as it stands now, but it could of course be inversed without any further consequences to the Doviello upgrade fix.
 
[to_xp]Gekko;12132383 said:
issue with the code that places goblin archers on goblin forts at gamestart: take a look at this start ( small pangea ) ... ouch that settler is toast

The first one stays put right?
 
I was just testing my modmod after merging in v2.41, with the alternate DLL for a less insanely aggressive AI.

I tried removing my fix for the Pirate's Cove crash bug (i..e, killing the Work Boat though python instead of XML), and found that the problem no longer seemed to exist for my automated Lanun Work Boats.

I then started another game as a different civ, and ended up getting a crash at the end of my tenth turn.

When I checked BBAI.log, I found that the last thing that happened before the crash was a Lanun AI using SPELL_PIRATE_COVE. It seems like whatever you did to fix the crash for automated human units broke it for AI units.

Going back to killing the work boat in python (with delayed death) instead of XML fixed the problem.
 
bug: centaur archers can be upgraded to from warriors, only centaurs should be able to ( no changing races via upgrade allowed in ffh ) . I guess the issue is archers need to be blocked from upgrading to centaur archers.
 
issue: Sidar, Kurios and Elohim start with worse than useless pacifism, forcing them to lose a turn to revolt or lose hammers while building early warriors ( 30% production loss compared to nationhood is HUGE earlygame ) . I suggest religion for kurios+elohim, nationhood for sidar.
 
Gekko, that was the worst start I have ever seen.
 
[to_xp]Gekko;12133936 said:
bug: centaur archers can be upgraded to from warriors, only centaurs should be able to ( no changing races via upgrade allowed in ffh ) . I guess the issue is archers need to be blocked from upgrading to centaur archers.

it seems the same is true for scouts as well, I guess they can also upgrade to regular centaurs too..


unrelated, does loyalty already correctly prevent For The Horde in MNAI? getting sons of the inferno from the worldspell would be way OP :D
 
Upgrading a unit which is the avatar of you leader still causes you to loose your traits.

...

I believe your if (!bConvert) lines in void CvUnit::kill(bool bDelay, PlayerTypes ePlayer, bool bConvert) were added to prevent this, as well as to stop the unit passing through def onUnitLost(self, argsList):, but they don't seem to be working.

Looks like the issue is again with the Delayed Death setting (i still dont really understand what it's even used for). The upgrade codes sets the delayedDeath flag when it calls the kill() function. I'll try removing that flag and see what happens.


I just now noticed that when a unit that starts with a religion in its xml defines but had converted to a different religion, it reverts back to its original religion once it turns barbarian. This isn't exactly a bug, but it does seems odd to me and has caused quite a bit of confusion for at least one player of my modmod.

Would you mind editing void CvUnit::betray(PlayerTypes ePlayer) so that the unit's religion wont get reset?

Hmmm.. ok. I'll look into it.


[to_xp]Gekko;12132383 said:
issue with the code that places goblin archers on goblin forts at gamestart: take a look at this start ( small pangea ) ... ouch that settler is toast

OK. I entered a bug for this issue.


Upgrading a Doviello unit by using their conversion spells does not conserve customized names. The following change to void CvUnit::convert(CvUnit* pUnit) fixes this issue:

Thanks!

It seems like whatever you did to fix the crash for automated human units broke it for AI units.

Works fine in my mod. What's different about workboats in your mod?
 
Works fine in my mod. What's different about workboats in your mod?

Well, my Work Boats do have UNITCOMBAT_NAVAL, and the Lanun's Seafaring tech is changed to a Seafaring civ trait which grants a seafaring promotion to all naval units. The seafaring promotion grants +1 movement, +20% withdrawal chance, +1 first strikes, and +1 cargo capacity.

I made Pirate Coves/Harbors/Ports function as super forts when the Advanced Tactics game option is active. (I always play with this option.)

I blocked the ability from being used when the unit is carrying any cargo, and allowed it to be used in unowned (but still not rival) territory. Under Advanced Tactics, I made the spell result set the plot's owner to be the same as the units owner.

I also changed the various Crew abilities so that they can be used within friendly Pirate's Coves/Harbors/Ports in addition to cities.
---
I just ran another quick test game after commenting out the line which killed the unit and restoring bSacrificeCaster again. Hannah seems to have used the spell 3 times in my current test game without a problem. I'm not sure why there was an issue before.

Edit: I should have left my old fix in. I was was just playing a game using my newly released version when I came across the CtD again. BBAI.log again shows that the last thing that happened was an AI (belonging to player 5 this time) Work Boat casting Pirate Cove.

This time I happen to have an autosave from the same turn. Simply load the attached file using tonight's release of my modmod and press enter to see what happens.

Switching the spell back to killing the unit in python instead of xml solves the problem.
 
does River of Blood still not cause pop decrease in enemy pop 2 cities?

also, barbarian trait leaders can explore graveyards.
 
If you let your city grow instead of buidling a worker rivers of blood when you get to size 3 is devastating. It is like loosing 20 turns.
 
Top Bottom