V36

[Raven Destroyer]

I've been seeing barb cities being taken by the AI lately so I'm not sure what changes were made there and when or if any since I've also seen them ignore such cities. The AI is programmed to be a little emotional when it comes to war decisions so it often has to do with diplomacy between nations rather than just the best strategic moves they can or should be making.

It might be a little overzealous in termination of war, I noticed a Siege stack wiping out a Minor State that managed to appear out of a Barb city, Long before that Siege stack was assembled or possibly build, it passed 3 Barb cities possibly going Right next to one, on it's way for no strategic gain just to take out a minor state that was in no shape or form anywhere close to being a nuisance to them,
I actually liked that minor nation a little as it had the possibility of growing into the nice void of no mans land between me and the Mongol Horde who just sacked and massacred them all

 

[Dancing Hoskuld]

I think the problem may lie in the fact that the Barbarians are now a nation. This means that they had at least 3 cities whereas that little nation only had one making it a much more viable option to attack.

 

[Thunderbrd]

The barbarians have always been represented by a single player. But that is an interesting point. Nevertheless, that proxy nation is one that the AI are always at war with. So it would have more to do with not having any agenda to push to 'win' that war.

 

[Dancing Hoskuld]

But lately they have been acting like a nation too. They are even using the contract system for unit production. We need to get them back to being a nuisance with each city acting as if it is alone.

I think we can do quite a bit just by getting rid of all the nation stuff out of their XML definition. They should not have the Cultures or Heroes in the list of things they can build. Neither should they have the Wonders; Great, National or Religious.

If necessary we could then replace their workers with something else which can only build "Bandit Hideouts" or some such which spawn barbarian units.

It would also be better if they had a subset of the units all with no resource requirements as barbarians should get their resources by raiding and taking from non-barbarian units. However that will take some doing.

 

[Thunderbrd]

The unit movement is still too slow even with the changes i made to speed it up, there must be a simpler faster solution.
The healer production code in CvCityAI::AI_chooseHealerUnit is very slow how could that be simplyfied?

I can't see why BuildUps should slow things down at he moment.

Well... hmm.

I just did a profile of a new dll where I adjusted things so that it would cache the results of choose healer unit and reuse those results for the round, and I removed the movement changes.

Messed up thing? It ended up showing the new dll was slower than the old.

Huh?

Spoiler :

Old:

[852586.438] Fn Time (mS) Main thread time (mS) Avg time #calls Child time Self time Parent Alternate Time
[852586.438] Root 424398 424398 424398 1 408411 15987 0
[852586.438] CvGame::update 407044 407044 5814 70 407044 0 IFPPythonCall2.CvGameInterface::cannotDoControl 0
[852586.438] CvGame::update.Turn 407035 407035 5814 70 407034 1 CvGame::update.OneTimeInit 0
[852586.438] CvGame::updateMoves 390477 390477 5578 70 390477 0 CvDllPythonEvents:ostEvent.gameUpdate 0
[852586.438] CvGame::updateMoves.AI 332366 332366 3652 91 332355 11 CvGame::updateMoves.Human 0
[852586.438] CvPlayer::setTurnActive 268390 268390 5591 48 520528 -252138 CvSelectionGroup::autoMission 0
[852586.438] CvPlayer::setAutoMoves 268309 268309 5708 47 268309 0 CvPlayer::hasReadyUnautomatedUnit 0
[852586.438] CvPlayer::setTurnActive.SetInactive 268249 268249 11177 24 268248 1 CvPlayer::setTurnActive.SetInactive 0
[852586.438] CvPlayer::setTurnActive.SetInactive.doTurn 268248 268248 11177 24 16108 252140 CvPlayer::setTurnActive.SetInactive.doTurn 0
[852586.438] CvPlayer::setTurnActive.SetActive 252163 252163 10506 24 252162 1 CvPlayer::setTurnActive.SetInactive 0
[852586.438] CvPlayer::setTurnActive.SetActive.doTurn 251547 251547 10481 24 251547 0 CvPlayer::setTurnActive.SetActive.CalcDanger 0
[852586.438] CvPlayer::doTurn 198610 198610 8275 24 198462 148 CvPlayer::doTurn 0
[852586.438] CvPlayer::doTurn.DoCityTurn 155769 155769 6490 24 155141 628 CvDllPythonEvents:ostEvent.BeginPlayerTurn 0
[852586.438] CvPlayerAI::AI_unitUpdate 118184 118184 1738 68 118123 61 CvPlayer::hasReadyUnautomatedUnit 0
[852586.438] CvSelectionGroupAI::AI_update 118112 118112 15 7405 118084 28 CvPlayer::hasBusyUnit 0
[852586.438] CvUnitAI::AI_update 117844 117844 31 3707 117666 178 CvGame::updateTimers 0
[852586.438] CvUnitAI::AI_Update.civ 105892 105892 44 2358 105829 63 CvUnitAI::AI_Update.civ 0
[852586.438] CvCity::doTurnChooseProduction 81783 81783 284 287 81782 1 CvPlayerAI::AI_updateFoundValues 0
[852586.438] CvCityAI::AI_chooseProduction 81782 81782 483 169 79164 2618 CvCity::doTurnEnactNewProduction 0
[852586.438] CvCityAI::AI_bestBuildingThreshold 67544 67544 54 1233 63820 3724 CvCityAI::AI_bestBuildingThreshold 0
[852586.438] CvPathGenerator::generatePath 64069 64069 2 27683 122875 -58806 CvPathGenerator::generatePath 0
[852586.438] CvSelectionGroup::generatePath() 58945 58945 2 26751 58936 9 CvSelectionGroup::generatePath() 0
[852586.438] CvGame::updateMoves.Human 58110 58110 29055 2 58110 0 CvGame::updateMoves.Human 0
[852586.438] CvPathGenerator:rocessNode.NotKnownInvalid 54642 54642 0 15675728 48345 6297 CvPathGenerator::generatePath.Success 0
[852586.438] CvCityAI::AI_buildingValueThreshold 54461 54461 1 29988 50958 3503 CvCityAI::AI_buildingValueThreshold 0
[852586.438] CvPlayer::doTurnUnits 54390 54390 2266 24 54280 110 CvPlayerAI::AI_doResearch 0
[852586.438] CvCity::doTurnCompleteProduction 47449 47449 136 348 47449 0 CvPlayerAI::AI_updateFoundValues 0

New:

