[Freeciv-Dev] Re: (PR#7287) Extended Topologies

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >


Marcelo Burda wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
> 
> Le ven 20/02/2004 à 00:35, Jason Short a écrit :
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
>>
>>Marcelo Burda wrote:
>>
>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
>>>
>>>Le jeu 19/02/2004 à 22:48, Jason Short a écrit :
>>>
>>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
>>>
>>>>Next, I'm not happy with the xsize/ysize/size/ratio setup.  If you
>>>>change the xsize nothing happens, and you can't figure out why.  At a
>>>>minimum the user needs an error message here.  (This is also something
>>>>that should be its own patch.  I'm not convinced that we need this.)
>>>
>>>me too
>>>i thinck the best is no more set xsize and ysize directly but only 
>>>ratio and size.
>>>this way init_topo make maps whit desired ratio and size but make good
>>>xsize and ysize for all topologies, some topo need even numer on
>>>[xy]size and some times ysize need to be ysize % 4 == 0.
>>>this is the work of init_topo and set_ratio in map.c

I think the best way is no ratio or size but only xsize and ysize.

This is what the user understands, and the rest is decidedly user
unfriendly noise, at a level of understanding they should never be
required to know or understand.

There is no reason why the init() routine cannot correct the values
for a given choice of options and present a message to the user as
this is done - "Changing ysize to even value YY to support ISO wrap"
or some such flavour.

[...]
>>>>The topology_id isn't fully explained (in "help topology").  What are
>>>>topologies 5-15?  Why don't we have 22-31?
>>>
>>>the problems is you kep ISO-map option in topology_id, iso-map need to
>>>be a separate option an not a bit flags of topology_id.
>>>for me topology_id is a list of selected topologies, first the
>>>cartographicals ones(flat, cylinder,quincuntial) then some ScFi(exotics)
>>>ones Torus,Mobius, etc.
>>>but the ISO_FLAG break it
>>
>>It's just another bit; it shouldn't break anything.  Just make sure you 
>>use appropriate masks.  We may later add a HEX_FLAG for hexagonal tiles. 
>>- this will probably go into the same bitfield.
>>
>>I'm not opposed to making these all separate values, but we decided 
>>before not to do it that way.
> 
> Some things are best as flags others as index. topology_id is a good
> name for the last usages, i propose a separate topology_options
> HEX_FLAGS and ISO are one type of topology flags, this modifie the
> neghiboard realtion of tiles. this 2 flags are good for topology_options
> and can be used with all of wraping-topologies indexed in topology_id. 
> 
>>jason

There is no reason for the topology id to be a dense set of indicies.

There is also no reason for assuming topology bits must always cross
multiply to produce valid topologies.

There are ways to organize the bits to increase the density with some
bits being bitflags and others being indicies into an enumerated subset
of orthogonal properties. This should be outlined in an RFC and documented
in the code. But all of this is implementation and should never impact the
user view of things even if it is completely rewritten down the road. In
this respect the user should probably see something more akin to Marcelo's
dense set of indicies as a list of descriptive names with perhaps some
optional ranges for some properties that reduces the namelist somewhat.
If the list is enumerated with a counter or letter as a shortcut, this
counter need not bear any relationship to the underlying topology id, but
just be a convenience tag in the dialog.


Having said that, it does not seem to me that there is any reason not to
have square, ISO or HEX tilesets as the underlying grid for any of the
current 8 wrapping topologies or quincuntial and any of the newer wraps.
Until the new stuff supports at least the current two tileset flavours
it is not complete. Put differently, the ISO_FLAG and topologies Jason
is looking for are not the breakage, I think the incompleteness of the
new stuff is.


Cheers,
RossW
=====