On 2 April 2013 12:53, Emmet Hikory <per...@shipstone.jp> wrote:

>     So, the solution would be to have some road compatibility check in
> map.c:tile_move_cost_ptrs().  There are two methods to do this in the
> ruleset that seem to have precedent: either define the road_class concept,
> and have all roads that belong to the same road_class be compatible, or
> to have an "integrates" field that takes a bitvector of roads with which
> the current road is compatible.  The former is less expensive in terms of
> the necessary operations in tile_move_cost_ptrs() (because we can iterate
> over the road classes, and then only iterate over members internally
> when checking nativity, rather than having to recursively iterate all
> the roads for roads*roads operations), but the latter may be more
> comprehensible to ruleset authors (because it looks just like so many other
> lists in the rulesets, and there are no new concepts involved).

 Either is doable, even with quite clean SW architecture, but for casual
modder relations of different entities might get a bit too complicated if
we mix 'extras' and 'road class', which would be used with some extras
(roads) only. To avoid bitvector solution being computationally expensive,
cache similar to what road drawing already uses for "hider" roads,
constructed ruleset loading time, should be implemented.

> (I'd really like something that
> let different unit classes have different move_costs for the same road,
> but haven't figured out any sane way to do that)

In the past that kind of tables for having separate values for every
combination have been rejected on basis of being unnecessary detailed for
the resolution of the freeciv. That's more like Wesnoth's realm.

 - ML
Freeciv-dev mailing list

Reply via email to