Hotspots only in plugins?

I've been excited about the possibilities presented by miniwindows, and I managed to build nifty gauges, a mapper capture window, and a list of recent afflictions. However, I just now started working on building buttons to control my scripts, and I was sorely disappointed when I read that hotspots can only be used inside plugins.

So, could it please be explained why I cannot use the hotspots in my main script? I'd like to understand this because I tend to keep far away from plugins, for various reasons.

The way I understand it, plugins have the purpose of splitting up functionality and making it accessible to different worlds without needing to import different scripts into your main script file, which would then mean all worlds would need to be updated manually when you make a change to a script. Also, plugins can easily be installed/removed/enabled/disabled, which makes it rather easy to find culprits when things go wrong.

Now, why Nick chose not to make several features available to plugins, I can only guess. But my best guess is: he wants people to use plugins. If everyone imports things into their main scriptfile, and there are no reasons to use plugins other than 'it makes it easier for others to use', then plugins would be a wonderful feature that got wasted because people don't know any better.

Anyhow. I am very interested in knowing your reasons not to use plugins. I'm personally a 'never-poking-the-main-script-file-with-a-bazooka' kind of of person, so we're polar opposites in that regard. :)

I use plugins very sparingly because I want my scripts to share the same memory space, basically. I don't want to have to deal with event notification, variable passing, or any of the issues that arise from making things too compartmentalized.

I understand that plugins can make it easier to distribute things to others. When I'm coding and debugging, however, they are more trouble to reload and test. You can't just open a dialog, tweak a trigger's properties, and try it again. You have to edit the plugin in a text editor and then reinstall it.

I never really had an issue with that. It's pretty trivial to make a 'reload this plugin' script accelerator.

Then again, I -always- have a text editor open. I by far prefer it, even. I don't like modal dialogs while I'm mudding either, so it actually allows me to do more at once.

That is not to say that I can't sympathize with your comment about transfering values, since I consider it somewhat of a pain as well. But in my eyes, any script is written decently from the ground up, so with the proper things encapsulated in the right plugins. It just saves me tons of work in the long run.

I don't like the modal dialogs, either, and I've been wanting the world settings one at least to be made modeless.

I try to build scripts that are very modular and will work for a variety of different characters. With plugins, I have a very difficult time making them communicate and share with one another, so I end up just putting it all in the world and my install/configure functions just load it and set it up for the user.

First, here is a "reload the plugin I am working on" alias:



I use a variant of that (you need to change the plugin ID and the filename) so that if the plugin is loaded, it reloads it, and if not loaded (eg. because of a syntax error) it loads it from scratch. Then to test I just type "rl" and start testing.

Then I have the plugin open in Crimson Editor, so I can just Alt+Tab back and forth and effortlessly change things as required. To add more triggers/aliases/timers, just enter them in the main GUI, then use the Copy button to get them on the clipboard, then delete them from the main world file. Then, just paste them into the plugin where required.

You should be able to get them to communicate with each other with BroadcastPlugin or CallPlugin, combined possibly with GetPluginVariable or GetPluginVariableList.

The approach of putting everything in the world file, first misses out on some of the plugin-specific callbacks, and also makes it hard to distribute your ideas to players who may already have their own scripts in their world file. The whole idea of plugins was that you could selectively add them, regardless of whatever they already might be using.

I suppose hotspot callbacks could be called in the main script file, but I am reluctant to do that. Effectively it would encourage non-modular distributions. If you were desperate, you could fudge around it by making a small plugin whose job was simply to add hotspots to miniwindows, and when the callback was called, generate some alias that communicates with the main script.

I've tried the functions provided for communicating with various plugins and world files. It always ended in disaster when things just started getting too complicated for me to know what was going where any more. I'll worry about the distribution of my scripts, providing enough functionality and documentation to make them relatively seamless with existing world settings, but I'm not going through the rigmarole of getting my modular plugin design to work.

If the only reason for the hotspot limitation is to keep me from mucking with my world file, I'd like to be the judge of that and design my own scripts, for better or worse. I'm not about to get into fudging things with plugins to work around a hotspot limitation.

I'm a fan of scriptfile tuning and I'm not very happy when I must make a plugin. In my opinion hotspot option should be available as all other from the script file. When I'm writing scripts only for me it's much more esier to learn and edit/repair/improve.

Check this out: I'm playing now with sort of scripts that makes few simple functions available to user, eg. creating simple, preconfigured miniwindow at choosen place and size. And so, if somebody want to create with this plugin at start of world his set of miniwindows, it is impossible from scriptfile (when doing it in scriptfile is most intuitive), because he is limited to use $world->CallPlugin function instead of classic callbacks (plugin functions are hidden for scriptfile - why? I can use them from alias/macro/etc, but from scriptfile no? ), and he is forced to use a plugin, because hotposts don't work instead. Mess.

After all - yeah I used to make plugins from my scripts. But with plugin generator, with all triggers, macros, aliases and variables preseted. With all script tested and debugged. It's just easier to play with code and create required aliases/etc with a click instead of fighting with XML and crushings of client after plugin file updates.
----
After a bit of hours I'm just angry with this. So I'm making calmly a requesting for unblock the Hotspot feature to use it with scriptfile... Please?

Nick: Anyway, when are youg going to publish the new version?

OK I see that if it is holding back development of miniwindows, that restriction can be removed.

The next version should come out in the next week or so.

Thank you, thank you, thank you, thank you!!

In return, I'm slowly but surely converting everyone I know (and several people I don't) over to MUSHclient. Everyone's very impressed with your work (and mine, too, of course)!

Thank you in advance, Nick. Looking forward to new version :)

I just installed the latest version, and I'm still having this problem. Did it get added? I'd hate to go on a wild goose chance tracking down an error that doesn't exist.

Thanks!

Looking at the version history, it doesn't seem like this change has been made just yet.

In my case I would never have a script file, just simply plugins, as I prefer modular programming. I also usually set up methods to communicate between the plugins when necessary. Usually aliases that are sent from one plugin to another with no command history added to them. So I can also test the sent data easily by simply typing in a test set as well.

-Onoitsu2

I forgot, sorry.

It doesn't appear to be added by now either. Any reason in particular this was scrapped?

In the interests of keeping this thread to only two pages, this feature has been added to version 4.46.

Please note that a restriction has been added in this version (not directly related to this problem, but found when testing it). The restriction is that miniwindows may not have an empty string as a name any more. This is because in various places in the code an empty miniwindow name is take to mean "no active miniwindow".

In particular, this will affect you if you are testing miniwindows outside plugins, and do this:



In this case GetPluginID will return an empty string, which will now not be acceptable as a window name. Thus this code would fail outside a plugin, but work inside one.

To work around that, make sure that miniwindow names are not just the plugin ID, if you are testing outside plugins. eg.