Mudding along with 3.23...

From a recent E-mail:

For the most part, I haven't testing programming plugins under this new version. I did, however, install it as soon as it became available.

I haven't had any significant problems with this version so far. There was the blank line issue, but I am pretty sure that extends back through all previous versions. It's mostly just a cosmetic bug anyway.

I've sort of been lazy about programming lately. Haven't really been in the mood. I took some time to try and get "LogSend" working (See related thread), but put that on hold for the time being.

Here is my current to-do list:
- Turn "Script Tools.vbs" into a plugin.
- Edit main Script file (with EQ script inside) to work with Tools plugin.
- Export "EQ Script" back to it's own file, then turn it into a plugin, for public release.
- Build webpage at my site to host my plugins.

I don't yet feel like the Script Tools is ready for public release, because of the "LogSend" issue, which is putting the whole project on hold, at least the public release part.

I'm sorry I can't offer more input at this time. I'll try and get around to doing some programming this weekend.

Oh, BTW, I haven't tried the sample plugins yet either. The emotes one won't work at my main mud because of the way the emotes are presented in multiple columns. That's fine, I'm sure they work for other people.

One thing I was considering, is how to name my files. I've decided that I should keep version numbers for my plugins, and I think I'll include the version number in the script's file name. I'm curious, what would happen if a user tried to install a plugin with the same "Plugin name" as an existing plugin? ...Guess I'll find out when I play with it later. :)

Well.. I installed it, but as to testing..

I am reluctant to make most of what I have into plugins for two reasons. The first being that most things I have done have been strictly color coding, etc. The second problem is that most of the other things are either duplicated in stuff Magnum has already down or would require serious reworks to make them 'legal'. One example is my potion lister. Technically you are supposed to figure out what the ingredients are yourself, but currently that info is hard coded into the script, so wouldn't necessarilly be legal to hand around. I just don't have much of anything at the moment that wouldn't either need a complete rework or any new ideas I have thought up to do. I may convert my reboot timer into one though, but it uses the status line so collisions with other plugins are both possible and likely. :p

Otherwise looks good. The only problem I have run into was a result of a mistake I made in a new color coding script and forgetting that I needed to turn the dang trigger itself off to keep it from tripping on the same line that was supposed to change the color... Sigh.. Took me 10-12 tries to figure out why. lol

I'm just plugging along happily with 3.23. I've started converting most of my script file into a selection of plugins I may release for use with Among The Stars TrekMUSH. So far, I have plugins that do the following:

1. Color-Coding
Color-coding is now much more powerful with the ability to completely gag a line and use World.ColourTell and World.ColourNote to build a completely new string with a much larger selection of colors than was possible using normal color-change triggers.

2. Sound-effects for use with the space system
I have a fairly extensive collection of computer sound effect wave files that add flavor unobtrusively. None are sound bites of speech, all are the various beep effects, and tend to feel like part of the operating system rather than harsh, patched-together soundbites of Picard saying "Make it so", etcetera. I'll probably wrap this in a zip file so when the plugin is installed, I'll be able to know where the sound files are located.

I'm also starting to experiment with creating entries in the Registry for use with Windows' built-in sounds control panel. As the registry is quite accessible from scripting, this would allow for creater customizability for scripted sound effects and less hard-coding of filenames.

3. Replacement contact list.

The replacement contact list uses a trio of triggers to gag the contact list, capture each line into an array (well, actually a Scripting.Dictionary COM object), then redisplay the list with the following changes:

1. sorted by range to target
2. column order changed for clarity
3. new contacts hilighted
4. contact name colorcoded by type (ship/planet/base/anomaly/other)
5. range color coded (docking range, missile weapon range, beam weapon range, sub-parsec range, and "too far" :)

For any out there who are on ATS and are worried about their macros/alias/scripting rules, none of these plugins force the client to automatically send responses to the MUSH. They just redisplay data. They won't violate any ATS rules.

So far, performance is excellent, even though I'm performing a very crude bubblesort on the list just before displaying it.

That should work OK. The only thing they can't have is the same ID, which shouldn't happen if you allocate unique IDs when developing them.

From another thread, elsewhere:

I haven't experienced any significant bugs with the latest version, in all the time I have been using it.

I haven't released (or even worked on, really) any plugins, because I've sort of been experiencing the chicken-or-the-egg dilema:

That is, I've been waiting for some minor fixes before releasing any plugins. I've wondering to myself if Nick has been waiting for me (and others) to release plugins to see if everything works. :)

The two things I would really like to see resolved in the future versions:

-Grab directory paths from Global Mushclient settings. I really want this, because I don't want the user to have to edit the plugin... and I don't want to resort to reading the registry unless I really have to.

-The "logging" problem I posted about elsewhere. I want a subroutine that works well for everybody, whether they don't log, they do log, or they log in HTML. I would like to see the commands logged in the same colour they are presented in the output screen. I still feel you, Nick, should just copy, paste & edit the World.Note logging (which works fantastically) to have World.Send log the same way. That way, I wouldn't need a LogSend subroutine at all.

Another point about logging: Although I am attempting to include a logging subroutine in my script, it is fairly likely that other plugin writers may not, which is another important reason for having World.Send's log properly themselves, without need of a dedicated routine.

-Finally, and this is really just cosmetic, I hope you eventually resolve the minor problem of blank lines continuing to be echoed to the output screen and logs after using World.Send statements. A blank line will only appear after the final World.Send in a routine. Oh, and World.Note's... same thing.

All of that aside, I would say that MUSHclient has evolved superbly. I think you've managed to implement this whole plugin idea well, so many Kudos to you, Nick. :)