Zugg Software :: View topic - Prompt trigger not matching, did I do something wrong?

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

I followed the pattern matching helpfile to build it.

Original prompt:
|(317%/47)](100%[3756/3756])(100%)(100%)[0/0]>

Trigger:
#tr {^~|~(&%d{exp}~%~/&%d{lvl}~)~]~(&%d{hp}~%~[%d~/%d~]~)~(&%d{mn}~%~)~(&%d{mv}~%~)~[&%d{dmgD}~/&%d{dmgd}~]~>} {}

Posted: Sun Feb 14, 2010 11:59 am

i would use

#trigger {~|~((%d)~%~/(%d)~)~]~((%d)~%~[(%d)~/(%d)~]~)~((%d)~%~)~((%d)~%~)~[(%d)~/(%d)~]~> } {#addkey prompt_db exp %1;#addkey prompt_db level%2}}

ect ect

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

I then have to use these vars into a gauge and fighting triggers. Would they work anyway if they are DB items instead of VARs?
Accessing data from the DB isn't slower than reading a @var?

What is the convenience of using the DB instead of VARs?

Posted: Mon Feb 15, 2010 6:43 am

to many vars look ugly imho, and no it takes no extra time to read from a var its quite simple just use %db(@prompt_db,field) so for example %db(@prompt_db,exp) and it will show whatever is filling the %1 spot

Wizard Joined: 22 Mar 2007 Posts: 2320

It does take a little bit longer to read a value from a db variable than from a variable, but not enough to worry about (think: microseconds, or something like that). On the other hand, using the %db() for gauges and expression triggers would be very inefficient. If you had, say, 5 gauges using a database variable and %db(), and one prompt value changed, all five guages would have to evaluate the expression, while only one gauge would have to evaluate if each one used a separate variable. I recommend using separate variables. If you are concerned about clutter, you can keep it cleaner by moving the prompt variables into a separate class.

Also, do note that you need to set this trigger to "trigger on prompt" instead of "trigger on newline". Otherwise, it won't fire until you (or the mud) sends a carriage return.