|
jg1lbert Wanderer
Joined: 09 Nov 2006 Posts: 55
|
Posted: Tue Nov 14, 2006 5:40 pm
just curious question about trigger priority and states |
The help file says that Cmud doesnt use priority on triggers. I noticed a lot of new triggers I make have varying priority numbers. What is the range of priority? is 1 like #1 and 9999 like last? or vice versa?
another question. Is there a way from the command line to set a trigger with like a wait state so it only fires now and again? some triggers, I'll go in and add a wait state with the more+ button at the bottom. Just looking for a shortcut |
|
|
|
The Raven Magician
Joined: 13 Oct 2000 Posts: 463
|
Posted: Tue Nov 14, 2006 6:09 pm |
The priority is what sorts them in the list of triggers.
I believe that triggers higher on the list are checked before triggers farther down on the list. Not sure about that. |
|
|
|
jg1lbert Wanderer
Joined: 09 Nov 2006 Posts: 55
|
Posted: Tue Nov 14, 2006 8:14 pm |
seems like trigger priority 1 works more often than 9999, with the highest number, sometimes didnt fire a #say I was looking at... now what about negative priorities? where do those come in?
|
|
|
|
Morgal Beginner
Joined: 06 Nov 2006 Posts: 26
|
Posted: Tue Nov 14, 2006 8:52 pm |
Seems like my trigger priorities keep on increasing..
Im up to 9470 now, and its 10 every trigger.
Is this correct?
Gareth / Morgal |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Nov 14, 2006 8:54 pm |
Quote: |
The help file says that Cmud doesnt use priority on triggers |
Where does it say this? It is probably left over from copying most of the help topics from zMUD, so let me know and I'll fix it. CMUD *does* use priority numbers for triggers (and buttons and status bar items and menu items).
The range of priority numbers is unlimited (well, whatever a 32-bit integer can hold). Triggers are executed in priority order, with the smaller numbers executed first. In other words, it first executes trigger "1", then trigger "2", etc. While negative numbers might work, it's not recommended and might stop working in future versions.
The #CONDITION command is used to add states to triggers within a script. |
|
|
|
saet Apprentice
Joined: 12 Jun 2006 Posts: 106
|
Posted: Tue Nov 14, 2006 9:24 pm |
I had to change the priority of triggers for some coloring issues. My regex isn't the greatest so I don't know if it's something I could improve so priority doesn't matter. Anyways... I notice there is a big gap between priority numbers, so I just set it 1 lower than the one it needs to be in front of. But is there anything to worry about with identical priority numbers? I know that the chance of getting identicals is very rare from the gaps I've seen and I only have ever needed to change one trigger, but I was just curious.
Oh, btw. I remember reading some post that had me under the impression that trigger priority was being removed in CMUD, something about it not being needed. It was probably when it was still called zMUDXP. My memory can get hazy though. |
|
|
|
Guinn Wizard
Joined: 03 Mar 2001 Posts: 1127 Location: London
|
Posted: Tue Nov 14, 2006 9:31 pm |
It was probably that the #PRIORITY command was being removed that you're thinking of(?). CMUD processes each line mud output completely before moving onto the next, whereas zMUD would sometimes still be processing the last line when the next was received, resulting in some odd results for scripts.
|
|
_________________ CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;) |
|
|
|
saet Apprentice
Joined: 12 Jun 2006 Posts: 106
|
Posted: Tue Nov 14, 2006 9:38 pm |
That was it, I misunderstood the post at first. Don't even know what #PRIORITY does in zMUD exactly. Good memory.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Nov 14, 2006 11:32 pm |
The "gap" between priority numbers is there for efficiency reasons. If you sort the settings editor by priority and then drag/drop a setting to a new priority position, CMUD needs to go through and change the priorities of other objects to "move them up" to make room for the setting you just dragged. By giving a gap between default priorities, this minimizes the number of database records that CMUD needs to update when you drag/drop and improves the speed.
Essentially, the gap gives you a bit of room to add things before it needs to start moving other settings up.
If two settings have the same priority number, then they will both execute before anything with a higher number, but there is no way to know which one will execute first. So it's ok to have a bunch of settings with the same priority, as long as you don't care which order they execute in.
So, priorities are really easy...they are just a number to indicate which order to execute. The database is sorted by this number. Just like if you wrote down your triggers in order, starting at one. It doesn't matter if you skip numbers or anything like that. |
|
|
|
|
|