Zugg Software :: View topic

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I have written a lot on this forum about my troubles writing a blocking command and yet it's still a big problem for me. I have made solutions that seem to work most of the time but I find that they all seem to trigger the less robust places in CMUD at some point making it blow up with a nullpointer, index out of bounds or something like that.

Now instead I'd like to suggest implementation of commands that all "Simutronics enabled" clients support and most other mud clients for that matter.

What I need is commands that:
* Wait for the prompt to continue
* Wait for certain feedback from the mud
* Wait for a roundtime (this is a kind of combi command that first waits for feedback on the command and then waits the amount of time that the feedback states. It will say something like: "You swing your mallet at the goblin. Roundtime: 10.")

Commands can be seen on the URL below:

http://www.play.net/playdotnet/play/stormfront_scripting.asp

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

It's not that easy, Matt. I've posted about this several times and it always ends up being a rather complex solution. Yours is too - if you don't believe me try and make just a small script using this technique. It gets ugly. A built-in solution would be nice.

Posted: Sat Apr 19, 2008 8:13 pm

You can already do things the way Matt's suggested, or with the various #wait commands. What do you mean by "built-in"? What do you think could be done to make it easier?

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Apprentice Joined: 12 Jun 2006 Posts: 106

CMUD will never have the support you want for simutronics games. Everything can be done with it, but it's more work. I <3 zMUD and wish I didn't have to use something else for my combat scripts, but it's too much of a pain.

Posted: Sun Apr 20, 2008 12:14 pm

kjaehus: You still haven't actually made any suggestions. What exactly would you want the blocking command you're talking about do? What would you like its syntax be? How would it let you solve the problem you're having?

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Posted: Sun Apr 20, 2008 9:45 pm

EDIT: Ninja'd by Viji - trust me to spend ages looking things up to make sure I'm not missing something :( This post is addressed to kjaerhus.

Thankyou very much, by the way, for taking my post in the spirit it was intended. I agonised for a while about changing the tone somehow, because I thought it sounded a bit accusatory - thanks for not interpreting it that way and coming back with good suggestions.

So, here're my thoughts on each of your proposals.

1) CMUD needs to understand when something's a prompt. It can't just assume that every line not ending in CRLF is a prompt, because sometimes the MUD will provide lines that're prompts, but that aren't the prompt (like in-game text editors). So the way you would do this is, as I said before, with one of the wait commands - in this case, #waitsignal. Use #signal within your prompt trigger, and have any scripts you want to wait until then use #waitsignal to wait for it. Job jobbed.

2) There's already a command that does exactly this. #waitfor.

3) I'm not quite sure what you're wanting here. It seems like #waitsignal with a timeout would perhaps do what you want, but I'm not sure what you mean. Reading the beginning of your post where you detail your issue, it sounds like a simple #wait might also be what you want.

The trouble with all these commands, of course, is that they use threads. The reason we suggested a FIFO is because it avoids threading issues, but threads are the only way to pause script execution like you want. If you're waiting and not using threads, what happens if the trigger fires again in the meantime?

With a FIFO, you have a couple of options - you can either have your script pretend the command was added to the queue when the previous command is sent, and start waiting then, or your can start waiting immediately and run both commands when their wait conditions are satisfied. You can do either of these with threads as well, it's just harder to do the first well and you have the added annoyance of dealing with threads. And if you wanted execution to pause without using threads, we'd be back to the days of not really knowing when it was going to execute and what was going on, which can't be a good thing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

And Fang provided to real explanation why no one was too keen on writing up a script like I just provided. It also is not robust enough to handle more things as your needs grow, and that is part of why it should be avoided.

As you can see meeting your minimum requirements is very easy. CMud has the commands to do it already. I could even simplify that roundtimeCommand more, but I will leave that as an exercise for you.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Thanks for your nice and compact solution, Vijilante. I am sure this works and I have something I've made myself that works most of the time too. I based my own solution on short waits though so I can cancel the wait if I find that the pattern I wait for will never match anything. To my knowledge you cannot stop the #waitfor unless you set a timeout which in some cases would have to be pretty long to take things as lag for instance into consideration.

