Gammon Forum : MUSHclient : Miniwindows : Hotspots only in plugins?

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Miniwindows

Hotspots only in plugins?

Hotspots only in plugins?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Larkin (278 posts)

Date

Fri 19 Sep 2008 08:52 PM (UTC)

Message

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.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #1 on Sat 20 Sep 2008 06:19 AM (UTC)

Message

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. :)

Posted by

Larkin (278 posts)

Date

Reply #2 on Sat 20 Sep 2008 11:37 AM (UTC)

Message

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.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #3 on Sat 20 Sep 2008 11:58 AM (UTC)

Message

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.

Posted by

Larkin (278 posts)

Date

Reply #4 on Sat 20 Sep 2008 12:05 PM (UTC)

Message

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.

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #5 on Sun 21 Sep 2008 01:30 AM (UTC)

Message

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


<aliases>
  <alias
   match="rl"
   enabled="y"
   send_to="12"
   sequence="100"
  >
  <send>

if ReloadPlugin ("97d89d35e4b6d88747267240") == error_code.eNoSuchPlugin then
  check (LoadPlugin ("/program files/mushclient/worlds/plugins/some_plugin.xml"))
end
Note "plugin reloaded"

</send>
  </alias>
</aliases>

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Larkin (278 posts)

Date

Reply #6 on Sun 21 Sep 2008 02:19 AM (UTC)

Message

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.

Posted by

Yergo Poland (20 posts)

Date

Reply #7 on Wed 03 Dec 2008 05:05 PM (UTC)

Message

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?

I'm doing my best with English... Sorry ;)
Scripting: php (currently rewriting things to Lua)

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #8 on Wed 03 Dec 2008 07:27 PM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Larkin (278 posts)

Date

Reply #9 on Wed 03 Dec 2008 07:38 PM (UTC)

Message

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)!

Posted by

Yergo Poland (20 posts)

Date

Reply #10 on Wed 03 Dec 2008 08:21 PM (UTC)

Message

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

I'm doing my best with English... Sorry ;)
Scripting: php (currently rewriting things to Lua)

Posted by

Katie Love (19 posts)

Date

Reply #11 on Fri 20 Mar 2009 11:24 PM (UTC)

Message

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!

Posted by

Larkin (278 posts)

Date

Reply #12 on Sat 21 Mar 2009 12:09 AM (UTC)

Message

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

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #13 on Sat 21 Mar 2009 12:46 AM (UTC)

Message

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

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #14 on Sat 21 Mar 2009 07:44 PM (UTC)

Message

Quote:

Did it get added?

I forgot, sorry.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

46,663 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )