Zugg Software :: View topic

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

I am trying to make some dynamic calling of scripts and have found some problems with #EXECUTE. I would expect that the following lines would do the same:

Sorcerer Joined: 13 Jan 2006 Posts: 715

I'm curious as to why you would think you needed #EXEC in the first place?
You can call aliases directly in scripts or from command line.

Posted: Sun Jan 27, 2008 6:39 pm

I thinkyou mean to use a pattern of {$commandTrigger} in your trigger.

#exec does call aliases properly (or should). What do you mean by "feedbackCommand will not be blocking"?

And finally, what's the point of the waitsignal? It seems like you're creating a trigger that then deletes itself when it goes off. Wouldn't it just be easier to use temp triggers, or to have the #untrigger commands in the triggers themselves?

If the objective was to have each command sent sequentially after a prompt (and that's what you meant by "blocking", preventing the other aliases from being run) then that won't be possible because of your use of waitsignal - each feedbackCommand is run in its own thread, which means that they should all execute simultaneously.

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

The idea of the "feedbackCommand" is to send a command to the mud and wait until mud has registered the command and performed it. This is why I call it blocking - script will not continue until feedback is received from the mud. The signal is used to allow the script to continue - as you see after executing the command it will wait for the signal before proceeding.

The reason I use #EXEC is that I want to get the name of the alias as a parameter to my script. That way I have to use the command or the name of the alias will just be sent to the mud instead of invoking the alias of the same name.

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

None of the gurus have an idea about a solution to this? I do think there IS a bug with #EXECUTE but perhaps you have solved the problem in another manner. How do you ensure that the previous command is accepted by the mud before sending the next one? And don't you ever call aliases with #EXECUTE?

Posted: Mon Jan 28, 2008 5:01 pm

I do call aliases with #execute, and it works. Simple test:

#alias test something
#exec test

sends "something" just as it should.

The method I use for this particular problem is with a FIFO list. You keep the list of commands in a string list, with parameters and everything, and then each time your "you can do something else" trigger fires, you pop another item from the list and #exec it until your list is empty. A complex implementation of this principle was written by Vijilante (of course :P) for zMUD - you can find that thread here. The script was updated for CMUD by Guinn and Arminas - you can find their code in this thread. At the end of that thread, you'll find some example Lua code that tries to simplify the data structures involved.

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

I know that you can use #EXECUTE for aliases - I am saying that it's not working properly. Have you tried the example I provided in the first post?

I have considered a fifo before but still I have to decide when to stop putting things in the fifo then (my scripts are looping indefinitely so I can't put all commands in the queue at once) and I still have to find out when it's ok to fire the next command. This is what "feedbackCommand" does. And it works well unless you try to call the alias with #EXECUTE.

Thanks for the threads though, I'll take a look at them to see if there is something I can use there.

Posted: Mon Jan 28, 2008 6:08 pm

I think you need to better explain your problem. First you ask if "#execute was not made to call aliases" - but now you agree that it can call aliases. So is your issue with the functioning of your script, or with using the #exec command to run that script? What exactly is happening that you don't expect to, or isn't happening that you do? What're you doing in each case?

Logic for adding items to a FIFO list can be anything you like, really - you can have an #if check in the trigger that adds another item to the list that checks for a certain number of repetitions, or you can have another trigger that disables the first when a certain line is received, or anything else you like. It's a flexible system.

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

A screwdriver is not made for breaking coconuts but that doesn't mean that it's not able to do it somehow. There may be a better alternatives though... ;-)

I don't need a fifo because this kind of construction solves a problem I don't have currently. Whether you use a fifo or not you still need some kind of mechanism to ensure that you do not fire the next command before the current is eaten by the mud. In the example I have provided there is an alias for this called feedbackCommand. It takes three parameters:

$command : the command to be sent to the mud
$feedback : expected feedback. If empty blocking will stop when prompt is received (myprompt>). If not empty blocking will stop when recognizing $feedback pattern in mud output.
$hideOption : an option to hide the command. If empty the command will be shown on the screen.

Now let's discuss the contents of the feedbackCommand alias:

Posted: Mon Jan 28, 2008 7:36 pm

I understand your problem now. I'd posit, actually, that the bug is with the normally-called alias and not with the #exec'ed version. You're assuming that the aliases will be executed in sequential order, which isn't true. By using a thread-related command (#waitsignal) to pause the thread, you're causing the alias to be run in its own thread. What this means is that when your doSomething alias is run, the three feedbackCommand aliases create three separate threads. Each thread runs through its own command list until it gets to the #waitsignal, sending the command three times in the process. Whichever of the three triggers fires first causes the feeback signal and the triggers are deleted. This is the way it should be working, and if it's not working that way, that's the bug.

I suggest a FIFO list because you don't actually need "some mechanism to ensure that you do not fire the next command before the current is eaten by the mud". When you add items to the queue, they can stay in the queue for as long as you need - adding an item to the queue isn't linked to getting an item from the queue. So as long as you only get an item from the queue when you're ready for another command to be sent, there's no problem. For example:

#trig {You can practice again} {SendNextQueueItem}

where SendNextQueueItem is an alias that pops an item from the queue and sends it. Since youre obviously ready to practice again once you get the message "You can practice again", there's no problem with too many items being sent.

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

#WAITSIGNAL is blocking the current thread or so the documentation says. I don't see in the documentation that #EXECUTE creates a new thread and continues. Do you disagree?

In your fifo system how do you know when it's time to fire the next command? When you see a prompt? What if that is sometimes too early? In Dragonrealms which I play there are roundtimes for some commands. So in some cases I wait for the prompt or a pattern and in other cases I need to wait until a certain amount of time has elapsed.

EDIT: Another point I thought I made before: My scripts run indefinitely so I still need a mechanism to stop me from blowing up the fifo.

Posted: Mon Jan 28, 2008 8:16 pm

I'm not arguing that #waitsignal doesn't pause the current thread - #exec doesn't create a new thread, and I never claimed it did. The point is that #waitsignal is specifically designed not to prevent any other scripts from being run - it's for this reason that an alias containing a #waitsignal is run in its own thread.

When abilities have individual cooldowns, it complicates matters. If I was only worried about queueing individual abilities (that is, I can use as many abilities as I like, as frequently as I like, so long as they're not cooling down) I'd probably use a separate queue for each.

But if abilities have cooldowns as well as being being on some more general system (like every time I use any ability, I have to wait 10 seconds before I can use that ability and also 2 seconds before I can use any ability) I'd use the more general system from the second thread there. If you take a look at my Lua code, you'll see that the intention is that an ability can require, take and need whatever flags you like. So it can require that the two-second wait be finished, and also that the ten-second wait is over. A different ability could have no cooldown of its own but have to obey the general 2-second cooldown. Yet another ability might not cause the 2-second cooldown (and thus wouldn't take it, but would still require it) while having no cooldown of its own. Another ability might be spammable any time you like, and would require and take nothing. In a more complex situation like that, I'd use the system outlined in that thread.

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

Well, I thought I could use the #SIGNAL / #WAITSIGNAL for something. Seems I can't or at least not if I choose to use the #EXECUTE command to run aliases. Why that is I am not sure I understand. As I only have one thread (at least to my knowledge) I would have thought that it would work nicely. Whether it's a bug that it works in one situation or that it doesn't work in the other I'll leave to Zugg (if he ever gets in here). I don't see why it shouldn't work as I thought it would.

Maybe I'll try utilizing the #WAIT command now that it's fixed. I do have a lot of scripts based on my own system which has normally worked. Until recently I didn't rely on the #SIGNAL / #WAITSIGNAL but on #WAIT instead. There were some other flaws to that but maybe they are gone in v2.0. Anyway I am not keen on the fifo and I am still not sure I understand how it should bring me further. Basically what I need to have is a mechanism to ensure that my scripts are run efficiently, not too fast and not too slow, and I really have no need to queue things. Then I'd just have to look at the queue all the time to see if there was room for another command as my scripts would otherwise smack it down instantly with some out-of-index exception.

Thanks for your help so far.

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

Apprentice, YAY! Do I get a new spell now? Razz

Posted: Mon Jan 28, 2008 11:37 pm

The trouble is that if you use any of the commands that relate to threads (basically, anything with the word "wait" at the start, including #wait) then the script is run in a new thread. The idea is that if, say, a trigger goes off while your script is waiting, then the trigger script won't be held while the wait is happening, which (as you can imagine if your trigger never fired to do the #signal, or indeed if the command line was forced to get in line behind the script as well, you'd have no way to cause the signal to resume the script) is a pretty bad idea. So #wait will cause you the same problems.

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

Well, until now wait has always been working for me although there have been some flaws to it. I don't know if this is the case with CMUD v2 though.

I think perhaps Zugg is making things too complicated here. Being a powerful client program doesn't necessarily mean that user have to possess greater powers to use it. As I see it a mud generally consists of two things: 1) A simple request/response model where the client sends a request to the mud server and it responds, 2) The mud server pushes events to the client. Why I have to deal with threads in this matter I really can't see. I realize that while my script is blocking because it is waiting for server response I WOULD like to actually be able to catch the response and other events with triggers so those should of course run in other threads but it doesn't have to exposed to me. I realize that it's probably easier to not encapsulate the complexity of multithreaded programming to the users of CMUD but I think people would write more robust scripts faster and use more time actually playing their muds if he did. I think writing CMUD from scratch gave Zugg a perfect chance to make a more clean and robust client but instead he apparently focused on adding as much complexity from the start on behalf of robustness and simplicity that CMUD while still a relatively new client looks pretty old to me.

Well, enough for my two cents. What I am trying to achieve here should actually the most simple task of all. I just need a construction to ensure that I don't send a new request to the mud server before it has sent me a response to my last request. Very simple - or so it should be. Now I don't need a queue but anyway the queue manager would still need to know when to take the next element from the queue and send it to the server so there really is no difference. How you achieve this I cannot quite figure out. If you can tell me it would be nice. In other words how do you get your "You can practice again"?

Posted: Tue Jan 29, 2008 12:44 pm

Threads were only introduced in v2 - check the changelog. The point is that the #wait command really requires threads to be of any use, otherwise, as you say, you can't respond to anything else while the script is waiting. Before threads were added, in CMUD v1 and in zMUD, using the #wait command in triggers could cause problems (for example, if the same trigger fires again while the first one is still waiting, but there are no threads, how does the client know when to send the commands?). So it was either a case of adding threads or removing #wait. And since Zugg decided to add threads, it made sense to add some more commands to be able to manipulate them - some people make use of them, and some people don't. If it wasn't exposed, then nobody would be able to.

But I digress. Your problem is one where you're waiting for certain text from the MUD to signal that you're ready to send another command - in your script's case, the contents of the $feedback variable is the string you're waiting for. When you receive this text, you're ready for another item to be sent to the MUD. Perhaps it would be easier if you didn't think of the script as having to prevent another item from being sent to the MUD, but the script only choosing to send a command to the MUD once it's received the text that lets it send another command. At the simplest level, you could do something like this:

#trig "AutoPractice" {You can practice again} {practice @currentskill}

and then enable and disable this trigger to continue practicing automatically. You could add another trigger to automatically disable it if you receive text saying you can't learn any more, or a counter to count the repetitions and stop after a certain number. But at the simplest level, this is what the script is doing - waiting for the text that indicates it can send another command, and then sending another command. Everything else is just logic to decide which command to send, if any.

With the script I mentioned previously, you can keep track of a large number of cooldowns. An ability could require that its own cooldown be finished before it's run again, and if you attempt to remove an item from the queue when that ability hasn't cooled down, it'll remain on the list. The script will iterate through all the abilities on the list and only remove them if they're able to be used at that time. If not, they remain on the list.

You ask "how do you get your 'you can practice again'" - you already have this data in your $feedback variable. If that variable's not specified, you've chosen to use the prompt - so you try to remove an ability from the list on your prompt, and on the text in $feedback. If there's nothing on the list that usable at that time, then the script won't send anything, so you can call it as many times as you like. You could have a 0.5 second alarm that tries to remove an item from the list, and things will still only be removed when they're able to be used.

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

I never used #WAIT in triggers so I did not have any problems related to this. What I use triggers for is signaling to main script that it may continue. Now forget the queue for a moment and pretend you have an alias with two lines each doing something in the mud:

Posted: Tue Jan 29, 2008 1:55 pm

There wouldn't be any obfuscation at the level you describe: #alias feedbackCommand {#additem CommandQueue %1} will add items to the FIFO list to be executed. There'd just be more code outside that alias instead of it all being in there.

It's actually only single-use alarms that have a 500ms minimum; #alarm 0.250 {#say omg spam} works fine.

And finally, this problem isn't really any harder to solve in CMUD than it is in zMUD - you just have to use a different method. A #wait loop is a horrible way to solve this problem, I'm sure you'll agree - similarly, the method you were using before won't work very well any more.

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

I appreciate your answers but we are not getting closer to a solution. Try to solve it without the queue please. You see I don't really want the queue as it would put some restrictions to the way my script works and I don't need the advantages that a queue mechanism generally offers.

Examples of things that may be a problem with your queue as I see it:
* How will I know that I can put another item on the queue? (this is similar to the problem of deciding that server has responded) Remember that my script loops run indefinitely.
* How will I be able to filter on this particular command or do anything out of the ordinary? I don't know when the command is sent to the server so only way is to let queue handle it meaning that this will have to be quite complicated.

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

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

In the version history.

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

I think that would be bending the intentions of #CONDITION a little and would probably obfuscate the scripts. Do you have a simple example that works?

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

Ok, so I dislike alarms a little less now. Doesn't quite solve my problem though. As I mentionen in the post it is another matter... ;-)

Posted: Tue Jan 29, 2008 2:57 pm

To loop it indefininately, you'd need to start it manually, but then you could have a trigger:

#trig {Response from first command} {second command}
#cond {Response from second command} {third command}
..
#cond {Response from nth command} {first command}

But you'd need to reset the trigger with #state 0 at the same time you turned it off.