[Freeciv-Dev] Re: (PR#8852) savefile positions should all be native

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

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



Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8852 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>Map positions are the core way to transmit all coordinates and the default
>>arguments for all functions. These are always he default for such parameters.
>>
>>Natural should *never* be used except in specialized local settings, and
>>even native that are the main form for save games and such usage are
>>probably not appropriate in this case.
> 
> 
> Ross, you were the one who originally pushed for the map to be stored in 
> native coordinates, remember?  And you were right.  Map coordinates are 
> unintelligible to anyone looking at a savegame.

I thought your were discussing changes to starting positions, and not map
savegames. The two are not the same, and one should carefully look at where 
they arise if you want to change this.

I don't think conceptually pushing starting positions down into the savegame 
layer that would make them native is worthwhile. I think they are used as 
map elements on their own, i.e. as another input element like a map, a rule 
or whatever. But if you can workup a framework in which starting positions 
are only used in a savegame context and never need to be exposed as map 
coordinates, then making them native is fine. I think this is not he case 
though in all the current usage.

>>>So the remaining map positions should be converted to native.
> 
> 
>>Don't fix things that aren't broken and propose an RFC for discussion of 
>>significant changes to things that have backwards compatibility and many 
>>other ramifications.
> 
> 
> But...
> 
> 1.  They are broken.  Savegames are quite unintelligible with mixed 
> positions.  They are also unintelligible with map positions.

Your hangup with presentation level concepts polluting core elements is 
making things difficult. Please try to understand the subtle difference 
between native coordinates and where they are used, and GUI or presentation 
level concepts and where they need be used.

Trying to add arbitrary user perspectives to core elements while perhaps 
useful in some cases to the developer, should never be the overriding 
concern in cases where one is trying to build a simplified core standard 
that can be incrementally extended. The point at which presentation and core 
occurs is the native/natural boundary with map part of the core and in fact 
the one common core element that all other coordinates should convert to and 
from. Thus there is at most a double conversion step between any two 
coordinate types and it can always use the standard transformation functions 
to do this.

> 2.  A patch is a request for a change.
> 
> So my question is, what is your suggestion for fixing this?
> 
> One idea I had was that the savegame could specify what type of 
> coordinates it used.

No!  Always store savegames in native coordinates where the actual form of 
the native *is* topology specific and coded for core storage efficiencies 
and other considerations such as a compact rectangular debugging view of the 
map. It should *never* be stored in user presentation forms like natural, 
and we have already gone through the bounding box issues with map forms to 
exclude them.

> [map]
> coordinates="native"
> 
> Where "native", "natural", or "map" is specified.  A single function 
> could then be used for loading tile positions, in whatever coordinate 
> system is specified.
> 
> The only real advantage I see to this is that it can work with imported 
> savegames that use a different coordinate system.

This doesn't make sense. Try rewording for my mental limitations ...

The main use of savegames is to store compact information that doesn't keep 
overflowing Ranier's servers, not giving users and certainly not developers 
pretty GUI views.

> jason

Cheers,
RossW
=====