Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Advise on map editor.

On May 22,  5:37pm, Scott Wedel wrote:
> Subject: Re: CF: Advise on map editor.
> Regarding overlay fix:  I suggest that a version be made which attempts
> to remove all overlays with unions and that the unions be defined so
> that the physical layout of the structure is unchanged.  Thus, if there
> is a mistake in splitting the overlay, it shouldn't affect the game
> since it still the same address in the structure.  Then individual
> variables can be split from the overlay and play tested to verify
> the union was defined correctly.

 Unfortunately, that is not possible.  Anonymous unions are not supported in
ANSI C.  Thus, to do something like that with say the map attributes, it would
be something like:

 object {

   union u1 {
	char *slaying;
	char *destmap;
    }
    union u2 {
	int sp;
	int destx;
    ]
    union u3 {
	int hp;
	int desty;
    }

 and so on.  And then when you wanted to access something, it would be
op->u1->destmap, op->u2->sp, etc (Actually, syntax is probably slightly
incorrect, but the point remains.)

 I hardly thing this makes things much more readable.  IT also requires quite a
bit of work to change it.

 And this still doesn't prevent one from using hp for the destination for the
map.  And the editor would still need to have some knowledge.

 If we were using C++ (where anonymous unions are supported), this might not be
a bad thing.

 A better method (but still not quite perfect) would be to access everything
through macros (map stuff more or less does this.)  Thus, something like
GET_MAP_DEST(m) would just return m->slaying.  Do this for all elements which
have contradictory/non intuitive meanings (and by grouping all these defines in
one place, you could pretty easily see what the overlays happen to be.)

 The other potential advantage to this is that if it gets decided to split
these values out or otherwise change where they are stored, only the macros
need to be changed.

 Of course, it would still be nice to store these more indepent in the
archetypes and map files also.  So instead of sp/hp being stored in the map
file for remote destination, destx and desty would be used.  However, this then
requires some form of mapping for specific item types (ie, if the object type
is an exit, then save hp as destx, sp as desty, etc.)  The advantage of a
general mapping like this is that then hopefully crossedit could take advantage
of it to use the same mappings (ie, this is an exit, so show the value as
destx, but really store it in hp)


-- 

-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: