Zugg Software :: View topic

Enchanter Joined: 09 Sep 2007 Posts: 605

CMUD enumerates all new settings itself and that is acceptable in most cases. But sometimes you need to modify default priority value. Say, you want mapper-related triggers of prompt trigger fires earlier. Or you may want that a set of triggers from a class has fired only after triggers from another class. Additionally while studying others packages I've noticed that many authors set settings priorities manually to some large numbers in order to not interfere with settings outside their package.

Keeping track of all settings to be renumbered manually, especially if you continue to add new/remove obsolete settings or developing your session settings and package(s) at the same time, is annoying. Why not let the computer to do this job? Instead of editing priorities by hands, you may set base priority value for a class and CMUD would take that into account when it will create (or even copy) a setting within that class next time. This feature can be handy for package developers and developers of moderate or big-sized systems if they wish to keep settings performing similar job

So, here is my suggestion: add "Base priority value" (or like) text box to the class properties and a checkbox for enable\disable it. It should be disabled by default, making everything transparent if this feature is not needed for a class. Possibly, "Include subfolders" checkbox will be a good addition for package developers letting them specify base priority number for entire package only once.

Posted: Mon Feb 08, 2010 5:54 pm

Unfortunately, there is no good way to do this. The Priority field is a database field that the settings are sorted by to determine their running order. Having any sort of "dynamic" priority value like this would defeat the purpose of having the database indexed and would cause severe performance slowdowns. Basically, the index would need to be rebuilt every time you enabled or disabled a class.

I understand the issue you are raising, but we'd need to have more discussion on other possible ways to improve it. People have also lived with this for many years with their zMUD scripts, so I'm not sure this is a very big priority right now with so much other stuff to be worked on.

Enchanter Joined: 09 Sep 2007 Posts: 605

May be I missed something but I do not see technical difference between tweaking priority manually (how everyone can do it now) and tweaking by CMUD itself. It is just a matter of who will do renumbering (a user or CMUD).

I understand that my suggestion has pretty low priority in your huge todo list. Nevertheless I don't consider "if people lived in the Stone Age iron isn't required to them" the strong counter-argument. Wink

Posted: Fri Feb 12, 2010 4:52 am

The point is that many people enable and disable classes very frequently. Having CMUD rebuild the trigger priority index every time a class is enabled/disabled is a bigger performance hit than you might realize.

Tweaking a trigger manually is completely different because changing a single trigger priority manually doesn't happen as often as enabling/disabling classes, and doing it manually usually means that the performance hit won't be noticed because it is fast compared to the human time taken to use the GUI to change the trigger priority. Whereas class enable/disable is usually done within a script where performance is extremely important.

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

I can see where Arde is going with this and he doesnt want it to be done automaticly.
He just wants to be able to set a range for the priority in each class and anytime a setting is created in that class instead of automatically assigning the next available priority it will assign the next available priority that comes in the range.

It will never "change" the existing priority of a setting (unless that setting is manually copied into the class).
however I think doing this at the class level will be too much of a pain and more confusing for newer users.
Making this available in the module/window advanced properties tab would be a better option (it would affect only those settings created or copied into said window/module)

Example: in a Blank Session If the range is set to 4000-5000 in the untitled window when a trigger is created instead of it assigning 10 for the priority it will assign 4000 for the first, 4010 for the second etc etc. When it reaches 5000 the next created one would be 4005 etc until is uses up all the available numbers in the range. Then it would just go back to using the standard next available priority in this case 10.

I would defiantly make use of a feature like this, but it does rank lower on the todo list since #step and #pause used with the mapper are still wonky :p

Posted: Fri Feb 12, 2010 5:00 pm

OK, sorry, I thought Arde was talking about adjusting trigger priorities at run time as classes were enabled and disabled. I somehow misread the original post and didn't realize he was only suggesting it to effect settings as they are initially created.

I'll add this to the wish list for some future version.