|
nightstrike Newbie
Joined: 29 Oct 2005 Posts: 2
|
Posted: Sat Oct 29, 2005 4:29 am
#WAIT -- Maybe it's just the way I think... |
I've been reading that #wait is bad for a number of reasons, and I should use either triggeres or #alarm. I am curious, though. What's wrong with code like this as an alias:
Code: |
#WALK OrsenaAcademy
#WHILE (%iswalk( ) = true) {#WAIT 1000}
get document from shelf
get scrap from shelf
#WALK OrsenaTower
#WHILE (%iswalk( ) = true) {#WAIT 1000}
get lens from coinpurse
get smallkey from coinpurse
|
That's just how I think... Walk somewhere, and when you're there, do something. Is that so bad? How can I write that using the "proper" methods? I thought of soemthing like this:
Code: |
#WALK OrsenaAcademy
#TEMP {Academy} {
get doc
get scrap
#walk OrsenaTower
Temp {Tower} {
get lens
get smallkey
}
}
|
I don't like that, though. After I'm done, I'll have nested temp triggers 79879324 levels deep. Ok, well, maybe 5 levels deep. But still... What's the "right" way to accomplish something like this?[/code] |
|
|
|
Theragil Apprentice
Joined: 13 Feb 2004 Posts: 157 Location: USA
|
Posted: Sat Oct 29, 2005 1:35 pm |
Your approach is logical and straightforward, and if it worked, it'd be the way to go. But zMUD's implementation of #wait is not smart enough to support it.
Probably the way to do what you're doing is just to have a trigger that goes off when you're at OrsenaAcademy (or a room script) that gets the document and such and walks to OrsenaTower. And so on. If you don't want to always do that when you get to OrsenaAcademy, put the triggers in a class and enable or disable it at appropriate times. Or set a variable to 1 or 0 depending on whether you're doing this, and let the trigger or roomscript check it before doing the next step. |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Sat Oct 29, 2005 5:59 pm |
Quote: |
But zMUD's implementation of #wait is not smart enough to support it.
|
I guess I should go check this to be sure, but from what I remember the only problems associated with #WAIT was its behavior when used in a trigger. When used in a trigger, everything but the data flow and strictly client-side activities coming in from the MUD stopped for the duration of the wait--script processes, updating windows, everything. This doesn't/didn't happen in aliases, so while #WAIT was generally discouraged entirely it technically wasn't a bad thing to use in all situations. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Theragil Apprentice
Joined: 13 Feb 2004 Posts: 157 Location: USA
|
Posted: Sat Oct 29, 2005 6:04 pm |
It'd be inappropriate to use the way he's using it above, entirely, because it'd prevent the triggers that drive the mapper from running so he'd never get there. It'd be an infinite loop.
|
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Sat Oct 29, 2005 8:18 pm |
Quote: |
It'd be inappropriate to use the way he's using it above, entirely, because it'd prevent the triggers that drive the mapper from running so he'd never get there. It'd be an infinite loop.
|
The internal, auto-config ones? That's a new one to me, because I know for sure that when used in an alias #triggers contained in your settings file are completely unaffected. Including the slow-walk trigger. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
nightstrike Newbie
Joined: 29 Oct 2005 Posts: 2
|
Posted: Sun Oct 30, 2005 2:49 am |
I've used it to successfully walk to locations. I use slow walking.
|
|
|
|
Theragil Apprentice
Joined: 13 Feb 2004 Posts: 157 Location: USA
|
Posted: Sun Oct 30, 2005 1:44 pm |
Well, if it works for you, good on you. So where is the problem then?
|
|
|
|
yejun Wanderer
Joined: 13 Jun 2005 Posts: 51
|
Posted: Mon Oct 31, 2005 4:37 am |
it will have problems, if there are 2 #wa commands need to execute simultaneously in zmud 7. The second #wa will execute until the first one finish even in a different connection window.
However in zmud 5.55, the behavior is different. |
|
|
|
|
|