Zugg Software :: View topic

Apprentice Joined: 16 Dec 2002 Posts: 103

I'm having trouble w/ a script that stores eq. info. into a db. The info. is stored, correctly, into a temp. record, as per the example by Troubador. The anticlass field of the last record grabbed looks like this: "Magic User|Chaos Cleric|Thief|Paladin|Anti-Paladin|Bard|Ranger|Order Cleric|Druid|Monk|Artificer" The db field is set to be of type "option list" w/ "allow other" checked. The database is only storing the first two entries, though - in this case "magic user, chaos cleric" I have seen other people request help with this exact same issue, but never seen any useful responses. In fact, there is a similar question in the same post thread as Troubador's example in the finished scripts forum.

I am using 6.62 at present, but the problem has existed in all versions I have used.

Also, the problem may only happen when the "allow other" is checked and no fields are specified. Not sure on that one, though

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

I was asked very politly to withdraw my answer as it did not solve this persons problem but seeing that Lightbulb who knows more about this stuff than most people tried to help this person and seem to get the same unwelcoming response tp his help I diceded to leave this post.

Most answers to questions can only be given suggestions to how to fix the problems but not useually the exact answer because there is no way to know all the information.

But I though Lightbulb did a fantastic job and I think I did as well.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

I have no difficulty with it. After changing the AntiClass field to "allow other":
#VAR temp1 %dbget( 0)
#ADDK temp1 Name {Test Item Only}
#ADDK temp1 AntiClass {Mage|Cleric|Thief|Ranger|Paladin|AntiPaladin|Warrior}
#NEW All @temp1
#SHOW %dbget(##)

