FfH2 0.23 Bug Thread

[MagisterCultuum]

I'd prefer the techs granting a free priest rather than first level disciple unit. The found temple ability always works, plus a priest could be useful if you already had the religion in your cities, had already converted, but lacked the prerequisite resource to build your own priests.

 

[bcr1776]

I'm not sure if this is FfH-specific, but it's only happened while playing FfH. My UI disappears randomly. I can't get it back. Alt-i...nothing works.

I have the same problem, if I Cntl-L game and load the same turn again it comes back. Alt-I seems to be defeated in this version.

 

[Chandrasekhar]

I'd prefer the techs granting a free priest rather than first level disciple unit. The found temple ability always works, plus a priest could be useful if you already had the religion in your cities, had already converted, but lacked the prerequisite resource to build your own priests.

Well, the problem with that is that you'd get a priest before you converted to the religion. It'd be way too easy to hit all of the religious techs just to get every divine spell at your disposal.

 

[Sureshot]

Now, if you could only get that Thane, Disciple, etc. to spread his religion 100% of the time, instead of fizzling out sometimes, it would be a great feature.

Why not just put the religion in a city instead of giving the unit???

you get to choose this way. but also, its 100% if you do it in a city that has no religion yet.

 

[Calavente]

hmm... it's almost 100%, sometimes it doesn't work, even in no-religion city.

 

[Sarisin]

hmm... it's almost 100%, sometimes it doesn't work, even in no-religion city.

That's true. I just had it happen in my game yesterday when I sent a Zealot gained from researching OO to a city with no religion. It didn't spread.

Interestingly, in my game there is a load of barb cities (what else is new), and my Runes of Kilmorph seems to be spreading to ALL of them.

 

[Sureshot]

ive never had a religion fail to spread into a city with none lol

 

[Calavente]

lucky you!!

 

[BeefontheBone]

Not lucky, I'm positive that's how it's coded. It's very small for a city with 1 in it, then increases pretty quick.

 

[Dora190]

Built the baron and sent him on a killing spree, but despite numerous kills he has failed to raise a single werewolf. Wondering if this is just me or a bug.

 

[TheBoatman]

Built the baron and sent him on a killing spree, but despite numerous kills he has failed to raise a single werewolf. Wondering if this is just me or a bug.

By any chance, did he have hidden nationality? HN prevents creating new werewolves.

 

[Dora190]

By any chance, did he have hidden nationality? HN prevents creating new werewolves.

Oh Bugger! Yup thats it....

 

[xanaqui42]

Here is an apparent Vanilla defect. Essentially, if you try to trade away bonus resources (from buildings), the call to this function's iChange is -1, even if m_paiNumBonuses[eIndex] == 0. This causes several problems, the least of which is an assert (if asserts are on). The following code seems to fix it; note that this breaks saved games:

Spoiler :

void CvCity::changeNumBonuses(BonusTypes eIndex, int iChange)
{
	bool bOldHasBonus;

	FAssertMsg(eIndex >= 0, "eIndex expected to be >= 0");
	FAssertMsg(eIndex < GC.getNumBonusInfos(), "eIndex expected to be < GC.getNumBonusInfos()");

	if (iChange != 0)
	{
		bOldHasBonus = hasBonus(eIndex);
		// Smarter Orcs start - patch for number of bonuses.
		if ((iChange > 0) && (m_paiFreeBonus[eIndex] < m_paiMaxFreeBonus[eIndex]))
		{	
			m_paiFreeBonus[eIndex] += iChange;
		}
		else
		{
			m_paiNumBonuses[eIndex] = (m_paiNumBonuses[eIndex] + iChange);
		}
		if (m_paiNumBonuses[eIndex] < 0)
		{
			if (m_paiFreeBonus[eIndex] > 0)
			{
				m_paiFreeBonus[eIndex] += m_paiNumBonuses[eIndex];
				m_paiNumBonuses[eIndex] = 0; // for breakpoint.
			}
		}
		// Smarter Orcs end
		if (bOldHasBonus != hasBonus(eIndex))
		{
			if (hasBonus(eIndex))
			{
				processBonus(eIndex, 1);
			}
			else
			{
				processBonus(eIndex, -1);
			}
		}
	}
}

