Zugg Software :: View topic - Help - Script for populating Database via Identify

Newbie Joined: 10 Jul 2008 Posts: 4

I need a little help. I am attempting to create triggers that will populate the database with information from an in game identify spell.

Here is how the identify is displayed within Highlands 3 mud:

Object 'a vortex ring', Item type: ARMOR
Item is: NOBITS
Weight: 1, Value: 5000, Level: 10
AC-apply is 5
MAX AC-apply is 5
Can affect you as :
Affects: DAMROLL By 1
Affects: MAXMOVE By 5

This is what I have come up with, but I see a problem with populating the Affects data since the label for both data elements is the same.

#ALIAS id {#T+ identify;#VAR Item "";cast identify %1}
#TRIGGER {Object &Item.Object Item type: &Item.ItemType} {} identify
#TRIGGER {Weight: &Item.Weight} {} identify
#TRIGGER {Value: &Item.Value} {} identify
#TRIGGER {Level: &Item.Level} {} identify
#TRIGGER {AC-apply is &Item.ac-apply} {} identify
#TRIGGER {Max AC-apply is &Item.MaxAc} {} identify
#TRIGGER {Affects: &Item.Affects} {} identify
#TRIGGER {Affects: &Item.Affects2} {} identify
#TRIGGER {$} {#T- identify;#IF (!%null(@NewItem)) {#NEW @ItemType @Item}} identify

Can anyone help me out?

Thank you,

DaxD

Posted: Thu Jul 10, 2008 10:39 pm

Do all items always have exactly the same output, or is there a variable number of affects it can have?

Newbie Joined: 10 Jul 2008 Posts: 4

Not all items will have the effects data. The effects can be different values. The rest of the output is standard on all items. (Cost, Weight, Max-Ac..etc)

Sorcerer Joined: 13 Jan 2006 Posts: 715

The answer is simple, change your Affects trigger to be multi-state.

Newbie Joined: 10 Jul 2008 Posts: 4

I have no experience with multi-state triggers. Could someone give me an example of the application of one that might be used as a solution to my problem?

I am working hard to become a master of zmud.

Posted: Fri Jul 11, 2008 2:53 pm

It's pretty easy to set up a multistate trigger. The difficulty comes with capturing a number of effects between 0 and lots.

#trig {Object '(*)', Item Type: (%w)} {script here}
#cond {Item is: (*)} {script here} {within|param=1}
#cond {Weight: (%d), Value: (%d), Level: (%d)} {script here} {within|param=1}
...etc...
#cond {Can affect you as :} {#t+ Affs} {within|param=1}
#cond {Some message that tells you the list of affs is finished, probably your prompt or a blank line} {#t- Affs}

#trig "Affs" {Affects: (*)} {script here} "" {disable}

You then put your add-to-database part of the script in the final trigger along with the #t- Affs command. There's a ton of info on multistate triggers in the help, too.

EDIT: Oh, and because this seems to be an issue almost every time I do something like this: Pay very close attention to the way the script is formatted. The #cond commands aren't part of the trigger's script, they're on a separate, new line because they create trigger states just like #trig creates triggers. Look the command up in the help.

Newbie Joined: 10 Jul 2008 Posts: 4

Thank you Fang.

I have a lot to learn about advance scripting and this example helps.

Sorcerer Joined: 13 Jan 2006 Posts: 715

Another option is to embed them as normal triggers in a class, with only the first line of identify being outside of it, and one of that commands in that trigger is to turn the class on.
Then you trigger off a blank line (IF a blank line is received after the last "Affect" line) to turn the class back off

#TRIG {^%s} {#T- IdentClass}