Zugg Software :: View topic

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

I have some triggers that auto populate my spells into a bunch of different variables going by the spell name.

Spell variable Examples stored in /bott/TempVars/SpellVars/ folder:
@armor
@strength
@shield

Looking at the armor spell variable: /bott/TempVars/SpellVars/@armor

Armor variable stores these keys:

@armor.spelllevel
@armor.levelreceived
@armor.maxspelllevel
@armor.difference
@armor.increased

With these values (respectively):
6
4
10
4
0

When the MUD prints out..

Posted: Tue Feb 27, 2018 4:50 am

in this case try
$val=(%db(@armor, increased)+1)
#ADDKEY armor increased $val

You have to rely on the scope to pick the right variable with the #ADDKEY command... though unless you have more than one @armor variable, there is no need to specify classes anyway.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

I'm needing to pick up the variable @armor from the triggered text 'Your knowledge of (%*)increases!' since this will trigger on different spells.
Following your lead would I use it like so? I don't feel like this would specify the %1 as @armor

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Tested yours and it works perfectly when specifying @armor just as you typed, but I need it to dynamically change the spell name. Mine doesn't work as it creates a new @armor at the base class level instead of modifying the existing @armor.increased value.

Site Admin Joined: 29 Sep 2000 Posts: 389 Location: USA

Zugg fixed something in the server that adjusted the clock and Shalimar can't post again until it gets to be after when the computer thought he last posted, which is unfortunately tomorrow. We're really sorry about that.

Posted: Tue Feb 27, 2018 8:04 pm

If any of the classes along the way are disabled, then it can't see them via scope and it will create a new variable.
Alternately, you could copy the entire variable into a local variable and then assign that via a #VAR command with all the class stuff.

P.S. remove the % from your trigger pattern, (*) is a better 'anything' capture, or if it is only ever one word, then use (%w) to be more precise.

#TR {Your knowledge of (%w) increases!} {
$val=(%db(%concat("@", %1), increased)+1)
#ADDKEY %1 increased $val
}

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Thanks for the reply! Let me process your post and see if I understand what's going on! I'll check back with the results.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Thanks for the tip. I'll go through and change all my (%*) to (*)

Tried adding this to the script as you suggested. None of my classes are disabled so all triggers and variables should work.

Posted: Tue Feb 27, 2018 10:32 pm

It should be using the existing one unless it has the British spelling of armour.
I dont see why it would not be referencing the variable either...
Try:

$val=(%db(%eval(%concat("@", %1)), increased)+1)

Posted: Tue Feb 27, 2018 10:43 pm

$val=(%db(@{%1}, increased)+1)

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Let me try

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

That last statement is incrementing, but creating a new @armor variable.

Posted: Wed Feb 28, 2018 1:06 am

So something is preventing the original variable from being seen by the firing trigger.
Perhaps move the original so it can be found easier?
Just by the naming of your classes, this clearly isn't a temporary variable. (Truly temporary things should be in $localVars.)

If not, something like this might force it to be saved in the proper place...
But if we can't reference it in the first place, we should end up with the non-incrementing issue again.

$temp=@{%1}
#ADDKEY $temp increased %eval(%db($temp, increased)+1)
#VAR %1 $temp _nodef {class|stuff|spelled|out}

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Testing if I can post again....

Posted: Thu Mar 01, 2018 5:43 am

Yea, the forum clock got fixed, bad timing, but at least the post times look accurate now.
I really think the issue here is a disabled setting, whether its one of your classes or the original @armor variable itself.

The only other way for them to not have scope on each other is if the original variable was in a separate window object from the firing trigger
Or if the original variable is a separate package entirely that was not active in the window object the trigger is located in.
Neither of which seems likely (those are more advanced topics IMHO), but I don't know for sure.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Just curious, did you happen to run these suggestions through CMud yourself?

I'm going to create a new player session and try the absolute bare necessities and see if it has something to do with any of the other scripts I have in my current session. I appreciate your repeated help!

Posted: Thu Mar 01, 2018 2:29 pm

Which suggestions exactly?
I'm just troubleshooting here.
I have had scoping issues in the past as well.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Any of them really. Just curious how you help others troubleshoot.

Posted: Thu Mar 01, 2018 3:00 pm

It's mostly an accumulation of better practices.
I started off on this forum by asking questions, learning the intricacies of the various functions and commands.
As I grew more familiar with it, I found myself asking less, and answering more.

The #SAY command is one of the most powerful debugging tools, if only for letting you see the current value of a given variable, to ensure that it is what you are expecting.
Most issues are a result of a variable definition gone wrong, (bad pattern, string manipulation, or scoping), or general zScript syntax.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

I use #SAY and #SHOW quite often for testing and triggering.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

So I ran a separate test and came up with something that works but can't for the life of me get it to incorporate into my existing trigger that handles a little more data. Here is my two working triggers.

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

These are my two triggers I can't seem to get working properly.

Posted: Fri Mar 09, 2018 8:07 pm

In the first one...
(%*) should be (*) or (%w)
Also, if it is using a multi-word item name, white space might be causing issues, try something like this to get around it:

$name=%replace(%1, " ", "_")

Try using #DELKEY to get rid of increased, rather than setting it to 0. You are right, it is treating the data as a string...

It is possible you may have corrupted your package.
Does the Issue persist if you get rid of the original variable and allow it to recreate itself?

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

I'll try your suggestion. What I'm doing currently is I have three triggers one trigger is based on one word spells, second trig is based on two word spells, 3 for 3 word spells. Capturing them and combining the words together without any white space.

enchant armor would be enchantarmor

Using your suggestion I'm guessing would help bring those 3 trigs into one. Love it!

Novice Joined: 30 Sep 2004 Posts: 47 Location: Arkansas

Attempted using your suggestion you mentioned last week (shown below) I may have my syntax incorrect as I'm not real sure what the $temp _nodef portion is doing. The result of this is it's creating an entirely new variable at the base level (not in the class /bott/bot/TempVars/SpellVars) but retaining all the information saved (increased, splev, levrec) and actually incrementing increased correctly.