[850293.750] Fn Time (mS) Main thread time (mS) Avg time #calls Child time Self time Parent Alternate Time
[850293.750] Root 441124 441124 441124 1 418090 23034 0
[850293.750] CvGame::update 416288 416288 4524 92 416288 0 IFPPythonCall2.CvGameInterface::cannotDoControl 0
[850293.750] CvGame::update.Turn 416278 416278 4524 92 416277 1 CvGame::update.OneTimeInit 0
[850293.750] CvGame::updateMoves 399523 399523 4342 92 399523 0 CvDllPythonEvents:ostEvent.gameUpdate 0
[850293.750] CvGame::updateMoves.AI 339323 339323 3002 113 339304 19 CvGame::updateMoves.Human 0
[850293.750] CvPlayer::setTurnActive 269716 269716 5619 48 523627 -253911 CvSelectionGroup::autoMission 0
[850293.750] CvPlayer::setAutoMoves 269635 269635 5736 47 269635 0 CvPlayer::hasReadyUnautomatedUnit 0
[850293.750] CvPlayer::setTurnActive.SetInactive 269575 269575 11232 24 269554 21 CvPlayer::setTurnActive.SetInactive 0
[850293.750] CvPlayer::setTurnActive.SetInactive.doTurn 269554 269554 11231 24 15641 253913 CvPlayer::setTurnActive.SetInactive.doTurn 0
[850293.750] CvPlayer::setTurnActive.SetActive 253935 253935 10580 24 253934 1 CvPlayer::setTurnActive.SetInactive 0
[850293.750] CvPlayer::setTurnActive.SetActive.doTurn 253307 253307 10554 24 253306 1 CvPlayer::setTurnActive.SetActive.CalcDanger 0
[850293.750] CvPlayer::doTurn 199567 199567 8315 24 199417 150 CvPlayer::doTurn 0
[850293.750] CvPlayer::doTurn.DoCityTurn 157210 157210 6550 24 156570 640 CvDllPythonEvents:ostEvent.BeginPlayerTurn 0
[850293.750] CvPlayerAI::AI_unitUpdate 125829 125829 1398 90 125754 75 CvPlayer::hasReadyUnautomatedUnit 0
[850293.750] CvSelectionGroupAI::AI_update 125739 125739 16 7796 125707 32 CvPlayer::hasBusyUnit 0
[850293.750] CvUnitAI::AI_update 125446 125446 33 3704 125252 194 CvGame::updateTimers 0
[850293.750] CvUnitAI::AI_Update.civ 113282 113282 47 2361 113217 65 CvUnitAI::AI_Update.civ 0
[850293.750] CvCity::doTurnChooseProduction 82265 82265 288 285 82265 0 CvPlayerAI::AI_updateFoundValues 0
[850293.750] CvCityAI::AI_chooseProduction 82265 82265 492 167 81812 453 CvCity::doTurnEnactNewProduction 0
[850293.750] CvCityAI::AI_bestBuildingThreshold 71462 71462 58 1228 67681 3781 CvCityAI::AI_bestBuildingThreshold 0
[850293.750] CvPathGenerator::generatePath 65389 65389 2 27486 125545 -60156 CvPathGenerator::generatePath 0
[850293.750] CvSelectionGroup::generatePath() 60265 60265 2 26569 60255 10 CvSelectionGroup::generatePath() 0
[850293.750] CvGame::updateMoves.Human 60200 60200 30100 2 60200 0 CvGame::updateMoves.Human 0
[850293.750] CvCityAI::AI_buildingValueThreshold 57985 57985 1 29532 53067 4918 CvCityAI::AI_buildingValueThreshold 0
[850293.750] CvPathGenerator:rocessNode.NotKnownInvalid 55963 55963 0 15670690 49859 6104 CvPathGenerator::generatePath.Success 0
[850293.750] CvPlayer::doTurnUnits 55196 55196 2299 24 55085 111 CvPlayerAI::AI_doResearch 0
[850293.750] CvCityAI::CalculateAllBuildingValues 48835 48835 82 592 48519 316 GetBuildingValue.CacheMiss 0

I... don't... understand. Certainly not seeing cause here to keep these changes and commit them to the dll as it looks as if it would just slow things down further. That said, it may improve things significantly LATER in the game. This is pretty close to the stage of the game that SO is complaining about.

This stood out:

Spoiler :

[850293.750] CvPathGenerator:rocessNode.NotKnownInvalid 55963 55963 0 15670690 49859 6104 CvPathGenerator::generatePath.Success 0

This stood out a bit. That's a LOT of hits! Something is definitely wrong inside the path generator. On the old dll:

[852586.438] CvPathGenerator:rocessNode.NotKnownInvalid 54642 54642 0 15675728 48345 6297 CvPathGenerator::generatePath.Success 0

But lately they have been acting like a nation too. They are even using the contract system for unit production. We need to get them back to being a nuisance with each city acting as if it is alone.

I think we can do quite a bit just by getting rid of all the nation stuff out of their XML definition. They should not have the Cultures or Heroes in the list of things they can build. Neither should they have the Wonders; Great, National or Religious.

If necessary we could then replace their workers with something else which can only build "Bandit Hideouts" or some such which spawn barbarian units.

It would also be better if they had a subset of the units all with no resource requirements as barbarians should get their resources by raiding and taking from non-barbarian units. However that will take some doing.

The cities aren't using the contract system but the units themselves might be due to unit AI calls for assistance. As for the XML definition you're probably right about that. Interesting idea about the workers.

