[Freeciv-Dev] Re: (PR#9496) PATCH: Clean up on set-ratio

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

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


The original code allowed one to define a FlatEarth scenario map
with dimensions 3x53 if so desired. This might be used with a
"try to take city X in 5 turns". I do not see how you can now do
this and thus the new code is broken.


Fixups for topologies must be topology specific. Thus introducing
a NS or EW wrap would force a change in the above, as would an iso
or hex requirement if that was also a choice. But the change for a
hex map should not impact any other type. Thus any comment about
what a future topology might require is appropriate only when one
gets to that stage, and should be irrelevant to the current set of
topologies and their limitations. If you have not properly broken
the system down into the levels of abstraction necessary to do this,
then please think things through again. Topology specific fixups
need to be applied per topology, and not globally. This has been
stated as one of the key concepts which a global ratio violates and
muddles.

The system should work as follows:
1)  It should have hardcoded defaults that work for all maps if the
     system/ruleset/user does not further specify anything. This means
{xsize,ysize} values for each defined type and nothing else.
2)  Selecting dimensions or topology types/features should cause the
     appropriate limitation checks/fixups for those changes to be run.
How the new dimensions are input or pre-massaged is a UI issue which
may be topology dependent, may be UI dependent and should be handled
at the appropriate (local) code level. Thus if the {xsize,ysize}
dimensions are collected by a size UI dialog (i.e. big/normal/small)
or reset in a context that needs fixups, the appropriate fixup code
should be run to correct anything at the appropriate topology-aware
level.
3)  At some level of verbosity, the user should be informed of both
     the final map dimensions, and any changes/rationale made by fixups.

One can introduce "aesthetics" in fixups like rounding up, or choice
of super-even granularities on a per topology or other basis with
appropriate rationale that has limited impact on maps in general with
any argument constrained to just the needs or common usage patterns of
a topology in question. Note that for a scenario as above switching to
a hex or iso map would be a "different" scenario which may or may not
be recognized by the scenario developer. Printing the warning message
when making a topological fixup should alert one to the difference.
What is meant by this, is that scenarios with ambiguities/incompletely
specified parameters might look complete, but in reality have some
fundamental differences that make them really different. Getting the
conceptual model right for what one wants to do is critical to making
it clear what can and cannot be done, and what is implementation and
UI presentation vs what the core concepts and low-level parameters are
that one is dealing with.

The code is not far off getting it technically right in many spots, but
I don't think it really displays the correct requirements and conceptual
model yet and thus is still presenting the wrong picture and building
things in wrong directions.

Cheers,
RossW
=====

Marcelo Burda wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=9496 >
> 
> Le dim 25/07/2004 à 11:19, rwetmore@xxxxxxxxxxxx a écrit :
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=9496 >
>>
>>Ratio is *not* a fundamental or worthwhile concept and just leads to
>>an endless set of these sort of problems. As has been stated from its
>>initial proposal, it should not be included in any Freeciv code. At
>>most there may be some dialog that is totally different from the
>>rest of the game concepts that wants to use it. Certainly low-level
>>code like map.c is not an appropriate place for anything but the
>>fundamental definitions of the low level window {xsize,ysize} with
>>appropriate topology restrictions like even and odd row limits from
>>wrapping constraints.
>>
>>Please see these are removed from the patch code and replaced with
>>something closer to the original layering of core and GUI/user needs,
>>i.e. the ratio concept *never* appears as pollution at this level and
>>is cleanly separated into something fundamental and UI oriented with
>>the code placed accordingly.
>>
>>Cheers,
>>RossW
>>=====
> 
> Ups! i think make the code and comment more clear and we go to these
> pseudo pollution concept!
> First, i am not solve any type of problem! accuracy on size for a size
> one map is not very important,  more there are absolutely uninteresting.
> if i improve it this is i can easy improve it.
> instead to 80x50 i get 78x52, not a problem!!
> I am unable to create a more easy way to set well defined map.[xy]sizes
> than 
> 
>>set size 7 (a sample)
> 
> this is all of a user need to known, set size 1 very small, set size 29
> very big.
> Can you do best?
> the topologies restriction need to be well done to avoid future bugs,
> set-ratio do it(maybe set_sizes is a best name), this way we can assume
> sizes are all the time good ones. some math can be easier this way.
> The original code was a lake on it, no initialize topology concept
> existe before adding init_topology and set_ratio. Go back to these 
> times are a wrong idea.
> 
> I understand your, maybe you not like news topologies in freeciv and
> this code are needed for this. But allow us to love these news ideas we
> try to make it the best way. but we are doing it anyway.
>  
> Marcelo
> 
> 
> 
>