[Freeciv-Dev] Re: normalize_map_pos and invalid map positions

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Tue, 13 Aug 2002, Ross W. Wetmore wrote:
> Normalize_map_pos() is the swiss army knife for coordinate testing.
>
> It returns false if the coordinate is unreal - generally terminal error.
>
> It returns true and a valid normalized coordinate pair otherwise. This
> may involve normalizing the coordinates in the process but that is always
> possible if they are real.

> This should be used at all portal points, i.e. places where you should
> check for unreal coordinates. This includes source creation, network
> input points or any place where one might want to check for corruption
> of any sort, or even just a change in the definition of "normalized".
>
> In some cases it is better to use unnormalized or differently normalized
> coordinates for a given operation. In this case one would normalize before
> handing off such coordinates to more picky code outside of this module,
> or do it on input to any module that might receive such coordinates.

> This should always be the case. It doesn't hurt to fix things up and
> continue in any situation, and a few judiciously placed checks like
> this will be useful to catch the unreal cases which are terminal.

> So even the big reason for normalizing everywhere is not really that
> sensible with truly generalized topologies.

So what you are suggesting is that normalize_map_pos() is used at the
lowest level where coordinates are generated, changed or received from the
client, and that the the higher level functions receive properly
normalized map positions which are checked with is_normal_map_pos().

Right?

Obviously we should not use normalize_map_pos() in high level code that
should receive normalized coordinates, since it could receive real,
non-normalized but completely wrong coordinates, and passing
normalize_map_pos() over them would make them even more wrong by
normalizing them, and it would return TRUE, suggesting that coordinates
are okay.

> >example: a unit at (0,0) is ordered to move "northwest" by:
> >a) the server (by proxy of the ai)
> >b) a remote client.
> >
> >What should ideally happen in a general topological framework?
>
> If you normalize the position before handing it off and it comes back
> something other than (-1,-1) you don't need to worry. Since you can
> choose the soft condition of normalization in any way you like, this
> should almost always work - I can't think of a case where it wouldn't.

Uhm, shouldn't the dir function that returns the coordinate for northwest
from (0, 0) return a _normalized_ map position? Then both coordinates
should be >= 0, no?

> If your topology wants to define the value (-1,-1) as both real and
> normal

Now you lost me again. I thought a normalized map position by definition
would be "unwrapped" and always refer to a square map (x1 >= 0, y1 >= 0)
to (x2 > x1, y2 > y1) in size.

But a negative map value can be normal?

Yours
Per