Zugg Software :: View topic

Beginner Joined: 02 Sep 2006 Posts: 10

I don't understand the animosity towards #WAIT. From what I gather from Zugg's article the problems with this come about when #WAIT is used in triggers. I don't use #WAIT in triggers. I use it in scripts that wait in loops for something to happen, then proceed. I find this very easy to reason about and code for, so why take this ability away?

For example, in my MUD, many actions come with an associated variable roundtime. So I wrote a script like this called "wfr" (wait for roundtime) - (and yes this is pseudocode):

wfr
{
set temp trigger that fires on RT string and sets RT variable
set RT variable to 0
until RT variable is set
{
#wait 200
}
#wait for number of seconds in RT variable
}

Then I can easily write scripts like this:

remove weapon
wfr
climb hill
wfr
wield weapon
wfr

I've created variations of wfr that do stuff like wait on multiple strings and return which matched, and so on. They all have timeouts or are easily cancellable by me with ESC. For example, I have wfmr, which takes a variable name and a bunch of match strings, waits for a match, and returns the index of the string that matched. It also waits for a roundtime after the match. I can use it like this (to make up a contrived example) - (and yes this is also pseudocode):

killorc
{
set orcdead to 0
until orcdead is greater than 0
{
attack orc
wfmr result "You kill the orc" "You hit the orc" "You drop your sword"
case result {orcdead=1} {} {get sword; wfr}
}
}

It seems that Zugg's scripting philosophy is event-driven to a fault. I think it is far easier to write and reason about scripts written in a functional manner, instead of breaking up the script into many pieces that hang off of individual triggers and alarms. I'm hiding tons of complexity within function calls as you can see above. I despair of writing a script like that with just triggers and alarms that's remotely as simple.

To see how easy MUD scripting should be, consider any of the StormFront/Wizard scripts that are made for Simutronics games. They are all functional; you can output commands to the game, then call 'match' or 'matchwait' to wait for a specific MUD response (and that handle roundtimes transparently), then continue, then match again, and so on.

So far I've been able to get away with doing things this way in ZMud because of #WAIT. I don't see any technical reason why this paradigm should be discouraged, given that I avoid all the pitfalls mentioned in Zugg's article by not waiting in triggers. Triggers are cool and have their uses, but I've always found sequential scripting far more useful and natural in a MUD. If this ability is going to be taken away in cMUD, please let me know now so I can consider my options.

Posted: Tue Sep 05, 2006 10:58 pm

This really belongs in the zMUD forum. But zMUD/CMUD is "event driven" because that's how Windows works. Windows is completely event-driven, as is the network system.

The problem with using #WAIT is that it's not clear what you should wait for. How much of the program should stop? Should the mouse and keyboard activity stop? Clearly not. The mouse and keyboard are "event driven" in Windows, and you expect them to continue to respond. Well guess what...the network input/output is also event driven in Windows. So while your script is "waiting", you want all MUD input to stop (but probably not MUD output). So then what about other triggers? What if the stuff you are waiting for never comes? Do you just hang forever?

The way #WAIT is implemented in zMUD is that a new message thread is created. This allows Windows to continue processing other messages, like for the keyboard and mouse. During the delay, MUD input and output is also accepted and other triggers can fire on the incoming text.

So, imagine that you have a trigger that fires on common text that does a #WAIT 1000 (10 seconds). You can end up with more and more threads as more wait commands are executed and put into the background.

Waiting in an alias has the same problems as waiting in a trigger...the article just focuses on triggers, but the same problems explained in the article exist no matter where you use Wait.

Using Wait is actually a lot like old-style programming using "go-to" rather than using structure programming. While it takes some getting used to, event-driven languages perform and scale much better than "wait-style" programming.

And no, neither zMUD nor CMUD are ever going to change to the limited capabilties of the StormFront/Wizard clients. I'm sure there are plenty of zMUD/CMUD users here that can give you an earful why you shouldn't be coding scripts like that and why the zMUD event-driven model is better.

#WAIT still exists in CMUD, but it still has the same problems and limitations as with zMUD and is not recommended for general use. If you want to use it, then fine, I don't care. You might find it more "natural", but you are missing out on a lot of performance and improvements by rejecting the event-driven model.

Beginner Joined: 02 Sep 2006 Posts: 10

I'll ask in the main ZMud forum for examples of how scripts like the ones I have above can be implemented in ZMud in a way that is easy to understand. I understand how simple scripts can be converted to multi-case triggers, but the paradigm breaks down for me once you start getting into complications like nested loops, reuse of multiple-matching code, etc.

Beginner Joined: 02 Sep 2006 Posts: 10

