Matthias Pfafferodt <matthias.pfaffer...@mapfa.de> writes:
> Am Saturday 10 October 2009 09:54:26 schrieb Goswin von Brederlow:
>> Matthias Pfafferodt <matthias.pfaffer...@mapfa.de> writes:
>> > Am Thursday 08 October 2009 01:43:23 schrieb Goswin von Brederlow:
>> >> On a related matter, how does migration work with the patch?
>> >> The patch says the city radius is considered. Does the other city need
>> >> to lie within the city raidus? Do the city radius of both cities need
>> >> to overlap? Can there be a gap of <x> tiles between the city radii of
>> >> both cities?
>> >> I think the migration distance config option should select this, e.g.
>> >> -99: city must lie within city radius
>> >> -x: city radii must overlap
>> >> 0: city radii must touch
>> >> x: there may be x tiles between city radii
>> >> I think a default of -1 would make sense.
>> > At the moment migration is defined by a migration distance (1 to 7). The
>> > patch #1232 adds the possibility to set the migration distance to 0. In
>> > this case, the migration distance depends on the city radius (migration
>> > distance = city radius + 1; your case 0).
>> I will definetly want to have more choices there.
> The migration distance setting could also be defined as the value added to
> current city radius. This would require a change of the current definition
> (name). Example:
> city_radius_sq = 5 => city_radius = 2
> mgr_dist = 2
> max distance for migration (tiles) = 2 + 2 =4
> city_radius_sq = 10 => city_radius = 3(.1) = 3
> mgr_dist = 2
> max distance for migration (tiles) = 3 + 2 =5
Yes, that is along the lines of my though.
Defining max distance for migration (tiles) = radius1 + radius2 + X
would make things more difficult I guess. radius2 won't be known so
you would have to assume the maximum, scan for cities and then check
if their radius is big enough for migration.
But just radius1 + X should be easy to code.
>> > As for the migration one has to check all tiles within migration radius
>> > of the receiving city for giver cities the radius should be as small as
>> > possible.
>> If checking the tiles is too expensive then cache the result:
>> When creating a city check if it is within the migration radius of
>> another city and link it into a migration list for that city. When
>> the city radius of a city changes (and therefor migration radius) then
>> scan the area once to rebuild the list.
> This list has to be updated every time a city is created or destroyed.
> Furthermore it would spread the code needed for migration over a lot of
> files. At the moment it is mainly in one file.
Actualy I thing something like that is already needed. The road/rail
building AI currently has no notion of connecting cities, only
adjacent tiles. With city_min_dist raised that performes really bad.
If a city knew the surrounding cities the auto-worker could build a
road on a line between two cities.
But a lot of AI code needs a fresh look and redesign I feel.
>> But is it too much work? If I understood migration right then it is
>> done only once every 5 turns.
> That's right. Migration is checked every fifth turn after a city was founded
> (default settings).
> Does the variable city radii work for you?
Seems to work great so far. I'm not sure the plague settings are fine
tuned yet though. I have a large food box and cities always get plague
before hitting size 12 an requiring a Sewer System. The plague
effectively obsoletes the size 12 limit except when migration happens
a lot and the city shoots up. Not sure if that should be that way.
My biggest city is size 17 so far. I will have to see if the plague
allows the city to grow to size 30 at all.
Freeciv-dev mailing list