FfH2 0.30 Bug Thread

Can someone explain to me why I can't build Meshabber or Gibbon Goatia? I have the requirements (per the Civopeida) for both units, but they are not showing up on the build list. And no, no other Civ has built Gibbon yet. I have a huge tech lead.
 
I'm playing Sheaim with the Octopus Overlords religion. 6 AIs on the map, 3 good, 3 neutral, all decide to pick on me. Fine, I can deal.

What's not cool: I finally muster up enough troops after repelling wave after wave of assaults (I'm on an island, so not too bad) to send out a small group of tough nuts to trash a few cities in order to boost the armageddon count (this is by turn 500 or so, up until then, it's been pretty much under 10 the whole time).

Every single horseman, mardeluk (sp? whatever the giant ape's name is), the avatar of wrath, what have you - every single last one of them spawned on my island (there was a section of 6 tiles at the south end of my island that wasn't covered my my culture zone, as it was all tundra & I couldn't be bothered). Note that this happened even after I had trashed enough towns that there could have been spawn points on the other islands I was raiding.

So much for evening the odds. :lol: Point being though, there should be some logic in there to make sure that all the barbarian specials don't spawn within the same relative location.
 
I have three privateer ships in one port, and I have a Mobius witch that can cast fair winds. I noticed that for a good 30 or so turns, I couldn't upgrade any of these ships until the fair winds spell wore off on each.
 
I've found the reason for the morgoth WoC bug . In fact a group try to load a ship that is not at the plot , so split and push the mission MOVE_TO_UNIT . But the mission fail , the new group can't generate a path to the boat . So the group stay in place and return true to the update . Then some of this units merge with an other group . Then the new group try to load again the ship ... this result the WoC .

Here my fix at the end of CvUnitAI::AI_load (not sure this is the best fix, i have commented the other one but the mission can fail for some other reasons ) :

Code:
			if (pSplitGroup != NULL)
			{
				//if (!generatePath(pSplitGroup->plot(), pBestUnit->plot(), iFlags))
				//{
				//	return false;
				//}

				CvPlot* pOldPlot = pSplitGroup->plot();

				pSplitGroup->pushMission(MISSION_MOVE_TO_UNIT, pBestUnit->getOwnerINLINE(), pBestUnit->getID(), iFlags, false, false, eMissionAI, NULL, pBestUnit);

				if (pSplitGroup != NULL)
				{
					if (pSplitGroup->plot() == pOldPlot)
					{
						return false;
					}
				}

				return true;
			}

Yeah :) , Tcho !
 
The reason of the Falamar WoC bug is caused by hidden nationality (not a BtS reason this time). There is a group with some HN units that need to split to enter a boat . but the function to split a group loop until there is no more units into the old group . So for each unit it test if the unit can join the other group , Since they got HN they can't join anymore to any group . So the function enter into an infinite loop .

There is now a req for cast Mask , but you need to put a function that separate each group when Svartalfar cast "veil of night" (not sure of the name) .

Tcho !

PS : I've tested both with the patch h DLL . the two patch K games were loadable and the bugs could be reproduce.
 
Both of these are great finds. I bet that second one is the more common reason we are seeing WoC's in svartalfar games. I would guess I need to force group splits when I apply hidden nationality everywhere with their world spell.

Thanks again for doing this!
 
This should be enough , and you can also remove the group test in reqMask :

in CvUnit::setHasPromotion:

Code:
        if (GC.getPromotionInfo(eIndex).isHiddenNationality())
        {
			setHiddenNationality(bNewValue);

			if (bNewValue)
			{
				CvSelectionGroup* pUnitSelectionGroup = getGroup();
				if (pUnitSelectionGroup != NULL)
				{
					if (pUnitSelectionGroup->getNumUnits() > 1)
					{
						joinGroup(NULL);
					}
				}
			}
        }

Tcho !
 
Im going to do it in the setHiddenNationality function so that regardless of how it gets set the unit is always bumped out of his group.

Code:
void CvUnit::setHiddenNationality(bool bNewValue)
{
    if (bNewValue)
    {
        joinGroup(NULL, true);
    }
    m_bHiddenNationality = bNewValue;
}
 
Baron Duin attacks with a two handed sword swing rather then an empty fist 'swipe'.

Looks kind of odd, any other setting it could be changed to?
 
Hi all -

In doing some of my own modding, I was poking around the FfH2 python files to see how the engine processes a unit death.

I noticed the following in the

def onUnitKilled(self, argsList):
'Unit Killed'
section. After checking to see if the unit is AV or OO religion, the engine grants a manes unit to the Infernals. But the action is listed twice:

if (unit.getReligion() == gc.getInfoTypeForString('RELIGION_THE_ASHEN_VEIL') or unit.getReligion() == gc.getInfoTypeForString('RELIGION_OCTOPUS_OVERLORDS') or unit.isHasPromotion(gc.getInfoTypeForString('PROMOTION_DEATH1')) or unit.isHasPromotion(gc.getInfoTypeForString('PROMOTION_ENTROPY1'))):
cf.giftUnit(gc.getInfoTypeForString('UNIT_MANES'), gc.getInfoTypeForString('CIVILIZATION_INFERNAL'), 0, unit.plot(), unit.getOwner())
cf.giftUnit(gc.getInfoTypeForString('UNIT_MANES'), gc.getInfoTypeForString('CIVILIZATION_INFERNAL'), 0, unit.plot(), unit.getOwner())

Is this WAD to give the Infernals two manes per AV or OO unit killed? Or should the duplicate entry be removed?

Thanks!
 
Its intended to give a chance at getting 2.
 
Its intended to give a chance at getting 2.

That would be my inexperience with Python, then. To me it looks like it just performs the same function twice, which would mean it always produces two Manes. I don't understand how listing the same function twice in a row creates a random chance of the second incidence also being processed.

I think I need to go get a book on Python!
 
That would be my inexperience with Python, then. To me it looks like it just performs the same function twice, which would mean it always produces two Manes. I don't understand how listing the same function twice in a row creates a random chance of the second incidence also being processed.

I think I need to go get a book on Python!

Check out the gift unit function in the CustomFunctions directory. It has some checks on it that randomize if the unit ends up being created or not.
 
Actually, all flying units still get the river crossing penalty (and the amphibious assault penalty, iirc). The promotions should probably be made to let the unit ignore these penalties, like waterwalking does.
 
Is this WAD to give the Infernals two manes per AV or OO unit killed? Or should the duplicate entry be removed?

Thanks!

Its intended to give a chance at getting 2.

To explain further:

Code:
cf.giftUnit(gc.getInfoTypeForString('UNIT_MANES'), gc.getInfoTypeForString('CIVILIZATION_INFERNAL'), 0, unit.plot(), unit.getOwner())

This line is a call to the giftUnit() function in the cf object

The cf object is declared before the CvEventManager class is declared, which is the area to declare global variables (and an object is a kind of variable), here:

cf = CustomFunctions.CustomFunctions()

What this does is it creates an object of the class named CustomFunctions()from the module CustomFunctions, and stores that object in the variable named cf.

What this all means is that all functions in the class CustomFunctions, from the module with the same name, are now accessible through the object called cf.

To explain further. gc is used in the same manner, it's an object for CyGlobalContext() which is a basically a class to access almost all information in the game.
getInfoTypeForString() is a function that converts any valid string (which means a line of text inside ' ' or " " for those that don't know) into an integer with the value of the index of the supplied info type. In this situation it's used to get the Index for UNIT_MANES, and CIVILIZATION_INFERNAL. This is cause most functions need to know the index of the InfoType it's going to process. (the index is basically based on what order they are added in the XML, the first is always 0).

Ok this is starting to get complex, but I hope I explained it so that even a non-programmer can understand. And if I am explaining it in a wrong way, then someone with a greater understanding can correct me.

Anyways, in the file CustomFunctions.py you will find the function giftUnit(). And it takes these variables: iUnit, iCivilization, iXP, pFromPlot, iFromPlayer. (Ignore the self variable, it's basically a way for the functions in a class to get access to all other functions. And variables declared with the prefix "self." within the class. I think it's required for functions declared in a class to have this variable. But calls from the outside so to speak do not need to supply this variable when calling the function)

In that function it does indeed do a random check and the chance to get a mane is as follows:

iChance = 100 - (CyGame().countCivPlayersAlive() * 3)
iChance = iChance + iXP
if iChance < 5:
iChance = 5
if iChance > 95:
iChance = 95
if CyGame().getSorenRandNum(100, "Gift Unit") > iChance:
iUnit = -1

...an iChance of 95 (which is max) would in this case mean a 4% chance since CyGame().getSorenRandNum(100, "Gift Unit") actually randomizes between the range 0-99.
And an iChance of 5 (which is minimum) would mean a 94% chance.

EDIT: chance of it NOT rewarding a mane that is, since it sets iUnit to -1 if it's succesful, and -1 means no unit, since no unit has that index (how could you if it starts at 0 ;)).

Ok, end of, hopefully a helpful rant. :)
 
Top Bottom