An option would be to go whole-hog and add multithreading (I think this was mentioned as a possibility in an earlier thread). Give us synchronization primitives and the ability to execute scripts in separate threads. For the non-power-users you can formalize the atomic script changes you're talking about to stop ordinary users from shooting themselves in the foot with #PRIORITY and #WAIT. For power users it's completely up to us to make sure our threads synchronize properly.

Posted: Wed Sep 06, 2006 4:10 am

I've always used #WAIT in my scripts cause quite honeslty I haven't found a better way to do things.

e.g. See a repop, wait 20 seconds, disconnect. wait 120 seconds.. reconnect.

How on earth can you code that event driven ?

Or another example.

I have triggers for attacking known mobs in an area based off the long description.
Some mobs I wish to intentionally attack last, so in their triggers I #wait 50 so that their attacks are delayed by that ammount.

I guess I don't see how else to do time based things without wait. ?

Wizard Joined: 14 Oct 2000 Posts: 1368

Example on how to do the repop:
#alias repop {
#alarm +20 {
#echo disconnect
#alarm +40 {#echo reconnect}
}
}

You can do pretty much the same thing with the mobs:
#TRIGGER {({@mobs})} {#alarm +50 {kill %1}}

Unfortunately the last example doesn't work in cMUD because of the new way arguments are expanded.

Posted: Wed Sep 06, 2006 5:26 am

So what exactly is the difference between setting alarms, and just freezing the operation of one single trigger/alias with wait, they achieve almost exactly the same purpose, but from what I can see you have more problems with alarms when you try and put in multiple delays in a row.

e.g.
#BEEP
#WAIT 100
#BEEP
#WAIT 100
#BEEP
#WAIT 100
#BEEP
#WAIT 100
#BEEP
#WAIT 100
#BEEP

etc would end up with 5 nested alarms to achieve the same thing ?

Wizard Joined: 14 Oct 2000 Posts: 1368

Beginner Joined: 02 Sep 2006 Posts: 10

Unfortunately the bottom line is that it is just much harder to write scripts in this way, even though they may theoretically be more powerful. Trying to write a script that needs to wait on 4 different types roundtime in 20 places in 3 nested loops that branch to different places based on 5 different matches is fantastically complex if done solely in an event-driven manner, but is so easy in Wizard script that 12-year olds can write it. It would be far easier from my point of view to give me true multithreading, and let me code scripts and triggers the way I want and leave it up to me to manage my own synchronization instead of forcing me into a 100% event-driven paradigm.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The short way...
#TRIGGER "RT1A" {-30} {#EXEC {%pop(RT1Queue)};#T- RT1A} {} {alarm|disable}
#TRIGGER "RT1" {Round time 1:(%d)({.%d|})} {#T+ RT1A;#CALL %alarm(RT1A,%eval(%1*1000+%2*100))}
#VAR RT1Queue {} {}
Duplicate that changing the names around for all 4 round times, then all your scripts need to do is dump commands in the right queue and check that your not waiting on that round time to decide whether to send 1 command.
#ADDITEM RT1Queue {remove weapon}
#ADDITEM RT1Queue {climb hill}
#ADDITEM RT1Queue {wield weapon}
#IF (%trigger(RT1A)=0) {#EXEC %pop(RT1Queue)}

Completely simple to my way of thinking. Of course this how the brain naturally works when issuing the commands manually. If some event occurs that takes precedence over the already thought out actions, meaning what is queued up, then the queue can be dumped and a new set of actions put in. Again script and brain function match.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I agree with Zugg and Vijilante on this. As a software engineer, I would avoid anything akin to a "goto" statement, such as the #WAIT command. It is inefficient and drains your resources, not to mention that it is much less flexible when you want to make changes to your script.

I disagree that adding "true multi-threading" capabilities to CMUD would be a good idea. As someone who has written many multi-threaded applications on Windows and Linux, I know that it's truly painful to get all the synchronization just right. It would be many times harder to get it right when relying on a somewhat unknown software architecture that provides you an interface to its own threads.

The examples posted by Rorso and Vijilante are efficient and flexible. You can have any number of beeps you want. You can queue up as many actions as you want or even modify the actions on the fly based on other events that occur, such as dropping your sword instead of attacking successfully. It's just a different way of thinking for some of you, and that's going to take some adjustment.

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Posted: Wed Sep 06, 2006 5:20 pm

Also, don't forget about multiple trigger states. With multi-state triggers you can actually implement a full "state machine". And "state machines" are an excellent way to deal with complex loops and conditionals. Remember that you have full control over the trigger state and can change it in any of the triggers (or other scripts), so you don't even need to have the states executes sequentially.

