Zugg Software :: View topic

Adept Joined: 20 Jul 2004 Posts: 268

Just curious, I haven't, yet, run into a problem with having the same trigger type in several classes. (ex: You gained a level! in #class lvltracker. You gained a level! in #class weapontracker.)
Is it just better to have ONE trigger and have it do everything it needs to do in diff classes? (You gained a level! modify #class lvltracker & #class weapontracker.)

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

As long as your triggers have unique differant ID's its not a problem. Same with specific classes to but Im not to sure.

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

You will run into the problem of wich one gets processed first.
the other is Zmud can only handle a certain amount of stuff at one time and the more trigs of the samething you have the more chance you run of something not getting done. This bug has never been fixed and probably won't while Zugg is working on his other projects.

Adept Joined: 20 Jul 2004 Posts: 268

so
#trigger {^You gain a level!} {#add Level 1;#add Weapons 1}
is better than
#trigger {^You gain a level!} {#add Level 1} <--in some class
#trigger {^You gain a level!} {#add Weapons 1} <--in some other class

SubAdmin Joined: 18 Nov 2001 Posts: 5187

In nearly all cases the first will be better then the second.

Where it gets murky is when you have a very large complex trigger, some of which won't even be used if the right conditions aren't met. That is when it starts to be better to split the trigger into smaller segments that can be turned on and off with #T+ and #T-. The same improvment can also be made by simply splitting portions of the complex trigger into aliases and then simply calling the alias when the conditions require.

The reason it becomes better in this situation is because the entire contents of the trigger is copied from its permenant memory residence for the parser to work with. This allows %nn substitutions to be done. Large complex triggers require more overhead memory and copy time each time they fire. Also if you already preform an #IF check on the conditions of variables in another trigger then it makes no sense to spend time preforming that same check again simply adding the right #T- there instead of using the alias method can improve speed.

The specific steps involved in the example you gave:
Match "^You gain a level!"
Place on stack trigger info
Allocate/reuse memory
Copy script "#add Level 1;#add Weapons 1" to block
Execute "#add Level 1"
Execute "#add Weapons 1"
Release memory
Pop from stack

versus

Match "^You gain a level!"
Place on stack trigger info
Allocate/reuse memory
Copy script "#add Level 1" to block
Execute "#add Level 1"
Release memory
Pop from stack
Accelerated Match "^You gain a level!"
Place on stack trigger info
Allocate/reuse memory
Copy script "#add Weapons 1" to block
Execute "#add Weapons 1"
Release memory
Pop from stack

The accelerated match is from the regex system used. I believe it uses hash tables, updated whenever a new trigger is added, that compares all other triggers with it and determines if they can fire on the same text. Then once each match occurs it can eliminate all triggers that are not known to fire from the same text. Allowing the field of possibilties to narrow quickly. Don't quote me on that though I never thoroughly examined the code involved.

Adept Joined: 20 Jul 2004 Posts: 268

Understood. thanks :-)

Side note: I've been changing my subject titles to include *SOLVED* for those that I have gotten answers on. Wouldn't it be nice if you could close your own post?
Maybe have it change the subject itself, or an icon or something?
*shrug* just a thought