[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Zipped-up plugins
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Zipped-up plugins
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by Fadedparadox   USA  (91 posts)  [Biography] bio
Date Sun 16 Aug 2009 03:25 PM (UTC)  [ quote  ]
Message
Sounds good.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sun 16 Aug 2009 05:55 AM (UTC)  [ quote  ]

Amended on Sun 16 Aug 2009 05:56 AM (UTC) by Twisol

Message
Nothing. The original idea was to keep those files in the zip, i.e. not unzip them. It's possible to do that, it's just a fair bit harder for the code to handle compared to normal files. It just keeps related things together "under one roof", you might say.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Blainer   (191 posts)  [Biography] bio
Date Sun 16 Aug 2009 05:30 AM (UTC)  [ quote  ]
Message
I must be missing something. What is hard about making a zip file with a file structure that when
unzipped at the MUSH directory creates a folder under plugins and extracts the required files into it?
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sun 16 Aug 2009 05:17 AM (UTC)  [ quote  ]

Amended on Sun 16 Aug 2009 05:23 AM (UTC) by Twisol

Message
I think all in all that's exactly what my initial idea was aiming for, so that's great. However I have to disagree with the sentiment of having to unzip an archive to use it. As I said, Java does this perfectly well with its JARs, and it supplies classes that make reading/writing compresed data entirely transparent. It is probably a little difficult to do this in C++ (since Java's already written it for you), so I'm fine with plain old directories. I think you hit the nail on the head with your Warcraft analogy.


Some problems come to mind, though.

1) At this point in time, disabling a MUSHclient plugin does not keep it disabled next time you open MUSHclient. This makes it pretty hard to run an auto-installer if everything's going to be added.

2) MUSHclient comes with many plugins already (and most that I have never used myself), so an auto-installer would also include all of those.

3) How does MUSHclient tell which directories contain a plugin? The benefit of using archives is that you'd have a standard file suffix like .MPA, although I see that archives also have their share of downsides.

4) The 'require' path. I desperately want this to be changed so that it checks a plugin's relative path first. If my plugin is in plugins\foo\bar\, I want require("baz") to look for plugins\foo\bar\baz.lua first. Otherwise this is just another bit of info tacked on to require; right now I have to use require(GetInfo(60) .. 'filename'), and this would be worse because the plugin's subdirectory name isn't necessarily fixed. It's throwing too many variables into the equation.

5) Back to the auto-installer. It would likely have no concept of installing certain plugins for only certain world files, and at that point you'd be better off adding it to the list on your own. I'd much prefer an auto-installer to just check the directory, and show the un-added plugins in a separate part of the Plugins dialog. That way I can select which ones I want to add for this world myself, and the plugins window would only display the ones that I've enabled myself. Did that make sense? I felt like I rambled a little there.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Sun 16 Aug 2009 04:52 AM (UTC)  [ quote  ]
Message
*boggle*

I think I see where you guys are coming from with this. But how about this? First, let's look at how WoW implements plugins.


  • They have an AddOns folder inside their installation directory.

  • For each plugin there is a subfolder (not a file) (eg. Cartographer folder for the Cartographer plugin).

  • Inside that folder are some standard files, in particular Cartographer.toc which is the "Table of Contents" file. That lists other files that are required.

  • The plugin itself is a .lua file (Cartographer.lua in this case)

  • I am not an expert, but somewhere in there are the dependencies (in other words, what other plugins also need to exist)

  • Any required data is in the folder as well


Now this effectively gets around the mess of not knowing what belongs to what. They also have the idea of a "saved data" folder somewhere else. In their case they put different accounts into different directories, which is conceptually similar to the plugin state file which has the world id as part of the name.

I don't know about having everything in a zip file - it has to be unzipped anyway to use it, but the folder idea I quite like.

A while ago I did a "plugin installer" plugin which simply installed every plugin it could find in a directory. Effectively WoW does the same (other programs would be similar, eg. Photoshop). Rather than having to go through a "plugin install" process you simply unzip the plugin folder (for a specific plugin) into the plugins folder.

So, to summarize, what you could simply do is:


  • Make a plugin per folder
  • Inside that folder put the .lua file
  • Also put any data (eg. images, sounds, databases)
  • Somewhere (possibly the plugin itself) put dependencies


Now MUSHclient could scan all folders looking for plugins, build up a list, check all the dependencies are satisfied, and then start installing them (eg. the ones which others are dependent on, first).

All this could be tricky to get right, but your comments are welcome, even if you think my idea has serious flaws in it. ;)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sun 16 Aug 2009 04:29 AM (UTC)  [ quote  ]
Message
Yes, that's exactly what I'm trying to avoid. I've already gone that route actually, first posting about serializing the result of string.dump (after passing it through base64 encoding to handle the 0-chars), then making a script to act as a proxy between you and a plugin, getting a plugin variable and loadstring()'ing it. This is cleaner and more versatile, plus it conceivably allows for writing to the archive to change resources like a database.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Blainer   (191 posts)  [Biography] bio
Date Sun 16 Aug 2009 03:40 AM (UTC)  [ quote  ]
Message
I'm sure this is a stupid idea, but couldn't you use serialize on install to put the files where you want them. Would mean a bloated plugin file though.
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Sun 16 Aug 2009 03:27 AM (UTC)  [ quote  ]
Message
This is really just the latest idea come from an ongoing thought flow, on making it easier to distribute plugins and/or communicate between them. Tired of me yet?

I know of several plugins that require certain resources (such as images), and I'm sure there will be plenty that also have sqlite databases distributed alongside. I personally have quite a few plugins in my plugins directory, and it's getting really disorganized in there. My idea is to add support for zipped plugins, where the plugin is pre-packaged with its resources, and you only need to move around the .zip file itself.

The idea comes from Java's .JAR format. A MUSHclient plugin archive (.MPA?) would simply contain the plugin's .xml file (either named identically to the zip, or something standard like plugin.xml), as well as the plugin's resources, such as images or databases.

Theoretically (and this part is more of an afterthought) you could change the contents of the ZIP, perhaps saving an updated database into the archive, or 'require'ing a file from it (to serve the same purpose as my LoadPPI script from before, but without having to wait until the other plugin has loaded). I know Java has support for this sort of access in its java.util.zip package, but I don't know how easy it would be to implement something similar in C++. I think this particular facet would make zipped plugins even more useful.


In summary, zipped plugin support will allow plugin resources to be packed alongside the plugin itself, keeping things organized. And letting MUSHclient modify the archive's contents would add an unprecendented level of ease of use. I really think this would be a great addition, and I hope it's not too hard to add in any form.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

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.

2,079 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]