Zugg Software :: View topic

Adept Joined: 18 Jun 2019 Posts: 279

So...
I have a string list

statmod_types=Strength|Wisdom|Hit points|Mana etc

I have a trigger:-

Stat Mods:%s(*)%s: (%n)%s(*)%s: (%n)

Works fine.

I tried using:-

Stat Mods:%s(@statmod_types)%s: (%n)%s(@statmod_types)%s: (%n)

The documentation suggest that @vars can be used in triggers. I tried a #FORALL (%1) but the trigger failed. The documentation is, once again, not helpful.

Adept Joined: 18 Jun 2019 Posts: 279

Also...

On another trigger I tried this:-

%s{(%w)|(%w) (%w)}%s

Am testing for things like

corpse
bloody corpse

where I don't know if there may be one word or two. This didn't work.

Posted: Thu Jul 23, 2020 1:24 pm

You need to wrap your variable in curly brackets to use it in a pattern.
You can also use anonymous variables.

%s{@statmod_types}%s: (%n)%s{@statmod_types}%s: (%n)

{corpse|bloody corpse}

Adept Joined: 18 Jun 2019 Posts: 279

Ah. I was doing ({@var}) as I also want to capture the variable.

EG.

#ADDKEY dbvar_location/@statmod_types dbvar

Am trying to populate dbvars for eq items according to type (armor, weapon, etc) and have one var for each type. With a switch it is easy as I just use the literal word...but then my switch is about 16 items long. Using the contents of the trigger variable just means a couple of lines of code.

Posted: Thu Jul 23, 2020 6:07 pm

You can use both, but you have to use the curly for sure.

Adept Joined: 18 Jun 2019 Posts: 279

So does the trigger automatically loop through all items in the string list if it is used in the trigger pattern?

Posted: Thu Jul 23, 2020 8:38 pm

It's more like it becomes x triggers in one.
%1 (or whichever) becomes the literal string that matched in this instance.

Adept Joined: 18 Jun 2019 Posts: 279

After taking your advice to name temp triggers, several of them stopped misbehaving. However, one temp trigger that does not want to play nice...NOTE! This is NOT CODE, am just wording it simply.

MY 'popitemlist' gets item data from looted mobs:

name, room, zone, mob

basic items that appear from the 'death line' on a kill (You get someitem from the blahblah corpse of the mob of doom.) So I get someitem, mob, room, zone and drop them, into a dbvar. At a later stage (I intend to stick automation into a tick event), I manually run a pre_mid alias (mid = mob id). This alias is the crucial one, it takes the name and IDs an item to get the unique key. As I said, I want to quit the word search after a get a successful result.

pre_mid reads in a 'record' from the popitemlist. Initially I was 'popping' an item off the list, but this (obviously) depletes the list. Thus I have to keep copying a list back in. The reason I started to use a loop is that the documentation states that #BREAK can only be used in a loop and it gives an example. HOWEVER, #FORALL, #WHILE, #UNTIL are not mentioned. So I am not certain that #BREAK actually works outside of LOOP.

Then there is a second loop (currently FORALL) which takes each word and runs ID against it to see if I get a valid result. In every case, the loop runs through EVERY word. NO matter I now use a loop and have a BREAK statement in there.

Secondly, re. TEMP triggers. It seems a TEMP trigger cannot be run from within a function. For example, the above scenario to get an ID match could be better served by using a function:

Eg.,, valid_key=@get_idkey(@local string)

But I cannot get a TEMP trigger to work within a function. I switched get_idkey from a function to an alias and pass a parameter to it. I have to use a perm variable to store the result as it would be not be prudent to recall the parent script with a returning variable.

Posted: Fri Jul 24, 2020 11:36 am

#BREAK works in all the loops

Make use of $local vars
$this=@popItemList
Since they die outside of the script it doesn't matter if they get depleted, and you retain the master list.

