Modders Guide to FfH2

The only time you can pass the unit who attacked is in a combat death. If you are trying to work with ANY death, you are only able to know which player did the dead, if any.

So the argument trapped by 'iAttacker' is a reference to a player? I had just assumed it was a reference to a unit. Either way, it would still seem to be a good idea to pass that along, since I can see a lot of areas in the scenario code that are weakened.

For instance, the 'Radiant Guard' problems with not letting falamar win, are due in large part to a very clunky means of determining success. Instead of asking 'who killed hyborem' or 'who killed basium' you instead try to figure out which teams are at war with basium/hyborem, and use that to determine a victor.

If they had the Attacker information (Even if it is just the player) there would have been a significantly easier time of it.

Also, even if the unit was not killed via combat, passing a null value is completely workable, so long as you make sure to check for it.
 
Thats another set of files you need to change, rather a lot of files as each religion calls up a different set, you woulod need to add another duplicate set of call up for the enclave, each withb its own version for differnet religions, rather lot of work for something of limited use. Are you sure you cant settle for just the standard repalcement for them?.

Well I had something bigger in mind after this step, but i doubt I will have the time for it, so I guess I will have to settle for it how it looks for now.
Thanks for your help.
 
Keal, any chance to get updated source soon? I just downloaded FfH 040 third time, just in case it was updated without changing name...

I have updated my modmod already but do not really want to release it without updating core first.
So Please, Please, Please... :)

I second that!
but I don't think Kael would update the source without adding the patch letter to the name :p
 
Patch "f" updated source code is in the first post.
 
Reccomendation:

void CvUnitAI::AI_barbAttackMove()


This controls what Barbarians do when moving about, already tweaked some long ago by the looks of it, but could use some updating IMO. Primarily 2 sections:

Code:
	if (AI_heal())
	{
		return;
	}

	if (AI_guardCity(false, true, 2))
	{
		return;
	}

These two are near the bottom of the list, the first one isn't needed at all anymore since the Barbarians all get to heal while moving, so should be removed completely (in Gift of Kylorin I was frequently taking advantage of Maelstrom to cause the Barbarians to sit down and leave me alone so that I could heal)

The second one should change to:

Code:
    if (!isWorldUnitClass((UnitClassTypes)(m_pUnitInfo->getUnitClassType())))
        if (AI_guardCity(false, true, 2))
            return;

This alone should prevent Orthus & the Horsemen from camping in cities, and you can remove the "Always Raze" code so that the Barbarians don't wind up wiping out their OWN cities (I've seen Acheron sitting in the middle of nowhere due to Buboes having spent a turn in the city long before)



Also spotted
Code:
	if (plot()->isGoody())
	{
		if (plot()->plotCount(PUF_isUnitAIType, UNITAI_ATTACK, -1, getOwnerINLINE()) == 1)
		{
			getGroup()->pushMission(MISSION_SKIP);
			return;
		}
	}

Which seems to tell the Barbarians to stand on Goody Huts unless there is another Barbarian there with UNITAI_ATTACK already. They don't do this anymore though, so I am mildly confused as to why. But it seems like this function ought to be clipped as well.
 
The issue people have with HN units not showing Combat Odds when attacking a Barbarian Civilization are due to this little line right here:

Code:
bool CvUnit::isEnemy(TeamTypes eTeam, const CvPlot* pPlot) const
{
	if (NULL == pPlot)
	{
		pPlot = plot();
	}

//FfH: Added by Kael 10/26/2007 (to prevent spinlocks when always hostile units attack barbarian allied teams)
    if (isAlwaysHostile(pPlot))
    {
        if (getTeam() != eTeam)
        {
            return true;
        }
    }
//FfH: End Add

	return (atWar(GET_PLAYER(getCombatOwner(eTeam, pPlot)).getTeam(), eTeam));
}


My question is: Does it still cause a spinlock after 3.17 patch, and if so, can we account for this exception being made in the function which decides about displaying combat odds, while leaving this exception in-place to assist the AI logic?
 
Great stuff Xienwolf, Im really excited to see you poking around in the AI code. I'll make the changes you mentioned for healing and world units staying in cities (but im cool with barb units stopping on goody huts).
 
Version in the first post has been updated to patch "g".
 
Any changes to the DLL in h?
Yes, there are. From the changelog:
9. New system to fix scenario load crashes. There is now a "Fall from Heaven II Scenarios" option under Load Scenario on the main menu that should bring you directly into the scenario load menu and load without crashes.
I am getting python errors when starting scenarios after updating everything else but dll still based on g...

But it is Christmas, so no hurry, please :)
 
Actually that isn't a DLL change, Kael created a scenario which is a VERY tiny map with a single city in it and happens to start with the Scenario Select screen open :) It is a work-around, but a pretty elegant one for the time being.
 
I know I tend to treat this as a "help me not have to think" thread so:
Animal AI. If I want to make animals cross borders like regular units, do I need to perform SDK hackery, or can I just chance some python/xml somewhere?
If I just changed all the UNITAI_ANIMAL to something else, would that do the trick, and what should I change it to?
 
Yes, just change UNITAI_ANIMAL will do it, but I think you also have to remove the bAnimal tag in UnitInfos to be ALLOWED to remove that AI type. Otherwise, you need SDK modifications to enable UNITAI_ANIMAL to enter territory, or to disable the limitation of AI types for bAnimal units.
 
Actually that isn't a DLL change, Kael created a scenario which is a VERY tiny map with a single city in it and happens to start with the Scenario Select screen open :) It is a work-around, but a pretty elegant one for the time being.
I like it, but actually it added a new game option (GAMEOPTION_WB_LOAD_SCREEN), so it required some dll changes.

I will add a question of my own. Is it possible to add a year/turn display in religion/corporation/city "founded:" field?
Ever since removal of years from FfH I miss the display of year that things get founded. So, if anyone knows where year display is blocked and how to unblock, I would like to know it, too :) If plain display of turn of foundation can be added, it would be even better.
I asked it already, but while I was able to solve guild screen and ranged strength display problems (a big thanks to Xienwolf for pointing me the right direction with the guild screen), this one still bugs me.
 
Yes, just change UNITAI_ANIMAL will do it, but I think you also have to remove the bAnimal tag in UnitInfos to be ALLOWED to remove that AI type. Otherwise, you need SDK modifications to enable UNITAI_ANIMAL to enter territory, or to disable the limitation of AI types for bAnimal units.

Aha, but then IS_ANIMAL type checks won't work? I would need to replace them all with custom checks and maybe create an "animal" promo to compare with.
 
True, that approach would keep Mezmerize, Subdue, and AI bonuses from functioning. I do remember coming across this in the SDK and there was only a single line which caused animals not to be allowed in terrain, with an override to stop that block if owned by a non-barbarian. So it would actually be a single line change in the SDK if you go that route.
 
Back
Top Bottom