Thunderbrd
C2C War Dog
We have a vision. 'nuff said. The bug squashing is the unfortunate necessity along the way.
V36
- Thread starter fox456
- Start date
May it be a good one, although those lines bear eerie resemblance to many famous last words. Pride and arrogance so eagerly appearing here so very often goeth before a downfall.
Appearance of bugs is unfortunate necessity due to flaws and limits of man but crushing them is the work of true honor and pride to those who truly love their product.
∴ ☯ ∴
From this quote- I get the impression that you are a very experienced and dedicated programmer who knows what he is talking about and wants to find and correct bugs. So why not join the team.
You can then help correct all the faults you find rather than just complain about them. Of course, if you are not a programmer and just complaining for the sake of it, you have no idea about what is involved.
I do expect a sarcastic response to this post, which will be ignored.
Thunderbrd
C2C War Dog
@Joe: I profiled your save to see what's taking so long (and it is a long turn yes.) It looks like it boils down to inefficient AI in general. Pathing has some issues and I think some units are getting confused by those bugs and running numerous rechecks they shouldn't have to. Naval AI is incredibly inefficient and your game shows a number of units checking an exorbitant amount of times if they are stranded (which apparently they are.)
Unfortunately all of these areas are the most complex areas in the mod. There are known problems with pathing but it's way outside of my comprehension what all is taking place there.
I'll be doing some further analysis tomorrow but I'm not entirely sure that I CAN speed this game up too much. I suspect that part of the problem boils down to there simply being a LOT of AI units - something that Alberts2 has pointed out is an issue as it is. The production cost changes I'm getting into evaluating now should help tremendously with that and hopefully won't impede AI planning too much (we'll see.)
Again, the problems are lurking in the most difficult segments of the code so we'll see if there's anything I can do but I don't want to go muddling about and generating further bugs either so its something to be very careful with.
Oh Koshling whereart thou!
The most time expensive routines:
Unfortunately all of these areas are the most complex areas in the mod. There are known problems with pathing but it's way outside of my comprehension what all is taking place there.
I'll be doing some further analysis tomorrow but I'm not entirely sure that I CAN speed this game up too much. I suspect that part of the problem boils down to there simply being a LOT of AI units - something that Alberts2 has pointed out is an issue as it is. The production cost changes I'm getting into evaluating now should help tremendously with that and hopefully won't impede AI planning too much (we'll see.)
Again, the problems are lurking in the most difficult segments of the code so we'll see if there's anything I can do but I don't want to go muddling about and generating further bugs either so its something to be very careful with.
Oh Koshling whereart thou!
The most time expensive routines:
Spoiler :
ostEvent.gameUpdate 0
JosEPh_II
TBS WarLord
Thanks for the update and info TB.
I wish koshling had the time to lend a hand even if only on a limited basis.
And is alberts2 still involved?
JosEPh
I wish koshling had the time to lend a hand even if only on a limited basis.
And is alberts2 still involved?
JosEPh
Thunderbrd
C2C War Dog
We haven't heard from Alberts2 in a bit here but it wouldn't be the first time he ducked out silently for a while then came back later. I wish I knew if he had any design or improvement goals to attend to though.
This is what stands out to me:
[951365.750] CvUnitAI::AI_assaultSeaMove 425077 425077 1307 325 425031 46 CvUnitAI::AI_workerMove 0
[951365.750] CvSelectionGroup::isStranded 334039 334039 0 968773 333988 51 CvPlayer::setTurnActive 0
[951365.750] CvSelectionGroup::calculateIsStranded 333988 333988 64 5206 333938 50 CvSelectionGroup::calculateIsStranded 0
[951365.750] CvSelectionGroup::isHasPathToAreaPlayerCity 333743 333743 889 375 4650 329093 CvSelectionGroup::isHasPathToAreaPlayerCity 0
[951365.750] CvUnitAI::AI_pickupStranded 329745 329745 529 623 329531 214 pathValid move save 0
[951365.750] PipelineThread 296755 0 9891 30 196126 100629 0
[951365.750] CvPathGenerator::generatePath 280211 280211 2 129663 532467 -252256 CvPathGenerator::generatePath 0
After some analysis, this shows pretty clearly that the lion's share of the turn time is being spent evaluating if some of the AI units are stranded and if and what to do about it. There's caching in place that's speeding it up significantly as it is surprisingly enough. However, ultimately the problem lies in the fact that this evaluation asks for quite a few calls to 'generatePath' which can be a slow function, particularly if it gets frustrated, which this is asking it to do (check all possibilities before you give up to ensure we are stranded).
The crux of this is here in this function:
where we are looping through all the cities of the player on the same continent. The problem, I believe, lies in the fact that there may be quite a few cities on the continent these units are 'stranded' on but they are 'stranded' because they can't reach those cities for whatever reason anyhow.
This could mean there's some kind of fort blockade, mountains that are uncrossable... enemy uncrossable territory trapping some AI units... something along these lines.
What's really interesting about this is just how much time this issue eats up so I'm thinking that the pathing check is where the biggest issue with this lies. And again, there's OOS errors, movement rule disagreements and numerous asserts coming from pathing in every game I evaluate. But it's just so very complicated there!
I'm not sure what the best way to go about trying to attack this problem would be to be honest. The calculation on if a unit is stranded will only take place once for every unit that requests this information in a round thanks to caching (and it's STILL costing a LOT) and that was the one thing I could've imagined implementing here. Koshling already beat me to it long ago.
This is what stands out to me:
[951365.750] CvSelectionGroup::isStranded 334039 334039 0 968773 333988 51 CvPlayer::setTurnActive 0
[951365.750] CvSelectionGroup::calculateIsStranded 333988 333988 64 5206 333938 50 CvSelectionGroup::calculateIsStranded 0
[951365.750] CvSelectionGroup::isHasPathToAreaPlayerCity 333743 333743 889 375 4650 329093 CvSelectionGroup::isHasPathToAreaPlayerCity 0
[951365.750] CvUnitAI::AI_pickupStranded 329745 329745 529 623 329531 214 pathValid move save 0
[951365.750] PipelineThread 296755 0 9891 30 196126 100629 0
[951365.750] CvPathGenerator::generatePath 280211 280211 2 129663 532467 -252256 CvPathGenerator::generatePath 0
After some analysis, this shows pretty clearly that the lion's share of the turn time is being spent evaluating if some of the AI units are stranded and if and what to do about it. There's caching in place that's speeding it up significantly as it is surprisingly enough. However, ultimately the problem lies in the fact that this evaluation asks for quite a few calls to 'generatePath' which can be a slow function, particularly if it gets frustrated, which this is asking it to do (check all possibilities before you give up to ensure we are stranded).
The crux of this is here in this function:
Code:
bool CvSelectionGroup::isHasPathToAreaPlayerCity( PlayerTypes ePlayer, int iFlags )
{
PROFILE_FUNC();
CvCity* pLoopCity = NULL;
int iLoop;
CvReachablePlotSet plotSet(this, iFlags, MAX_INT, false);
for (pLoopCity = GET_PLAYER(ePlayer).firstCity(&iLoop); pLoopCity != NULL; pLoopCity = GET_PLAYER(ePlayer).nextCity(&iLoop))
{
if( pLoopCity->area() == area() && plotSet.find(pLoopCity->plot()) != plotSet.end() )
{
if ( (iFlags & MOVE_IGNORE_DANGER) != 0 || getHeadUnit()->canAttack() )
{
FAssert( generatePath(plot(), pLoopCity->plot(), iFlags, true) );
return true;
}
else if ( generatePath(plot(), pLoopCity->plot(), iFlags, true) )
{
return true;
}
else
{
FAssertMsg(false, "Pathing failed to apparently recahable city");
}
}
}
return false;
}This could mean there's some kind of fort blockade, mountains that are uncrossable... enemy uncrossable territory trapping some AI units... something along these lines.
What's really interesting about this is just how much time this issue eats up so I'm thinking that the pathing check is where the biggest issue with this lies. And again, there's OOS errors, movement rule disagreements and numerous asserts coming from pathing in every game I evaluate. But it's just so very complicated there!
I'm not sure what the best way to go about trying to attack this problem would be to be honest. The calculation on if a unit is stranded will only take place once for every unit that requests this information in a round thanks to caching (and it's STILL costing a LOT) and that was the one thing I could've imagined implementing here. Koshling already beat me to it long ago.
The pathing engine is good when it finds a path but really slow when it doesn't. The best optimization would be to have a separate plot traversal here that checks if any player city is reachable instead of looping through the cities and asking for a path in each separate instance.
how even worse this issue becomes when using "Zone of Control" gameoption and how much influence city bombardment buildings have on this if any?
Thunderbrd
C2C War Dog
I was thinking much the same. However, I wouldn't have a clue how to best go about programming such a thing. I suppose I could get really creative... lol. However, could something already be partially in place for this and part of the problem be that it could be thinking there should BE a way to get through but just can't find it? There's an assert here that words itself in such a way that suggests this is the case.
Very nice to see you AIAndy!
I would think ZoC would make this situation much worse (if that's not a part of this evaluation as it is - I'm not sure if Joe has it on or not.) Doubt city bombardment buildings would have much to do with it because it wouldn't 'deny' the ability to move through the plot.
JosEPh_II
TBS WarLord
No ZOC in that test game. I don't use it normally.
@AIAndy,
Hope life has been treating you well.
JosEPh
@AIAndy,
Hope life has been treating you well.JosEPh
JosEPh_II
TBS WarLord
So where do we stand on release time for v36?
JosEPh
JosEPh
Thunderbrd
C2C War Dog
Quick question: Did we ever address the bit where the firepits that were generated in all cities by the Controlled Fire wonder were all needing rebuilt as soon as the Controlled Fire wonder obsoleted long before fire pits did?
To address Joe's question, I'm going to bite the bullet here and see what I can do about the production and food inconsistencies reported in the bugs thread. But I don't know what I'll find yet. If it will take too long to sort out, release away. Otherwise, give me a few hrs to update y'all on that.
SO's hang bug is taking place on loosing the game and I don't think it's critical, therefore, to the release of v36 to address. If I'm to address it at all I need a save from before the attack takes place that ends the game.
To address Joe's question, I'm going to bite the bullet here and see what I can do about the production and food inconsistencies reported in the bugs thread. But I don't know what I'll find yet. If it will take too long to sort out, release away. Otherwise, give me a few hrs to update y'all on that.
SO's hang bug is taking place on loosing the game and I don't think it's critical, therefore, to the release of v36 to address. If I'm to address it at all I need a save from before the attack takes place that ends the game.
Dancing Hoskuld
Deity
Nothing can be done about that. When the wonder (or normal building) goes obsolete you loose whatever it gave you. I tend to build that wonder just before getting the tech that obsoletes it so don't have that problem
Thunderbrd
C2C War Dog
So you're saying that we want the Captured Fire to obsolete before all the free fire pits would so unfortunately there's nothing we can do to change the captured fire to obsolete when fire pits do.
So... my suggestion would be to remove the free firepit and make the building instead generate an autobuilding that quadruples the output of production when building the firepit or makes the firepit cheaper to build during the time that Captured Fire isn't obsoleted.
EDIT:
We actually don't need the autobuilding as suggested. Just changing the free firepit tag to:
Will fix this in a manner which should be sufficient. This way it makes it easier to build the firepit while the Controlled Fire has been unobsoleted but doesn't then make you rebuild all your firepits once it has.
I'll be committing this change to the SVN but it can easily be reverted if anyone has any gripes with it. I believe it's a good solution to the annoyance factor on that.
So... my suggestion would be to remove the free firepit and make the building instead generate an autobuilding that quadruples the output of production when building the firepit or makes the firepit cheaper to build during the time that Captured Fire isn't obsoleted.
EDIT:
We actually don't need the autobuilding as suggested. Just changing the free firepit tag to:
Code:
<GlobalBuildingClassProductionModifiers>
<BuildingClassProductionModifier>
<BuildingClassType>BUILDINGCLASS_FIREPIT</BuildingClassType>
<iProductionModifier>100</iProductionModifier>
</BuildingClassProductionModifier>
</GlobalBuildingClassProductionModifiers>I'll be committing this change to the SVN but it can easily be reverted if anyone has any gripes with it. I believe it's a good solution to the annoyance factor on that.
Thunderbrd
C2C War Dog
That could work too... But I do like this solution as well. The idea is to make it so you can't build the Captured Fire after a pretty quick point on the tech tree so you'd need to use it or lose it where the golden age is concerned.
Dancing Hoskuld
Deity
I would prefer if you could not get the tech to obsolete it until you had built it. Unfortunately that tag is no longer working. It was in v33 or v34.
Thunderbrd
C2C War Dog
Not sure I understand. You're saying the building shouldn't obsolete until you've built it? That's synonymous with not obsoleting at all isn't it?
I think there's great benefit to Captured Fire obsoleting fairly early because it's best if you try to hold off on trying to build it til as late as you can but then you start risking not being able to at all if you somehow pop a free tech that just happens to be Fire Building (DAMN!!!) and with a build modifier to Fire Pit you also might just want to build it early so you can get those pits build faster and let the thing be more useful for speeding up production somewhat instead of waiting to use it to make the first round of desirable civic adjustments that would otherwise cause anarchy to get you through the revolution without delay. (What I find is truly the real use of this wonder - that and rapid city growth to get an early edge if timed properly.)
Dancing Hoskuld
Deity
No I am saying the you should not be able to learn the tech that obsoletes the building until you have built the building.
edit On the Tech XML tags PrereqBuildingClasses and PrereqOrBuildingClasses
edit On the Tech XML tags PrereqBuildingClasses and PrereqOrBuildingClasses
Similar threads