There is nothing stopping you from defining a #TEMP from within a #FUNC, it works fine locally.
It is unlikely to have any new text printing to screen while the #FUNC is processing for it to be relevant to define it there though.

Everything in CMUD is code to some degree, likely this issue is as well.
Show me the code and I might be able to spot the issue.

Adept Joined: 18 Jun 2019 Posts: 279

Items (popitemlist):
rec1={name="pair|of|WTC|padded|leather|boots"|mob=whip master|room=19983|zone=Warrior's Training Camp}
rec2={name="WTC|regulation|belt"|mob=whip master|room=19983|zone=Warrior's Training Camp}
rec3=name="WTC|fatigue|uniform"|mob=whip master|room=19983|zone=Warrior's Training Camp}
rec4=name="WTC|regulation|flowing|cape"|mob=whip master|room=19983|zone=Warrior's Training Camp}
rec5={name="WTC|knout"|mob=whip master|room=19983|zone=Warrior's Training Camp}

pre_mid(alias)

Posted: Fri Jul 24, 2020 7:52 pm

In the first code block:

#ADDKEY itemlist $local_id

Has no value, just the key.

#ADDKEY itemlist.$local_id $write_item
Should be?
#ADDKEY itemlist $local_id $write_item

Adept Joined: 18 Jun 2019 Posts: 279

I am beginning to think I have been staring at this too long. I decided to go back to the beginning and make it all more modular.

This is the very first part...and I am buggered if I can see the problem. It fires but not compile.

Apprentice Joined: 09 Apr 2008 Posts: 168

At first glance It looks like you have an extra space between sections. I would remove the space after the first list and put it before the wildcard (like how you have it at the end).

Adept Joined: 18 Jun 2019 Posts: 279

If you are referring to the trigger pattern, that is not where the problem is. Almost EVERYWHERE I have tried, the problem lies with the use of %i. It seems to work for some things but not others. WHich makes almost all uses of FORALL pointless.

Posted: Mon Jul 27, 2020 5:45 pm

If you are looking at the trigger in the settings editor, there is a syntax checker under the Editor menu, also ctrl+k
That will tell you precisely where CMUD thinks the first error in your code is.

Also, if you have a loop inside of another loop, the nested loop uses %j instead of %i, and then it goes on to %k if there is a third nested loop, and so on.

#ADDKEY Mob_EQID/looted_keys @Mob_EQID/current_item_id $object

This seems unnecessarily precise
Do you have so many variables with the same name that you have to specify the folder/class it is in?

If not, this should do the same thing:

#ADDKEY looted_keys @current_item_id $object

Regarding %i, have you checked to be sure that the current value thereof is not what is messing your code up?

Adept Joined: 18 Jun 2019 Posts: 279

Re. classes, I am trying to prevent errant occurrences of the same variable being created at a different level by whatever script may be running. By specifying the class, the variable should not get created outside that class.

I was not aware of the %i, %j, etc thing. Most helpful to know.

Here's a question:

If I have a trigger pattern

<somepattern>(%w)<rest of pattern>

and I am working on %1, if I have a temp trigger defined within the script, would it have access to the calling %1, or even, would a temp trigger have access to any local vars created at the script root level?

Posted: Mon Jul 27, 2020 9:09 pm

No, #TEMP triggers only have access to @savedVariables, or those from their own pattern.
#LOCAL variables live and die in the setting they are created in.

Save things to a permanent variable if you want to use them in other settings.

You could use a #WAITFOR instead of a #TEMP if you want to still have access to local things.

Back to the class/variable issue:
So long as the trigger can see a variable with the name provided, CMUD will use that variable.

Duplicates only get made when you force it, by including the class name, or if the class containing said variable, or any of the parent classes, get disabled.
Issues usually only crop up AFTER you have duplicated variables and arent supplying the class as well.
It's classic scoping.

Adept Joined: 18 Jun 2019 Posts: 279

I appreciate your assistance. I have been having issues with triggers for some time and, logically, I suppose the problem is mine but I just cannot see where I am going wrong. The documentation is weak and appears to be of no help.

The class/var issue is a chore.

I have a class tree such as:

Equipment
- get_eq_data (all data capture triggers)
MOB - collecting basic items info from mobs for later identifying
SHOP - id all regular store items
INV - identify any other inventory items.

From the documentation:

********************************************************

What if you wanted to end the previous trigger before the 5 lines were up? For example, what if you wanted to collect the inventory until a blank line was received? Well, you can use the #STATE command to set the current state of any trigger. Setting a trigger state back to zero resets the trigger. So, you could do the following:

#TRIGGER "InvTrig" {Inventory} {#VAR Inv "";#TEMP {^$} {#STATE InvTrig 0}}
#COND {} {#ADDITEM Inv %line} {LoopLines|Param=99}

********************************************************
So, of course I expect this to be exactly what I am after...only it isn't.

My prime example is this:

Adept Joined: 18 Jun 2019 Posts: 279

Aha! I saw your other post re. trigger states and that made far more sense than the documentation.

So I altered my script, swapped the loop for a within and set the state. Almost all is working.

The single data item pattern is still not firing.

Posted: Tue Jul 28, 2020 12:01 pm

Try viewing the trigger in the settings editor, only switch over to the Pattern tab, along the bottom.
Put the literal line from the mud you are trying to match on the Test line, and see if your pattern does in fact match.

Adept Joined: 18 Jun 2019 Posts: 279

It has nothing to do with the pattern and everything to do with trying to figure out which line may only have one stat on it and thus where to put the pattern.

Resistmods may have 1-22 items, and statmods may have 1-11 items. Therefore I need an either/or pattern which gathers data from either two items on a line or one item, OR I need a way to have another COND trigger which will fire within reach of the main trigger but not to the point it steps into another trigger pattern. The problem with 'within' in this case is that, if the number is too low it may not be within reach of the main trigger, and if it is too hih it is probably going to encroach on another pattern

Initially, I had these two in their own class and within was a solo trigger to match a one-item line. If there is no other solution I may go back to that...but even that was iffy as the class needs to be open only at a certain point. The logical openings were when 'Resist mods' or 'Stat mods' text appears but then there is always a two-item pattern on that line and it means attempting a re-parse...which was where I was getting infinite loops.

Adept Joined: 18 Jun 2019 Posts: 279

In fact, reparse seems to loop infinitely at every opportunity.

Posted: Wed Jul 29, 2020 2:40 pm

If you have multiple patterns and you cannot be sure of the order they will occur, then you do NOT want a state-based trigger.
You want a group of individual triggers that are all in the same class, so you can enable/disable the class as needed.

Your "endStatMods" trigger seems like a good choice for turning it back off.

Rather than reparse, there is a checkbox in the trigger for 'repeat within line' that should do what you expect.

Adept Joined: 18 Jun 2019 Posts: 279

I managed (with some thought) to get it sorted by reverting to classes and having triggers for both 1-item and 2-item lines. Seeing as it is almost all contained within one root class, I figured "what an ideal opportunity to make it a package". So I moved it all into a package. Imagine my surprise (yet again) when aliases I have for getting things out of containers and putting things into containers (g1,p1, g2 ,p3, etc) are no longer functional. The aliases still exist and if one types #ALIAS the entire list is revealed and lo! they are still there...but no longer working...from anywhere!

So packages are not as useful as the documentation states. Add to that, when I moved things into the package, some aliases actually disappeared! Now I have to try and recreate them.

UPDATE: It is some bug in the software. Like other issues, a restart cures the invisible alias thing...in fact it seems to be most things, not just aliases. Room scripts fail to fire and speed(safe) walks are failing, with movement of only 2 or 3 rooms before giving up.

Posted: Sat Aug 01, 2020 3:29 pm

Packages are funny, you need to add them to your session.

Click on the sessions button.
Edit your session.
Move to the Packages tab.
If your package is not on the list already, click the green plus button to add it.