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
patryn
Apprentice


Joined: 26 Sep 2001
Posts: 124

PostPosted: Sun Jul 30, 2006 6:29 am   

Powerful new idea.
 
I haven't been able to find an active wish list where I can add this idea so I thought I would just put it down here lest I forget it (which usually only takes 24 hrs :P)

Lately I've been trying to come up with work-arounds in order to disable a whole bunch of triggers (without actually re-organizing them into different folders). I haven't been very successful thus far, however I did come up with a few ideas which I believe would improve current scripting possibilities by allowing more customized control over the settings themselves.

All that is really required is a way to query and reference the various settings which are currently written.
I believe there are two easy ways that this sort of thing can be implemented for future Zmud (CMud) generations.

Idea #1: Provide capability to access a record of all triggers/aliases/buttons/etc which currently within the settings.
This can be approached in one of two ways.
1.) Either have this information sitting in predefined database variables such as %triggerList %aliasList etc. This information is then readily available at any time.
Or
2.) Provide a command and function which will return a database variable for the specified type of setting you're wishing to use.

Syntax:
#GetSettings Var [all|trigger|alias|button|timer|etc...]
%getsettings([all|trigger|alias|button|timer|etc...])

where Var is the name of the variable where the database record will be copied to. The second parameter specifies the type of setting you wish to filter. Default is All, which will return all settings in an easy to access database record.

The %key values within the returned database record consists of unique identifiers for each setting. (I don't believe these exist yet but would seem pretty easy to implement)
e.g. Trigger ID = (T1,T2,T3...Tn), Alias ID = (A1,A2,A3...An), Button ID = (B1,B2,B3...Bn) --- And so on and so forth.

The %val values within the returned database record consist of a string list of the various settings for that particular setting type. (Obviously different types of settings will have different types of string lists. i.e. Trigger settings will differ in format to Alias settings.)


Idea #2: GMail type labeling of settings. (This actually builds on the above idea. In a way it just extends it to allow for customising)
This idea is based on the 'gmail' labeling system where you don't have to sort anything really (if you don't wish to), you just stick labels on things, then use the label to filter everything.

Simply allow an infinate (or very large) number of user defined labels (as well as current default ones) to be assigned to any setting type.
Then provide functionality which would return a filtered database record based on a label query.

Syntax:
#FilterSettings expression Var
%filtersettings(expression)

where expression consists of a list of Labels that settings have to match in order to be returned and Var is the variable to store this information in.

Example:
You have a total of 500 settings made up of triggers, aliases, buttons, etc...
Each setting is automatically labeled with its 'type'(trigger/alias/button/etc)

'#FilterSettings (trigger) List' would store a database variable into @List which would contain all settings which contain a label called 'Trigger'
'#FilterSettings (alias and blue) List' would store a database variable into @List which contain all settings of the type 'alias' and a custom label of 'Blue'
'#FilterSettings (!blue) List' would store a database variable into @List which contain all settings of every type 'Except' those with a label of 'Blue'

Obviously the automatic labels which refer to the setting type will need to be reserved. Otherwise people can add an 'alias' label to a trigger type setting and have a trigger return in a filtered alias list.

'#FilterSettings (trigger and alias) List' should (ideally) return nothing, because a trigger is never an alias.



I can see such functionality giving CMud users a great deal more control over what executes and when by providing an easy way to reference settings. This would allow isolation of process intensive code without too much work on the users part. It 'is' possible to this at the moment.. however the maintenance ramifications of doing this to a settings file that will no doubt be changing constantly are much too great to be worth it. (IMO)

The Labeling system is my favoured approach because of how dynamic it can be. Also, if such a thing is eventually implemented, it would be neat to be able to select multiple settings and modify lables per selection group. (Much like the ability to change certain settings of multiple map rooms in the mapper, instead of having to change them one by one.)


Idea #1 seems to revolve around porting the settings file into a database form. Idea #2 can be approached in the same way, but it can also be implemented using the current way in which the settings are saved (to a text file as far as I can tell.)

The reason I mention this is because it may not be feasable to port the settings system into database form due to problems which may arise with the storage and retrieval of all of the various special programming characters which the settings file is riddled with.
_________________
That which does not kill us, makes us stronger.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Sun Jul 30, 2006 7:05 am   
 
In CMud, the settings ARE in database form. And, in ZMud, most settings-definition commands (#VARIABLE, #TRIGGER, etc) when used without parameters will list the defined settings of that type. The major problem with this functionality is that it gives no regard to the status of those settings nor does it differentiate locations. That means that even if you did get a list, you couldn't turn off JUST the enabled ones and you would not be able to re-enable duplicates at all.

Existing COM might have this capability, but I've not had much of a reason to use it yet outside of plugins.
_________________
EDIT: I didn't like my old signature
Reply with quote
Zugg
MASTER


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

PostPosted: Sun Jul 30, 2006 7:36 am   
 
Have you played with the COM interface? It's documented in one of the articles in the Support/zMUD Support menu. It has routines for accessing all of the settings. Each setting type has an array and you can simply loop through the array to do stuff.

Since CMUD uses a database now, there are definitely some things we can look forward to in the future regarding queries. But rather than returning stuff like unique id, or database variables, it will probably still return COM objects since it's a lot easier to access and change properties with a COM variable.

The "labelling" idea is a good one and I'll give that more thought in the future.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Sun Jul 30, 2006 8:50 am   
 
Patryn there is others feature in CMUD that, in tandem, can handle your specific problem directly.

With trigger priority now implement and an option for one trigger to prevent other triggers from firing on a particular line of input, you could set you desired long line trigger to be the top (or close to it priority) and after it fires you can then prevent other triggers from processing that line.

I'm sure someone will correct me if I'm wrong (but it is almost 5am), but give CMUD a shot and see if that does what you want.
_________________
Asati di tempari!
Reply with quote
patryn
Apprentice


Joined: 26 Sep 2001
Posts: 124

PostPosted: Sun Jul 30, 2006 11:15 am   
 
Ah right... well in that case... maybe it is time for me to get my feet wet with CMud, if only to get up to date with which functionalities are current :P

Sorry for the spam :)
_________________
That which does not kill us, makes us stronger.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Sun Jul 30, 2006 6:32 pm   
 
A suggestion on your COM interface. Please do not use Widestring in argument, I think you use widestring to compatible with BSTR. But in delphi the string -> widestring conversion is implicit, the result is miscoded widestring. When you use it again in zMud, those miscoded widestring will be convert back to string correctly. But if I want to reuse those string in COM interface by other program it cannot be decoded correctly.

btw, there is a delphi function and a Win32 api to do explicit string to widestring conversion.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Wed Aug 09, 2006 1:15 pm   
 
Zugg wrote:
The "labelling" idea is a good one and I'll give that more thought in the future.

Funny thing, first time I used gmail and noticed the labels, I was reminded of classes in zmud 5.55 (the version I began mudding with).
Reply with quote
Zugg
MASTER


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

PostPosted: Wed Aug 09, 2006 5:07 pm   
 
Yeah, but the difference between classes and labels is that a setting can only be contained within a single class. Where as with labels you could assign multiple labels to a setting. Labels give a many-to-many relationship that can be a bit more useful than the hierarchical relationship of classes.
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