Extended macros

I'm sure it's been mentioned before, but I haven't found a topic that covers what I want to say/ask.

One of the things I liked about zMUD was its ability to build a macro out of pretty much anything except Ctrl-Alt-Del. Here, in MUSHclient, I don't get that same capability. I'm curious to know what the reasoning behind the macro options was, considering the AddAccelerator function can do more than the macros settings allows.

In particular, I like to use Alt-, Ctrl-, and Shift- with the number pad keys for various direction commands like shooting a bow, squinting, evading pursuit, swimming, etc. Can anyone recommend a nice, clean way of allowing me to use all of these combinations of my keys to easily have access to several modes? That is, I don't want to have just Alt-NumPad and then switch through some "mode" variable. I'd rather have Ctrl-Shift-NumPad for some mode and then Alt-Ctrl-NumPad for another, etc...

Have you looked at world.Accelerator and world.AcceleratorList? Those should be able to define and redefine macros for any combination of keys, including possibly those funky media buttons and whatnot.

I have seen the functions. My question was more just to find out why the difference between macros and accelerators. Why not have more key options in macros instead?

There is no difference, except that macros are a bit harder to edit with a script. Functionally they are exactly the same.

Accelerators gives people the option of having any combination they'd like. Why make a list thats (literally) hundreds of combinations large when most people won't use most of them.
It also allows people to do more scripting with the creation/editing of (macros/accelerators), since macros didn't have a method to edit/create via script (well, except for XML importing, but you still couldn't edit very well, or see what you already had, save the world file).

Accelerators solved these shortcomings (scripting interface, allowing you to put script functions directly into the accelerator (as opposed to having to go through a middleman alias), as well as all the possible key combinations).

One of the things I'm hearing from many people on the zMUD vs MUSHclient argument is that zMUD has a much nicer interface for editting settings. Folks (myself included, I'd have to say) just like it better when "option" settings are in a separate dialog and all triggers, macros, aliases, etc are in the Explorer-like interface. With zMUD, you don't have an exhaustive list of macros that can later be "filled in." Instead, you can add a new macro item and select your key combination that will activate it.

This post might belong in the Suggestions forum now...

I hope that MUSHclient will some day allow us to do nested groups for settings, so that we can more easily enable/disable triggers and other stuff. It's something that is used a lot in zMUD, and it's also just very useful for organizing your settings in a way that you can easily come back later to edit things. XML is ideally suited to this sort of hierarchical storage, and the change could be made in such a way that the files would still be backwards compatible. (I've written apps that changed XML file formats and you could use the new data with the old program and vice versa. I loved it.)

Well Larkin.. The 'old' macro menu was a left over. It would be nice if it was reduced a bit maybe, with only preset defaults showing + any 'active' accelerators. That way you could see what accelerators are in use easilly, even if Nick left the ability to change them only from scripts. In the case of something like accelerators, having the plugins be essentially a black box is... inconvenient imho.

As for grouping settings, so you can turn them on/off. Have you looked at the world.enablegroup command? Personally, I think sorting by the group first would be slightly nicer in the dialogs, especially since you could enable/disable the entire group through there then, at least for the 'master' world files settings. Trying to figure out what is going on in a plugin... We really don't have any way of doing at the moment. But speaking of those.. You can also use world.enableplugin *and* the world.enablegroup functions for each plugin as well. So that is 3 levels of grouping:


The only thing 'not' grouped are variables, and there is still a seperation between the variables in the world file, and each plugin, so they don't interfer with any other scripts, including the main world. I am not sure what you think we are missing exactly Larkin. ;)

What I think is missing is a hierarchical structure for settings. Different people find this useful for different reasons. I like it for the organization and easy view you can get from it (in zMUD, for example) and also for the ability to quickly enable/disable groups and sub-groups with a single command.

I can have a folder called Afflictions and it contains sub-folders, such as General, Bashing, Monk, Venoms, or anything I want to include there. In my general folder, I would have afflictions that anyone is capable of giving me, such as webbing me or putting me to sleep. I would be able to disable all Afflictions with a single command, or enable just the folder for a particular class, or disable triggers for when I'm bashing NPC's.

The way MUSHclient has this setup, I can enable and disable either by individual names or by (flat) group names. If I want to turn off all afflictions and only leave the monk afflictions enabled, I have to either place them in separate groups (which limits me in other situations) or make a script that disables each one individually by name. This is not only painful, but inefficient. XML was made for hierarchies and for searching them quickly with XPath, so the storage on disk isn't a real issue. The problem would be storing them internally to MUSHclient and dealing with them there, and that's something I don't know about because it's all internalized.

Hmm. I see what you mean. Its not impossible, but would require a reworking of the way things display. Possibly even how they are stored. Something like what POVRay does for its custom menus, where you get something like:



Only, internally in the XML, instead of on the HD as file directories. So, instead of just using 'enablegroup "somegroup", 0', you could do 'enablegroup "combat/afflictions/basic", 0' or 'enablegroup "combat/afflictions", 0', etc. That actually might be fairly simple, or I would think so. Its the display that would require reworking. Something like having the 'existing' edit dialogs, but something new added for 'grouped items' in the existing hierarchy list, which would let you find items based on the groups and subgroups, instead of using the seperate trigger, alias and timer dialogs.

Now.. In the world file and plugins.. Either a true hierarchy could be added, which would mean risking the client saving out new version of the existing worlds without the 'group=""' field, but using the new XML layering instead *or* make the XML slightly less friendly, but simply extending the existing 'group' file to contain the "blah/blah2/blah3" type information. Something that the Mushclient would have to rebuild from the XML anyway, to avoid changing the original dialogs.

I think that would be doable in just a plugin. Well, a plugin with a database. You obviously wouldn't have the interface with the normal config windows, but the hierarchy seems doable.

You can even do that now to an extent (by cycling through trigger the trigger list and checking against their group names). I think magnum had a snippet that did that (disabled/enabled triggers based on a prefix on their label, editing it to include this shouldn't be too hard)... although it was a while ago.

Edit: Found one post talking about this, but it wasn't the one I was looking for. You could use the triggerlist to get the group names, and then parse the names to enable/disable based on substrings.
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=362