You won't see multi-threaded stuff added to CMUD any time in the near future. I have a lot of experience with multi-threading (and CMUD *is* multithreaded in many areas). And what I have learned is that it's a *very* advanced topic and probably the easiest way to completely screw up your program and make it unreliable. Without very careful design, your threads can lock and cause all sorts of obscure crashes. Especially with anything that has a user interface, like CMUD. The Windows GUI API is not thread-safe, so anytime you interact with the user interface, it must be synchronized with the main thread, and that causes lots of locking issues. The concept sounds great, but the implementation is harder than most people believe.

What Larkin posted is correct...there isn't anything that you can't do in zMUD. It just takes a different way of thinking. It's like learning object-oriented programming the first time. At first you wonder why anyone would bother and you wish you could just write stuff the "old way". Then, once you get the hang of it, you wonder how anyone could use anything else.

zMUD (and CMUD) are the most powerful and versatile MUD clients available. But along with this power and flexibility comes a requirement to learn new things. If someone doesn't want to learn new things then they are welcome to use "simpler" clients.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Good point on the multiple trigger states. I had forgotten to mention that. I've implemented lots of state machines in zMUD, and those trigger states are almost indispensible. I remember when they were first added to zMUD and how much fun I had figuring out how to use them (and then trying to explain to others what the heck I was doing). I'm still finding fun, new tricks to perform with trigger states, in fact.

Beginner Joined: 02 Sep 2006 Posts: 10

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Almost everything in that post is incorrect. Multi-state triggers combined with other tricks gives you more advantages beyond what threads do for you with none of the disadvantages. I still say it's just a different way of coding that you are resisting because you perceive other script languages or tools to be superior.

Give us a solid example of something you want to do with #WAIT or with a thread, and we'll give you a better way to do it without them.

Wizard Joined: 14 Aug 2004 Posts: 1269

Well, Merzbow, if you think Lich is the bee's knees, then why don't you just use that? Personally, I can't think of any reason why I would need multi-threaded scripts, and prefer the event-driven model.

Posted: Thu Sep 07, 2006 5:08 pm

Have I got an application for you! It's an open-source, multi-threaded, object-oriented Ruby on Rails extension for Eclipse. It was developed by a self-directed, agile workteam employing UML, Ajax and extreme programming techniques. According to Slashdot, Google is already investing heavily in it and calls it the next killer SOA for the Web 2.0.

Seriously, if you want to use Lich, go right ahead. I'm sure anyone using compiled CMUD scripts would be happy to go pvp with you any day.

Once again, this thread has nothing to do with CMUD beta testing.

Beginner Joined: 02 Sep 2006 Posts: 10

I see nobody has responded to the points raised in my post. If I'm wrong then every modern operating system is wrong also. Look at any Linux or Windows - you'll find many persistent processes running as daemons that wait on any number of events and continue execution when woken. They have execution stacks and local variables and can synchronize access to shared resources. Plus they run as a unit, and can be tracked and killed as a unit. With ZMud triggers you have no local variables, you have no stack so you must re-enter from the top every time, you must explicitly map out every one of your desired states, and cannot safely share resources. Plus you get temporary triggers, alarms, and whatnot that proliferate all over the place to accomplish a single task. It's state-of-the-art circa 1982 folks. Anyways, there's obviously no chance I'm going to change your minds so adios.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will further back up Kjata's challenge saying I can present at least 2 other solutions that will work in the current zMud scripting engine, and that they will be sufficiently different from each other and Kjata's solution as to be called unique. As CMud is still in its infancy and beta stages I am not going to make claims, beyond saying that the proposed and thus far demonstrated improvements in scripting abilities are a vast leap over what zMud had.

Apprentice Joined: 08 Dec 2002 Posts: 152

In game what i play, a battle round lasts ~3 seconds.
In the start of it, i run a simple scan on my targets after a 0,5 sec delay.
If i would do that with #WAIT, i would not need to encounter even lot of lag to my scannings to give results too late. Addition to that, my other 372 triggers are onhold because the damn program is on WAIT.
On the otherhand, with #Alarm +.5, all runs 99% of times just fine opposite to that with #Wait i got 99% of times everything going straigth to hell.

#Wait might be easy when starting to do "coding" but it will backlash on you ASAP you got any triggers that could be triggered after your #wait command.
Trust me, you want to do it and learn it "right" in first palce.

Magician Joined: 29 Nov 2005 Posts: 482

I have situations where i use both although i can honestly say its more than likely out of quick fixes to coding that i need.

I.E. i want to fire off triggers in the class but need to #WAIT To keep it from firing off right away as it runs the commands i started as well as to #WAIT to #t- it until after everything has processed since it has no unique end firing string and the times are different based on the displays i ask for.

Mostly laziness but its effective to keep things from firing till that script is done.

Alarm is nice but i try to keep those to a minimum as well