Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Thu Jul 26, 2012 10:43 pm   

Interactive Scripting
 
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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Thu Jul 26, 2012 11:19 pm   
 
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.
Reply with quote
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Thu Jul 26, 2012 11:27 pm   
 
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.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Fri Jul 27, 2012 4:51 pm   
 
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.
Reply with quote
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Fri Jul 27, 2012 9:29 pm   
 
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:

Code:

#9 w
n
enter grove
climb tree
do something else
climb down
s
#9 e


Okay, but what if the first 'climb tree' fails? What if it fails 10 times or only 1 time, or even no times? My script can't adapt on the fly, so I'd have to make triggers to handle that situation. What'd be neat, I think, is something like a branching command which checks for a successful climb (and continues the script), or also checks for a failure and repeats the climb command again until it succeeds.
Reply with quote
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Fri Jul 27, 2012 9:31 pm   
 
So, I guess the command could look like:

Code:

#<COMMAND> {text1} {response1} {text2} {response2}


And maybe there could be some commands like #LABEL and #GOTO like in BASIC where a failure to climb could just #GOTO the place in the script where it issues the climb command.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Jul 27, 2012 10:11 pm   
 
There's always #WAITFOR.
_________________
EDIT: I didn't like my old signature
Reply with quote
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Fri Jul 27, 2012 10:12 pm   
 
It'd need to wait for two possible strings, though, no? And one WAITFOR would preclude another WAITFOR from, well, waiting. Right?
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Sat Jul 28, 2012 1:25 am   
 
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?
Reply with quote
DefinNormal
Beginner


Joined: 24 May 2012
Posts: 12
Location: United States

PostPosted: Sun Jul 29, 2012 12:22 am   
 
Could you not use #COND for this?
Reply with quote
Daern
Sorcerer


Joined: 15 Apr 2011
Posts: 809

PostPosted: Sun Jul 29, 2012 12:54 am   
 
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.
Reply with quote
Blain20
Beginner


Joined: 27 Aug 2010
Posts: 25

PostPosted: Mon Jul 30, 2012 12:37 am   
 
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').
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net