Loophole

You can find all the actions linking to your room with... @entrances I think the command is? Unless setting them 'dark' hides them from that too.

Thanks for the heads-up. I've asked Austin about it, maybe he'll be able to find a solution or two. This isn't a good situation to have. You can check if they've arrived by constantly ws'ing and looking at the room...but how many times do you want to do that in conversation? ':)

That, and it's also a security breach--I'm actually more than a little upset about not knowing about the exploit after being encouraged to let folks use personal exits over the years. I've been letting this thing possibly occur for a while now. -.-

I thought that there was a way to setup a globle odrop into a room... Gurrr... it has been too long sense I was playing with that stuff. AKA.. you can setup a odrop into the room that you can see even if that player were set Dark.

Good for catching secretive Wizards.

Chahala

"Good for catching secretive Wizards."

*plots!*

;)

I'm not certain that odrop will work on the room, but I don't recall the conditions in which the drop and odrop on rooms are executed. @osucc here=drops in. ought to work, but the succ and osucc are executed whenever the room is used successfully, which includes being looked at. That'll result in ``false positive'' reports of people entering.

There's surely more ways than the one I outlined in the other big post.

This one needed some figuring out, but there's a way. The key is the _arrive properties, which are things done when a person arrives in a room, by whatever method.

So, what you want to do is set something like this in the room:

@set here=_arrive/announce:&{null:{otell:{name:me} just appeared in the room.},#dbref-of-the-room,#-1}}

The otell</cite> is pretty self-explanatory, the included message gets told to all in the room. (If you want commas in the message they have to be written as \, instead.) The #dbref-of-the-room is, well, the place to send the message. The #-1 means the message is shown to everyone including the person who enters.

The null prevents a duplicate message being sent to the person who enters. The & is needed for odd muck purposes -- without the ampersand the muck thinks you're trying to run a MUF program.

To run a MUF program you'd just @set me=_connect/voteautocheck:7365 or such -- that runs MUF program dbref #7365 on connection.

You can set a bunch of _arrive/ properties; they run in alphabetical order. You can also set _depart/ properties with similar conditions. On a person or zombie there's also _connect and _disconnect that run, well, you get the idea. All of this is well-documented in the minds of the fuzzball programmers, but hang around long enough and you'll encounter it.

So something similar would have to be set for depart, then? I'll check it out--thanks much for taking the time to put this together. :)

Doesn't appear as though the departure setting works just yet, but the arrival was the really big bug. A million and once thanks for taking care of that. :)

The trouble, for the record, was my typo in the instructions; I added a } where none was needed. The correct message -- whether to set on _arrive/ or _depart/, on _connect/ or _disconnect/ trees -- is like:

@set here=_arrive/announce:&{null:{otell:{name:me} just appeared in the room.,#dbref-of-the-room,#-1}}

The otell command taking three arguments, the message ({name:me} just appeared in the room.); the destination (#dbref-of-the-room); and the people to be excluded from notification (#-1, exclude no one in the room). MPI, of course, does bizarre unpredictable things when you get the braces in the wrong place. I apologize for the unnecessary confusion.

So all in all we have:
@set here=/_arrive/announce:&{null:{otell:{name:me} has entered.,#room-db, #-1}}

@set here=/_depart/announce:&{null:{otell:{name:me} just left the room.,#room-db,#-1}}

Wonderful! Up and running. :)

Does this work if set on an environment room, using {loc:me} as the dbref of the room to otell to?

Beats me, but looking over the code I think it should. Certainly _arrive and _depart/ get inherited; that's essential to the banish, ride, and a few other programs' workings. The {loc:me} should be the right substitution. Anyone want to run a test article?

I wouldn't object to including a default arrive/departure message that way if there's a way to do it without being redundant to osucc/odrop messages and if there's a way to suppress it when the room owner wants. (I could see silent arrivals and departures fitting, for example, the theme of a haunted house room.) This might turn into MUF before we're done with it.

Terry: please post if it works, and I'll plaster it into the main entry, above, under a bold. :)

I'm at work now (no access to MUCKs) and then going to an RPG session (no access to internet) so I can't try this anytime soon, or I would have instead of asking. }:P

New trouble--now anyone arriving via a normal "door" sports three arrival exits. Regardless, I'm puttin the fix in place anyway. :)

You could make it atmospheric so that it isn't redundant. Won't make it less spammy, tho.