Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Mon Feb 08, 2010 5:01 pm   

Suggestion: Base priority value
 
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.
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Thu Feb 11, 2010 4:28 pm   
 
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
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.

Quote:
Nevertheless I don't consider "if people lived in the Stone Age iron isn't required to them" the strong counter-argument

What I meant by that had nothing to do with "the Stone Age". What I meant is that out of thousands and thousands of zMUD and CMUD users, you are the first to request such a feature. That means it isn't a feature that is commonly requested, and therefore is much lower in priority than other features already on my to-do list that will have a bigger impact on more people.

I'm just one person and have a limited amount of time in a day, so I have to priority what I work on to benefit the most people.
Reply with quote
nexela
Wizard


Joined: 15 Jan 2002
Posts: 1644
Location: USA

PostPosted: Fri Feb 12, 2010 3:52 pm   
 
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
_________________
Zmud Support Library
Zmud Knowledge Base
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net