FfH2 Bug Thread

Not sure if this is a bug, but I just noticed I have 4 free engineers in a Luchuirp city I've conquered. Is there a natural explanation for this, or should I delete them in worldbuilder?
 
I'm sure that bug is on Kael's to-do list, but there are a lot of things that need to be fixed. Rolling back to earlier patches to test can be quite helpful, in that you may be able to pinpoint exactly which patch introduced the problem and thus make finding the solution easier. Permanently rolling back to avoid the problems isn't helping anyone in the long run, however, because without feedback the process of locating the source of these problems will take much longer.

This particular crash is hard to track down because it doesn't seem to be happening to everyone. I've never had it happen in any of the games I've played, for example, but if I load up one of the saves someone else has produced then their game crashes for me. Is there something about my playstyle that is somehow avoiding the problem, or have I just been lucky? It's hard to say. Maybe it would be helpful for someone who has this problem to post both the crashing save and the initial save, so that someone else can try playing the game to see if their method also eventually crashes. Either way, comparing the course of different playthroughs might make something stand out as a cause.

Could it be because we play different game modes? Large maps with lots of barbarians and animals seem to cause more crashes in my experience. I usually play huge/tectonics/lakes with barbarian world and aggressive barbarians, and almost every game crashes at some point. When I play smaller maps with less barbarians I usually don't crash.

Edit: Ah, thanks, never played Luchuirp much. Seems like you could create a pretty crazy great engineer farm with them...
 
[...] and almost every game crashes at some point.
You're absolutely correct. And just to be clear, I didn't mean to say that I've never experienced a crash.

Generally speaking, larger maps with more units are more likely to crash, even in stable versions of FfH2 or base Civ itself. Civ isn't without its own problems, and memory allocation errors that bring down the game are going to happen more frequently when more memory allocation is taking place. Most of these errors are not replicatable, however; reloading a save will allow the game to continue, and unless the game has suffered severe damage (usually caused by repeated cycles of saving and reloading from within a game) the error will not reoccur (although of course other memory allocation errors are always possible).

Even repeatable errors, or errors like this HN thing which reoccur even if the game is reloaded from a save, can be increased in likelyhood by game settings. More space means more units, which means more potential HN units (or tigers, or whatever) to cause a problem. I play on standard sized maps, because my computer takes a long time to process turns in the later stages of the game on larger ones. That fact undoubtedly reduces the chance that I'll experience certain bugs.
 
merging this into CvPlayerAI::AI_conquerCity should allow to modify the python event which caused OOS a few patches ago.

Code:
/************************************************************************************************/
/* UNOFFICIAL_PATCH                       06/14/09                       Maniac & jdog5000      */
/*                                                                                              */
/*                                                                                              */
/************************************************************************************************/
/* original bts code
		CvEventReporter::getInstance().cityAcquiredAndKept(GC.getGameINLINE().getActivePlayer(), pCity);
*/
		CvEventReporter::getInstance().cityAcquiredAndKept(getID(), pCity);
/************************************************************************************************/
/* UNOFFICIAL_PATCH                        END                                                  */
/************************************************************************************************/
 
There might be some bug with the high-to-low code and the grigori adventurers. When I gained control of the grigori I noticed that they didn't have any adventurer units, so I assumed that the AI had managed to kill them all off, but now that I've switched to the infernals, I've got three "adventurer has been born in a far away land" messages in one turn. Could it be that adventurers are removed when you gain control of the civilization?

Edit: Will do some testing when I get the time. :)

Hmm, just noticed I have no settler after taking over the infernals. They have all their other units, so this might be a bug as well.
 
As you said, the Grigori's previous Adventurers were probably killed off before you gained control of them; then, when you shifted to another civ the AI most likely cast the Grigori world spell. This is what caused several Adventurers to spawn in one turn.

You didn't summon the Infernals as the Grigori, so they've been around since one of the AIs summoned them. I assume you'd notice a second city, so they most likely sent their second settler out unescorted and it has been killed. (The settlers the Infernals start with both have the "Initial Settler" promotion, and the AI seems very willing to move such settlers around unescorted. This isn't so bad when the game is just starting, but by the time the Infernals enter the game it can be risky.)
 
Is there a reason weak claims it gives my kraken -1% strength and -1 defense?
 

Attachments

  • Civ4ScreenShot0060.JPG
    Civ4ScreenShot0060.JPG
    156.3 KB · Views: 164
There is a text error that currently causes all + or - strength effects to appears as +% or -% strength. The actual displayed strength and the strength used in combat calculations are the correct value.
 
Scutarii posted a game going WoC in the FlavourMod thread a short time ago. I could track the reason down to a problem introduced with one of the last base FfH AI patches.

First a little screen shot:
attachment.php


