[CF-Devel] Floors / walls and archetypes
crossfire-devel-admin at archives.real-time.com
crossfire-devel-admin at archives.real-time.com
Sun Sep 28 23:23:21 CDT 2003
Nicolas Weeger wrote:
>
Hi.
>
>
For some new functions I wanna add to CF, I need to be able to detect,
>
at a certain position, which object is a floor and which one is a wall.
>
I don't mean 'blocking pass or view' item, but the real floor or wall item.
>
>
Currently I plan on using a combination of GET_MAP_OB (hopefully the
>
floor), and FLAG_NO_PASS to check if something is a wall, also checking
>
things like slaying to avoid doors.
>
>
But looking in the code, there's in define.h
>
#define WALL 77
>
#define FLOOR 71
>
(as item type definition)
>
It seems those values aren't in archetypes anywhere, even in walls
>
archetypes.
>
>
Is there a simple way to find floor / wall? Should I use an item's type,
>
defining it manually in the editor, for floors / walls? Should I change
>
archetypes to add type 77 / type 71 to walls / floors?
>
Or am I missing an easy & obvious solution?
My question I guess would be 'what are you trying to do?'
For floors, thing to always check for is FLAG_IS_FLOOR.
For walls, no_pass is the right thing to check. As you note, there are some
things that have no_pass set which aren't really walls (eg doors), but the
question is then what are you really trying to do/check for?
Those type defines aren't really good - certainly for floors, where something
could be marked 'flag_is_floor', but already has another type (floor is simply
defined as something you can't see beneath, so any number of objects could be so
defined). You could perhaps say those aren't really floors, but then you get
into a messy discussion of 'just what is a floor?'
Those defines should actually be removed, since they aren't used for anything.
You could update are the arch's, but there are sure to be things that might
still not have the correct type set (eg, a map that takes another object, sets
no_pass on it. Is that a wall? sure looks like it).
My general philosophy is that types should only be defined if there is code in
apply.c or time.c (or maybe a few other places) that needs to know the type.
For something like walls and floors, which are passive, there really isn't any
reason to define a type, because the attributes of the object itself dictate the
no pass/can't see below behaviour.
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list