Are you saying that you are automatically safe from an AI if
1) you are on the same continent as he
2) there is no land path between the two of you?
Does this still hold true if the AI builds a city elsewhere? (On one of those patches of frozen tundra, or on a one tile island in the middle of the ocean, etc)?
Or does it only apply when the AI is 100% confined to that one continent, and thus can't trace an attack path through any other means (than the buggy code)?
I seem to recall a deity game from silverbullet's university series that had the same issue, with JC there as well no less unless I'm mistaken.
It would be interesting to know more about it.
Dresden refered to the fact that sometimes a AI stays stuck in "hands full" if they refuse to build boats and there is no land path to the target ( I had witnessed that once in one of my LHC as well ) and he gave your game as example .Are you refering to that?
@kazapp
My experience with isolated starts showed me that your 2 conditions alone are not enough to prevent a attack
DanF is the authority on this subject as he's the one who brought Gliese's game to my attention; I haven't looked into the details yet. So I expect he'll be able to shed more light on this.
This one seems to be tricky. If an area (=landmass) is divided by impassable terrain (mountains and inland lakes) the AI is not able to figure out how to get ANY units to the other side. A quick test showed that this of course also includes Settlers (another example might be Gliese's new Zara Yaqob Deity Game). But not only do large patches of good land behind the mountains remain unsettled, it appears that the lost/idle AI Settlers also prevent the settling of off-shore islands (that was just one observation, no code investigation yet). I am more and more convinced that such landmasses should be treated as separate areas, so that the AI knows that it needs to build boats. But this would lead to further problems like getting intercontinental trade routes and messing up the wonders that give bonuses for a continent (Great Wall, TGD, ...).
Now that you talk on that, this reminds me a lot the Vanilla pathfinder misfeature, aka "wall of units" exploit ( if the AI couldn't find a way to a city without stumbling in a enemy unit they would never attack anymore... I'm guilty of using that once or twice ). I haven't looked at the code to see the solution they implemented but from what I see in game, the AI still has that issue but randomly ( or maybe not ) sends units against the wall.... Not that this very helpful in here :|
I was playing yesterday Earth 18 civs and I think I saw something similar: I ( GK ) half rushed India and took one city ( it was a half hearted attempt, as i was shipping my main forces to Japan to finish Tokugawa ... so I only fielded 3 keshiks ). Made peace when the bastard decided to whip spears in his remaining cities ( and the guy was a useful buffer against Cyrus ) and many eons later I saw a Indian lbow in clear fogbusting target city location task ( as he standed there until I settled the spot, I asssume that ) in Tibet. I had spy view on Indian cities and I noticed a setter team rotting in Delhi for centuries in spite of Asoka knowing a ( very tortuous ) path to get there...... Might be the same stuff, don't you think?
Yep, it makes sense. It also explains that while Monty murders Roosevelt he never attacks Hyuana Capac. So in your game as HC you never had to worry about ticking off Monty at all because he'd never attack you!
I've had cities in south america attacking by Monty on the world18 map. Maybe AIs will utilize a navy if they have one, so once they start building ships they can attack, but they won't build ships to get to a target on thesame landmass.
I think if someone wants to fix this pathfinding bug, the best bet is to change the pathfinding algorith so the AI considers moving troops by boat when the target is on thesame landmass as well and then picks the best of the alternatives.
Maybe the problem isn't in the pathfinding, but in the unit building priority. If they want to declare war on a target on thesame landmass, the probability for building transport goes down to 0, in that case AI's before MC should be able to wage wars on a divided single landmass, since they'll build galleys anyway.
While investigating things regarding the eternal-WHEOOHRN-due-to-blocked-land-paths issue, I had a look at the code handling the AI's use of boats to get their Settlers to the best city sites ... and found a view things that appear amendable, especially in situations when the best available site with the highest found value is on the same landmass (=area) as an AI Settler but his path is blocked by impassable terrain or foreign culture. As a result, the AI will often be very slow or fail completely at the expansion of their empire with Settlers idling in their cities. Obviously it is worst on watery maps with snaky land shapes where pathfinding is difficult and blocking more likely (prime example: current Emperor Cookbook II Mehmed game).
Problem 1:
The AI will not move Settlers, not even Settler groups that can defend, through friendly territory of a neighbor with open borders. It has no problems to send Workers to build roads towards the new site or improvable resources, but will never follow with the Settler (example Dirk's Deity Game - 475 BC Pericles has an idle Settler in Corinth).
In CvUnitAI::AI_found() Settlers only check for possible paths with the flag MOVE_SAFE_TERRITORY, whereas Workers don't care in their pathfinding. I believe the Settlers should also consider paths through friendly territory (MOVE_NO_ENEMY_TERRITORY) when they are part of a group that can defend:
Problem 2:
The AI gets really crazy when it tries to solve this problem with boats. Settlers will always prefer to head for the best city sites on their landmass, if they don't find a path (blocked by mountains, closed borders) they will go aboard a Galley. The Galley then checks for the optimal site to go to - and finds that the best site is on the same landmass, so it unloads the Settler ... The boat will only start into the sea, if the best plot is not on the same area! If I understand all of this correctly then this is a clear bug which should be fixed.
The game determines the best site on the same landmass as the Settler (iAreaBestFoundValue) and the best off-shore site (iOtherBestFoundValue). The Settler will try to board a Galley first if the off-shore site is better than 110% Area-site. I think the sites on the same landmass but unreachable by land should be handled as off-shore sites.
CvUnitAI::AI_settleMove()
Spoiler:
Code:
[SIZE="3"]int iAreaBestFoundValue = 0;
int iOtherBestFoundValue = 0;
int iPathTurns;
for (int iI = 0; iI < GET_PLAYER(getOwnerINLINE()).AI_getNumCitySites(); iI++)
{
CvPlot* pCitySitePlot = GET_PLAYER(getOwnerINLINE()).AI_getCitySite(iI);
if ((pCitySitePlot->getArea() == getArea()) [COLOR="Blue"]&& (generatePath(pCitySitePlot, MOVE_NO_ENEMY_TERRITORY, true, &iPathTurns))[/COLOR])
{
if (plot() == pCitySitePlot)
{
if (canFound(plot()))
{
getGroup()->pushMission(MISSION_FOUND);
return;
}
}
iAreaBestFoundValue = std::max(iAreaBestFoundValue, pCitySitePlot->getFoundValue(getOwnerINLINE()));
}
else
{
iOtherBestFoundValue = std::max(iOtherBestFoundValue, pCitySitePlot->getFoundValue(getOwnerINLINE()));
}
}[/SIZE]
The same change in CvUnitAI::AI_settlerSeaTransport() to keep the boat from unloading the Settler again.
Problem 3:
The AI will not send the Galley out with only a Settler onboard. However it runs into problems when it has no access to metals and only builds Archers (UNITAI_CITY_DEFENSE), as they are not allowed to join a Settler on a boat (the can board a Galley together, but need to be a group before the Galley arrives to pick them up). IMO city defenders should of course be allowed to join a Settler on a boat.
CvUnitAI::AI_load
Spoiler:
Code:
[SIZE="3"]for(pLoopUnit = GET_PLAYER(getOwnerINLINE()).firstUnit(&iLoop); pLoopUnit != NULL; pLoopUnit = GET_PLAYER(getOwnerINLINE()).nextUnit(&iLoop))
{
if (pLoopUnit != this)
{
if (AI_plotValid(pLoopUnit->plot()))
{
if (canLoadUnit(pLoopUnit, pLoopUnit->plot()))
{
// special case ASSAULT_SEA UnitAI, so that, if a unit is marked escort, but can load units, it will load them
// transport units might have been built as escort, this most commonly happens with galleons
UnitAITypes eLoopUnitAI = pLoopUnit->AI_getUnitAIType();
if (eLoopUnitAI == eUnitAI)// || (eUnitAI == UNITAI_ASSAULT_SEA && eLoopUnitAI == UNITAI_ESCORT_SEA))
{
int iCargoSpaceAvailable = pLoopUnit->cargoSpaceAvailable(getSpecialUnitType(), getDomainType());
iCargoSpaceAvailable -= GET_PLAYER(getOwnerINLINE()).AI_unitTargetMissionAIs(pLoopUnit, aeLoadMissionAI, iLoadMissionAICount, getGroup());
if (iCargoSpaceAvailable > 0)
{
if ((eTransportedUnitAI == NO_UNITAI) || (pLoopUnit->getUnitAICargo(eTransportedUnitAI) > 0))
{
if ((iMinCargo == -1) || (pLoopUnit->getCargo() >= iMinCargo))
{
if ((iMinCargoSpace == -1) || (pLoopUnit->cargoSpaceAvailable() >= iMinCargoSpace))
{
if ((iMaxCargoSpace == -1) || (pLoopUnit->cargoSpaceAvailable() <= iMaxCargoSpace))
{
if ((iMaxCargoOurUnitAI == -1) || (pLoopUnit->getUnitAICargo(AI_getUnitAIType()) <= iMaxCargoOurUnitAI))
{
[COLOR="Blue"]// if (getGroup()->getHeadUnitAI() != UNITAI_CITY_DEFENSE || !plot()->isCity() || (plot()->getTeam() != getTeam()))[/COLOR]
{
if (!(pLoopUnit->plot()->isVisibleEnemyUnit(this)))[/SIZE]
But only if they don't get chosen as the best defender or as part of the minimum defenders:
CvUnitAI::AI_cityDefenseMove()
Spoiler:
Code:
[SIZE="3"]if (AI_guardCityBestDefender())
{
return;
}
if (AI_guardCityMinDefender(true)) [COLOR="Blue"]// moved up[/COLOR]
{
return;
}
if (!bDanger)
{
if (plot()->getOwnerINLINE() == getOwnerINLINE())
{
if (AI_load(UNITAI_SETTLER_SEA, MISSIONAI_LOAD_SETTLER, UNITAI_SETTLE, -1, -1, 1, -1, MOVE_SAFE_TERRITORY, 1))
{
return;
}
}
}
[/SIZE]
I'm not really sure about MOVE_SAFE_TERRITORY <--> MOVE_NO_ENEMY_TERRITORY here (and how they are defined in the first place).
I played the ECII as a test with these changes and found a much better Boat-REX of the AI. In this game Cyrus runs into problems because he cannot settle the southern part of his landmass (blocked by mountain) and has no metal in his starting area. He will therefore leave his land only for the far away SE sugar-island (this has a great iOtherBestFoundValue). Toku is boxed in between the human (South) and Shaka (North) and tries to settle in the SE Pig-Ivory spot, but can't get there when blocked by human culture. He can also not reach the long thin peninsula north of that region east of his capital by land. But he will start his Galley only when the Pig-Ivory spot is taken by the human, since his best site will then be the far SW island. Once the boat is in "leave-port-mode" he will decide to head for the eastern Fish-Iron site, as this is much closer (iPathturns devalue the FoundValue). Shaka seems to have similar problems. The picture shows the AI's REX-success in my 400-AD save played with my changed dll (left) compared to Gliese's 400-AD save (right, I think with normal 3.17).
Spoilerreveals whole map! :
IMHO this unfortunate AI behavior is not just suboptimal (which would make it a subject for the Better-AI mod) but deserves to be treated in the unofficial patch (please regard my proposed code changes as a starting point for a discussion which will hopefully lead to an AI, that is able to ship ALL their units around in a clever way to also prevent the eternal WHEOOHRN).
Thanks for sharing your thoughts Dan. However I would like to put a game up for discussion. I was playing a pangea map with the current HOF mod for vanilla (1.74.003), it had to be vanilla for the gauntlet I was playing.
In it I had teched to Cavalry and went on the rampage eliminating 3 (I think) AI's before stopping (I was aiming for a space victory). At this point one of the remaining AI's ran a settler and defender in a boat round my territory (we had open borders) to a very poor snow site with a metal resource right up north. Basically it was so poor I wouldn't have bothered burning it down if we had been at war
I don't know if anything was changed from vanilla to BTS but there might be some differences to look at.
Attached is a save from toward the end of the game where you can see the city in question if it is of any help.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
). I haven't looked at the code to see the solution they implemented but from what I see in game, the AI still has that issue but randomly ( or maybe not ) sends units against the wall.... Not that this very helpful in here :|