The two Shamans you see on the screen shot want to attack the elphant in the top left corner next turn, but since they are both UNITAI_WARWIZZARD the following code in CvSelectionGroupAI::AI_getBestGroupAttacker prevents them from attacking:
Spoiler :
Code:
[COLOR="SeaGreen"]/*************************************************************************************************/
/**	BETTER AI (Block some Units from attacking at low odds) Sephi              					**/
/**																								**/
/**						                                            							**/
/*************************************************************************************************/[/COLOR]
                        if (!GET_PLAYER(pLoopUnit->getOwnerINLINE()).isHuman())
                        {
                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_WARWIZARD)
                            {
                                if (iOdds<95)
                                {
                                   [COLOR="Red"] iValue=0;[/COLOR]
                                }
                            }

                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_HERO)
                            {
                                if (iOdds<85)
                                {
                                   [COLOR="Red"] iValue=0;[/COLOR]
                                }
                            }
                        }
[COLOR="SeaGreen"]/*************************************************************************************************/
/**	END	                                        												**/
/*************************************************************************************************/[/COLOR]
			[COLOR="blue"]FAssertMsg(iValue > 0, "iValue is expected to be greater than 0");[/COLOR]
That's the problem. Civ4 can't really handle an iValue of 0 here (indciated by the blue FAssertMsg line) and goes into an infinite loop - WoC!

Removing the new code solves the WoC, but there is maybe a better solution, that keeps the new AI functionality and doesn't result in a WoC.
 

Attachments

  • WoC.jpg
    WoC.jpg
    65.9 KB · Views: 668
I am using this in Wildmana. Returning a value of 0 means the game thinks the group has no attacker anymore and is finished with the group, even though this isn't the case.
Code:
/*************************************************************************************************/
/**	BETTER AI (Block some Units from attacking at low odds) Sephi              					**/
/**																								**/
/**						                                            							**/
/*************************************************************************************************/

                        if (!GET_PLAYER(pLoopUnit->getOwnerINLINE()).isHuman())
                        {
                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_WARWIZARD)
                            {
                                if (iOdds<95)
                                {
                                    iValue=0;	//Need to put the min to 1 to prevent WoC
                                }
                            }

                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_HERO)
                            {
                                if (iOdds<85)
                                {
                                    iValue=0;
                                }
                            }
							if (pLoopUnit->getLevel()>4 && iOdds<95)
							{
								iValue/=2;
							}
                        }
						iValue=std::max(1,iValue);
/*************************************************************************************************/
/**	END	                                        												**/
/*************************************************************************************************/
 
While we are waiting for this strange AI behaviour to be fixed,
I found out by chance that if you enable in the "custom game" starting options
"AI ignores building requirements"
the AI is happy to build all sort of units even in war time and in much more moderate numbers.

So no need to press our beloved devopers on this issue, let's go home and happily enable this option to enjoy the fiercest of battles with the improved AIs.

Sorry, I do not think this workaround works with scenarios because I do not think you can enable this option in them....or you can?
 
Two more for you sephi:

1) What's the deal with all those "PROMOTION_FOCUS_..." types? They are not in the XML files, but CvGameUtils trys to work with them anyway. My debug dll is bombarding me with failed asserts concerning those "promotions".

2) I suppose the ReligionHero tags are your work too? There are some positions in the dll where you should check first, if there exists a second religion hero at all before doing anything else with it, like checking the number of it's instances etc.

Here is an example location (CvPlayer::AI_doFavoriteReligion):

Code:
        if (getUnitClassCountPlusMaking(GC.getReligionInfo(getFavoriteReligion()).getReligionHero2())>0)
        {
            valid=false;
        }
 
1.) a few things got broke in the Merge from Wildmana to FFH and this is one of them (I guess Kael forgot the XML part of it). I have completly rewritten it (was just cheap temporary python thing anyway to try out a few things), so can't give you an easy fix. But I think if you block in the DLL the python callback where they are used and instead use the standard BTS promotion selection AI_bestPromotion or whatever it is you should be fine (and the BTS function will still be better than a function where most of it is missing).
2. yeah, that was also one of the first things I caught with a debug DLL.

