MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Tue Oct 07, 2003 12:22 am |
First question, you can use #PRIORITY if you want priority within your code. Beyond this, priority has little meaning in ZMud codewise. When you are working on triggers via the Settings Editor, however, you can sort triggers and settings to effect a slight form of priority. It is limited thusly:
1)all inherited settings go first (this is because the inherited settings are naturally loaded first). This means that inherited triggers will cause a seeming double-fire, the wrong code/value will be used, etc. Some types of settings are immune as they cannot be manipulated as an inherited setting (ie, variables.)
2)Classes form a top-down hierarchy, with subfolders of the parent folder (Class1) higher in the lineup than peer classes of the parent (Class2):
Class1
Class1|ClassA
Class2
Class2|ClassA
Zugg recently gave us a little OOP capability that allows us to specify particular settings, so this limitation isn't so glaring anymore.
3)Settings other than triggers work on a first-found basis. A button contained in the above Class2|ClassA class and is identical to a button in the Class1|ClassA class will never execute. ZMud searches for pattern-matches against EVERY active trigger, which allows us to simultaneously execute many different tasks on the same line. In a more limited sense than for classes, the newly-added OOP capability offsets this. |
|