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: Fri, 12 Sep 2003 07:45:37 -0700
Reply-to: rt@xxxxxxxxxxxxxx

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.

To reiterate the answer to the kneejerk followup ...
To move NW from (0,0) one of the infinity-1 other equivalent choices for
the position should be sent as the destination. In almost all cases, this
is what is currently done, as most coordinates are generated in normalized
form at source, i.e. the default effect of the realness check at coordinate
generation time.


Prior to gen-topology, this case never occurred except in odd situations
where a boat goto_dest was initialed to (-1,-1) and the dest selection
failed with the current move code failing anyway. Gen-topo probably needs
to look at some of these spurious cases, or consider how the server(/client)
should deal with bad coordinates now there are possibilities for the current
simple normalization/realness check to succeed. The quick fix is to identify
and deal with the spurious cases as some sort of defined override.

The general fix may bring back the proper form of is_real_map_pos() to do
a correct realness check, rather than just the simple normalization. The
resulting code will look a lot more like it did 2 years ago before a lot
of the mistaken optimizations (that have always decreased performance)
were introduced. An advantage to this is that the hook for handling any
number of other special coordinates and general strategy for coding can be
architected so advanced topology features like transporter tiles and Swiss
mts can be handled some day.

Cheers,
RossW
=====

Mike Kaufman wrote:
> On Fri, Aug 22, 2003 at 02:14:12PM -0700, rwetmore@xxxxxxxxxxxx wrote:
> 
>>No, Mike.
>>
>>You don't need to move to (-1,-1). Either it is an unreal coordinate if
>>you don't wrap, or the origin can be shifted to make it so (which also
>>makes it a sensible origin for array accesses and other usage). You
>>cam move to (map.xsize-1, map.ysize-1) or one of the infinite other
>>equivalent positions excluding the one special one in a wrapping topology.
> 
> 
> Lay it out for me Ross. A server receives a PACKET_MOVE_UNIT with (-1,-1)
> as the request.[xy] from a client. 
> The unit is at (0,0). What ought the server do?
> 
> -mike




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