FfH2 Bug Thread

Breunor said:
Bug thread updated. Expanded somewhat. We have a lot of bugs so I did my best.

http://forums.civfanatics.com/showthread.php?t=329991
Click to expand...


Good work summing it all up. I have something you might want to add to your list. EternalMoment posted a WoC game in this thread: Game freezes before enormous battle

The reason for the WoC was a Clan of Embers settler which for some reason became enraged. Removing the enraged effect from the settler solved the problem. To fix the WoC completely settlers should be excluded from the list of units which can gain the enraged promotion. The same is probably necessary for any other unit which can't attack. Any idea where to put the code for this?
 
how about his? CvUnitAI::AI_update. This should work not only for enraged promotion but any effect that gives AIControl to defensive only units.

edit: code updated
Code: 
/*************************************************************************************************/
/**	BUGFIX (also AI Units can become Enraged) Sephi                             				**/
/**																			                    **/
/**	                                                                 							**/
/*************************************************************************************************/
/** FFH code
    if (isHuman())
    {
        if (getGroup()->getHeadUnit()->isAIControl())
        {
            if (AI_anyAttack(3, 20))
            {
                return true;
            }
            AI_barbAttackMove();
        }
    }
**/
    if(isAIControl())
    {
        if (getGroup()->getNumUnits()>1)
        {
            joinGroup(NULL);
            return true;
        }
        //remove AI control from Defensive only Units
        else if(isOnlyDefensive())
        {
            changeAIControl(-1);
            getGroup()->pushMission(MISSION_SKIP);
            return false;
        }
        else if(isAIControl())
        {
            if (AI_anyAttack(3, 0))
            {
                return false;
            }
            if (AI_anyAttack(10, 0))
            {
                return false;
            }
                                    
            AI_barbAttackMove();
            return false;
        }
    }
/*************************************************************************************************/
/**	END	                                        												**/
/*************************************************************************************************/
 
Nice idea, but that would only work for originally human controlled units, because your posted fix is enclosed by:

Code: 
if (isHuman()) { ... your fix ... }

The enraged settler causing the WoC was an AI unit in the first place. Probably the problem is a Ai controlled defensive only unit trying to attack and not the AI control itself.

Moreover your code fixes only the symptom. I think the better idea would be to add a check in maybe CvUnit::canAcquirePromotion or CvUnit::isPromotionValid, so defensive only units can't get promotions like enraged in the first place. One would have to make sure all the necessary checks are done before calling setHasPromotion, though, because the function setHasPromotion doesn't check anything before applying the promotion.

Btw, I'm pretty sure the settler got his enraged promotion from the wrath event triggerd at an armageddon counter of 90 and above.

----------------------------------------------

A second problem. I think this tweak ...

Spoiler :
Code: 
bool CvSelectionGroup::isAutomated()
{
/*************************************************************************************************/
/**	Xienwolf Tweak							01/04/09											**/
/**																								**/
/**					Keeps the game from trying to select AIControls for you						**/
/*************************************************************************************************/
/**								---- Start Original Code ----									**
	return (getAutomateType() != NO_AUTOMATE);
/**								----  End Original Code  ----									**/
	return ((getAutomateType() != NO_AUTOMATE) || isAIControl());
/*************************************************************************************************/
/**	Tweak									END													**/
/*************************************************************************************************/
}
... can cause computing time intensive errors like this one ...

Code: 
Unit stuck in loop: Worker(Sheelba)[20, 39] (worker)

... because some units may count as automated in CvUnitAI::AI_update, but aren't really automated, because they don't have an AutomateType for the switch to evaluate here:

Spoiler :
Code: 
	if (getGroup()->isAutomated())
	{
		switch (getGroup()->getAutomateType())
		{
			... breaks 100 times without a result ...
		}
	}
	else
	{
		... the way to go ...
	}
 
How about this?
Code: 
bool CvSelectionGroup::isAutomated()
{
/*************************************************************************************************/
/**	Xienwolf Tweak / modified Sephi			01/04/09											**/
/**																								**/
/**					Keeps the game from trying to select AIControls for you						**/
/*************************************************************************************************/
/**								---- Start Original Code ----									**
	return (getAutomateType() != NO_AUTOMATE);
/**								----  End Original Code  ----									**/
	return ((getAutomateType() != NO_AUTOMATE) || [b](isHuman() && isAIControl())[/b]);
/*************************************************************************************************/
/**	Tweak									END													**/
/*************************************************************************************************/
}
 
