RE: set_aux_terrain_view?

["Stanley Sutton" <sutton at t-surf dot com>]

Never mind.  It is an incomplete 3D array.


-----Original Message-----
From:	Stanley Sutton
Sent:	Wed 10-Jul-02 16:00
To:	xconq7@sources.redhat.com
Cc:	
Subject:	set_aux_terrain_view?
If I'm understanding what is going on correctly, the auxillary view for
terrain types on a side is an array of Terrain types that have an
alternate value for the terrain, since the aux_terrain_view uses the
single dimension by  Terrain type.  However; set_aux_terrain_type uses
aref to set the auxillary view Terrain type.  I suspect this is wrong.
The current macro is:

#define set_aux_terrain_view(s,x,y,t,v)  \
  (((s)->auxterrview && (s)->auxterrview[t]) ? aset((s)->auxterrview[t],
x, y, v) : 0)

I suspect it should either be:

#define set_aux_terrain_view(s,x,y,t,v) \
   (((s)->auxterrview && (s)->auxterrview[t] && (s)->terrview) ?
aset((s)->terrview, x, y, ((s)->auxterrview[t])) : 0)

or

#define set_aux_terrain_view(s,t,v) \
  (((s)->auxterrview ) ? (s)->auxterrview[t] = (v))

depending on if the view terrain at a cell is to be modified with an
auxillary translation table, or all the terrain displays are to be
changed.  I suspect the former, as it makes more sense.  As written, I
think it would cause memory over writes in other arrays if used, since
it's calculating a cell address (2D) rather than a Terrain type address
(1D).  Also, I suspect to work entirely properly, the global translation
table needs to be consulted, if the side's table is missing, or not
filled in, just like the aux_terrain_view macro.

I suppose this could work as written is the side.auxterrview is a 3D
array, whith a comple copy of the cell for each terrain type.  I must
admit I'm not sure of what is going on, since the aux_terrain_at and
set_aux_terrain_at macros do the same sort of thing, and the
aux_terrain_at is used by both border_at and connection_at.