[Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet

["Baumans" <baumans@xxxxxxxxxxxxx>]

----- Original Message ----- 
From: <rwetmore@xxxxxxxxxxxx>
To: <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, July 28, 2003 6:13 PM
Subject: [Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet


> The third option has no disadvantage except in certain religious mindsets.
>
> Jason Short wrote:
> > rwetmore@xxxxxxxxxxxx wrote:
> >>Jason Short wrote:
<snip>
> > The options are:
> >
> >    if (!is_normal_map_pos(x, y)) break;
> >
> >    if (!normalize_map_pos(x, y)) break;
> >
> >    if ((x == 255 && y == 255) || !normalize_map_pos(x, y)) break;
> >
> > The first has the disadvantage that client must send only normal
positions.
> >
> > The second has the disadvantage that it's just plain wrong under torus
> > topologies - (255,255) will pass the test since it is a real position.
> >
> > The third has the disadvantage that if the client actually sends any
> > non-normal positions you'll end up with buggy behavior: eventually
> > they'll send (255,255) and have their goto route prematurely terminated.
>
> No disadvantage ... (-1,-1) has always been a special case, and can
> certainly continue to be one in the future.
What if the client sends (-1,-1), in the torus topology?  The server can't
tell what this means: is it supposed to terminate the route or go to the
normalized (-1,-1)?  The only way it can know what to do is to require that
the client not send (-1,-1) except as a special case, and we're back to
restricting the client.  (-1,-1) used to work because that never used to be
a real coordinate.  This is also applicable to (255,255).

You cannot deal with this in the server.  If you want to deal with it in the
client, why don't you just normalize?  The only other option is to hope and
pray that this never comes up.
>
> It has *no* impact on any  other normalization issues as long as you deal
> with it first, i.e.before applying some generic normalization. There is
> nothing buggy in normalizing any other coordinates as they are not and
> have never been special.
>
> The only *bug* is a religious issue about treating special cases as
> special cases - but that is just the way life works sometimes :-).
>
> > IMO the first choice is undisputably the best.
>
> I know, you always insist on restricting client behaviour as the solution
> to the server problem. It is neither necessary nor advisable.
>
> > Of course, there is a
> > fourth choice: adding an additional is_valid flag (to network code and
> > internal storage) to mark the special case.  This has been discussed and
> > rejected in the past, but personally I'm not opposed to it - it makes
> > the logic cleaner but the code lengthier.
>
> Redefining the special case for bad coordinates is an option. There is no
> real good solution here within the existing coordinate space and thus one
> needs an extra flag. This is also a lot of code change for something that
> is not required as making an existing coordinate special has always been
> the valid solution and still is.
>
> > jason
>
> Learn to live with coordinates that are real or unreal, and don't be hung
> up on the artificial condition of normalness that is neither well defined
> nor particularly useful in most technical situations.
>
> Cheers,
> RossW
> =====
>
>
>
>
>