Zugg Software :: View topic

Novice Joined: 07 Feb 2008 Posts: 40 Location: Italy

I'm trying to build an items db, here's how I think it should work, if any experts here can give me links to information to improve my knowledge or an example of what they would do to achieve this:

Mud info
You recite a scroll of identify which dissolves.
----------------------------------------------------------------------
an old filthy mantle is a type of armor made from base-material
It can be taken and worn on TAKE ABOUT
It is unlocateable
Its weight is 5 and its valued at 80008 coins.
If worn it will give you --
3 to your Damroll
2 to your Hitroll
15 to your Health-regen

AC-apply is 5
----------------------------------------------------------------------

Trigger
#tr {^You recite a scroll of identify which dissolves.} {
#cond &item.name is a type of &item.type made from &item.material
#cond &item.dam to your Damroll
#cond &item.hit to your Hitroll
#cond AC-apply is &item.ac
#DBLOAD id
#NEW all @item
#DBSAVE id }

Anything wrong with it? I've chosen only the info I needed and eluded the rest.

Posted: Thu Mar 20, 2008 10:53 pm

Yes, you need to read up on how to use the #cond command. The #cond command creates trigger states in the same way that #trig creates triggers. It needs running once, and then never running again.

Novice Joined: 07 Feb 2008 Posts: 40 Location: Italy

I've read about it, but the explication is very restricted. Don't you have any idea what I'm doing wrong using it in this example?

Posted: Fri Mar 21, 2008 11:56 am

The definition of a multistate trigger looks like this:

#trig {state 0} {command 0}
#cond {state 1} {command 1}
#cond {state 2} {command 2}

Notice how the #cond commands are outside the #trig command, on separate lines, because they're going to create a multistate trigger and only need running once. Once it's created, the trigger will wait for state 0's pattern, then run state 0's command, then wait for state 1's pattern, then run state 1's command. When state 2's command is run, it loops back round and waits for state 0 again. I seem to say this a lot, so perhaps I should find somewhere in the help files to put it.

Wizard Joined: 22 Mar 2007 Posts: 2320

Specifically, following your own logic, you would write something like (untested):

#tr {^You recite a scroll of identify which dissolves.} {#DBLOAD id}
#cond {(*) is a type of (%w) made from (%w)} {@item.name = %1; @item.type = %2; @item.material = %3}
#cond {(%d) to your Damroll} {@item.dam = %1}
#cond {(%d) to your Hitroll} {@item.hit = %1}
#cond {AC-apply is &item.ac} {@item.ac = %1; #NEW all @item; #DBSAVE id}

However, I don't think that will actually work for you. From your previous thread, it is obvious that not every identify will produce a Damroll line or an AC-apply line. The exact output of the identify depends on the nature of the object being identified. This is why I suggested using a multistate trigger to turn on and off a class containing the triggers which capture your data.

Here is a rough idea of what I mean (again, untested):

#tr {^You recite a scroll of identify which dissolves.} {#DBLOAD id}
#cond {----------------------------------------------------------------------} {#t+ identify;#var item ""}
#cond {----------------------------------------------------------------------} {#t- identify;#NEW all @item;#DBSAVE id}
#class identify {disable}
#tr {(*) is a type of (%w) made from (%w)} {@item.name = %1; @item.type = %2; @item.material = %3}
#tr {(%d) to your Damroll} {@item.dam = %1}
#tr {(%d) to your Hitroll} {@item.hit = %1}
#tr {AC-apply is &item.ac} {@item.ac = %1}
#class 0