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

[Mark Wedel]

Andreas Vogl wrote:

>
     
      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.
     
     
 With the new system, you need to seperate internal stacking from visible
stacking.

 Visible stacking is how it appears to the client.
 Internal stacking is how the above/below pointers really point.

 These two are no longer connecte in much any way.  If there is a monster on the
space, no matter what the internal stacking is, it will be put at the top of the
visible stacking.

 The only case internal stacking really makes a difference is for the floor
objects - objects below the floor in the internal stacking are not visible.

 currently, when the additional parts of multipart objects are linked in, they
are put just above the floor object.  This unfortunately means you can't hide a
multipart object beneath the floor.  I guess it wouldn't be too hard to fix this
- if the head is beneath the floor, put the rest beneath the floor, otherwise it
goes above the floor.


>
     
     
     >
     
      > 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.
     
     
 Costs a little, in that you need to have a if (op->head) look at op->head
values, otherwise look at op values.  Real performance effects are probably not
that great.

 However, currently link_multipart_object, which is what adds in these other
object parts, does duplicate the name and title - duplicating invisible and
blocked would be pretty trivial, and keeps life simpler (this way, things like
looking a the space does not need to get updated, nor do other functions). 
Plus, adding the invislbe and blocked values to link_multipart_objects would be
pretty trivial to do.


>
     
      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.
     
     
 The building is sort of a no one situation.  If you make it so that you can't
walk on the roofs, it means that shops can only be on the north side of roads.

 Its a little tricky, in that when the other parts of the multipart objects are
linked in, it will inherit the flags of the archetype for the more section
(blocked and/or invisible).  So these really need to be set or cleared,
depending mostly on if the head is different from the archetype.