Jean Elcard said:
Good work summing it all up. I have something you might want to add to your list. EternalMoment posted a WoC game in this thread: Game freezes before enormous battle

The reason for the WoC was a Clan of Embers settler which for some reason became enraged. Removing the enraged effect from the settler solved the problem. To fix the WoC completely settlers should be excluded from the list of units which can gain the enraged promotion. The same is probably necessary for any other unit which can't attack. Any idea where to put the code for this?
Click to expand...

Thanks! I'll add this when I get a chance.

Best wishes,

Breunor
 
Jean Elcard said:
Nice idea, but that would only work for originally human controlled units, because your posted fix is enclosed by:

Code: 
if (isHuman()) { ... your fix ... }
Click to expand...
missed that one. I think it should be removed unless Enraged Promotion and other effects were only intended to work for human units.
 
I couldn't check it, but I think this should remove the WoC for the enraged settler

Spoiler :

in CvUnitAI::Patrolmove()

change
Code: 
                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_SETTLE && pLoopUnit->getOwnerINLINE()==getOwnerINLINE())

to

                            if (pLoopUnit->AI_getUnitAIType()==UNITAI_SETTLE && AI_canJoinGroup(pLoopUnit->getGroup()))


in CvUnit.h add
Code: 
bool AI_canJoinGroup(CvSelectionGroup* pSelectionGroup) const;
in CvUnit.cpp add
Code: 
//Unlike CvUnit::canJoinGroup this Function doesn't check for atPlot(), so we can use it to plan AI moves ahead of time
bool CvUnit::AI_canJoinGroup(CvSelectionGroup* pSelectionGroup) const
{
	CvUnit* pHeadUnit;

	if (pSelectionGroup->getOwnerINLINE() == NO_PLAYER)
	{
		pHeadUnit = pSelectionGroup->getHeadUnit();

		if (pHeadUnit != NULL)
		{
			if (pHeadUnit->getOwnerINLINE() != getOwnerINLINE())
			{
				return false;
			}
		}
	}
	else
	{
		if (pSelectionGroup->getOwnerINLINE() != getOwnerINLINE())
		{
			return false;
		}
	}

	if (pSelectionGroup->getNumUnits() > 0)
	{
		if (pSelectionGroup->getDomainType() != getDomainType())
		{
			return false;
		}

        pHeadUnit = pSelectionGroup->getHeadUnit();
        if (pHeadUnit != NULL)
	    {
			if (pHeadUnit->isHiddenNationality() != isHiddenNationality())
			{
                return false;
			}
            if (pHeadUnit->isAIControl() != isAIControl())
			{
                return false;
			}
		}
	}

	return true;
}

This should keep units from trying to group with the Settler even though they aren't allowed (because of AIControl)
 
I think this has been reported before but the computer AIs seem to have a stack-of-doom obsession at the moment. Not only do they have a big stack of their core units, going well past 100 units sometimes, they then wander it around their territory aimlessly. This means that Basium's angels never leave home to attack, no matter how often he declares war. Almost no boats are being by computer opponents. If the elves do a 'march of the ents' they just add the ents to the stack and wander the stack off to a corner of their empire. Etc. This is in randomly created games as well as scenarios.
 
(Edit: Reply to Neomega: ) I think that event applies a bonus only to the Archer unit, not to all archery units. In other words, if you build an Archer and upgrade it to a Longbowman then the unit will have the bonus, but if you build a Longbowman directly the unit will not have the bonus. If you have a game handy where you've gotten this event, can you confirm this?
 
Emptiness said:
(Edit: Reply to Neomega: ) I think that event applies a bonus only to the Archer unit, not to all archery units. In other words, if you build an Archer and upgrade it to a Longbowman then the unit will have the bonus, but if you build a Longbowman directly the unit will not have the bonus. If you have a game handy where you've gotten this event, can you confirm this?
Click to expand...

Aye, you are right.
 
