On Tue, Apr 02, 2013 at 03:27:26PM +0300, Marko Lindqvist wrote:
> On 2 April 2013 12:53, Emmet Hikory 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.
Towards extras, I was thinking that move_cost would be a extras_class
attribute, and that one would set a very high value (e.g. 99) for things which
would be implemented as bases on current trunk, or similar (because 0 is
a valid move_cost value, so can't safely be used as a boolean check).
Depending on what other attributes might be easily considered shared, I
would expect several extras_classes to be used for the current rulesets.
Although this may reduce the volume of data entry for individual extras,
I certainly agree that it raises the bar for ruleset authors, and may
cause unnecessary confusion or reduce accessibility.
I'll go with the bitvector for this then, and thanks for the pointer
to cache code to make it not terribly expensive. To make sure I understand,
one would iterate over the road types, and then iterate over the (presumably
smaller) bitvector of identified compatible roads in map.c, and would
populate the cache bitvector in ruleset.c when loading the ruleset,
which precached values would be sent to the client in the road packet (no,
this isn't quite the same as hiders, but this needs to also be available
on the server for the AI).
> > (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.
Thanks for the hint. I'll try to find a way to model what I want
without these sorts of details then. I suspect I can do a lot with
judicious use of UCF_TERRAIN_SPEED (as in the experimental ruleset, where
Settlers and Trireme have the same movement on Rivers).
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
