I still haven't figured out what to do with my Move() problem. To recap: the room's Enter() proc looks like this:
Enter()
. = ..()
Roleplayspiel()
Roleplayspiel() contains lots of sleep() procs, and mob/Move() has been altered. A player trying to go into the room will enter it fine, but nothing after the ..() in Move() will occur. Move() works fine on all my other rooms.
It hasn't occurred to me until now to see if the rest of Move() finally occurs once Roleplayspiel() returns... should I?
Z
ID:138412
 Aug 31 2000, 11:21 am
|
|
On 8/31/00 3:21 pm Zilal wrote:
It hasn't occurred to me until now to see if the rest of Move() finally occurs once Roleplayspiel() returns... should I? Yes this is likely the cause. Here's how it works: * Move() calls Enter() * The mob changes location as Enter() returns the "." value to the server. * Enter() sleeps (inside Roleplay spiel). * Move() finishes after Enter() returns Confusing, eh? I think the expected behavior would be: * Move() calls Enter() * Enter() sleeps * The mob changes location after Move() finishes But as far as I know, the server must get an immediate response from server-triggered events like Enter(), since it cannot itself sleep. This is really Dan's territory, so I'll pose the question for him. | |
The built-in Move() procedure is hard-wired into the server and does not wait for anybody. That means if it calls Enter() and that proc sleeps, execution immediately returns to the server with whatever return value may be available (ie any assignment to "."). In the future, I am considering making all built-in procedures wait, just like any user-defined proc waits when it calls a sleeping operation. If your code depends on this question, you could soft-code your own Move() procedure and totally bypass the hard-coded one. The real source of your problem may be as simple as sending a message to a room that the player has already vacated. Are you sending it directly to the player or to an entire room? You might try Deadron's suggestion of sending it to the whole world as a sanity check. --Dan | |
On 9/1/00 8:04 am Dan wrote:
The real source of your problem may be as simple as sending a message to a room that the player has already vacated. Are you sending it directly to the player or to an entire room? You might try Deadron's suggestion of sending it to the whole world as a sanity check. The problem was simply that everything after the ..() in my overridden Move() wasn't occurring. The player was getting moved to the room but was not receiving the room's description, which is the last thing that happens in my Move() proc. All this talk about messages is confusing me. Deadron's suggestion--putting the spawn(1) in--worked. Thanks Deadron! Z | |
Deadron's suggestion--putting the spawn(1) in--worked. Thanks Deadron! That was going to be my suggestion as soon as I read your post (you can also simply use spawn(), i.e. without a delay), but, as always, someone beat me to it. Basically, this new waitfor default assumption is the direct opposite of what it was before: Before, if you wanted it to ensure something ran before something else, you inserted "waitfor". Now, if you want to ensure something runs AFTER something else, you insert "spawn()"! Not to sound bothersome or anything, but, what exactly makes this new notation better? We still have to type the exact same amount of characters, albeit in opposite locations. =) (Libelous comments about my ancestry, Deadron? Whatever for? (Oh, btw, considering my ancestry was British about 3 centuries ago, it is spelled "libellous" by them (not by me, though) =)) | |
On 9/1/00 1:36 pm Spuzzum wrote:
Basically, this new waitfor default assumption is the direct opposite of what it was before...Not to sound bothersome or anything, but, what exactly makes this new notation better? We still have to type the exact same amount of characters, albeit in opposite locations. =) My guess would be that the change was to fix the kind of situation I kept finding myself in (though I never got around to complaining about it, imagine that) -- in order to stop stuff from happening while a prompt() was up or something, I'd end up having to pick through my code and use a waitfor in half a dozen different procs. And if I missed one I'd get a whole range of wacky behavior. It was quite annoying. With the new approach, I know that a sleep() will sleep everything, and I don't have to worry about it. | |
On 9/1/00 1:36 pm Spuzzum wrote:
Before, if you wanted it to ensure something ran before something else, you inserted "waitfor". In my opinion, this new notation is far superior. For one, it ensures that inlining a proc is equivalent to calling it directly, eg: proc/func() sleep blah1() proc/callme() func() blah2() executes: blah1() blah2() not: blah2() blah1() But this wasn't the reason for the change. That came about because we didn't have a good way to make libraries with sleeping functions in the old notation. Suppose you, the black-box designer, wanted to make a function that caused the caller to sleep. In the old system, you had to explicitely set the waitfor property: proc/func() set waitfor = 1 sleep blah1() But the problem is that this only caused the immediate caller to sleep. So if the person using your library called you directly: mob/verb/test() func() ... It would be ok. But if he called you through a series of procs: mob/verb/test() func2() ... proc/func2() // need set waitfor=1 for this to work as expected func() It wouldn't work unless he explicitely told each of them to also wait. So the library would impose certain restrictions on its user, which is poor OO design. Now the "set waitfor" property is pretty much obsolete, because you can use spawn() to accomplish the same thing. Getting rid of an instruction is always a good thing. | |
On 8/31/00 3:21 pm Zilal wrote:
Sometimes it helps to make sure a call like Roleplayspiel() happens after everything else is taken care of, using spawn:
Enter()
. = ..()
spawn(1)
Roleplayspiel()
That way there is no way for the Enter/Move procs to get messed up, and Roleplayspiel() will happen next tick.
Can't hurt, but you might try the above first if you haven't already.
A good debugging check is simply:
var/result = mob.Move(destination)
if (!result)
world << "Hey there's a problem!"