Zugg Software :: View topic

Newbie Joined: 24 Jun 2003 Posts: 8 Location: USA

I have an alias that populates certain fields in a spell database, the alias looks like this:

#ALIAS setStatus {; Parameter 1 is the Name of the spell:String;; Parameter 2 is the Status: Boolean;; Parameter 3 is the Length: Integer;#DBGET %query( &Name=%1, All|Spells);#DBPUT %rec {Status=%2|Length=%3}} "DBStatus"

Then there is a set of triggers that trigger off the affects
list ex:

You are affected by the following spells:
Spell: shield : modifies armor class by -20 for 19 hours
Spell: giant strength : modifies strength by 4 for 10 hours
Spell: stone skin : modifies armor class by -40 for 9 hours

Triggers that populate the database in the affects list.

#TRIGGER {Spell: giant strength : modifies strength by %n for (%d) hours} {#IF (@PermenantSpell) {setStatus "GiantStr" 1 -1} {setStatus "GiantStr" 1 %1}} "Status|AffectedBy"
#TRIGGER {Spell: haste : modifies dexterity by %n for (%d) hours} {#IF (@PermenantSpell) {setStatus "Haste" 1 -1} {setStatus "Haste" 1 %1}} "Status|AffectedBy"
#TRIGGER {Spell: shield : modifies armor class by %n for (%d) hours} {#IF (@PermenantSpell) {setStatus "Shield" 1 -1} {setStatus "Shield" 1 %1}} "Status|AffectedBy"

Triggers that populate off the casting of the spells.

#TRIGGER {You are surrounded by a force shield~.} {setStatus "Shield" 1 %eval( @p.Level+8);do_UpdateStatus} "Status"
#TRIGGER {You are surrounded by a white aura~.} {setStatus "Sanctuary" 1 %eval( @p.Level/6);do_UpdateStatus} "Status"

The triggers that populate the database work great, they all test properly when I cast the spells. The problem occurs when I do the affects list...When there is one or two spells that are affecting my charecter it seems to work fine. But, when I have 10-15 spells affecting my charecter they fail miserably. I believe the triggers are firing too fast for the data population. Is there a way to be sure the data populates.

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

The best solution would probably be to stop using the database. You can do without the Status, since you can find out whether you have the affect from the Length. That brings it down to two values for each affect, Name and Length, which can be stored in a Record variable with the Name as the key and the Length as the value.
#TR {Spell: giant strength : modifies strength by %n for (%d) hours} {#IF (%ismember( "GiantStr", @PermenantSpell)) {#ADDKEY Affects GiantStr P} {#ADDK Affects GiantStr %1}} "Status|AffectedBy"

Obviously, you'll need a routine to set initial values for all the affects. I'd recommend setting them to -1 (or P for permanent affects) just before you check affects, then let the triggers update them. Any affect you don't have will still be at -1 at the end of the affects list.

Newbie Joined: 24 Jun 2003 Posts: 8 Location: USA

I used to have a system exactly like the one you are describing. I then ported to the database because I wanted more information stored and more flexability than using data record variables. I have multiple charecters which are of different classes and each class obtains their spells at different levels. With the data record I would need a new variable for each class, the level I get the spell, the short name of the spell, the mana cost for each spell, etc. With the database design I can quickly store all this into one table.

Today I tried working this script into it by setting all the affects into one data record similar to what LightBulb suggested.

#VAR SpTemp {Haste12Armor15Shield42} {_nodef} "Status|AffectedBy"
#TRIGGER {$} {#T- AffectedBy;#LOOPDB @SpTemp {#IF ( %val == "P") {setStatus %key 1 -1} {setStatus %key 1 %val} #WAIT (6000)};do_UpdateStatus} "Status|AffectedBy"
#TRIGGER {Spell: armor : modifies armor class by %n for (%d) hours} {#IF (@PermenantSpell) {#ADDKEY {SpTemp} {Armor} {P}} {#ADDKEY {SpTemp} {Armor} {%1}}} "Status|AffectedBy"
#TRIGGER {Spell: haste : modifies dexterity by %n for (%d) hours} {#IF (@PermenantSpell) {#ADDKEY {SpTemp} {Haste} {P}} {#ADDKEY {SpTemp} {Haste} {%1}}} "Status|AffectedBy"
#TRIGGER {Spell: shield : modifies armor class by %n for (%d) hours} {#IF (@PermenantSpell) {#ADDKEY {SpTemp} {Shield} {P}} {#ADDKEY {SpTemp} {Shield} {%1}}} "Status|AffectedBy"

Even with the Wait command embedded into the script slowing the update of the database, I still recieved similar results to before.

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

It might be just a typo, but the trigger you posted doesn't use the #WAIT command, it's just an unrecognized fourth and fifth parameter to the #IF command.
#TRIGGER {$} {#T- AffectedBy;#LOOPDB @SpTemp {#IF ( %val == "P") {setStatus %key 1 -1} {setStatus %key 1 %val};#WAIT (6000)};do_UpdateStatus} "Status|AffectedBy"

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

It seems clear that your problem is in the setStatus and/or do_UpdateStatus aliases. The most likely problem is that you do a query for every Affect and that means the entire database must be checked against the query every time.

You already have the database set up. That means each Affect already has a record number. Instead of constantly querying the database for the record number of GiantStr, just write it into your script. There's also no need to update the ENTIRE record to change two or three fields. Just update the ones you're changing. Assuming that the record number of GiantStr is 7sp:
#TRIGGER {Spell: giant strength : modifies strength by %n for (%d) hours} {#IF (@PermenantSpell) {#DBPUT 7sp {Status=1|Length=-1} {#DBPUT 7sp {Status=1|Length=%1}} "Status|AffectedBy"

NOTES:
1. Untested, but it should work -- the concept is sound. It might need some tweaking (for instance I'm sure you'll need to add spaces to the pattern).
2. I don't see where @PermenantSpell comes from, but I assume you've got that scripted correctly somewhere else.