I am using this in Wildmana, there shouldn't be any problem merging it in FFH
Code:
void CvPlayer::AI_doFavoriteReligion()
{
    for (int iI = 0; iI < GC.getNumTraitInfos(); ++iI)
	{
		if (hasTrait((TraitTypes)iI))
		{
		    if(GC.getTraitInfo((TraitTypes)iI).isAgnostic())
		    {
		        return;
		    }
		}
	}

    //Pick a Favorite Religion
    if (getFavoriteReligion()==NO_RELIGION)
    {
        for (int i=0;i<GC.getNumReligionInfos();i++)
        {
            if (GC.getGameINLINE().getSorenRandNum(100,"Choose Religion")<GC.getLeaderHeadInfo(getLeaderType()).getReligionWeightModifier(i))
            {
                setFavoriteReligion((ReligionTypes)i);
                break;
            }
        }
        //If still have none, pick randomly
        int hack=0;
        while (getFavoriteReligion()==NO_RELIGION)
        {
            ReligionTypes newReligion=(ReligionTypes)GC.getGameINLINE().getSorenRandNum(GC.getNumReligionInfos(),"Choose Religion");
            if (GC.getLeaderHeadInfo(getLeaderType()).getReligionWeightModifier(newReligion)>=0)
            {
                setFavoriteReligion(newReligion);
            }
            hack++;
            if (hack==30)
            {
                break;
            }
        }
    }
    //Convert to Favorite Religion if possible
    if (getFavoriteReligion()!=NO_RELIGION)
    {
        if(canConvert(getFavoriteReligion()))
        {
            convert(getFavoriteReligion());
        }
    }
    //Choose new Religion for Opportunists
    if (GC.getLeaderHeadInfo(getLeaderType()).isReligionOpportunist() && getFavoriteReligion()!=NO_RELIGION)
    {
        bool valid=true;
		if (GC.getReligionInfo(getFavoriteReligion()).getReligionHero1()!=NO_UNITCLASS)
		{
			if (GC.getGameINLINE().getUnitClassCreatedCount(GC.getReligionInfo(getFavoriteReligion()).getReligionHero1())==0)
			{
				valid=false;
			}
		}

		if (GC.getReligionInfo(getFavoriteReligion()).getReligionHero2()!=NO_UNITCLASS)
		{
			if (GC.getGameINLINE().getUnitClassCreatedCount(GC.getReligionInfo(getFavoriteReligion()).getReligionHero2())==0)
			{
				valid=false;
			}
		}

		if (GC.getReligionInfo(getFavoriteReligion()).getReligionHero1()!=NO_UNITCLASS
			&& getUnitClassCountPlusMaking(GC.getReligionInfo(getFavoriteReligion()).getReligionHero1())>0)
        {
            valid=false;
        }

        if (GC.getReligionInfo(getFavoriteReligion()).getReligionHero2()!=NO_UNITCLASS
			&& getUnitClassCountPlusMaking(GC.getReligionInfo(getFavoriteReligion()).getReligionHero2())>0)
        {
            valid=false;
        }

        if (valid)
        {
            for (int i=0;i<GC.getNumReligionInfos();i++)
            {
                if (((GC.getReligionInfo(getFavoriteReligion()).getReligionHero1()!=NO_UNITCLASS 
					&& GC.getGameINLINE().getUnitClassCreatedCount(GC.getReligionInfo((ReligionTypes)i).getReligionHero1())==0))
					||((GC.getReligionInfo(getFavoriteReligion()).getReligionHero2()!=NO_UNITCLASS && GC.getGameINLINE().getUnitClassCreatedCount(GC.getReligionInfo((ReligionTypes)i).getReligionHero2())==0)))
                {
                    if (GC.getLeaderHeadInfo(getLeaderType()).getReligionWeightModifier((ReligionTypes)i)>=0)
                    {
                        setFavoriteReligion((ReligionTypes)i);
                    }
                    break;
                }
            }
        }
    }
    return;
}
 
Bug with the Blood of the Phoenix.

I'm playing as Sidar and carefully "farming" my adepts to arrive to mage, upgrade them then transform in Shades.

This worked with some highly promoted warrior in the early game, but i needed many turns to build lots of adepts and waiting them to arrive to the necessary XPs to promote to mages, then for they arrive to 26XP.

I upgraded the first 4 to Archmages, they are great units. Then i built the Blood of the Phoenix and i lost the chance to transform them in Shades. Dammit. I can use WB to create Shades and delete the mages with 26 XPs, but it's not nice.

Edit: i've found a way to trasform them in shades. They can't be transformed 'cause i have the Blood of the Phoenix, thus they can resurrect. So i kill them, they reappear in Capital, then i can trasform them in Shades.

Wild mana

I'm now playing with 041j and seen nothing new compared to previous version on this aspect. I expected those wild mana nodes guarded, never seen one. It's my 4th custom game with this patch.
 
1.) a few things got broke in the Merge from Wildmana to FFH and this is one of them (I guess Kael forgot the XML part of it). I have completly rewritten it (was just cheap temporary python thing anyway to try out a few things), so can't give you an easy fix. But I think if you block in the DLL the python callback where they are used and instead use the standard BTS promotion selection AI_bestPromotion or whatever it is you should be fine (and the BTS function will still be better than a function where most of it is missing).
2. yeah, that was also one of the first things I caught with a debug DLL.

Thanks a lot. I'll work the necessary changes into the next FlavourMod version and hope that Kael is going to update the FfH base code as well soon.
 
Things to do:
...
. I want to switch the "Wrath" armageddon event (AC 90) to make all the effected units Always Hostile so they can fight with your allied neighbors.


Just beating a dead horse :p :deadhorse:
 
always hostile and randomly move would be nice :p
 
Back
Top Bottom