[MudWalker] Several suggestions.

[Sune Foldager]

Greetings list.

I just subscribed a few mins ago, because I have some feature  
suggestions in particular wrt. the scripting system.

1. Firstly, the editing window for triggers and aliases is very  
small. This is probably fine for simple things, but for more advanced  
scripting, it gets rather annoying to have to scroll all the time.  
Also, the width is far too small. A bigger window, a pop-up window  
for editing or even an external editor command could be useful here :-).

2. I greatly miss the possibility of "reaching" Lua from the "command  
line", i.e. from the normal mud input window. It would seem natural  
to be able to type something like: @@foo = 12   to do the same as  
that line would do if put in a trigger or alias. In particular,  
reading out variables is a tedious process now, requirering one to  
make an alias.

3. I would very much like to be able to reach aliases from inside  
other aliases and triggers. Currently, I can use 'send' to send data  
to the mud, but it would be nice if there was a way to inject data as  
if it came through the input window.

4. I would like commands to turn settings (aliases, triggers,  
others..) on and off with commands, and in connection with this have  
a "short name" assigned to each setting (that the user picks), used  
to control it. So a command could look like   on 
("name_of_setting");    or similar.

5. This is a bit more involved, but I propose a more elaborate  
structure for settings such as aliases and triggers (this was  
inspired by zMUD on Windows, although zMUD has many flaws in its  
implementation IMO):

There should then be a hierachy or "file structure" creatable and  
maintainable by the user. The user can create 'folders' and 'sub  
folders', and folders can contain settings such as trigger, aliases,  
variables and maybe more. In a way acting like objects. Like triggers  
and alises and other settings, folders can be turned off and on, and  
this will have the obvious effect on its contents.

With this system, grouping related settings serving a purpose in a  
folder is possible, and turning the entire thing on and off is easy.  
Sub-folders, then, can be used for more advanced purposes.

Per default, settings are created at the root level, which is always  
on. To use this system, the user creates sub folder and puts settings  
in them. All aliases inside a folder that is enabled, can be  
activated from the command line, and all triggers in an enabled  
folder would be checked against input.


If any or all of the above has been suggested before, I apologize in  
advance. I'd very much like to hear comments :-).

-- Sune Foldager.