Follow-up Comment #3, patch #4639 (project freeciv):

    That depends on what is considered a regression.  While it would be better
than what is in place now, it would not be as good as what was in place before
integrating roads.  For purposes of example, let us categorize paths for
simplicity into "road" and "railroad", where "road" is a dependency of
"railroad", and different terrains have different values of "road" and
"railroad", and all "road" paths integrate, and all "railroad" paths integrate
(which is handy because it grants per-terrain build-time without using a
single hardcoded per-terrain road_time value).  So, in the event that a
autosettler is considering a path that has no continuous adjacent terrain,
failure to consider the dependencies of an integrating road will differ from
the pre-integration behaviour (because potential_road[] would be false, as the
"road" for the starting terrain would neither integrate nor be a dependency
for a "railroad" under consideration).

    I've been thinking about this more, and suspect that the algorithm is no
longer able to handle the flexibility of the current ruleset definitions.  As
another example, assume there are two kinds of road, "road" and "railroad",
which do not integrate, if "road" may be built on any TC_LAND terrain, and
"railroad" may be built on any non-mountainous terrain that has a "road", the
current algorithm will grant overly large bonus for building railroads near
mountains, as it will never notice this is impossible (or maybe the example is
less complicated if one can't put railroads in jungles, because of the
interaction with production bonuses).

    Also, with complex nativity, and road nativity, there are other factors
involved in generating connectivity: if a settler could build either roads or
canals, where roads were slightly faster for some unit classes, and canals
provided native movement to other unit classes that were previously non-native
to the tile, which is better?

    Although it does provide a regression, perhaps something like the
following makes sense as a replacement (ignoring caching optimisation, etc).

Iterate over all tiles adjacent to the given tile
    Iterate over all roads integrating with the given road
        If the integration road can ever be built on the iteration tile,
            If any dependency road of the iteration road exists on the
iteration tile
                       OR any dependency road of the iteration road is being
built there
                Iterate over all unit classes
                  /*target tiles are adjacent to given tile and non-adjacent
to iteration tile*/
                  If creating the given road on the given tile allows a unit
class to
                                                                              
                  reach a target tile better/faster
                    increment the bonus
multiply the bonus by a magic number (3 seems reasonable)
divide the bonus by the number of unit classes in the ruleset

    This should handle the nativity situation (the magic number is used to
reduce the number of bonuses that fall to zero because of unaffected units
(e.g. sea/air).  As a bonus it clears up the messy undocumented mess (with
some apparent transcription mistakes) that is the current guidance model.

    A more advanced solution would somehow use pathfinding to determine
whether adding the given road to the given tile generally improves
transportation flexibility for that player's units (to reduce e.g. 0-cost path
loops, etc.), but that probably belongs in another ticket (and may represent
unacceptable computational cost).

    _______________________________________________________

Reply to this item at:

  <http://gna.org/patch/?4639>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to