DaveGold said:
I think this has been reported before but the computer AIs seem to have a stack-of-doom obsession at the moment. Not only do they have a big stack of their core units, going well past 100 units sometimes, they then wander it around their territory aimlessly. This means that Basium's angels never leave home to attack, no matter how often he declares war. Almost no boats are being by computer opponents. If the elves do a 'march of the ents' they just add the ents to the stack and wander the stack off to a corner of their empire. Etc. This is in randomly created games as well as scenarios.
Click to expand...
Aye, I'm currently playing a customized game with 7 AI civs. Jonas is my neighbour and he's walking around with a stack of 20 highly promoted axeman. Aggressive AI is checked and so is no building requirements. And even though he's annoyed with me and under cultural pressure from me he's not declaring despite me only guarding each city with 3 archers tops. :dunno:

On the bright side: Keelyn knows how to use Loki. Stole a city from me! :sad: :D
 
Emptiness said:
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.
Click to expand...

Regarding "memory allocation errors that bring down the game are going to happen more frequently when more memory allocation is taking place":

What do you mean by "memory allocation error"?

I see 4 possibilities:

1) Memory corruption. But then this is a bug and cannot be part of a supposedly "stable" version.
2) The heap management is buggy.
3) There simply is not enough memory available. The program runs out of memory due to fragmentation/caching/whatever. But this could (easily) be semi-fixed by telling the player to restart the game when memory becomes scarce.
4) There are memory leaks. Solutions: a) fix them b) as in 3).
 
Civ4 itself has a memory leak of some sort.

I stopped getting MAF's when I increased the paging file, though.
 
Sezren said:
Regarding "memory allocation errors that bring down the game are going to happen more frequently when more memory allocation is taking place":

What do you mean by "memory allocation error"?
Click to expand...
I'm talking about #4; to make this clear I should have said "dynamic memory allocation errors". #2 (as it pertains to dynamic memory allocation errors) is a subset of #4. #1 is a different problem. #3 can be caused by various things, including accumulated dynamic memory allocation errors, and is probably the reason for most crashes they cause. Increasing the amount of physical memory (or increasing the size of the page file) will usually increase the mean time between these crashes, although ymmv. Occasionally restarting the game (save game, exit to Windows, relaunch Civ, load saved game) will reset the timer to zero, so your advice is good. Users playing on larger maps or with more civs would want to restart more often, but exactly how often one should restart will vary based on too many factors to list here. If one finds that the game start to become unstable after about 6 hours of play (for example), then I'd suggest saving and restarting every 5 hours.
 
Lone Wolf said:
Civ4 itself has a memory leak of some sort.

I stopped getting MAF's when I increased the paging file, though.
Click to expand...

yea that helps a bunch - but if you are a chronic reloader :blush: you will still get some. For some reason if you use F5 to reload a quick save the cache isn't cleared so the info keeps pilling up until MAF... I think :) It does seem that the wildmana mod is more stable in my system so I was wondering if the unofficial patch or some other sephi fix has improved on the issue...
 
I'm not sure if this has already been posted, appologies if it hsa.
Malakin - LightBringer - Potency
The promotion is meant to slowly gain XP (20% chance gainn 1XP per turn) but this is not working. The LightBringer never gains any XP by itself, I wait several hundred turns.

Can anyone else confirm this?
Or am I just the unluckiest player, ever... :)
 
Potency increases the rate at which spellcasters gain their free xp. Lightbringers are not spellcasters. They gain the Potency promotion for free when built by a Spiritual leader, but it has no effect until the Lightbringer is upgraded to a spellcasting unit.
 
You must log in or register to reply here.

Similar threads

The_J
Old World update #138
Replies
1
Views
1K
Trav'ling Canuck
Trav'ling Canuck
The_J
Old World update #139
Replies
1
Views
669
PiR
PiR
A
New Version – 5.0-alpha.03
10 11 12
Replies
239
Views
30K
hokath
hokath
A
  • Locked
New Version – 4.21.1 (May 3, 2025)
2 3 4
Replies
66
Views
17K
Recursive
Recursive
The_J
  • Sticky
"Dante Update", version 1.0.28.4665, May 27, 2025
Replies
0
Views
3K
The_J
The_J
Back
Top Bottom