I do have problems like sometimes a roundtime is ignored or an exception for something internal is thrown and I do find this disheartening. That's why I suggest built in commands so the complexity is out of my hands as a user. It's functionality that you can find in many other scripting engines I believe (Simutronics' own Wizard and Stormfront, Genie3, YASSE, Warlock2), so I think it's not a completely unreasonable request.

EDIT: This was a reply to Vijilante's first response. You guys are quick... Smile

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Thanks to you both (Fang and Vijilante) for your quick answers. I'll summarize a little here on the situation from my view.

I've always been very happy about zMUD but after the change to CMUD I have used more time with the scripting engine than playing - a lot more in fact. A lot of this is caused by changes to CMUD (like #wait) and probably quite a few bugs in CMUD too. A lot of bugs have been in my scripts too I am sure but I think it's not easy to see what is wrong when CMUD suddenly explodes so I've often felt quite lost when this happened. It still does - a lot. I've tried many solutions but it's like I've always hit my head against something new.

I think if I had something to say I'd make an effort to make CMUD clean and robust instead of adding complexity. Complexity belongs under the hood in my opinion. Why add multithreading features to CMUD and then discourage the use of it? Wouldn't it be better to handle the complexity of multithreading in the engine and simplify the scripting instead? Of course this would demand more work from a CMUD development point as adding such functionality would demand more than merely exposing underlying features to the user. As a standard user when would you ever want to care about threads? If I need to wait I need to wait. I don't want to know that a new thread is created so that my triggers will still run - I expect them to and I expect my window with all the buttons and so on to be responsive. Couldn't this expected behavior be used to actually implement multithreading without bugging the poor users who I think in most cases are mostly interested in playing a mud and then enhancing the experience with some nice scripts which really can't be written fast and easily enough so that the main focus is on playing.

Another thing is why does CMUD have to explode all the time? I feel like when I do something wrong it doesn't catch the exception in the engine and try to give me an explanation of what went wrong with the script. I just get a hard exception and I have no idea what went wrong really. It might happen in a script that have run nicely for ten minutes. Suddenly BANG!!! - something went wrong. Many times this causes CMUD to be unstable and a restart is needed. Maybe I am asking for too much I don't know, but I feel something could and should be done to improve this.

EDIT: Well, I might have forgotten the point that connects this post with the topic. My point is that the more powerful commands CMUD offers out of the box the less complexity I have in my scripts therefore my scripts would be simpler and cleaner.

Posted: Sun Apr 20, 2008 11:53 pm

CMUD doesn't discourage the use of threads - in many places, they're very useful. We, the gurus, tend to discourage the use of threads, mostly because the kind of person who has to ask questions about threads is the kind of person who's going to make a total arsecake out of it and then ask for help. We're volunteers and it's a lot of hassle. Nobody likes debugging threading code, let alone someone else's threading code.

Your major point, one about complexity in the scripting language, is a very knotty problem and one I don't really feel qualified to talk about. I think it hinges on the idea of providing as much power as possible to the user, to make them able to do as many things as possible. That's most likely the reason that threads are exposed to the user, and it's also presumably the reason why so many other things are. And I can't see that being a bad thing - the more functions the user can manipulate, the better their scripts will be. Some MUDs are completely different to others, so one solution won't suit everyone. You need to be able to make your own.

But of course that's all assumption and speculation, mostly based on what I remember of discussions around the time that threads were added. You could try looking up some of those old topics and read the discussions there, but I suspect the only concrete answers will come from Zugg himself.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

SubAdmin Joined: 18 Nov 2001 Posts: 5182

There actually has been major focus first by Zugg and followed through by all the beta testers to try and make sure threading doesn't get in the way of users that are oblivious to it.

Lets use my simple script from above as an example. It doesn't say anything about threading and it will work very easily to start. I think a new user would readily find the required commands in the help. Of course all the wonderfully helpful people around here would point out some of the other fancy commands and flourishes that are in my example, and the new user could go on there merry way.

They generally wouldn't notice that threads are laying around as they perfect the feedback text, and they really wouldn't have to. The only way they would ever find a problem is if they decided to try the #THREAD command, or they used a single load of that session with the failing script for a long enough time. You already know that the problem is too many threads laying about.

-----
Let's move to the next thing that a new user would want to do, a trigger. Again working with my above script a new user creates a simple trigger

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Mon Apr 21, 2008 7:40 pm

I may be completely off base, because I don't play the Simutronics MUDs but the whole concept of roundTime is fairly intuitive in understanding but complex in implementation. I would argue that attempting to script it, in any form would require a fair amount of coding effort. I imagine 'hiding the details' for the type of implementation you describe would either 1) limit the functionality and efficacy provided by multiple threads or 2) create a two tiered threading system that would be very error and bug prone.

With that said, I don't think it's unreasonable to expect someone who want to code the roundTime to tackle the compexity that also comes with coding in a multi-threaded environment.

My $0.02

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Wed Apr 23, 2008 8:12 pm

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Wed Apr 23, 2008 10:37 pm