Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: (PR#3936) introducing native coordinates
Home

[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: jdorje@xxxxxxxxxxxxxxxxxxxxx, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3936) introducing native coordinates
From: Ross Wetmore <rwetmore@xxxxxxxxxxxx>
Date: Wed, 16 Apr 2003 17:50:16 -0400


Raimar Falke wrote:
On Mon, Apr 14, 2003 at 11:02:28AM -0500, Jason Dorje Short wrote:

Raimar Falke wrote:

On Sun, Apr 13, 2003 at 05:37:59PM -0500, Jason Dorje Short wrote:
[...]
There are certain parts of the code which are topology
dependent. These parts are few:
- neighborhood relation: can be reduced to MAPSTEP
- distance: is reduced to map_distance_vector
- wrapping/normalization: is reduced to normalize_map_pos

None of these are topology-dependent under map coordinates. So in essence you are saying that these are the only parts of the code that need map coordinates.

But there may be more

Quite possible. But finding these on the way is a goal.

Actually it isn't.

One only needs to find the cases that matter for the currently implemented
set. Subsequent iterations can deal with followon extensions on an as need
basis.

That doesn't mean that finding and cleaning things up isn't a good thing,
but it is not a general requirement.

[...]
So we both say that our changes are minimal.

Yes but are you both right?

Who would you give odds on, the person that hasn't worked through the
issues or developed working code for a number of extensions, or someone
that has?

(I still don't see why you believe your method requires fewer code changes. This may be true, but there is no evidence for it.)

Let me create some code so that we can have some facts. Hopefully this
week.

Is there an implementation of your approach which is complete? For
measure of speed and general impact this doesn't have to support
mapview.

        Raimar

There has been a complete working model for all the core (aka non-mapview)
changes for close to two years. The original code changes took about a week
to produce but have gone through a number of update and cleanup phases
since then.

The complete working code including GUI fixes for all supported topologies
has been around in two forms for over one year. A merged package exists
against current CVS. The native split appeared Dec 2001 as a cleanup of
the regular mappos fiasco in parallel with the GUI phase.

I hope you can be as complete in your example. But I suspect it will take
awhile before it reaches the level of stability and robustness of the
existing versions. Hopefully you will better appreciate their approach
though once you get your hands dirty.

In the meantime we should perhaps continue with the discussion of the
proposed solution and not stop all progress while we wait for Raimar to
develop his personal flavour. Not having to argue two or spend so much
time on other things will perhaps make things run a bit faster.

Cheers,
RossW
=====



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