[CF-Devel] bug in mutliparts (RE: warrior prooving tower)

Andreas Vogl andi.vogl at gmx.net
Tue Aug 14 04:54:16 CDT 2001


Mark W. wrote:

>
     
      I'm not sure what all multipart objects are out there that need
     
     >
     
      special handling.  Obviously, teleporters are one.  Exits have
     
     >
     
      already been done.  I'm not sure what other objects may have a
     
     >
     
      similar problem.
     
     
Currently, to my knowing the following types of mutliparts exist:
- floor (big mountains)
- buildings (= exits)
- pentagram teleporters
- monsters

I think monsters and buildings should be placed always ontop (like
all currently do). Teleporters should be placed ontop everything
except monsters.
Floor should probably be placed below everything else, but
that's hard to say. I could imagine wanting both to put sth below
and above it.

>
     
      For simplicity, copying the flags from the head to the more parts
     
     >
     
      will at least take care of the blocked and invisible flags.
     
     
Hm... Are you sure it is better to copy the values into the
body, rather than making the code always look at the head?
Since every body object has a pointer directly to the head,
I don't think this would cost any cpu time.

>
     
      I just thought of a case where the blocked value of the head should
     
     >
     
      not get transferred to the reast of the objects - the shop buildings.
     
     >
     
      In most cases, the head is blocked, but if that gets extended to all
     
     >
     
      parts, that obviously won't work very well.
     
     >
     
     
     >
     
      I'm not sure what the best solution is. One might be to clear to the
     
     >
     
      blocked flag from the shops [...]
     
     
True. Unfortunately, as long as we keep the current scheme of saving
only the multi-heads, the no_pass won't work for buildings anyways.
I do agree that this is a tricky problem. Walking over rooftops
of big buildings feels kinda odd.

Andreas V.

    
    


More information about the crossfire mailing list