When adding aliases manually (either in the GUI or by writing them in the plugin) you have a "group" option, presumably to keep everything clumped together nice and neat. Is there a way to specify a group when using the AddAlias script?
AddAlias
Posted by Nobody on Wed 17 May 2006 03:21 AM — 10 posts, 36,779 views.
After adding the alias, which I presume you are going to give a name, do this:
You can also enable or disable an entire group. See:
SetAliasOption ("alias_name", "group", "group_name")
You can also enable or disable an entire group. See:
http://www.gammon.com.au/scripts/doc.php?function=EnableAliasGroup
Thanks Nick. Gee, you're a busy guy on these forums eh?
Another thing I've noticed: I'm working on my own custom script to handle input such as #alias. I'm using ideas from your versions on how to do it, but I'm writing it entirely myself. I've noticed that you can't do something like:
#alias {hello} {say hello;wave}
because when you hit enter, the ';' is replaced with a newline so you get an incomplete alias, and "wave}" gets sent to the mud. Obviously there's a hack to work around this by turning off the command delimiter, but to me, that's not a workable option. Is there anyway to turn off the splitting of chars until after the trigger has dealt with it?
Another thing I've noticed: I'm working on my own custom script to handle input such as #alias. I'm using ideas from your versions on how to do it, but I'm writing it entirely myself. I've noticed that you can't do something like:
#alias {hello} {say hello;wave}
because when you hit enter, the ';' is replaced with a newline so you get an incomplete alias, and "wave}" gets sent to the mud. Obviously there's a hack to work around this by turning off the command delimiter, but to me, that's not a workable option. Is there anyway to turn off the splitting of chars until after the trigger has dealt with it?
There is a description about how command processing works in these release notes:
http://www.gammon.com.au/scripts/showrelnote.php?version=3.35&productid=0
Unfortunately, from your point of view, input is broken up at the command stack character first, and then the individual lines are tested for aliases.
For your idea to work that sequence would have to be reversed.
However I think that the current method is more natural. eg.
Assuming these are both aliases you want them both to be processed, and not have a single alias "healme;runaway" matched.
The latest release of MUSHclient lets you disable command stacking by putting the command stack character at the start of the line, so your example would need to be entered as:
The only other thing I can think of is another plugin callback, like "OnPluginCommand" however which operates on the raw command as typed, before command stacking is processed.
http://www.gammon.com.au/scripts/showrelnote.php?version=3.35&productid=0
Unfortunately, from your point of view, input is broken up at the command stack character first, and then the individual lines are tested for aliases.
For your idea to work that sequence would have to be reversed.
However I think that the current method is more natural. eg.
healme;runaway
Assuming these are both aliases you want them both to be processed, and not have a single alias "healme;runaway" matched.
The latest release of MUSHclient lets you disable command stacking by putting the command stack character at the start of the line, so your example would need to be entered as:
;#alias {hello} {say hello;wave}
The only other thing I can think of is another plugin callback, like "OnPluginCommand" however which operates on the raw command as typed, before command stacking is processed.
Well, it's a steep learning curve, that's for sure.
Am I correct in saying that the "GetAliasList" only returns aliases from the particular plugin that it's called from?
Like I said, I'm trying to write my own #alias function, and I was hoping that the eventual execution of #alias will result in an alias command that acts as a command-line interface to the current alias system - in other words, if I make an alias with #alias, I can then edit it using either the #alias command, or the GUI.
I have an alias defined in the GUI that doesn't seem to appear in my GetAliasList list. I'm guessing this is normal?
Am I correct in saying that the "GetAliasList" only returns aliases from the particular plugin that it's called from?
Like I said, I'm trying to write my own #alias function, and I was hoping that the eventual execution of #alias will result in an alias command that acts as a command-line interface to the current alias system - in other words, if I make an alias with #alias, I can then edit it using either the #alias command, or the GUI.
I have an alias defined in the GUI that doesn't seem to appear in my GetAliasList list. I'm guessing this is normal?
Yes, each plugin and the "global" world have their own script space, and set of triggers, aliases, timers and variables.
The idea is that you can write a plugin without worrying too much about what other plugin writers might have done.
However, obviously, if two plugins both make an alias that matches "foo" there is going to be some sort of clash.
As for the list of aliases, see:
http://www.gammon.com.au/scripts/doc.php?function=GetPluginAliasList
This gives the list of aliases in a particular plugin, and with a blank plugin ID, lets a plugin access the global aliases.
What is your ultimate objective here? To make a plugin that implements #alias, to add aliases in the global world space? Or itself? Or something else?
The idea is that you can write a plugin without worrying too much about what other plugin writers might have done.
However, obviously, if two plugins both make an alias that matches "foo" there is going to be some sort of clash.
As for the list of aliases, see:
http://www.gammon.com.au/scripts/doc.php?function=GetPluginAliasList
This gives the list of aliases in a particular plugin, and with a blank plugin ID, lets a plugin access the global aliases.
What is your ultimate objective here? To make a plugin that implements #alias, to add aliases in the global world space? Or itself? Or something else?
Quote:
Am I correct in saying that the "GetAliasList" only returns aliases from the particular plugin that it's called from?
Am I correct in saying that the "GetAliasList" only returns aliases from the particular plugin that it's called from?
The design idea here was that, when you initially develop your scripts in the global world script space, GetAliasList will return the list of aliases in your current world. Then when you migrate your aliases etc. into a plugin, along with its associated script, then GetAliasList will continue to operate in a natural way, that is it returns the list of aliases that are now in that plugin.
My goal here, whether it sounds grand or foolish, is to implement a set of functions that mimic how the tintin #commands work. The reason for this is pretty simple. I'm going to suggest to some of my friends that they try out mushclient. However, I'm perfectly aware that most of them are embedded in the #commands, and are totally used to them. They're also much faster, and easier to just type in the commands than have to blunder through a GUI with windows.
So, I'm trying to make it so that if they try out mushclient, I give them my Tintin plugin, so they can just paste all their tintin commands right into it and it'll get them 90% of the way to having the client setup the way they like it (I've noticed that some things are gunna be a real bitch to convert nicely).
So, I'm trying to make it so that if they try out mushclient, I give them my Tintin plugin, so they can just paste all their tintin commands right into it and it'll get them 90% of the way to having the client setup the way they like it (I've noticed that some things are gunna be a real bitch to convert nicely).
Yeah, I thought you were doing something like that. :)
The problem with using a plugin, in itself an admirable idea, is that for the reasons I mentioned, the plugin can basically only affect its own "space", thus if you do an #alias command they will get added to the plugin, which will work, however the aliases will be tedious to edit, since they won't appear in the GUI editor.
Also, aliases are not saved when you save a plugin, only variables are, so they will need to be re-added every time. I suppose you could serialize them into variables, and have the plugin re-add them every time it starts, but somehow this sounds wrong to me.
This is really a once-off step isn't it? How about this? Make a script which will read the tintin commands (perhaps from a file, or the clipboard) (see world.GetClipboard), and write out a file (or put on the clipboard with world.SetClipboard), the converted aliases/triggers/timers etc. in XML format.
The XML format is the one used internally by MUSHclient, so every option is available in one place (like groups, obscure options not supported by AddAlias and so on).
Any conversion problems could be reported to the screen with Note. There are bound to be some, because not every tintin script command will be supported by MUSHclient.
Then as a single extra step instruct the player to go to the File menu -> Import and import the converted things from either the clipboard or your output file from the conversion.
This will import them into the main "space" of MUSHclient, and they can then admire the converted aliases etc. inside the GUI interface.
Then for adding further ones "on-the-fly" I think you will need to use the main script file (not a plugin) so they will be added into the main interface, not the plugin space. All you have to tell your friends to do is save the script file to disk, set it as the script file, and turn scripting on. When it loads it can add any aliases it needs, auto-detecting if they are already there.
If I may recommend, use Lua as the language. It ships with MUSHclient, so they will definitely have it. Syntactically it is similar to C (and thus Jscript), and not far off VBscript. I had a plugin in VBscript that I converted to Lua, largely by doing find-and-replace, like converting "EndIf" to "end -- if".
The problem with using a plugin, in itself an admirable idea, is that for the reasons I mentioned, the plugin can basically only affect its own "space", thus if you do an #alias command they will get added to the plugin, which will work, however the aliases will be tedious to edit, since they won't appear in the GUI editor.
Also, aliases are not saved when you save a plugin, only variables are, so they will need to be re-added every time. I suppose you could serialize them into variables, and have the plugin re-add them every time it starts, but somehow this sounds wrong to me.
Quote:
... if they try out mushclient, I give them my Tintin plugin, so they can just paste all their tintin commands right into it and it'll get them 90% of the way to having the client setup the way they like it ...
... if they try out mushclient, I give them my Tintin plugin, so they can just paste all their tintin commands right into it and it'll get them 90% of the way to having the client setup the way they like it ...
This is really a once-off step isn't it? How about this? Make a script which will read the tintin commands (perhaps from a file, or the clipboard) (see world.GetClipboard), and write out a file (or put on the clipboard with world.SetClipboard), the converted aliases/triggers/timers etc. in XML format.
The XML format is the one used internally by MUSHclient, so every option is available in one place (like groups, obscure options not supported by AddAlias and so on).
Any conversion problems could be reported to the screen with Note. There are bound to be some, because not every tintin script command will be supported by MUSHclient.
Then as a single extra step instruct the player to go to the File menu -> Import and import the converted things from either the clipboard or your output file from the conversion.
This will import them into the main "space" of MUSHclient, and they can then admire the converted aliases etc. inside the GUI interface.
Then for adding further ones "on-the-fly" I think you will need to use the main script file (not a plugin) so they will be added into the main interface, not the plugin space. All you have to tell your friends to do is save the script file to disk, set it as the script file, and turn scripting on. When it loads it can add any aliases it needs, auto-detecting if they are already there.
If I may recommend, use Lua as the language. It ships with MUSHclient, so they will definitely have it. Syntactically it is similar to C (and thus Jscript), and not far off VBscript. I had a plugin in VBscript that I converted to Lua, largely by doing find-and-replace, like converting "EndIf" to "end -- if".
I knew you were going to say something like that. Which means the 8 hours I spent yesterday reading the helpfiles and learning the scripting routines was a big waste of time. Well, not really, but all the time I spent coding and debugging certainly was. Ah well, in the end I know your approach is probably the better way.
Still frustrating to have all that time wasted though.
Actually, forget everything I said above. I've worked out a wonderfully simple and splendid way of doing this that works exactly how I want, and doesn't require me to rewrite all of my code. Of course, if I ever convert it to lua I'll have to rewrite it, but for now I'm sticking to the only language I'm comfortable in, perl.
Still frustrating to have all that time wasted though.
Actually, forget everything I said above. I've worked out a wonderfully simple and splendid way of doing this that works exactly how I want, and doesn't require me to rewrite all of my code. Of course, if I ever convert it to lua I'll have to rewrite it, but for now I'm sticking to the only language I'm comfortable in, perl.