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
tahnar
Beginner


Joined: 21 Mar 2007
Posts: 14

PostPosted: Thu Mar 22, 2007 9:33 pm   

Chain-calling other Scripts/Triggers
 
I have been digging through posts here and cannot find one which addresses my issue, so here it goes. The documentation still seems a bit spare on many things like Trigger States, the various types of Triggers and many of the commands available (specifically, examples of how each option might be used - it's not always as obvious as you might think!).

In the MUD I play, there is a fairly repetitive task which needs to be done where the parameters of what is done changes each run. For instance, I may be starting in one location, need to move to another to pick something up and a third one to drop it off. The movement can be fairly complex and not (that I can figure out) suitable for Speedwalking (or any other type of walking) because it often involves non-standard movement commands and pauses to wait for the game to finish an action (e.g, press a button and wait for an airlock to cycle before continuing movement).

I have broken up the activities done into smaller parts which can be pieced together on the fly to create a series of movements to achieve my task. This modular method keeps me from needing to write a separate trigger/script for every possible permutation of job which may come up. (Automapper would be perfect for this... except it doesn't work on this MUD, which has no standard way of describing room exits, room titles, descriptions or anything else, unfortunately.)

I enter a command such as: dojob 111 current start finish
Where 111 is the ID of the job to start, current my current location and start/finish are the job's locations. The dojob script sets the variables and then triggers some build code. The build code puts together a bunch of variables which will be called to catch triggers, for instance:

#VA cmd3 %concact("CODEmove",@start,"2",@finish)

After it generates all the commands necessary to do the full run of tasks, it does a #SHOW for each @cmd saved in order to step me through the events.

Now (thanks for keeping with me!), my problem:

When I activate dojob it works perfectly. By that, I mean all variables and commands are set up exactly as I designed and all the #SHOW commands are formatted correctly. My problem is that all the #SHOW commands are displayed IMMEDIATELY, which causes some events to be triggered long before I need them to be.

What I am essentially looking for is a subroutine ability. I want my main loop to trigger a command in sequence and then do NOTHING until that command is finished, at which point it moves on to the next command trigger. Right now, I get an output of:

#SHOW CODEmoveCurrent2Start
#SHOW CODEmoveStart2pickup
:
#SHOW CODEmoveFinish2Rest
<Only NOW does the sequence of commands generated by the cmd1 trigger finally start kicking in>

What I want to see is:
#SHOW @cmd1
<movement and other commands>
#SHOW @cmd2
<etc.>

Sorry for the long, long post, but I felt I needed to explain what I was attempting to do in detail. If you want still MORE detail, ask away!
-t
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Fri Mar 23, 2007 2:49 am   
 
Each time you are preforming a task I am assuming that your mud gives you a standard text. IE DONE! or Now you need to stirl the pot!

If this is the case you can create classes of triggers for each task so, If you were making swords for example you would have a class for swordmaking. Then you would have an alias that when you run it performs the first required task then turns on the trigger that tells you that it is time to do the next task. When this trigger fires it turns on the next trigger performs its task and turns itself off. Like a chain.

alias makesword
action
speedwalk to the forge.
get the tongs
light the fire
put iron and coal into forge
work the bellows
turn on the pump the bellows trigger.

Pump the bellows trigger
The fire is too cool to work the steal effectively you should fan the flames.
Pump bellows.

The fire is now hot enough for your metal working.
Hammer ingot into Longsword
Turn on the hammer trigger and turn off the pump the bellows trigger

Hammer trigger
The metal is still not quite the right shape for your longsword.
Hammer ingot into longsword.
turn on quench trigger

Quench trigger.
Your longsword is ready to be quenched.
Turn off hammer trigger
quench the sword
turn off quench trigger

Basically now you need to choose your method of decision making based on output. This is just one idea other people may come up with others.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
tahnar
Beginner


Joined: 21 Mar 2007
Posts: 14

PostPosted: Sun Mar 25, 2007 3:57 am   
 
I cannot make a trigger for each task, because many of them involve just moving around (Speedwalking not so good an option in this game - too many non-standard movement options). For instance, a sample "job" will consist of:

Move from starting location to a specific room
Accept a job and pickup some goods
Move back to the starting location
Board a ship
Fly to a new location
Disembark ship
Move from landing pad to a specific room
Deliver job
Move back to ship

As you can see, most of the tasks involve moving around. While I could, conceivably, set a #TEMP trigger for a room description, under normal circumstances I will have brief displays on - only room name showing (and that often isn't unique enough to trigger).

It is working fine, with care, so I can get along well enough. I probably need to wait until Zugg puts in actual Function functions, so to speak, to achieve what I am truly trying to accomplish here.

As a side/related note - It's very quirky using CMUD with this game (Federation II) - no data in the prompt, no standards for room names and descriptions, no room exits given (except in a non-standard way in the room description, and not alway then). The Automapper absolutely despised trying to work under these conditions. ;) I end up doing it mostly by #MAKE, with lots of corrections as it suddenly goes off and creates a room to the north (of a different room!) after I've just moved southeast. If anyone else has experience with this game and CMUD (or even ZMUD), I'd love to have a discussion. :)
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Sun Mar 25, 2007 4:17 am   
 
Ok, So how DO you know when a tasK is completed? I am guessing that you get SOME sort of user feedback. So speedwalking doesn't work well. Have you considered making paths or placing a string of directions into an alias? Have you considered placing these tasks into stacks?
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
tahnar
Beginner


Joined: 21 Mar 2007
Posts: 14

PostPosted: Sun Mar 25, 2007 12:17 pm   
 
For the actual tasks performed (collect, deliver) there is feedback. For the movement elements, the only feedback is the normal movement feedback (e.g., anew room popping up). What I have done for now took a lot of setup, but is time-efficient on the back-end.

First, I created an alias for every general movement possibility (LOTTA work). For example, earthac2lp and earth lp2ac (i.e., earth: move from AC to the landing pad or from the landing pad to AC) and something similar for every other planet I can be on as well as paths between planets (earth2mars).

I start job by typing: dojob nnn start finish where "nnn" is the job ID, "start" is the planet where the job begins and "finish" where it ends. The "dojob" alias the converts those variables into a series of commands it fires off one after another. For "dojob 123 earth mars" it would create the following triggers:

CODEearthlp2ac as CMD1
CODEearthac2lp as CMD2
CODEearth2mars as CMD3
CODEmarslp2ac as CMD4
CODEmarsac2lp as CMD5

Then it does a #SHOW for each of those codes, interspersed with two preset triggers (CODEpickup which sends the "accept nnn" and "collect" game commands and CODEdropoff which sends "deliver"). I could use #FIRE, of course, but I like the visual evidence for potential debugging. I name the triggers with CODE to avoid accidentally setting things off by chance descriptions. I could easily trigger on the pickup and deliver commands, but there are many more segments pieced together than just two those. Doing it this way cut down a lot of work, since I only had to code for doing specific segments and then string them together into a necessary chain instead of working out every possibility that might come up.

I tried to slightly shorten the coding by just using aliases instead of triggers (also would avoid the accidental triggering issue), but aliases do not seem to send correctly as game commands unless typed in directly. For instance, if marslp2ac is "e;n;n;w" then CMUD will send exactly "e;n;n;w" to the game, not 4 separate movement commands. I think that has to do with aliases not being expanded unless they are the first thing going into the pipe. In any case, it wouldn't shorten the code drmatically, just change the method used and make it look tidier in execution (but #FIRE in place of #SHOW would do that, too).

Not sure what you mean by placing the tasks into stacks, except in a C coding type reference, which I don't think CMUD can do (PUSH, etc.).
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Sun Mar 25, 2007 3:12 pm   
 
Look into the %push, %pop, %additem, %delitem, %numitem, and %item functions. They let you set up string lists. Which you can treat as a stack of commands!

#var tasks "jump|gotoEarth|shout"
#exec %pop(tasks)
#T+ jumptrigger
#T+ shouted

#trigger "jumptrigger" {You jump about like a fool.} {#exec %pop(tasks);#T+ gottoearthtrigger;#T- jumptrigger}
#Trigger "gottoearthtrigger" {You arrive at earth.} {#exec %pop(tasks);#T+ shouted;#T- gottoearthtrigger}
#trigger "shouted" {You shout loudly at no one in particular.} {#say Your tasks are complete!;#T- shouted}
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Sun Mar 25, 2007 3:13 pm   
 
Also, CMud should NOT be sending e;w;nw all to your mud at once like that in an alias, or at least if it is there should be an easy way to fix it. Please post the contents of one of your aliases that does that.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
tahnar
Beginner


Joined: 21 Mar 2007
Posts: 14

PostPosted: Sun Mar 25, 2007 10:09 pm   
 
I think it's a chain-calling problem with the alias expansion. Here is a sample setup:

#ALIAS CODEearth2mars {nw;w]
#ALIAS CMD1 {CODEearth2mars}
#ALIAS DOJOB {<many commands embedded, of which one is CMD1>}

If I just send CODEearth2mars, I get the normal movement commands - a NW followed by a W. However, if it is in the middle of running DOJOB and that sends the command CMD1, it was just sending "nw;w" all at once. I no longer have an active piece of code which is doing this (and couldn't duplicate the problem just now) - I modified it all to use triggers instead - but I am pretty certain the setup was along those lines. That was one of my original frustrations and the reason I switched all to triggers in the first place.

Now I set the CMDs up as variables (CMD1 = CODEearth2mars, etc) and then just #SHOW cmd1 and whatnot, to start up the triggers.

I'll check into the %pop/push function and such functions, though. Sounds like it could come in handy in my next project - autobacktracking (cannot trust automapper in this game - no standards!) - the ability to get back to the landing from anywhere in a specific zone.
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