As for the units, barbarian cities and spawns require no resources which was part of what made it difficult to hold them to needing a particular cultural resource for cultural units (but that's been solved in the code last I looked - and NOT by making all resources necessary, just by impeding those units with a cultural resource requirement.)

 

[Harrier]

Well... hmm.

The cities aren't using the contract system but the units themselves might be due to unit AI calls for assistance. As for the XML definition you're probably right about that. Interesting idea about the workers.

Now, this is where you may scare away players.

What is the "Contract System". Never read about it before. or know what it is.

It would be great, if someone on the team would spend some time posting about (and adding to the Pedia) some of the newer features of this Great mod. So that players do not get to confused and maybe lose interest.

Just a thought.

 

[Dancing Hoskuld]

The "Contract System" is quite old. It is used only by the AI. Yes it would be a good candidate for a concepts page.

 

[Thunderbrd]

The Contract Brokerage System is an AI feature, not a player feature. It was established by Koshling long ago. Just gives us some major abilities to work with the AI in improved ways.

EDIT:
Yeah, so everything I tried today even worsened the situation for more involved games as well. Ugh...

 

[olduser]

Well... hmm.

I just did a profile of a new dll where I adjusted things so that it would cache the results of choose healer unit and reuse those results for the round, and I removed the movement changes.

Messed up thing? It ended up showing the new dll was slower than the old.

Huh?

Spoiler :

Old:

[852586.438] Fn Time (mS) Main thread time (mS) Avg time #calls Child time Self time Parent Alternate Time
[852586.438] Root 424398 424398 424398 1 408411 15987 0
[852586.438] CvGame::update 407044 407044 5814 70 407044 0 IFPPythonCall2.CvGameInterface::cannotDoControl 0
[852586.438] CvGame::update.Turn 407035 407035 5814 70 407034 1 CvGame::update.OneTimeInit 0
[852586.438] CvGame::updateMoves 390477 390477 5578 70 390477 0 CvDllPythonEvents:ostEvent.gameUpdate 0
[852586.438] CvGame::updateMoves.AI 332366 332366 3652 91 332355 11 CvGame::updateMoves.Human 0
[852586.438] CvPlayer::setTurnActive 268390 268390 5591 48 520528 -252138 CvSelectionGroup::autoMission 0
[852586.438] CvPlayer::setAutoMoves 268309 268309 5708 47 268309 0 CvPlayer::hasReadyUnautomatedUnit 0
[852586.438] CvPlayer::setTurnActive.SetInactive 268249 268249 11177 24 268248 1 CvPlayer::setTurnActive.SetInactive 0
[852586.438] CvPlayer::setTurnActive.SetInactive.doTurn 268248 268248 11177 24 16108 252140 CvPlayer::setTurnActive.SetInactive.doTurn 0
[852586.438] CvPlayer::setTurnActive.SetActive 252163 252163 10506 24 252162 1 CvPlayer::setTurnActive.SetInactive 0
[852586.438] CvPlayer::setTurnActive.SetActive.doTurn 251547 251547 10481 24 251547 0 CvPlayer::setTurnActive.SetActive.CalcDanger 0
[852586.438] CvPlayer::doTurn 198610 198610 8275 24 198462 148 CvPlayer::doTurn 0
[852586.438] CvPlayer::doTurn.DoCityTurn 155769 155769 6490 24 155141 628 CvDllPythonEvents:ostEvent.BeginPlayerTurn 0
[852586.438] CvPlayerAI::AI_unitUpdate 118184 118184 1738 68 118123 61 CvPlayer::hasReadyUnautomatedUnit 0
[852586.438] CvSelectionGroupAI::AI_update 118112 118112 15 7405 118084 28 CvPlayer::hasBusyUnit 0
[852586.438] CvUnitAI::AI_update 117844 117844 31 3707 117666 178 CvGame::updateTimers 0
[852586.438] CvUnitAI::AI_Update.civ 105892 105892 44 2358 105829 63 CvUnitAI::AI_Update.civ 0
[852586.438] CvCity::doTurnChooseProduction 81783 81783 284 287 81782 1 CvPlayerAI::AI_updateFoundValues 0
[852586.438] CvCityAI::AI_chooseProduction 81782 81782 483 169 79164 2618 CvCity::doTurnEnactNewProduction 0
[852586.438] CvCityAI::AI_bestBuildingThreshold 67544 67544 54 1233 63820 3724 CvCityAI::AI_bestBuildingThreshold 0
[852586.438] CvPathGenerator::generatePath 64069 64069 2 27683 122875 -58806 CvPathGenerator::generatePath 0
[852586.438] CvSelectionGroup::generatePath() 58945 58945 2 26751 58936 9 CvSelectionGroup::generatePath() 0
[852586.438] CvGame::updateMoves.Human 58110 58110 29055 2 58110 0 CvGame::updateMoves.Human 0
[852586.438] CvPathGenerator:rocessNode.NotKnownInvalid 54642 54642 0 15675728 48345 6297 CvPathGenerator::generatePath.Success 0
[852586.438] CvCityAI::AI_buildingValueThreshold 54461 54461 1 29988 50958 3503 CvCityAI::AI_buildingValueThreshold 0
[852586.438] CvPlayer::doTurnUnits 54390 54390 2266 24 54280 110 CvPlayerAI::AI_doResearch 0
[852586.438] CvCity::doTurnCompleteProduction 47449 47449 136 348 47449 0 CvPlayerAI::AI_updateFoundValues 0

New:

[850293.750] Fn Time (mS) Main thread time (mS) Avg time #calls Child time Self time Parent Alternate Time
[850293.750] Root 441124 441124 441124 1 418090 23034 0
[850293.750] CvGame::update 416288 416288 4524 92 416288 0 IFPPythonCall2.CvGameInterface::cannotDoControl 0
[850293.750] CvGame::update.Turn 416278 416278 4524 92 416277 1 CvGame::update.OneTimeInit 0
[850293.750] CvGame::updateMoves 399523 399523 4342 92 399523 0 CvDllPythonEvents:ostEvent.gameUpdate 0
[850293.750] CvGame::updateMoves.AI 339323 339323 3002 113 339304 19 CvGame::updateMoves.Human 0
[850293.750] CvPlayer::setTurnActive 269716 269716 5619 48 523627 -253911 CvSelectionGroup::autoMission 0
[850293.750] CvPlayer::setAutoMoves 269635 269635 5736 47 269635 0 CvPlayer::hasReadyUnautomatedUnit 0
[850293.750] CvPlayer::setTurnActive.SetInactive 269575 269575 11232 24 269554 21 CvPlayer::setTurnActive.SetInactive 0
[850293.750] CvPlayer::setTurnActive.SetInactive.doTurn 269554 269554 11231 24 15641 253913 CvPlayer::setTurnActive.SetInactive.doTurn 0
[850293.750] CvPlayer::setTurnActive.SetActive 253935 253935 10580 24 253934 1 CvPlayer::setTurnActive.SetInactive 0
[850293.750] CvPlayer::setTurnActive.SetActive.doTurn 253307 253307 10554 24 253306 1 CvPlayer::setTurnActive.SetActive.CalcDanger 0
[850293.750] CvPlayer::doTurn 199567 199567 8315 24 199417 150 CvPlayer::doTurn 0
[850293.750] CvPlayer::doTurn.DoCityTurn 157210 157210 6550 24 156570 640 CvDllPythonEvents:ostEvent.BeginPlayerTurn 0
[850293.750] CvPlayerAI::AI_unitUpdate 125829 125829 1398 90 125754 75 CvPlayer::hasReadyUnautomatedUnit 0
[850293.750] CvSelectionGroupAI::AI_update 125739 125739 16 7796 125707 32 CvPlayer::hasBusyUnit 0
[850293.750] CvUnitAI::AI_update 125446 125446 33 3704 125252 194 CvGame::updateTimers 0
[850293.750] CvUnitAI::AI_Update.civ 113282 113282 47 2361 113217 65 CvUnitAI::AI_Update.civ 0
[850293.750] CvCity::doTurnChooseProduction 82265 82265 288 285 82265 0 CvPlayerAI::AI_updateFoundValues 0
[850293.750] CvCityAI::AI_chooseProduction 82265 82265 492 167 81812 453 CvCity::doTurnEnactNewProduction 0
[850293.750] CvCityAI::AI_bestBuildingThreshold 71462 71462 58 1228 67681 3781 CvCityAI::AI_bestBuildingThreshold 0
[850293.750] CvPathGenerator::generatePath 65389 65389 2 27486 125545 -60156 CvPathGenerator::generatePath 0
[850293.750] CvSelectionGroup::generatePath() 60265 60265 2 26569 60255 10 CvSelectionGroup::generatePath() 0
[850293.750] CvGame::updateMoves.Human 60200 60200 30100 2 60200 0 CvGame::updateMoves.Human 0
[850293.750] CvCityAI::AI_buildingValueThreshold 57985 57985 1 29532 53067 4918 CvCityAI::AI_buildingValueThreshold 0
[850293.750] CvPathGenerator:rocessNode.NotKnownInvalid 55963 55963 0 15670690 49859 6104 CvPathGenerator::generatePath.Success 0
[850293.750] CvPlayer::doTurnUnits 55196 55196 2299 24 55085 111 CvPlayerAI::AI_doResearch 0
[850293.750] CvCityAI::CalculateAllBuildingValues 48835 48835 82 592 48519 316 GetBuildingValue.CacheMiss 0

I... don't... understand. Certainly not seeing cause here to keep these changes and commit them to the dll as it looks as if it would just slow things down further. That said, it may improve things significantly LATER in the game. This is pretty close to the stage of the game that SO is complaining about.

This stood out:

Spoiler :

[850293.750] CvPathGenerator:rocessNode.NotKnownInvalid 55963 55963 0 15670690 49859 6104 CvPathGenerator::generatePath.Success 0

This stood out a bit. That's a LOT of hits! Something is definitely wrong inside the path generator. On the old dll:

[852586.438] CvPathGenerator:rocessNode.NotKnownInvalid 54642 54642 0 15675728 48345 6297 CvPathGenerator::generatePath.Success 0

Without knowing the changes you made in that new dll i can't really say anything about it.

 

[Thunderbrd]

Without knowing the changes you made in that new dll i can't really say anything about it.

Ultimately, the changes made it so that the healer build evaluation would only happen once for each player in a round. And it reverted the movement rules back to the gross oversimplification. That was it.

So I've been thinking, obviously the movement rule change wasn't that great an impact and there was a downside in making the healer build evaluation national as it had to stop only looking at the 'area' the city was in. So perhaps the movement rules aren't that delaying at all and I can just simplify the healer build evaluation. As far as that goes, I suppose that the stack can call for a healer when it wants one, which city attack stacks will already do and a city can simply broker for the healers it needs to support the local troops there. That would certainly give me a lot of room to simplify there. Also reducing it to only one potential call during a city build selection routine could help.

In the meantime, I'm backing up a working version of the SVN through revisions and using an old developed savegame to take time profile snapshots at different revisions. I'll be looking to see just how great an impact the movement rule changes actually made at the time but then you've simplified some of that effectively too. It IS possible that some of those changes you and I both made actually sped things up a bit due to some small spotted optimization opportunities found during the adjustment. It's also possible that it doesn't really have an impact until a ridiculous number of units are in the game and I don't have a save (nor the time to evaluate such a save) that would show that.

What I'm trying to do now is identify if and when there has been a slowdown around the ancient to classical era. So far, there's really no evidence that our current assets have slowed much if at all - in fact, the current assets are rating faster than most of the previous. (Edit: The following only applied to an Ancient game - 8610 was significantly faster for an Industrial game) I did see a slight drop in time cost from 8610 going back to 8604 which is a little odd because the coding changes were fairly minimal within that range.

 

[olduser]

So I've been thinking, obviously the movement rule change wasn't that great an impact

No they had an really huge impact before i made a few changes to make things faster again. Now it's still too slow but you need a really advanced game to really see it with the profiler.

You made those movement changes in rev8185-rev8194 but with all the other changes simply using such an old dll might give wrong results.

 

[Thunderbrd]

It would have to be a very very advanced game perhaps.

I tested a few games removing all references to CvUnit::canUnitCoexistWithEnemyUnit and returning to a massively simplified status. In both cases, it actually made the turns take longer, which I think had something to do with simply causing some re-evaluations of movements. I'm sure a more advanced game would show the difference clearly but one tested game was up to Industrial so it'd have to be a VERY advanced game indeed. Unfortunately I don't have anything to test that against.

So is it really worth it to remove the enhanced ability to control game movement rules this section provides? This not only makes tunnels work properly but also enables us to be able to infuse a few different move/attack rule changes for units that are submerged, hovering in flight at a high altitude, burrowing etc... It formed the basis for near future plans to be implemented for the naval units.

Another way to address the problem would be to make units more expensive and bring unit production modifiers the cities have access to under some control so that the board doesn't get swamped by so many units that it becomes an issue (since it can handle hundreds - thousands of units on the map already without any noticeable difference after your adjustments.)

Additionally, 'too slow' with a massively advanced game is kinda a given. Civ in all of its manifestations has always slowed to 15-30 min per turn on such a game.

However, I did simplify the Healer Build evaluation and that took a significant amount of time off. And thorough testing has shown that there really hasn't been a major slowdown in turn times lately as much as I'd thought. Games just quickly take on added turn times around the Ancient era because AI cities and units proliferate quite a bit around then.

There might be a way to speed up the evaluation of whether a unit can be co-existed with that involves expanding the checkPlot() function to a third evaluation statement that checks for compatible unit states beyond simply 'visible' (the 2nd evaluation as it stands now.) But it COULD also be just as slow or slower and I don't really think there's any way to avoid it.

Another way could be to gameoption or bugoption advanced movement rules and attach tunnels and realistic later unit interactions to that option so players have a choice between streamlined and less realistic (or less functional at least) and slower but enabled.

Nevertheless, none of this really addresses much of what might be causing any early game slowdowns, or if there even is a noteworthy slowdown in the early game, such as that reported by SO.

 

[Raven Destroyer]

I think the problem may lie in the fact that the Barbarians are now a nation. This means that they had at least 3 cities whereas that little nation only had one making it a much more viable option to attack.

Was i too Vague? i guess i was it wasn't a Barb stack it was the Mongolian nation doing you know the Mongolian thing looting and plundering across the continent, this time ignoring 3 barb cities to get a Minor state

Sadly Barbarians aren't much of a thing I'm in the Classic age and the game just started to get beyond the initial stage of Warfare with everyone having Writing, (A.I. not much beyond Writing)

 

[Dancing Hoskuld]

The barbarian nation is the biggest one on the map so of course the Mongolian army is going to go after smaller nations.

 

[Thunderbrd]

The barbarian nation is the biggest one on the map so of course the Mongolian army is going to go after smaller nations.

But here's what I don't understand. Sure a nation might be reluctant to go to war with and invade a larger nation. But since all civilizations are ALWAYS at war with the barbarians, why wouldn't they have targeted those barb cities first? Perhaps because the cities were pop 1 and would've been destroyed if they were taken at that time? Hard to say. I'd have to read the coding on how they target cities.

 

[Dancing Hoskuld]

I have seen it happening in other mods as well. I suspect that the risk is to high because the total number of barbarian units on the continent is big.

Size one cities of non barbarians get attacked.

BtW did your latest fix solve the problem of workers not being attacked at all when in the wild areas?

 

[Thunderbrd]

I have seen it happening in other mods as well. I suspect that the risk is to high because the total number of barbarian units on the continent is big.

Size one cities of non barbarians get attacked.

BtW did your latest fix solve the problem of workers not being attacked at all when in the wild areas?

I doubt it would have addressed that. The problem I found did relate quite perfectly to the 'too damaged to be attacked' issue but not to a null strength value to start with.

I don't think the risk of attacking a city of a nation you're at war with takes any consideration at all the size of the rest of the nation. You're already at war so you've already kicked the hornet's nest as it were... so it's only going to at that point evaluate the value of taking that particular city (I believe the AI is under-appreciating the wealth they can get in captives by taking out barb cities and letting them return over and over.)

 

[Raven Destroyer]

Missionaries also take full advantage of that Worker bug, My Missionaries are worse then Jehova's across the continent without any animals molesting them,

I can't recall if i ever seen Civ IV A.I. be as Zealous in Barb hunting as they where in Civ III where they would smell a Barb half a Continent away and take it out, but this situation where the Mongolians passes 3 Targets to take out a 4th of a Different nation, Somewhere it kinda made a weird decision between taking the Large Hornet Nest down a Peg and Elimination of a Non-issue, i guess Take out what you can but those 3 Barb settlements aren't that much of a bump for a decent Siege stack which the A.I. Build more often then I,

 

[olduser]

It would have to be a very very advanced game perhaps.

I tested a few games removing all references to CvUnit::canUnitCoexistWithEnemyUnit and returning to a massively simplified status. In both cases, it actually made the turns take longer, which I think had something to do with simply causing some re-evaluations of movements. I'm sure a more advanced game would show the difference clearly but one tested game was up to Industrial so it'd have to be a VERY advanced game indeed. Unfortunately I don't have anything to test that against.

So is it really worth it to remove the enhanced ability to control game movement rules this section provides? This not only makes tunnels work properly but also enables us to be able to infuse a few different move/attack rule changes for units that are submerged, hovering in flight at a high altitude, burrowing etc... It formed the basis for near future plans to be implemented for the naval units.

Another way to address the problem would be to make units more expensive and bring unit production modifiers the cities have access to under some control so that the board doesn't get swamped by so many units that it becomes an issue (since it can handle hundreds - thousands of units on the map already without any noticeable difference after your adjustments.)

Additionally, 'too slow' with a massively advanced game is kinda a given. Civ in all of its manifestations has always slowed to 15-30 min per turn on such a game.

However, I did simplify the Healer Build evaluation and that took a significant amount of time off. And thorough testing has shown that there really hasn't been a major slowdown in turn times lately as much as I'd thought. Games just quickly take on added turn times around the Ancient era because AI cities and units proliferate quite a bit around then.

There might be a way to speed up the evaluation of whether a unit can be co-existed with that involves expanding the checkPlot() function to a third evaluation statement that checks for compatible unit states beyond simply 'visible' (the 2nd evaluation as it stands now.) But it COULD also be just as slow or slower and I don't really think there's any way to avoid it.
Another way could be to gameoption or bugoption advanced movement rules and attach tunnels and realistic later unit interactions to that option so players have a choice between streamlined and less realistic (or less functional at least) and slower but enabled.

Nevertheless, none of this really addresses much of what might be causing any early game slowdowns, or if there even is a noteworthy slowdown in the early game, such as that reported by SO.

In the right conditions those unit movements changes cause huge slowdowns that can't happen. It might not be visible in your game using the internal profiler and that is exactly what i was saying a few months back. It only appears as noise in the profiler logs until you have the right conditions and then you are able to see it really slowing down the turn time. The main problem is that the code you have added causes too much recursive looping through units, the same thing happened in the healer build evaluation.

You end up with far too many calls to CvUnit* getUnit(IDInfo unit). That leads too alot of spin time because of the CriticalSections needed for the multithreading. I'am not sure but i think the internal profiler doesn't show the spin time so you can only see it in the turn times.

I had a save somewhere that had a bit over 50 minutes turn time and after my changes it was down to ~20 minutes. Without those movement changes the same turn took only a few minutes. I have to see if i can find that save and upload it here.

 

[Reisk@]

But here's what I don't understand. Sure a nation might be reluctant to go to war with and invade a larger nation. But since all civilizations are ALWAYS at war with the barbarians, why wouldn't they have targeted those barb cities first?

Exactly. If there is a large barbarian threat nearby, it really isn't smart move to start new wars at that time.