[CF-Devel] Bug: show invisible and burning items

[Michael Toennies]

Hm, now a different one appears.

I was now in the hall near kurte, where the 5 pentragrams are to
travel to the past.

I had cast show invisible. A TALK symbol for a magic mouth appears in the
middle,
where then the teleporter appears. After the teleporter appears, i step over
it - nothing.

It seems, that the teleporter get blocked, looks like from the magic mouth.

If i press apply, the magic mouse get triggered.

Hm, the bad thing is, that i can't trigger the teleporter "by hand".
This can happens in other way, perhaps when items get dropped on the
teleporter.
This then blocks him. Bad, when you want flee.

Teleporter should be also triggered by hand like doors with apply. This
should trigger the
same routine.

Problem with this teleporter is, that there is a pedestal, which triggers
the teleporter i think.
We should find a solution for this. Or improve the "range" of the pedestal.


>
     
      > > I had some fight to do, and after it i cast show inv
     
     >
     
      > > to unhide to door.
     
     >
     
      > >
     
     >
     
      > > But only the "flash" comes out at the map point where the door is,
     
     >
     
      > > but the door don't appear.
     
     >
     
      >
     
     >
     
      > True, this happens. It is more a map bug I think.
     
     >
     
      > Items with flag "invisible 1" become visible on show-inv,
     
     >
     
      > so do items placed under the map-floor.
     
     >
     
      > The hidden oakdoor in "s_f/st3" is BOTH under the floor and
     
     >
     
      > "invisible 1". In this case show-inv. fails, and that is
     
     >
     
      > intentional (There must be some means of hiding stuff
     
     >
     
      > from all too curious players).
     
     >
     
     
     >
     
       The pup lands maps were done before enhancements to show invisible (so it
     
     >
     
      doesn't show things like magic ears and what not) was added, so
     
     >
     
      it is certainly
     
     >
     
      possible the map is presuming a different behaviour.
     
     >
     
     
     >
     
     
     >
     
      > > How show invisible works? Should it not unhide all invisible ?
     
     >
     
      > >
     
     >
     
      > > When not, it should, its a pain like in maps for pupland
     
     >
     
      where whole sets
     
     >
     
      > > work with it.
     
     >
     
      > >
     
     >
     
      > > I don't want enter a map x times, because i have a random in the show
     
     >
     
      > > invisible code.
     
     >
     
      >
     
     >
     
      > No, don't worry. This doesn't happen anywhere else to my knowing.
     
     >
     
      >
     
     >
     
      > However, a short note on show-invisible:
     
     >
     
      > While making maps I realized that we need a (simple and clean) way to
     
     >
     
      > mark any given object both as "invisible" and "not affectable
     
     >
     
      by show-inv".
     
     >
     
      >
     
     >
     
      > Typical example: I want to make an invisible teleporter, it has to be
     
     >
     
      > on top of the map-floor, but I don't want the player to discover it
     
     >
     
      > via sho-inv. Currently this is not possible (except for one dirty
     
     >
     
      > workaround).
     
     >
     
     
     >
     
       Right - some flag that determines if show invisible should
     
     >
     
      work/not work for
     
     >
     
      that object is needed.  However, that is a bit of work to update
     
     >
     
      all the arch's
     
     >
     
      and maps to use it (coding it probably would not be too hard - in
     
     >
     
      fact, it would
     
     >
     
      simplify the show invisible function).
     
     >
     
     
     >
     
       Whether the flag should be a positive flag (show invisible works for this
     
     >
     
      object) or negative (even with show invis, this should remain
     
     >
     
      invis) should
     
     >
     
      probably be determined by the relative number of objects (and
     
     >
     
      their use) that
     
     >
     
      fall into the category, and the method chosen should be such that requires
     
     >
     
      minimal changes to the arch and maps.
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >