Because this E-mail conversation turned lengthy and covered what I thought was an interesting perspective on my part, I'm posting the content here:
Quote:
Your plugin looks pretty cool.
Just a suggestion, maybe make some of the commands respond to no arguments, eg.
That didn't match the alias, and I'm not sure what the syntax is, so you might respond:
Syntax: eqlvl <desired level>
Eg. eqlvl 42
However you have taken the plugin idea and run with it, exactly how I was hoping it would happen. :) I suppose you have tried: /world.debug "plugins"
The new plugin wizard will simplify smaller plugins, and even ones like yours, and hopefully will lead to a whole swag of them being written.
Things like the recent requests "WHO lists to a separate window", "equipment to a separate window", etc, would all make good plugins.
Someone could also do a better "plugin_list" plugin - eg. list a single plugin if wanted, show all aliases, variables etc. and so on.
Anyway, looks good. :)
Regards,
- Nick
Thanks! :)
The "eqhelp" command accepts arguments. Specifically, the other aliases as arguments. For example "eqhelp eqlvl" gives you the help for the "eqlvl" alias. In most cases, if an argument is illegal for some reason, the plugin will list the appropriate help file for that alias. However, that said, your suggestion is valid. An alias that expects arguments should present the help if NO arguments were provided. I'll fix that.
Actually, I've never used /world.debug. For some reason, I've overlooked that function, but it's definitely useful for plugins, where there is no other quick method to check the value of a variable. I'll be using it in the future. :)
Although I currently only use one character at the primary mud I play, I envision some point where I will want to use more. This presents a challenge to me, because much of my script is still written in the main world's support structure. I don't like the idea of sharing a world file between characters, because the 'state' data should be independent for each player. I don't like the idea of cloning the world file, because changes reflected in one file will not migrate to the other files.
I have to admit, I wish you had designed MUSHclient with that in mind, keeping separate world files and player files to accommodate the different requirements.
With that perspective, the way to look at MUSHclient now, is that the world file is not actually the world file, but the --player-- file.
Given that, my tasks for the current mud I play are to migrate all "world" related material to plugins. It's the plugins that are truly the "world" files, for they can be incorporated into any "--player--" file.
For myself, that's a monumental task, because my "support structure" is quite large. I am currently looking at developing an "AOD_Monitor" plugin which handles the monitoring of a wide assortment of data from the mud, such as my current health, how long a spell has been effecting me or a mob, etc. I am also considering developing an "AOD_Spell_Queue" plugin, which is responsible for allowing me to queue spells\skills so that they will cast one after another. This one has it's complexities, because I might want to develop it with sub-plugins of it's own, one for each guild in the game... (Which could be problematic because some guilds share skills\spells with other guilds). Yet another plugin I am considering is an "AOD_AutoBots" plugin. It would be a controversial plugin that does many of the things people already automate on the mud, but no one wants to talk about, for fear of being site banned for illegal script use. Stuff like repeat heal skill when one completes, repeat offensive spell when one completes, autoleave the ferry, corpse looting (when your flag is
removed on a mob), etc.
The biggest challenge to all of that is the interdependency between the plugins. All of those proposed plugins require certain levels of interdependency on the others. The "monitor" calls the "Spellqueue" when my health drops too low, the "Autobots" only function when they are toggled on, and depend on "Monitor" data, and issue calls to the "SpellQueue", etc. Given the stickiness of making cross-plugin calls, this could require some interesting and
innovative subroutines. Also, because of that interdependency, I pretty much need all 3 to in production at the same time, else I go without a lot of functionality while I develop the next one. It's enough to make me want to just keep them all in the current state they are in... but again, it's not practical if I want to develop ALT characters.
Anyway, the reason I got into all that ranting was simply to respond to your suggested plugins. :) I agree, they would all be valuable... but if you were trying to make a 'hint', I'm afraid I might be too busy with my own Godzilla's to tackle any small fries. I expect pretty much all of my plugins will be comparable in size and complexity to my current "AOD_EQ" plugin. (And somewhere in there I've got to do some playing! LOL) |