|
SpiritWolf Wanderer
Joined: 02 Jul 2002 Posts: 74 Location: USA
|
Posted: Wed Apr 21, 2004 5:45 pm
Using #forall in a trigger |
This trigger is part of a larger set of triggers I have to stick stuff into an equipment database. Problem I'm having is that it only wants to capture the first item out of the string list and seems to ignore the rest.
Here is the trigger:
#TRIGGER {Item is: (*)$} {#FORALL {MAGIC|WHOLE-BODY|WHOLE-HEAD|ANTI-FEMALE|ANTI-MALE|NOLOCATE|NOSELL|GLOWING|LIT|DARK|TRANSIENT|NOCHARM|NOBURN|NOSLEEP|NOSUMMON|NORENT|NODROP|FLOAT|BLESS|TWOHANDS} {#IF (%pos( %upper( {%i}), "%1")) {#ADDITEM dbitem.flags {%i}}}} "ItemFlags" {case}
Sample text:
Item is: MAGIC NOBURN NOIDENTIFY NOCHARM ANTI-MALE
Not sure If I'm just trying to use #forall wrong, or if I'm trying to use something in the if statement wrong, heh. |
|
|
|
jessew Apprentice
Joined: 03 Mar 2003 Posts: 141
|
Posted: Wed Apr 21, 2004 6:43 pm |
Just to test that trigger I cut and pasted into my command prompt
Set dbitem to null and used #show {Item is: MAGIC NOBURN NOIDENTIFY NOCHARM ANTI-MALE} (your sample output)
then to see if it worked i did #SHOW {@dbitem.flags}
and got back
MAGIC|ANTI-MALE|NOCHARM|NOBURN
which I think is what you were aiming for?
So It appears to work fine, but if thats not the output you were looking for let me know.
Jesse |
|
|
|
SpiritWolf Wanderer
Joined: 02 Jul 2002 Posts: 74 Location: USA
|
Posted: Wed Apr 21, 2004 6:53 pm |
Hrm.. ok, so the trigger does seem to be working.. its just not importing it into the database correctly for some reason. Figured it was the trigger and totally forgot about checking the variable, heh.
So.. any suggestions on why a stinglist isn't imported into a database correctly? The field in the database is called Flags, and the field type is set as option list. All the options are in lowercase, but I don't suppose that matters since it captures the first item and not the rest. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Thu Apr 22, 2004 12:26 am |
First make sure "Allow other" is checked in the option list settings so it will pick up new flags for you. Second since none of your flags have spaces in them shorten your code by using %replace. Option lists prefer to receive the list seperated by commas so that is what you should replace spaces with. If you want to specifically not record certain flags then it makes sense to preform a list conversion and #DELITEM those, then switch to CSV for the database.
#TRIGGER {Item is: (*)$} {#ADDKEY dbitem flags {%replace("%1", " ", ",")}} "ItemFlags" {case} |
|
|
|
SpiritWolf Wanderer
Joined: 02 Jul 2002 Posts: 74 Location: USA
|
Posted: Thu Apr 22, 2004 6:49 pm |
Ok, that trigger works pretty nice (why isn't it listed in the help files that option lists prefer comma's over anything else?). Now, my problem is that those aren't the only flags in that line. Some more examples:
Example 1: Item is: MAGIC FLOAT NOBURN NO-WARRIOR NO-THIEF ANTI-ORC ANTI-HUMAN ANTI-BARBARIAN ANTI-TROLL ANTI-OGRE
Example 2: Item is: MAGIC NODROP ANTI-GOOD FLOAT NOBURN ANTI-EVILRACE ANTI-GREYELF ANTI-DWARF ANTI-HALFLING ANTI-GNOME ANTI-LICH
Now, I have the following set up in a trigger based off the one Vijilante posted:
#TRIGGER {Item is: (*)$} {#ADDKEY dbitem Flags {%replace( "%1", " ", ",")};#ADDKEY dbitem antiAlign {%remove( "ANTI-", (%replace( "%1", " ", ",")))};#ADDKEY dbitem antiRace {%remove( "ANTI-", (%replace( "%1", " ", ",")))};#ADDKEY dbitem antiClass {%remove( "ANTI-", (%replace( "%1", " ", ",")))};#ADDKEY dbitem antiClass {%remove( "NO-", (%replace( "%1", " ", ",")))};#T- ItemFlags} "ItemFlags" {case}
I didn't check the "Allow other:" box for the option lists in the database because I don't want it to add items. I split the Item flags line into four diffrent sets of flags being: Item flags, antiClass flags, antiAlign flags, and antiRace flags. In my first example, magic, float, and noburn are item flags, and are correctly added into the database as such. No-warrior and no-thief are anti-class flags and the trigger only seems to catch the no-warrior one. The anti-orc/human/barbarian/troll/ogre flags are all anti class flags, and none of them are being entered at all.
My second example is basicly like the first, except is has an anti align flag in it, which it captures just fine. Problem is that it confuses the anti-good flag with the anti-goodrace flag and doesn't pick up on the anti-evilrace flag.
I remove the anti- and the no- for the flags and re-add them later when I pull the info out of the database so it looks something like:
itemname: anti-good-evil, anti-orc-troll-ogre, anti-warrior-thief
instead of having all those anti's in there for every anti flag.
The #delitem is more then likely what I need to delete the stuff out of the line that I don't need, and then reparse the trigger or something to get the next set of flags and so on, but not quite sure how to go about that.
I have a long list of triggers for each and every flag that I'm trying to cut down in size is where this all comes from.
Hopefully I made some kinda sense and someone can lead me in the right direction. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri Apr 23, 2004 1:29 am |
Sound like you want to use %replace instead of %remove. The %remove function only removes the first occurence, %replace does all occurences. So a few changes that should help, I combined all the replaces for a little more speed since your flags seem not to have any overlap, such as a THIEF and an ANTI-THIEF flag, the could cause problems:
#TRIGGER {Item is: (*)$} {#ADDKEY dbitem Flags {%replace(%replace(%replace( "%1", " ", ","),"ANTI-", ""), "NO-","")};#ADDKEY dbitem antiAlign {@dbitem.Flags};#ADDKEY dbitem antiRace {@dbitem.Flags};#ADDKEY dbitem antiClass {@dbitem.Flags};#ADDKEY dbitem antiClass {@dbitem.Flags};#T- ItemFlags} "ItemFlags" {case} |
|
|
|
SpiritWolf Wanderer
Joined: 02 Jul 2002 Posts: 74 Location: USA
|
Posted: Tue Apr 27, 2004 2:38 pm |
Problem is, the warrior and cleric flags overlap once you remove the NO- and ANTI- from them, hence the need for the lists with what to match and the #forall's.
I've tried a trigger such as:
#TRIGGER {Item is: (*)$} {#forall {MAGIC|WHOLE-BODY|WHOLE-HEAD|ANTI-FEMALE|ANTI-MALE|NOLOCATE|NOSELL|GLOWING|LIT|DARK|TRANSIENT|NOCHARM|NOBURN|NOSLEEP|NOSUMMON|NORENT|NODROP|FLOAT|BLESS|TWOHANDS|GLOW} {#ADDKEY dbitem Flags {%replace( "%1", " ", ",")}};#forall {ANTI-GOOD|ANTI-NEUTRAL|ANTI-EVIL} {#ADDKEY dbitem antiAlign {%replace( %replace( "%1", "ANTI-", ""), " ", ",")}};#T- ItemFlags} "ItemFlags" {case}
The above trigger will only add the items from the first #forall into the database, but won't add the items from the second #forall. If I move the second #forall to be first in order, then it adds that information into the database, but not the stuff from the second even though its been added to the proper fields in the variable.
Sample pattern:
Item is: MAGIC NODROP ANTI-GOOD FLOAT NOBURN ANTI-EVILRACE ANTI-GREYELF ANTI-DWARF ANTI-HALFLING ANTI-GNOME ANTI-LICH
What gets added into the variable in the Flags field:
MAGIC,NODROP,ANTI-GOOD,FLOAT,NOBURN,ANTI-EVILRACE,ANTI-GREYELF,ANTI-DWARF,ANTI-HALFLING,ANTI-GNOME,ANTI-LICH,
What gets added into the variable in the antiAlign field:
MAGIC,NODROP,GOOD,FLOAT,NOBURN,EVILRACE,GREYELF,DWARF,HALFLING,GNOME,LICH,
So it seems to me the trigger is working correctly, just the items are not getting input into the database for some reason. Any suggestions?
EDIT:
After further looking, it seems any #forall after the first doesn't add the information into the variable before the command I use to stick the information in the variable into the database fires, hence the correct information being in the variable, just not getting added to the database. Adding an alarm for the command allows things to finish, but adds a delay I'd rather not have. Any suggestions on that? |
|
|
|
Pega Magician
Joined: 08 Jan 2001 Posts: 341 Location: Singapore
|
Posted: Tue Apr 27, 2004 9:57 pm |
I mentioned in another thread regarding what I have observed as the slowness of looping commands.
http://www.zuggsoft.com/forum/topic.asp?TOPIC_ID=16032
#FORALL delays the execution of the trigger it is used in, this delay usually goes beyond its current sequence of trigger firings.
The #PRIORITY command will help to stop proccessing of other triggers until this one is completed.
You can keep the #FORALL command for non timing sensitive tasks, or change it to a non-iterative routine or a routine which excludes zMUD's looping commands. From what I hear the database's flag option supports up to 31 flags. In my opinion, 31 #IF statements could be quicker than setting up the looping routines in the case of zMUD's script. If you can place 31 patterns in 31 regex triggers it could be even quicker, and you can turn off the triggers when you don't need them.
Hope this helps. |
|
|
|
|
|
|
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
|
|