Zugg Software :: View topic

Newbie Joined: 25 Apr 2011 Posts: 3

Original Zmud line was

#ALIAS target {targ=%1;zone=%2;#trigger {You see* <@targ>* to the (%w)} {ff %1 %%1} {@zone}}

Basically, the alias "target" could be used to designate targets within a given zone.

Target Squid Ocean

A class folder named Ocean would be created with a trigger that would initiate an attack on the mob Squid.

Sadly, this code doesn't move seamlessley into Cmud. Any help would be greatly appreciated.

Jason

Sorcerer Joined: 15 Apr 2011 Posts: 809

You don't need <> to expand variables in CMUD anymore. Check out this page from the Changes for zMUD users section of the CMUD manual, it even has an example similar to what you're trying to do Very Happy

Newbie Joined: 25 Apr 2011 Posts: 3

The idea is to manually build a list of targets contained in a particular zone. When I scan, I see:

You see the Clan Training Dummy to the west.

I'm attempting to create an alias that will create the trigger and class folder (if required) for the targets.
Right now, the alias, Target, looks like this:

$targ=%1
$zone=%2
#trigger {You see * @targ * to the (%w)} {smile} {@zone}

typing Targ Dummy Test results in the Test Class folder being created, and a trigger appearing within that folder...as it should. However, the trigger reads:

#trigger {You see * $targ * to the {%w} {smile}

for some reason, the $zone variable is being properly expanded to create the class folder Test, but the @targ variable is not being expanded to create a trigger including the word dummy.

Elaborate, if you'd be so kind :)

Apprentice Joined: 03 Jul 2006 Posts: 110

nevermind -- misread the issue.

Wizard Joined: 22 Mar 2007 Posts: 2320

You haven't made clear what you want the trigger pattern to be. If you want the trigger pattern to be "You see * $targ * to the (%w)", then that is the correct way to do it (as you have seen). If, however, you want the trigger pattern to be "You see * Dummy * to the (%w)", you need to do something different. The #TRIGGER command will treat everything within that first set of braces as a literal string. To change that, you need to use #EXEC:

Newbie Joined: 25 Apr 2011 Posts: 3

#EXECUTE did the trick.

Alias: Target
$targ=%1
$zone=%2
#exec {#trigger {You see* $targ *to the (%w)} {ff $targ ~%1} ($zone)}

Creates a Class Folder for each zone and puts the trigger for each target within that folder. I can then scan to acquire targets and fire at them.

Thanks again.

Posted: Tue Apr 26, 2011 2:52 pm

Hmmm... you would have to use %concat to atring together all the parts of a new trigger like that.... triggers really should not be created automatically anyhow.
Have you considered a database variable?

Wizard Joined: 22 Mar 2007 Posts: 2320

Actually, Shalimar makes a good point. Depending on exactly what you are trying to do, it may be easier to do this as a stringlist or database variable. For instance, suppose @curzone is the name of your current zone, and @mobs is a database variable defined as in Shalimar's trigger. Shalimar's trigger is an interesting way to add new mobs to the list (I like that MXP code, Shalimar). Then all you need is the following trigger to fire the ff command:

Sorcerer Joined: 15 Apr 2011 Posts: 809

Wizard Joined: 22 Mar 2007 Posts: 2320

I think you are confused, Daern. Variables in both the first and second parameters of the #TRIGGER command (the trigger pattern and the trigger value, or trigger code) are _not_ expanded when executing the #TRIGGER command. They are expanded only when the trigger is fired, not when the trigger is created. The third parameter of #TRIGGER is different. The third parameter is the class in which the trigger itself should created when executing the #TRIGGER command. Clearly that has to be expanded when executing the #TRIGGER command, or else Cmud won't know where to create the new trigger.

In order to expand variables in either the pattern or the code when _creating_ the trigger, you need to use EXEC.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Wizard Joined: 22 Mar 2007 Posts: 2320

Hm. I apologize. I didn't bother testing because it's not supposed to work that way and you didn't say that you had tested it. If it is acting the way your test seems to show, then I believe you have found a bug.

Try typing "#trigger {$test} {$test}" on the command line. It should make a trigger whose code is "$test"; in other words, it should be creating a local variable within the trigger. It _should_ act the same way when executing #TRIGGER from within a script. Otherwise, there is no way to create local variables within a trigger. I can't check this right now from work. Can you test it and post your results?

Posted: Thu Apr 28, 2011 4:42 pm

No, local variables are *not* expanded within a trigger pattern, sorry. You would need to use #exec to do that.

When you put a variable in a trigger pattern, that variable is not expanded until the trigger is tested when each line is received from the MUD. If you want the variable expanded when the trigger is *created* then you need #exec.

If you don't want to use #EXEC, the other trick is to use %eval to force the expansion of the variable in the trigger pattern. When doing this you will also need to specify the optional first argument of #trigger which is the ID name. For example, this will work:

Sorcerer Joined: 15 Apr 2011 Posts: 809

Rahab, I had to modify that a bit, it wouldn't compile since it's trying to send the contents of the $test variable to the mud, and $test doesn't exist. #TRIGGER {$test} {$test = "testing";#show $test} worked fine, but $test = "testing";#TRIGGER {$test} {$test} created a trigger with the pattern $test and code testing. As I said before, the local variables are being expanded in the trigger's code, but not the pattern. So, there is a way to create local variables within a trigger - this problem only occurs if the local variable already exists when the trigger is being created.

Zugg, I'm aware that local variables aren't expanded within a trigger pattern, and I was asking why. Rahab explained it very well, and he also raises a very good point. As I just said, local variables _are_ expanded in the trigger code. If you want to make a trigger (or alias, etc.) with a local variable in it, and that local variable already exists, it will be expanded, and your trigger/alias/whatever won't work. Take this scenario, for example:

Wizard Joined: 22 Mar 2007 Posts: 2320

You're second option would not work, Daern. #EXEC is explicitly designed to expand variables. That is the main purpose of it. Your second solution would flip that on it's head, and break a lot of code as well.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Not if it's executing a string. I just ran this code on my command line: