Different tiles acquiring logic for different civs?

[infidel88]

Is that even possible? I always find it weird when wood/jungle based civs get coast tiles acquired by cities before forest

 

[notque]

It's possible, i think the question is it worth it.

 

[ExpiredReign]

Another odd thing is when there's a tile you want but it's behind a mountain, the automatic selection almost never acquires the mountain and then the tile you want, seems like I always have to manually buy those sort of tiles.
Again, is it worth looking into the code for that? I'm not sure.

 

[matlajs]

question is, why some cities, if they have resource in reach, will not acquire them and some do it. first i thought cities acquire tilles ,, in ring''. i mean first they acquire all tilles in second ring, than third etc. but some cities just acquire one tille in second ring and imediately go for resource in third, often it works for starting cities.

 

[Strigvir]

Automatic tile acquisition logic only takes in account the base terrain yields.

 

[infidel88]

but puts food ahead of production or what? how come 2f coast is more attractive than 1f2p forest?

 

[Enrico Swagolo]

but puts food ahead of production or what? how come 2f coast is more attractive than 1f2p forest?

It doesn't put food ahead of production, it's just insane

It never goes towards an atoll despite it being better at everything than Grassland, same with a Lake. Or Marsh. I don't get how it works.

It also seems to prefer going towards bonus resources and strategics than luxuries, but sometimes it doesn't? I don't get it.

 

[ilteroi]

unfortunately the code to determine which plot is the next one to acquire is one of the worst pieces of code i've ever seen. it seems to work most of the time, so i'm loath to touch it but here are some of the constants which go into it. if you want to experiment, go ahead and change them in the database.

base cost (determined by pathfinder, aggregated from city plot)
INFLUENCE_RIVER_COST()
INFLUENCE_HILL_COST()
INFLUENCE_MOUNTAIN_COST()
pTerrain->getInfluenceCost()
pFeature->getInfluenceCost()

additional per-plot constants added afterwards:
iPLOT_INFLUENCE_IMPROVEMENT_COST
iPLOT_INFLUENCE_RING_COST
iPLOT_INFLUENCE_ROUTE_COST
iPLOT_INFLUENCE_NW_COST
iPLOT_INFLUENCE_YIELD_POINT_COST
iPLOT_INFLUENCE_NO_ADJACENT_OWNED_COST

least cost wins.

 

[Gazebo]

unfortunately the code to determine which plot is the next one to acquire is one of the worst pieces of code i've ever seen. it seems to work most of the time, so i'm loath to touch it but here are some of the constants which go into it. if you want to experiment, go ahead and change them in the database.

base cost (determined by pathfinder, aggregated from city plot)
INFLUENCE_RIVER_COST()
INFLUENCE_HILL_COST()
INFLUENCE_MOUNTAIN_COST()
pTerrain->getInfluenceCost()
pFeature->getInfluenceCost()

additional per-plot constants added afterwards:
iPLOT_INFLUENCE_IMPROVEMENT_COST
iPLOT_INFLUENCE_RING_COST
iPLOT_INFLUENCE_ROUTE_COST
iPLOT_INFLUENCE_NW_COST
iPLOT_INFLUENCE_YIELD_POINT_COST
iPLOT_INFLUENCE_NO_ADJACENT_OWNED_COST

least cost wins.

Fairly certain that code was written as part of a 'get kids to code' contest at an elementary school.

G

 

[notque]

I've edited it before, and it works. The problem is I didn't enjoy it anymore with my changes, and left it alone. If someone wants, I can set it up given some criteria, test is, and make sure it functions as intended. It just didn't impact things in a way that was meaningful to me. Remember, all the AI are going to get the same changes, and it ended up just being more annoying if anything.

Some times the annoyance you're used to is better than the one you have to relearn.