Changing the default "send to"

Is it possible to change the default "send to" for new aliases, triggers, and multi-line triggers to always be "send to script"? I rarely use any others now, and it'd be handy to not have to select that every time. A few of the other options would be nice to have set on by default too, like expand variables.

Twisol suggested recompiling mushclient to do this, but I don't have the slightest clue what that entails... ^^;

Haha, it wasn't a serious suggestion! =/ I wouldn't really expect someone to modify and recompile the source for something like that.

Hee, I thought as much. But now maybe we'll both find out if there's already a way to do it!

Edit: I see what you did there, Mr Nick! Pointing out options in the newest version... hehe.

Edit 2: But... I see no mention of 4.54 being released yet... *sits and waits*

4.53 came out an hour before you posted... patience grasshopper. :)

I don't like to release two versions within a day of each other unless some major bug is found. Maybe someone else will have another brilliant idea. :)

I prefer to always have aliases -not- keep evaluating, but triggers -always- keep evaluating, but I can't really set that default separately with the current setup. Same with case sensitivity (aliases never, triggers always). Any chance it could be improved to allow this?

OK well spotted before I even announced it, and I changed as you suggested Twisol.

Oh, and now is the time to speak if you seriously want to have other defaults (not just because they may vaguely sound good, but because you can make out a good case for it).

Oooh!

Could we have XML Import warning go to the world like other scripting errors too?

Basically, make the window just go away unless it's actually needed for the Global plugins which might not have a world open. It's a little annoying to have an XML Import window pop up and cover the error and the whole hitting enter thing in annoyance to clear away a messagebox to move this XML Import window ends up being "edit" despite it just being labeled "OK" so it reopens the file which is usually already open and the cursor sitting at the lines in error, oops not anymore since the file's newly opened dang it, cursor's back at the top of the file and arghhhh. *stops and takes a breath*

Okay, it's very annoying. :)

It does what?

You mean when loading plugins? Or pasting triggers? Or something else?

It happens when you load a plugin with a typo in it (leave out a paren somewhere)

Yes please! Totally unrelated to the topic, but I really hate how a new notepad-ish window is opened every time something goes wrong with an XML import. Being able to note the XML errors would be great.

I think a case could be made for not opening the editor when a plugin fails to load, too. Normal users don't care about the plugin code, and us developers can just hit Edit (which is, after all, right there on the plugin dialog), open it ourselves, or more likely than not use the editor we already have open.



AFAIK, global plugins are only loaded into a world, just like every other plugin. The only special thing is that they're automatically loaded into every world.


Technically, you did, in the post detailing the non-GUI options MUSHclient supports. ;)

True, but he did ask for other brilliant ideas. :)

Well here's the problem. The loading sequence is such that IIRC plugins are loaded early on - certainly into a world document, but before the document is fully established. There is a point in world creation where the output font, font size, window size, wrap column etc. are established (that is, they are read from the world file). Before that it isn't possible to do notes to the output window.

This is why when loading plugins, if they do a note as part of the install process you won't see it. However if you reload the plugin later on, you *do* see it.

So, an error during world loading (including plugin loading) rather than nicely being visible in the output window would totally disappear, possibly causing a lot of confusion.

Still, maybe errors could be batched up. ;)

Remind me again why plugins are just not loaded until everything's set up? Was it because it's done as soon as each <plugin> tag is read from the XML file?

(I think I just answered my own question there...)

Probably a deeper question is, when is "everything set up"?

On the one hand, you could say the world file should be loaded first so that plugins know things like the world file font, on the other hand you might argue that plugins are setting up the world parameters, and that the "everything is set up" once the plugins are loaded.

Imagine for a moment that Plugin A changes the world font. Then plugin B makes a decision based on what the font size is. The overall result will change depending on whether Plugin A or Plugin B is loaded first. And who is to say which should be first. Alphabetic order?

In fact I think what happens is that loading the world is like this:

• Load main world file
• Load plugins
• Create output window based on what is now the established font, font size, width etc.

Thus a plugin loaded during startup can't write to the output window because it doesn't exist yet.

You may argue that you don't like that design, but it isn't necessarily "wrong", and an alternative design may have other flaws.

Even if plugin A specifies a font and output, those parameters aren't removed from the world file's attributes. Plugins are still plugins, and not required libraries, right? Firefox can run and function if AdBlock's not loaded... It's not like Adblock becomes a required DLL...

I don't think there's anything that a plugin can do that will require you to close the world and reopen it fresh when it is installed. They can be installed at any point in the session. If you're playing for an hour, and then get plugin A, you don't have to close and reopen the world... the font just changes. You may need to click the reinstall button for plugin B, but plugin A is not a core dependency. Even an ATCP/Telnet 102 plugin may require you to disconnect and reconnect, at most; not destroy the MDI window.


And I won't argue the principle about putting user preferences (the font) into a plugin - a modular piece of code intended for easy distribution.

I'd posit that the one fringe case... "a plugin may change the font and cause a flicker" is not enough to have a custom error handling routine that overrides the user's preference that errors get Noted to the world window.

So, I'm not saying this design is wrong. I'm just saying that it is counter to the rest of the plugin and general UI experience.

Actually, I'd really like to have an option to -not- load some, or even all, plugins at startup, and let me open the world first then hit one button or something to load them before connecting. My client hangs up on me every time I open my Achaea worlds, because of the map plugin I use (Nitro's map that grabs the actual IRE maps that nexus and the flash client use). It hangs up because of the plugin, because of how it caches the maps, so it'd be nice to tell it not to load on opening the world. It's a bit annoying to try and open all three of my Achaea worlds to copy triggers when each one hangs up the client XD I like the map too much to give it up though.

Maybe there could be an option for each plugin on the list that flags it for not loading right away, and then a new button added in somewhere up top (or a new command-line script?) that loads all those flagged plugins?

Some of my plugins remember if you had them disabled and automatically disable themselves next time they are loaded.

And I think there is a key you can hit which disables loading plugins. Can't remember what it is right now. If there isn't, there should be. ;)