[Freeciv-Dev] Re: topology patches

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 04:46 AM 01/10/27 -0400, Jason Dorje Short wrote:
>I have the following topology patches prepared or planned.  All of them
>are relatively small.
>
>check_map_pos : this doesn't deal specifically with topologies but it's
>the same code that's being affected.  Since it's a pretty
>straightforward change and one that we should have in CVS for as much
>time as possible before the next release, this should get first billing.
>
>rand_pos: this creates a rand_pos function in mapgen.c.  It's a small
>issue, but it's been argued liberally: what form should rand_pos take?

Drop it ... it is far too restrictive or expensive an interface to use
for most cases and its presence will result in bad abuse. When you want 
this particular limited functionality it is trivial to code.

>map_iterate: this changes the map iteration loops to use
>regular_map_pos_is_normal.  It is currently being held up (I believe) by
>several factors: (1) regular_map_pos_is_normal overlaps with rand_pos,
>(2) there was some thought of removing print_landarea_map in game.c, (3)
>Ross isn't happy with the form of many of the loops.  I'll propose an
>"updated" version of this shortly, though.

regular_map_pos_is_normal() is a very confused concept. I think you need
to review the topology RFC before adding such things to the code base.

>mapgen: (not yet proposed) this updates all of mapgen to be
>topology-independent.  It uses distance_from_pole,
>distance_from_[north|south]_pole, and (possibly) distance_from_edge to
>do the map computations.  rand_pos needs to be dealt with first, though.

No. Write a new map_generator if you want to do such things. Leave the
current ones alone for the forseeable future except for minor changes
to make sure they don't fault if used in various topologies they are
checked and registerd to support.

>diff_map_pos: (not yet proposed) this introduces a function,
>diff_map_pos (or similar naming) that determines the difference between
>two map positions.  It will be necessary for straightest_direction,
>dir_ok, is_cardinal_move, [xy]dist, and other GOTO code to be
>topology-independent.

These functions currently exist ... use them. Don't proliferate more 
noise.

>misc_topology: (not yet proposed) miscellaneous cleanups may include
>moving map_adjust_[xy] into client-only code, removing any remaining
>topology-dependent code, etc.

It may not be necessary to remove things. Isolate them as (documented) 
special cases if they are only used (safely) in special case code. Replace 
only that which is being used for the general flow path or causes faults.

>At that point, we should have a topology-independent server (well, OK
>probably not...it's hard to verify such things...).  We can then move on
>to the client.  This will be a bigger job, depending on how much cleanup
>we want to do in the process, but at least we can do some testing as we
>go along.

Get the basic model right for the server part. Note it really only uses
game or map coordinates, and thus is not really that tricky. Accept a
limited set of current implementations to back the model interfaces, and
don't worry about over generalization below the model interface, i.e. a
switch function, or virtual function indirection based on map_type index
to handle case specific details should be fine.

>jason