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