void CvCity::read(FDataStreamBase* pStream)
.
.
.
	pStream->Read(GC.getNumBonusInfos(), m_paiMaxFreeBonus); // Smarter Orcs

void CvCity::write(FDataStreamBase* pStream)
.
.
.
	pStream->Write(GC.getNumBonusInfos(), m_paiMaxFreeBonus); // Smarter Orcs

CvCity::CvCity()
.
.
.
	m_paiMaxFreeBonus = NULL; // Smarter Orcs

void CvCity::uninit()
.
.
.
	SAFE_DELETE_ARRAY(m_paiMaxFreeBonus); // Smarter Orcs

void CvCity::reset(int iID, PlayerTypes eOwner, int iX, int iY, bool bConstructorCall)
.
.
.
	if (!bConstructorCall)
	{
		FAssertMsg((0 < GC.getNumBonusInfos()),  "GC.getNumBonusInfos() is not greater than zero but an array is being allocated in CvCity::reset");
		m_paiFreeBonus = new int[GC.getNumBonusInfos()];
		m_paiMaxFreeBonus = new int[GC.getNumBonusInfos()]; // Smarter Orcs
		m_paiNumBonuses = new int[GC.getNumBonusInfos()];

void CvCity::changeFreeBonus(BonusTypes eIndex, int iChange)
{
	FAssertMsg(eIndex >= 0, "eIndex expected to be >= 0");
	FAssertMsg(eIndex < GC.getNumBonusInfos(), "eIndex expected to be < GC.getNumBonusInfos()");

	if (iChange != 0)
	{
		plot()->updatePlotGroupBonus(false);
		m_paiFreeBonus[eIndex] = (m_paiFreeBonus[eIndex] + iChange);
		m_paiMaxFreeBonus[eIndex] += iChange; // Smarter Orcs
		FAssert(getFreeBonus(eIndex) >= 0);
		plot()->updatePlotGroupBonus(true);
	}
}

In CvCity.h:
	int* m_paiMaxFreeBonus; // Smarter Orcs

 

[TheBoatman]

Oh Bugger! Yup thats it....

This should go to FAQ. It is asked too often.

 

[Horacio]

I do not know if it has been reported before.

I had Typhoid Mary defeat an opponent (she attacked) and after she won she got herself plagued!!!

And since I did not have a chance to heal her at that time, I lost her to her own plague.

 

[xanaqui42]

However, the combat odds code (which is the most visible indicator of if combat odds is working) doesn't. Here's a reference to my detailed post on the topic. The short form is that it seems that the change made to getCombatOdds during 0.23 is erroneous.

Note that I have a comment on this later.

 

[vorshlumpf]

I've also noticed that you can get slightly different combat odds when you are more than one space away from your target than if you are adjacent.

 

[xanaqui42]

However, the combat odds code (which is the most visible indicator of if combat odds is working) doesn't. Here's a reference to my detailed post on the topic. The short form is that it seems that the change made to getCombatOdds during 0.23 is erroneous.

The above is somewhat erroneous. While reverting this change during 0.23 will give you corrected combat odds (i.e. the odds will match how combat works), it won't allow the defender's resistances to be taken into account (which I think is why this change was made in the first place; the problem is that it doesn't look like it can work correctly). I'll work on a fix, and post the solution I come up with here.

 

[Calavente]

couldn't it be the opposite ??
ie : make the combat match the combat odds ...

because having a lvl (many) str (many) having 99,9 against a spearman and loosing (uncorrected) or having 0.01% (combat odds match combat) changes nothing

the issue is that it should be 99.9 and almost never loose.

from what I gathered, the issue seems to be more about the combat calculation itself than odd's calculation...

but maybe I'm totally off.

 

[Gabriel21]

I've also noticed that you can get slightly different combat odds when you are more than one space away from your target than if you are adjacent.

Yes, it's annonying indeed. You check it and getting close you always find lower odds. I cannot find a reasonable priniciple in this.