[Freeciv-Dev] Re: (PR#8632) Easy way to set map size with auto ratios (seteables if desired)

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

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



Marcelo Burda wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> 
> Le jeu 03/06/2004 à 09:16, rwetmore@xxxxxxxxxxxx a écrit :
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
>>
>>
>>Ratio is a bad concept that leads users to expect things they cannot get
>>and the idea that this is a good way to give a map shape is misguided.
>>
>>The exact numbers of rows and columns in a map are dependent on a number
>>of wrapping constraints and other low level details the end user also should
>>not be aware of other than in ways in which they might change parameter
>>input by adjusting an x or y value up or down a few counts. Fixups like
>>this to user input need a simple informative message under non-verbose
>>or information message category.
>>
>>The map view is a standard X x Y grid. Thus this is the simplest set of
>>parameters to define it, has been considered just hunky dorey as the
>>definition of ROWS and COLUMNS in TERM definitions for a dog's age, and
>>means that complex math for computing rations to get back to this level
>>of simplicity for grade schoolers is not required.
>>
>>Using simple parameter selections/defaults (e.g. 80x50) for standard maps in
>>the non-advanced section of user input is fine and having a "bigger/smaller"
>>button that allows one to choose a number of sizes with similar but adjusted
>>shapes is also fine, but having the user say they want a map of 100 tiles with
>>a ratio of 1.6 is just not a usable concept, and was never from its earliest
>>inception, as has been stated before.
>>
>>This should be considered a showstopper fixup.
>>
>>Cheers,
>>RossW
>>=====
>>
> 
> hmmm. i understand your points
> player are only asked, and player only ask, to set a size. little,
> medium, big. that is the base concept. i think the size option is well
> done.
> set size 1: is a very little one and set size 30 is a very Huge one. 7y
> old concept.
> 
> xsize and ysize are unneeded. and show simplest only if map as not ISO
> coordinates. For iso coordinated this need to by hard corrected to get
> the users want,  
> if your really want set this info then we need to ask for natural size
> and not for natives. to get the desired map. (but probably surprising
> small)

Incorrect. xsize and ysize refer to native coordinates and are the 
underlying dimensions of the map as stored. This should remain.

Natural *might* be used as user input in a dialog, but get converted to and 
stored as native for all internal use. But I think that native still makes 
more sense for the rectangular GUI window that the user is describing and 
will be more consistent across different types of maps. But if confined to 
the input dialog, it is not a big deal to have a lot of confusing natural 
flavours for different parameter coding to fold in as new topologies are 
added. But the underlying storage system *must* be consistent and follow 
standard rules across all the topologies.

Note a polar topology should still store xsize,ysize native dimensions even 
though the topology has 100 rings of increasing squares.

> if we make maps with a another shape (as a hexagon map) this info is
> really bad.

I agree, natural is bad. That is why native exists and is specifically 
chosen in each case for internal and not GUI reasons.

> then i think a size variables in the only really good one.

Wrong. It has the wrong number of dimensions for a 2D map for a start. I 
think you need to understand the logic of native which solves all these 
problems if you use it as designed, rather than trying to reinvent it in a 
broken way for your specific case.

> about ratio this can be more difficult.
> 
> the best way to allow player to create a no default map is with a
> boutons and a preview windows where players can view the ratio. but this
> is a little too much work. probably this will be done. latter.   

The best way is to hardcode the default dimensions in a copy of the standard 
structures that is presented as needed with the standard GUI dialogs just 
like when filled in or changed. The same values can be added as rules that 
overlay the hardcoded ones if present. The  user then gets to update these 
as desired where allowed, or by changing parameters that cause multiple 
changes to take place under program control (wizard rules for naive users).

> yes the code is a complex.(this only need to be writed one time, and
> this will never see by users) but not the concept. any body know about a
> 16:9 ratio of newer TV. or about 4:3 ratio of classic ones. this is not
> a so complex concept. and this is only wanted to creator, not to
> players!
> players are asked to not touch this option. and this option is put in
> internals not in geology to avoid this.

ROWS and COLUMNS is much clearer and involves less math or mental strain. 
Since this is the current Freeciv system, There is no reason to change it 
and risk new bugs or other maintenance issues.

> i want think as you, but i not like at all the xsize and ysize for
> players. that are really bad information.
> size are simple.
> ratio not so simple but exact. and players are not so stupid. (i think!)

But this is not for players, but coders as you say, it is hidden. That it 
should be not only hidden but abandoned completely as it adds only a 
different but in many ways unusable perspective is the next step.

Go back and understand the current Freeciv standards for this and do not 
seek to change them or fold in presentation or GUI concepts that should not 
be mixed with core mechanics of incremental topology development.

> Marcelo

Cheers,
RossW
=====