Zugg Software :: View topic

Beginner Joined: 27 Aug 2010 Posts: 25

If there is already a way to do this, please point me to it. I was thinking of some sort of interactive scripting in CMUD where the script can create one-time triggers and wait for the MUD to respond according to the trigger, and then issue commands, such as #NEXT or #REPEAT to control flow of the script. I believe most of what I'm thinking is possible in CMUD already, but it may be a bit less messy if there was an easy syntax to work with.

For example:

On the MUD I play, I can run a script which tries to climb a ladder. The script can set up a temporary trigger to look for a string which indicates success or failure of climbing the ladder. If failure, it should #REPEAT the last step. If success, it can advance to the #NEXT step.

I think the key here would be syntax to allow easy scripting. Or perhaps someone might want to create a converter.

Wizard Joined: 22 Mar 2007 Posts: 2320

You don't need temporary triggers. You can do all this with ordinary permanent triggers. The scripting is already about as easy as such a complex task can be. If you give us more information about exactly what the mud sends and exactly what you want, we can help you write it.

Beginner Joined: 27 Aug 2010 Posts: 25

I think what I'm asking for is a way to write all of the trigger states in one text file/area with less zScript syntax. It'd speed up script-writing.

Wizard Joined: 22 Mar 2007 Posts: 2320

I'm not at all sure what you mean by "write all of the trigger states in one text file/area with less zScript syntax". If you are trying to produce zScript code, you have to have zScript syntax. There are no converters from other scripting languages, and even if there were, it would be just as complex to write in that other language as to write it in zScript--probably a lot harder since few scripting languages have anything similar to cMud's triggers. [edit]I should note that Cmud allows scripts to be written in a few other languages, including Lua. But it's not any simpler than zScript, and handling variables and such is easiest in zScript[/edit]

zScript syntax is about as easy as you can get when trying to do complex things like the conditional actions you are talking about. The concept "look for a string which indicates success or failure" can't really be made any simpler than a #TRIGGER pattern. And the concept of "if failure repeat, if success advance" requires maintaing a command queue and structured logic for executing and advancing the queue. I don't see how you could design this logic any easier than zScript. Saying "if failure repeat the last step, if success go to the next step" sounds easy, but that doesn't tell the computer how you want the command queue stored or how you add commands to the queue, let alone what to do if you never get a "success" response or how to stop the loop manually if you need to.

You could try the Script Wizard in the Package editor. That gives menus for creating basic triggers, though nothing for this kind of command tracking. You would still have to figure out and design the scripts to handle the command queue.

Beginner Joined: 27 Aug 2010 Posts: 25

Currently, I can write a script that makes my character run around the MUD. However, sometimes the character fails a random roll. Instead of splitting this single script into pieces with different triggers and such scattered between nodes, there could be a branching/repeating scripter that keeps it together. For example:

My current script looks something like this:

Beginner Joined: 27 Aug 2010 Posts: 25

So, I guess the command could look like:

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

There's always #WAITFOR.

Beginner Joined: 27 Aug 2010 Posts: 25

It'd need to wait for two possible strings, though, no? And one WAITFOR would preclude another WAITFOR from, well, waiting. Right?

Wizard Joined: 22 Mar 2007 Posts: 2320

There are two options. One is to have a multistate trigger where one state grabs all mud output and tests whether it is a success or fail message. That test could be done in a #SWITCH command, which looks somewhat like what you suggested. But in truth, I believe the best option really is having multiple triggers.

Is there some special reason that you don't like the option of multiple triggers? It is the cleanest method of doing what you want, and #TRIGGERS are optimized to do exactly this. While you seem to consider this to be "one script", it is quite normal to break scripts into convenient pieces, such as functions, aliases, and multiple triggers. If you are going to compare this to a BASIC program, you should consider your entire session to be a single BASIC program, with each of your triggers and aliases communicating within the program. A single trigger shouldn't be considered a whole program--it is only a single function interacting with other scripts and the Cmud program. Trying to move all the testing you need into a single trigger is actually going to require more code, and more Cmud processing time, than breaking it logically into separate triggers. You can do it, as I said, with a multistate trigger, with a MANUAL-type state testing every line from the mud, and a #SWITCH to determine the action, but from Cmud's perspective, that is functionally equivalent (though a bit heavy-handed) to separate triggers testing for FAIL or SUCCESS messages. But if you want to do it that way, that's perfectly fine. I'll be happy to help. Can you describe the specific situation with a bit more detail?

Posted: Sun Jul 29, 2012 12:22 am

Could you not use #COND for this?

Sorcerer Joined: 15 Apr 2011 Posts: 809

You could to a certain extent, but since only one state can be active at a time, it's hard to pick up both a success and fail message in one multi-state trigger. It's not impossible, you could include both options in the pattern with something like ({success message|fail message}) then check in the code which one it was and act accordingly, but that really makes no sense. If you design a trigger pattern that matches on two different things, only to check which one was matched and do two different things, it's both more logical and more efficient to make it into two different triggers, each with their own part of the pattern and their own part of the code.

What might be a more realistic way to code this would be to have only the success messages in the multi-state trigger, and separate triggers for the fail messages that get enabled and disabled as required. Using Blain20's example from above, you could have a state that fires on a successful "enter grove" message, that will enable the trigger that fires on the fail message for the climb tree command. The next state will fire on the successful climb tree message, and will disable the climb tree fail trigger. That way climb tree will be sent repeatedly as long as you fail, and as soon as you successfully climb it, you continue through the multi-state trigger, doing whatever else is required in this sequence of commands.

Beginner Joined: 27 Aug 2010 Posts: 25

Thanks for the help, guys.

After stepping back and thinking about the issue, I think I could do this:

One single script runs around doing what I need the character to do. When the script issues a command where my character can fail, I can pause the script with a WAITFOR to wait for a success message before continuing on. Another singlular trigger can wait for the failure message and reissue the command again (such as 'climb tree').