Subject: 1.7.6 and logins.

From: vaughaog <[email-masked]>
Date: Fri, 22 Oct 1993 05:38:13 -0700

X-MOO-Reference: MagicMOO / wales.aston.ac.uk (134.151.17.2) 7777

After upgrading MagicMOO to use version 1.7.6 of the server AND making the
necessary alterations to #0. I find that my login watcher no longer functions.
The code involved is this:

#1080:"login_notify"   this none this
 1:  "login_notify(watcher, player, status)";
 2:  "...Sends a message to WATCHER telling that player PLAYER has...";
 3:  "...connected or disconnected...";
 4:  if (!$perm_utils:controls(callers() ? caller_perms() | player, this))
 5:    return E_PERM;
 6:  endif
 7:  dir = args[3] == "connect" ? "  --=>" | " <=--";
 8:  msg = tostr(dir, " ", args[2].name, " ", args[3], "ed at ", (time = ctime())[12..16], time[25..28], ". ", length(connected_players()), " total.");
 9:  args[1]:tell(msg);

Any ideas as to what is wrong here?

Owain (MagicDragon@MagicMOO)

---

From: "Jacqueline D. Hamilton" <[email-masked]>
Date: Fri, 22 Oct 1993 06:11:44 -0700

>  4:  if (!$perm_utils:controls(callers() ? caller_perms() | player, this))

Not sure how your verb is being called but check this line.  We had
a similar problem with the Monitor on MOOns, altho our Monitor code
is part of the player confunc, there's a check in the confunc of #6
that has ' if (valid(caller_perms()) && caller != this)', which promptly
aborts the player confunc verb when called by the #0:user_connected,
since #0 is valid and caller wasnt player.  It could be related to
this; I wouldn't be surprised if this affects quite a few people's code
when they try to upgrade to the new server.

-j.

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 22 Oct 1993 11:03:34 -0700

> Date:	Fri, 22 Oct 1993 06:11:44 -0700
> From:	"Jacqueline D. Hamilton" <[email-masked]>
> 
> We had a similar problem with the Monitor on MOOns, altho our Monitor code is
> part of the player confunc, there's a check in the confunc of #6 that has '
> if (valid(caller_perms()) && caller != this)', which promptly aborts the
> player confunc verb when called by the #0:user_connected, since #0 is valid
> and caller wasnt player.  It could be related to this; I wouldn't be
> surprised if this affects quite a few people's code when they try to upgrade
> to the new server.

I didn't realize that this change was going to break as much code as it appears
to be doing, else I would have looked for another way to do it.  Hopefully, the
changes to make things work again are relatively easy (e.g., a small change to
a permissions check).  Again, I apologize for the trouble.

	Pavel

---

From: "Gregory L. Searle" <[email-masked]>
Date: Fri, 22 Oct 1993 12:42:04 -0700

> a permissions check).  Again, I apologize for the trouble.

Hm. Now I seem to be experiencing some problems. I use a system of prompts
($command_utils:yes_or_no, $command_utils:read) to promote a BBS-like
startup for players -- that is, they are asked on their first login for a
whack of information, just as you are on a BBS. Another example is my
guest class. When they login they are prompted for their real names and a
short description.

The problem i am experiencing, I *think*, has to do with
#0:user_connected, where it forks and runs user:confunc. I believe that
the fork is conflicting with $command_utils:yes_or_no/read and I need to
know how important it is to have the fork in #0:user_connected. In other
words, what happens if I get rid of the fork -- which is denying
me some powerful options.

Cheers,
Greg Searle

   --==Global Village City Works Dept, Manager==--

   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  [DUBIOUS DISCLAIMER tm]
   :              Gregory L. Searle              :  Any heresy, iconoclasm,
   :    Computing and Communications Services    :  or subversion expressed
   :             Political Studies               :  above is my own, and is
   :       University of Guelph, CANADA          :  not to be confused with
   : [email-masked]  [email-masked] :  that of my employer(s).
   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  ||||_CopyLeft_1993_||||

---

From: Judy Anderson <[email-masked]>
Date: Fri, 22 Oct 1993 13:13:08 -0700

If you remove the fork, then if the room function crashes, the user
one won't get called at all.  Or vice versa, if you reverse them
temporally (leaving them in the same order in the code).