<URL: http://bugs.freeciv.org/Ticket/Display.html?id=39845 >
Jason Dorje Short wrote: > A triple-loop is also rather tedious (possibly too slow with a very > large number of old cities in the game). A simpler loop is possible if > we make border assignment context-based and impose the restraint that > borders can expand only one tile per turn. > Four (4) passes over the number of tiles, instead of one (1) pass over the cities? That's tedious? This is some new use of the word "tedious". What I found tedious was trying to read 900+ ->owner uses (in two branches simultaneously) to find the ones that were assignments instead of references.... In the computing point of view, by definition the number of cities is always less than the number of tiles, by orders of magnitude. The context-based borders are not "simpler" in any computational sense, because the execution is data dependent and therefore harder to debug! > iterate all tiles > iterate adjacent tiles > look at the owner source > mark tile for reassignment based on the highest factor > iterate all tiles > assign/reassign tile as marked > Wow, that's both slow *and* data intensive (another temporary variable per tile per player). But not as bad as the current code doing the adjacent tile search twice! > The hard question is what to do to a unit/fortress/city when the tile > under it gets reassigned. This part will end up being more coding > (though less argument) than the borders changes themselves. > No new code necessary. A unit reassigned converts to the new owner, attacks, or leaves. An occupied fortress cannot be reassigned. An unoccupied fortress has no border/vision of its own. A city cannot be reassigned. It *should* be able to be "converted", by proximity to a superior civilization, at which time it self-reassigns. > As a side note, I do think context-dependent borders are more stable > than context-independent ones. For instance with the above algorithm if > the factor (culture) formula was changed when you loaded an old game you > would find that borders changed to match the new formula, but did so > over several turns. > The context save first occurred in 2.1.0 two weeks ago, so there's not much in the way of "old" games that change over several turns. Any other savegame has to start from scratch. Vision in fits and starts with little carved out discontiguous blocks (see the picture) just isn't workable (and is annoying in practice). And I actively dislike the idea that buggy savegames won't be fixed until some gradual and unpredictable evolution.... That's what I'm trying to redesign. _______________________________________________ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
