Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2003:
[Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#4594) topology fix for goto route packet
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Sat, 13 Sep 2003 08:39:15 -0700
Reply-to: rt@xxxxxxxxxxxxxx

Mike Kaufman wrote:
> On Fri, Sep 12, 2003 at 07:45:37AM -0700, rwetmore@xxxxxxxxxxxx wrote:
> 
>>Under the current system this is the defined invalid coordinate. Unless
>>the specific codepath has been overridden to accept and deal this case,
>>the move request should fail.
> 
> ok, so we mandate that for the client to behave properly, it _must_ know
> about the special case of (-1,-1) not being a normal position.

It already knows this ... (-1,-1) has always been the default unreal
position, which is why it gets used in initializations like setting boat
destinations. All released clients since the dawn of time understand this.

It *should* be used to mark invalid goto_dests everywhere and many other
similar cases. But the discussion of how to mark/pass a bad/uninitialized
coordinate in some of these cases, i.e. whether by a special value in the
coordinate space, or by an extra-coordinate flag is part of the the other
discussion.

The current and longstanding default is that there is a special coordinate
reserved for this, namely (-1,-1).

> This does seem to be restricting client behavior which you write is not
> necessary or advisable. None of this really bothers me, it's just so 
> difficult to get a straight _and_ parseable answer from you Ross ;)

Mike, mike, mike ... the fact that Freeciv has always been coded with the
position (-1,-1) being an unreal position is not a *new* restriction, is
not a *client* (only) restriction ... is simply a long standing fact of
life in the codebase, even if this seems like a radically new or unparseable
concept because no one really cared before now that accessing map(-1,-1)
might just possibly be valid and not a cause for segfault in some
representation of a particular topology :-).

Thinking of this as a *restriction* is akin to thinking that the client
coordinates are restricted by being forced to lie within the defined map,
and furthermore that this is somehow a new feature.

The degree of difficulty there seems to be in understanding, or maybe it
is accepting, such trivial and straightforward facts is truly astounding.
Are you really having such trouble with basics like this? What is it that
you find so hard or difficult to grasp?


The current definition is fine, the gen-topo fixes to deal with this are
modest and the expansion of the concept of *reserved* coordinates to deal
with future topological features is actually a fairly efficient and good
way to proceed.

That is why a gen-topologies patch needs to respect this and not change
Freeciv behaviour by completely reversing longstanding definitions and
practices.

> -mike

On the flip side, I've yet to see any real justification and impact analysis
even simple outline of the fixups to deal with making such a change from
those that want to treat (-1,-1) as a real coordinate and abolish the reserved
coordinate concept.

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]