And sure enough, the new record (number ## blanked out) has Anticlass set to Warrior, Mage, Cleric, Thief, Ranger, Paladin, antipaladin. The order has been changed to correspond to option-list (Warrior first) and the new option has been added, in lowercase (antipaladin).

Your problem is probably somewhere in your script, not in the database module.

You might note that I did NOT use multi-word options, so that might be the problem, except then I would expect the first two classes to be the ones NOT listed. I also didn't use quotation marks. And I gave the actual commands used to run my test, so you can duplicate it for yourself.

LightBulb
Advanced Member

Apprentice Joined: 16 Dec 2002 Posts: 103

Like I said, I can look at the data captured into a temp record (@newRecord) and it is correct. The only thing that remains of the script is to
#DBLOAD eq
#NEW All @newRecord
#DBRESET

Therefore, I'm pretty sure the problem isn't in my script. The data just isn't getting input.

On a whim, I did a "#NEW All @newRecord" on the command-line, then opened the database window - what I found was that there were 2 records (one was incomplete and the other was complete).

So, it seems that the bug can be narrowed down to cases where records are inserted from aliases fired by triggers.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Just to be fair, I tried using multi-word and hyphenated values (the exact entry you posted).
#ADDK temp1 AntiClass {Magic User|Chaos Cleric|Thief|Paladin|Anti-Paladin|Bard|Ranger|Order Cleric|Druid|Monk|Artificer}
and then used a trigger
#TR gobbledy {gook} {temp}
to fire an alias
#AL temp {#NEW All @temp1}

There is still no problem. The problem is something on your computer, probably in that script you are so sure has nothing wrong with it.

LightBulb
Advanced Member

Apprentice Joined: 16 Dec 2002 Posts: 103

If the data in @newrecord is correct, how could the problem be in my script? Think, if you would, about how much more difficult it would be to script it so that the only anticlass data that gets entered would be the first two in the list? No, I don't see how I could be in error on this.

Also, while I appreciate your help, I think you should realize that your tests are a very poor approximation of my setup, and therefore not necessarily the best environment for duplicating the problem. You ASSUME that the problem couldn't be related to absolute record length or related database fields or some other insidious bug. If the bug were as easy to spot as you seem to think, I'm sure I would've already found it.

Apprentice Joined: 16 Dec 2002 Posts: 103

It occurred to me, after reviewing my last response, that I should probably give you more info. if I really wish for help. Please forgive the lengthy post.

This is the script that I use to capture/store data:
#CLASS {equip_id}
#ALIAS store_data {#DBLOAD eq;#NEW All @newrecord;#DBRESET}
#VAR newRecord {} {}
#TRIGGER {^Object '(*)', Item type: (%x)$} {#VAR newRecord %null %null equip_id;#ADDKEY newRecord Name {%1};#ADDKEY newRecord Kind %2;#TEMP eqidtemptrig {^$} {#T- eqidtemptrig;store_data}}
#TRIGGER {^Can be worn on: (*)} {#if (%1 != "TAKE ") {#var where %replace( %1, "TAKE ", "")} {#var where hold};#ADDKEY newRecord Wear @where}
#TRIGGER {^Restricted Classes and Races :$(*)} {#var rest {%1};#LOOP %numwords( @rest, ", ") {#ADDITEM newRecord.AntiClass %word( @rest, %{i}, ", ")}}
#TRIGGER {^Item is: (*)} {#LOOP %numwords( {%1}) {#IF %ismember( %word( {%1}, %{i}), {!GOOD|!EVIL|!NEUTRAL}) {#ADDITEM newRecord.AntiAlignment %word( {%1}, %{i})} {#ADDITEM newRecord.Flags %word( {%1}, %{i})}}}
#TRIGGER {^Weight: (%d), Value: (%d)$} {#ADDKEY newRecord Weight %1;#ADDKEY newRecord Value %2}
#TRIGGER {^ Affects : Damroll By (%x)$} {#ADDKEY newrecord Dam %1}
#TRIGGER {^ Affects : Hitroll By (%x)$} {#ADDKEY newrecord Hit %1}
#TRIGGER {^ Affects : HP By (%x)$} {#ADDKEY newrecord HP %1}
#TRIGGER {^ Affects : Mana By (%x)$} {#ADDKEY newrecord Mana %1}
#TRIGGER {^ Affects : Str By (%x)$} {#ADDKEY newrecord Str %1}
#TRIGGER {^ Affects : Con By (%x)$} {#ADDKEY newrecord Con %1}
#TRIGGER {^ Affects : Wis By (%x)$} {#ADDKEY newrecord Wis %1}
#TRIGGER {^ Affects : Age By (%x)$} {#ADDKEY newrecord Age %1}
#TRIGGER {^ Affects : Int By (%x)$} {#ADDKEY newrecord Int %1}
#TRIGGER {^ Affects : Cha By (%x)$} {#ADDKEY newrecord Cha %1}
#TRIGGER {^ Affects : Dex By (%x)$} {#ADDKEY newrecord Dex %1}
#TRIGGER {^ Affects : PEarth By (%x)$} {#ADDKEY newrecord PEarth %1}
#TRIGGER {^ Affects : PAir By (%x)$} {#ADDKEY newrecord PAir %1}
#TRIGGER {^ Affects : PFire By (%x)$} {#ADDKEY newrecord PFire %1}
#TRIGGER {^ Affects : PWater By (%x)$} {#ADDKEY newrecord PWater %1}
#TRIGGER {^ Affects : PSpirit By (%x)$} {#ADDKEY newrecord PSpirit %1}
#TRIGGER {^ Affects : MEarth By (%x)$} {#ADDKEY newrecord MEarth %1}
#TRIGGER {^ Affects : MAir By (%x)$} {#ADDKEY newrecord MAir %1}
#TRIGGER {^ Affects : MFire By (%x)$} {#ADDKEY newrecord MFire %1}
#TRIGGER {^ Affects : MWater By (%x)$} {#ADDKEY newrecord MWater %1}
#TRIGGER {^ Affects : MSpirit By (%x)$} {#ADDKEY newrecord MSpirit %1}
#TRIGGER {^ Affects : Move By (%x)$} {#ADDKEY newrecord Moves %1}
#TRIGGER {^ Affects : Armor By (%x)$} {#ADDKEY newrecord Armor %1;;#say Armor: %1}
#TRIGGER {^Has (%d) charges, with (%d) charges left.$} {#ADDKEY newrecord charges %1}
#TRIGGER {^Level (%d) spell of:$(*)} {#ADDKEY newRecord castlevel %1;#ADDKEY newRecord Spells {%2};#ADDKEY newRecord perc_cast 0}
#TRIGGER {^Attack Spell: (%1) Level: (%d) Percentage: (%d)$} {#ADDKEY newRecord Spells {%1};#ADDKEY newRecord castlevel %2;#ADDKEY newRecord perc_cast %3;#ADDKEY newrecord charges 0}
#TRIGGER {^AC-apply is (%x)$} {#ADDKEY newrecord AC %1}
#TRIGGER {^Damage Dice is '(%x)'$} {#ADDKEY newrecord Damage %1}
#TRIGGER {^Item will give you following abilities: (*)$} {;#say Affects: {%1};#ADDITEM newRecord.Affects {%1}}
#TRIGGER {^~[Auto-Auc~] : * auctioning *, min is *} {bid ?}
#CLASS 0

Pretty close to the example given by Troubador, it fires on item identification and auctioning on the mud "Age of Chaos" (aoc.pandapub.com 4000). After the trigger has fired, the database shows the record as having no more than 2 anticlasses, while examining the @newrecord variable shows that all anticlasses were in fact captured.

My db is setup as follows:
eq.dbd:
name <- text
damage <- number
dam <- number
hit <- number
armor <- number
ac <- number
kind <- single option (allow other)
wear <- single option (allow other)
weight <- number
value <- number
hp <- number
mana <- number
age <- number
str <- number
con <- number
wis <- number
int <- number
cha <- number
dex <- number
pearth <- number
pair <- number
pfire <- number
pwater <- number
pspirit <- number
mearth <- number
mair <- number
mfire <- number
mwater <- number
mspirit <- number
moves <- number
charges <- number
castlevel <- number
spells <- single option (allow other)
perc_cast <- number
anticlass <- option list (allow other)

I feel that it is also worth noting that this setup worked flawlessly for me in the past (I can not recall which version of zMud, though). I no longer have the original database, but the trigger-set is identical.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The problem is quite simple. Option lists are stored comma delimited. Change the trigger to:
#TRIGGER {^Restricted Classes and Races :$(*)} {#ADDKEY newRecord AntiClass {%1}}

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Yes, I realize my tests are only an approximation and I agree they aren't the "best environment for duplicating the problem". The best environment would be the EXACT script you are running and the EXACT MUD output which led you to notice the problem, and sometimes it might even be necessary to visit the EXACT MUD and get the output online. Unfortunately, you didn't provide any of that prior to now. So my tests, "very poor approximation" though they may be, are as close as I (or probably anyone else) could come.

Actually, having now seen the script, I suspect your problem is related to the #LOOP command. Trigger processing is no longer automatically paused until a #LOOP finishes running. You must use the #PRIORITY command when it's necessary to finish a #LOOP before processing subsequent lines.

What's happening is this:

You receive the lines (simulated)
Restricted Classes and Races :
Magic User, Chaos Cleric, Thief, Paladin, Anti-Paladin, Bard, Ranger, Order Cleric, Druid, Monk, Artificer

Your trigger fires, and begins running a #LOOP command to create the AntiClass list
#TRIGGER {^Restricted Classes and Races :$(*)} {#var rest {%1};#LOOP %numwords( @rest, ", ") {#ADDITEM newRecord.AntiClass %word( @rest, %{i}, ", ")}}

Additional lines are received and their triggers are processed.
A blank line is received, triggering the #TEMP trigger
#TEMP eqidtemptrig {^$} {#T- eqidtemptrig;store_data}

The #TEMP trigger fires the store_data alias, which creates the new database record with whatever information is in the variable at that time (apparently only the first two classes)
#ALIAS store_data {#DBLOAD eq;#NEW All @newrecord;#DBRESET}

The #LOOP (see above) finishes processing, so that all classes are now in @newRecord.AntiClass
You look at the database and see that the new record only has two classes checked.
You look at the variable and see that all eleven classes are listed
You assume there must be a bug in the #NEW command, when run from a script

The best solution would probably be to eliminate the #LOOP completely.
#TR {^Restricted Classes and Races :$(*)} {#ADDK newRecord AntiClass %replace( {%1}, ", ", "|")}

I didn't bother to test this, since (as you've pointed out) you consider my tests to be a waste of time.

LightBulb
Advanced Member
Using the unmodified data, as Vijilante suggested, would probably be even better.

Apprentice Joined: 16 Dec 2002 Posts: 103

You were absolutely correct about the race condition, Lightbulb. Thank you.

I can't believe that the semantics of the language could've changed that much - I don't think it would've ever occured to me that the fundamental looping structure would be different from one version to another.

At any rate, thank you for your help.