hackedpassword
commented
1 year ago Save Data:
Closed hackedpassword closed 6 months ago
hackedpassword
commented
1 year ago Save Data:
hackedpassword
commented
1 year ago I built a wave of new workers. They're heading to oasis's, building roads, railroads, then removing them. Nearly all the oasis's in my empire are full of very confused workers.
SomeTroglodyte
commented
1 year ago Nearly all the oases in my empire are full of very confused workers.
Sounds like a good thing, or maybe a techno party going on?
But seriously, I believe one part of this (Road removals seen as positive improvements) is a compound result of one generally positive code change unintentionally exposing a weakness in older code - which the author of the older code might have seen as obvious that "junk" would fall through unprocessed..
@yairm210 - in WorkerAutomation.chooseImprovement (L362+), for the "Remove Railroad" pseudo-Improvement
potentialTileImprovements but probably shouldn't be, as the rest of the function deals only in the actual improvement field, no relation to road field.Automation.rankStatsValue(bestBuildableImprovement!!, unit.civ) was 0 before fun getRankingWithImprovement was introduced, and getRankingWithImprovement now returns 1 -> the 0 before caused it to be shunted out of consideration, which is no longer the case.But the really interesting question would be - why do the partygoers not try to close the gap in the rail line just east of Delhi at (-22,-9) or (-23,-10)?
SomeTroglodyte
commented
1 year ago ... (close the gap) ...
That's likely explained up early in automateWorkerAction - if findTileToWork erroneously delivers oases, getPriority will be 5 and tryConnectingCities will never run.
Any coder can verify? I'm not the Automation guy, I was just curious and reviewed code, no testing.
SomeTroglodyte
commented
1 year ago Oh, I forgot - only affects oases where the owning city has a Hydro Plant, thus the +1 seen as in favour of the remove "improvement", tripping the ranking...
SomeTroglodyte
commented
1 year ago Another thing(s):
if (getPriority(tileToWork, civInfo) < 3) test, since any improvable and owned tile will always be >= 3, will prevent tryConnectingCities from being run far too much, I see no fuzzy logic allowing for a decision that maybe connecting cities could be more important than building farms on desert... Or at least my weak brains reads it that way. Combined with last point - explains a lot.SomeTroglodyte
commented
1 year ago .. and shouldn't reading TileImprovement.isGreatImprovement,isRoad,isAncientRuinsEquivalent tickle a little in view of the recent "Lazy" discussion? I'm not as good as y'all at measuring performance ..
hackedpassword
commented
11 months ago Didn't see any mention to a pull request. Probably closable?
github-actions[bot]
commented
6 months ago This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days.
SeventhM
commented
6 months ago Can someone confirm if this has been addressed?
hackedpassword
commented
6 months ago Confirmed.
Build 856 Android Mod: Unciv Rework
For an unknown reason, automated workers are building roads when that option is off. More peculiar is that they're only building them only on oasis tiles. Once a road is built, they build a railroad on it. I'm having to de-automate them, deconstruct the roads, send them elsewhere otherwise they'll go back to building more. Replace improvements is also turned off.