[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