Plugin Installer / Updater Application

[lunarwater]

I am learning to do .net programming, and have tried a shot at a plugin installer / updater application to assist with installing the latest plugins on PC. Its a work in progress, but I hope its a start towards making it easier for people to use the LUA Plugin system with LOTRO.

If people end up using it, I could use the support of plugin authors by following certain conventions when making and uploading their plugins for distribution. Details can be found on LOTRO Interface website below.

Thank you.

http://www.lotrointerface.com/downlo...ompendium.html (Windows Version)
http://www.lotrointerface.com/downlo...mMacLinux.html (Mac / Linux Version)

[ChromiteSwiftpaw]

I just want to say this tool rocks! It works easily and very fast. This will be great for keeping plugins up to date!

This is a fantastic tool for the people who want to stick their feet in the plugin pool to test the waters.

Question: Is there a place where it archives the versions of the zip files it downloads? I'd like to keep a backup of each and every zip it downloads if I could.

[lunarwater]

Question: Is there a place where it archives the versions of the zip files it downloads? I'd like to keep a backup of each and every zip it downloads if I could.

It caches them in window temporary folder. This is a hidden folder on windows for your account. It differs between Win xp and Win vista/7.

For windows xp it is @

C:\Documents and Settings\<Your User Name>\Local Settings\Temp

[ChromiteSwiftpaw]

It caches them in window temporary folder. This is a hidden folder on windows for your account. It differs between Win xp and Win vista/7.

For windows xp it is @

C:\Documents and Settings\<Your User Name>\Local Settings\Temp

OK, thanks. Any chance you could make an option to change that directory? Just a way to edit it. Many of the archives are useful to read the extra commands and stuff for the plugins plus I just like to have them stored in a safe spot.

[lunarwater]

OK, thanks. Any chance you could make an option to change that directory? Just a way to edit it. Many of the archives are useful to read the extra commands and stuff for the plugins plus I just like to have them stored in a safe spot.

That shouldn't be a problem. Thank you for feedback.

[Zuleyus]

This is a great tool, thank you very much!

I'd like to second ChromiteSwiftpaw's request - customizability always goes a long way in my book.
I would also like the spacer between the table view and the description field on the 'add' tab to be movable - three lines are a bit thin for a description field.
It would also be helpful if the 'add' tab would filter out any entries that are already installed locally.

[lunarwater]

This is a great tool, thank you very much!

I'd like to second ChromiteSwiftpaw's request - customizability always goes a long way in my book.
I would also like the spacer between the table view and the description field on the 'add' tab to be movable - three lines are a bit thin for a description field.
It would also be helpful if the 'add' tab would filter out any entries that are already installed locally.

Thank you for feedback. Those should be easy enough.

My plan is to release several features at once. I've completed the sizing request you made, along with a configurable tab to allow further customization. Since this is an application that has to be installed I want to try to bundle as many features into the next release before posting new version. My hope is I can work at getting some more data elements into the "Add New" tab such as

* Category of plugin
* Last date plugin was modified
* Perhaps some filtering capabilities / search

[ChromiteSwiftpaw]

My hope is I can work at getting some more data elements into the "Add New" tab such as

* Category of plugin
* Last date plugin was modified
* Perhaps some filtering capabilities / search

Very nice. That would would indeed be very useful.

Keep up the good work!

[lunarwater]

Thanks again for all of your feedback. I released a new version with your suggestions and more.

[Maldrake]

Is there a way to remove/delete plugins? Some plugins have versions that require the old version to be deleted before installing the new one and also I sometimes find that I don't use certain plugins and want to get rid of them. It would be handy if your program could handle this. If there isn't yet, could you add such a feature? Another, related, issue would be to have the ability to delete data files associated with the deleted plugin(s).

[lunarwater]

I will definitely put some more time into considering the delete capability because I chose not to do this up front.

The problem with automating the delete is the folder layout that encourages authors to place all their plugins in a single sub folder based on authors name. Because more than one plugin can be intermixed in one folder, and even overwrite or share each-others files, this creates a problem for automating it. I could make it delete the folder if only one plugin is sitting in it, otherwise prompt the user that more than one plugin is in folder and that those will need to be reinstalled.

At any rate, thank you for the feedback.

[D.H1cks]

I will definitely put some more time into considering the delete capability because I chose not to do this up front.

The problem with automating the delete is the folder layout that encourages authors to place all their plugins in a single sub folder based on authors name. Because more than one plugin can be intermixed in one folder, and even overwrite or share each-others files, this creates a problem for automating it. I could make it delete the folder if only one plugin is sitting in it, otherwise prompt the user that more than one plugin is in folder and that those will need to be reinstalled.

At any rate, thank you for the feedback.

I agree that an automated delete needs to be carefully thought out. Most of my plugins share a couple of folders, so it could be possible to disable many plugins just by uninstalling one.

Personally, I am doing my best to avoid ever having someone delete my plugin in order to update them.

However, if you decide you want to do this and need to add extra info the the xml file to exempt folders or files from deletion, let me know. I am happy to help and will try to keep all my plugins updated with correct .plugincompendium files.

[lunarwater]

I agree that an automated delete needs to be carefully thought out. Most of my plugins share a couple of folders, so it could be possible to disable many plugins just by uninstalling one.

Personally, I am doing my best to avoid ever having someone delete my plugin in order to update them.

However, if you decide you want to do this and need to add extra info the the xml file to exempt folders or files from deletion, let me know. I am happy to help and will try to keep all my plugins updated with correct .plugincompendium files.

Overwrite should always work with no problems with exception of one scenario. The author renames or removes one of their .plugin files. In an overwrite scenario, you will be left with that old .plugin that will likely not link up with code. This will result in a "unmanaged" grey plugin showing in LPC. I suppose a way around this is if you are updating a plugin, delete just the .plugin files and let the new archive spit out its new files as necessary.

I do suppose a plain.. remove feature could be added, but in the sense of plugin x (and any others in folder). I'd just want to prompt and get confirm dialogues in the way to save user from doing something they don't intend.

"Deleting Such And Such will affect other plugins. You are about to delete X plugins by SoAndSo. Are you sure?"

[Valamar]

Overwrite should always work with no problems with exception of one scenario. The author renames or removes one of their .plugin files. In an overwrite scenario, you will be left with that old .plugin that will likely not link up with code. This will result in a "unmanaged" grey plugin showing in LPC. I suppose a way around this is if you are updating a plugin, delete just the .plugin files and let the new archive spit out its new files as necessary.

I do suppose a plain.. remove feature could be added, but in the sense of plugin x (and any others in folder). I'd just want to prompt and get confirm dialogues in the way to save user from doing something they don't intend.

"Deleting Such And Such will affect other plugins. You are about to delete X plugins by SoAndSo. Are you sure?"

Thanks for the basic explanation of why authors want you to delete the old plugin first !!!

Which brings up the main problem which still exists across all Plugins, and which an other thread just touched on...

Namely Plugin packaging and "control."

Plugin Authors are a varied bunch from folks "just learning to program so I wrote a Plugin" -- to much more experienced programmers.

I would love to see a "Plugins Standards" sticky -- a "best practices" if you will:
How to package your plugin so you don't need Turbine's xxx.
How to package your plugin so you can unzip it "correctly" directly into the Plugins directory/folder.
How to label components so that you can...
How to "code" so that installers/updaters can track your versions and "automatically" update them.

One last comment. One of our more prominent authors, I forget who, which is probably why I can't find it --
wrote a couple of postings on programming, which I thought had been stickied, but I can't find it either on this forum or on Lotrointerface.com

[Garan]

One last comment. One of our more prominent authors, I forget who, which is probably why I can't find it --
wrote a couple of postings on programming, which I thought had been stickied, but I can't find it either on this forum or on Lotrointerface.com

Prominent... hmmm. I like that word I'm not sure, especially since I'm usually called other words, but I suspect you may be referring to my http://forums.lotro.com/showthread.p...gins-for-Noobs thread. I considered replicating it over at LoTROInterface.com but just haven't had the time. The next installment will probably have something to do with how to package a plugin so that it will work nicely with LotroCompendium and MMOUI Minion (the Minion client uses Lunarwater's .plugincompendium files so it's the same requirement for both). I haven't posted anything there in a while since all of my free time has been spent tracking down french and german crafting messages (an incredibly long and boring task) but I should have time to test out both updaters Soon™ (yeah, time for Sapience to start laughing maniacly).

As to "sticky" status, I thought I read a while back that Turbine changed their policy on sticky threads and will now only sticky threads that are actually created by a Turbine employee which is why new guides and such never get stickied. I believe it had to do with an excessive number of flame wars being caused by sticky threads but I may have been misinformed.

[lunarwater]

Is there a way to remove/delete plugins? Some plugins have versions that require the old version to be deleted before installing the new one and also I sometimes find that I don't use certain plugins and want to get rid of them. It would be handy if your program could handle this. If there isn't yet, could you add such a feature? Another, related, issue would be to have the ability to delete data files associated with the deleted plugin(s).

I added the remove feature you requested, but with the caveat that was described above.

Current development is on the mac & linux version.

[Crell_1]

It'd be nice if turbine worked out something with lotro-interface to host something like this internal to the client. Its harder to walk someone through installing a plugin than getting the plugins actual options set up once its installed.

[DaveDickey]

It'd be nice if turbine worked out something with lotro-interface to host something like this internal to the client. Its harder to walk someone through installing a plugin than getting the plugins actual options set up once its installed.

<<Note to lunarwater - Awesome utility!>>

Actually it's very easy to walk someone through plugin installs,
"Download and install lunarwater's Plugin Compendium."
After that they just point and click.

I think one of the best, possibly unforeseen, lagniappe features of lunarwater's Plugin Compendium is that it effortly installs plugins.

I just wish the plugin manager/launcher Bootstrap and the tasks tracker Daily Tasks were updated for compatibility with PC.

How about that as a feature request?
"Ability for users (not authors) to set up Plugin Compendium to track and update non-PC compliant plugins like Bootstrap."
Maybe it'd be a local copy of the .compendium file in a "non-compliant plugin update settings" folder the user could point to for untracked plugins?

Finally, it'd be nice if, when PC saw it needed updating, it did it automatically like it does for plugins instead of sending the user to lotrointerface to download and install the new version (ie when we went from 1.0.2 to 1.0.3).

Finally-Finally, the new plugin remove feature worked fine.
When the warning message popped up, I went to that directory, recalled there was a file in a different plugin by the author that I wanted to keep (a modified grid image for MrJackdaw's Align plugin) which I copied to a separate file, then I proceeded with PC's remove command.
Afterwards, I used PC to reinstall Align and copied the saved image file back in.
A feature request for plugin delete:
On plugin delete, zip the to-be-deleted directory(s), and move them an archive folder.

Finally-Finally-Finally, with the plugin delete function, does it also delete the related plugindata files?
If not, my server and character data folders will get pretty trashed up with the way I try out and remove various plugins.
It's hard to figure out to which plugin a cryptically named plugindata file belongs to and is safe to delete.

[ChromiteSwiftpaw]

How about that as a feature request?
"Ability for users (not authors) to set up Plugin Compendium to track and update non-PC compliant plugins like Bootstrap."
Maybe it'd be a local copy of the .compendium file in a "non-compliant plugin update settings" folder the user could point to for untracked plugins?

Oh now that'd be a great idea - allow users to host their own custom plugin feed on their own site and not LOTROInterface. That way kins or just anyone could host only the plugins that are tested and considered high value/fully tested.

[Garan]

Oh now that'd be a great idea - allow users to host their own custom plugin feed on their own site and not LOTROInterface. That way kins or just anyone could host only the plugins that are tested and considered high value/fully tested.

It would be up to your kin or other group to publish a website that supports the same API that LoTROInterface exposes but Plugin Compendium already supports custom feeds. You can assign a custom Plugin Feed URL on the "Configuration" tab of Plugin Compendium.

[DaveDickey]

It would be up to your kin or other group to publish a website that supports the same API that LoTROInterface exposes but Plugin Compendium already supports custom feeds. You can assign a custom Plugin Feed URL on the "Configuration" tab of Plugin Compendium.

Playing around with it, I see a list of kinship recommended plugins is easy to do as Garan says.
Just have an account/login name at lotrointerface and add all the recommended plugins to your favorites.
Then in the LPC configuration tab, point LPC to http://api.lotrointerface.com/fav/YOURUSERNAME.xml

It still doesn't work for plugins that don't comply with LPC's requirements, like Bootstrap and Daily Tasks.
But that looks like it is an issue with those plugins and not a make-or-break thing.
I can live with it for now as it's only 2 of the 17 installed plugins.

[lunarwater]

I just wish the plugin manager/launcher Bootstrap and the tasks tracker Daily Tasks were updated for compatibility with PC.

How about that as a feature request?
"Ability for users (not authors) to set up Plugin Compendium to track and update non-PC compliant plugins like Bootstrap."
Maybe it'd be a local copy of the .compendium file in a "non-compliant plugin update settings" folder the user could point to for untracked plugins?

First of all.. Thank you for all the great feedback. I agree with all of your ideas.

Let me clear up something regarding Lotro PLugin Compendium (LPC) and supported plugins. If you see a plugin that does not exist in LPC, and it isn't one in the list posted at http://www.lotrointerface.com/downlo...ompendium.html, then please bring it up. It may be that it is supported and that I simply missed the plugin during my review process. Upon initial release, I had to manually go through all of the plugins and try to come up with a list of all of the plugins that would install hands down, with-out any problems. From all I can see Bootstrap should have been added to the feed, and I have since added it.

The ability to have custom managed plugins is partially coded in the existing implementation, it is just missing pieces of the UI to make it fully functional. If you notice in the install folder of LPC, there is a file called "StaticPlugins.xml". Right now it points to one of the only non-lotrointerface plugins, namely turbines utilities. The static list of plugins, along with the lotrointerface.com feed of plugins get combined together to provide the list of "known plugins". If you are careful and edit the xml yourself, you add plugin entries that point to plugins that might be hosted on other websites (i.e. your guild's). Keep in mind though, that until it is a fully supported feature, I cannot guarantee that this initial way will stay in its current form.

However, I say all that to now bring up this point. I currently pay nothing for website hosting, but piggy back on lotrointerface's excellent website. Because of this, LPC has to work within the confines of the feed they allow me to use. In an ideal world, I would like to allow authors to maintain and edit the "how to install" type information, and have that get fed directly to LPC. If there is some hosting available that for such a endeavour, and something that has long term availability, I'd be all for working with someone on this. The primary two reason plugins are supported is #1 they contain dependencies on other plugins, or #2 they have an extra folder in the zip file's path. I could code around these two things, if I could embed information regarding those two things in the data feed that LPC functions off of. Its much easier to update a feed, than for me to compile workarounds into the app.

Finally, it'd be nice if, when PC saw it needed updating, it did it automatically like it does for plugins instead of sending the user to lotrointerface to download and install the new version (ie when we went from 1.0.2 to 1.0.3).

To support this, I'd have to redesign how LPC was originally written. It is something I would like to do, but it may be a ways off. Now that I have support for Mac & Linux versions of LPC, the project has gotten kind of big. I could definitely use some help.

Finally-Finally, the new plugin remove feature worked fine.
When the warning message popped up, I went to that directory, recalled there was a file in a different plugin by the author that I wanted to keep (a modified grid image for MrJackdaw's Align plugin) which I copied to a separate file, then I proceeded with PC's remove command.
Afterwards, I used PC to reinstall Align and copied the saved image file back in.
A feature request for plugin delete:
On plugin delete, zip the to-be-deleted directory(s), and move them an archive folder.

Great idea. I'll see about adding it.

Finally-Finally-Finally, with the plugin delete function, does it also delete the related plugindata files?
If not, my server and character data folders will get pretty trashed up with the way I try out and remove various plugins.
It's hard to figure out to which plugin a cryptically named plugindata file belongs to and is safe to delete.

This is something that can be done. I would need to get the authors to help in supporting this feature as the name of the plugindata files and location there-of is all over the place. Perhaps they can add additional entries to the .plugincompendium configuration files.

[Valamar]

Finally-Finally-Finally, with the plugin delete function, does it also delete the related plugindata files?
If not, my server and character data folders will get pretty trashed up with the way I try out and remove various plugins.
It's hard to figure out to which plugin a cryptically named plugindata file belongs to and is safe to delete.

This is something that can be done. I would need to get the authors to help in supporting this feature as the name of the plugindata files and location there-of is all over the place. Perhaps they can add additional entries to the .plugincompendium configuration files.

This is a much larger problem that it seems at first. I initially thought "no big deal" as all the plugins I use "uniquely" name their "PluginData" [something like <plugin-name>.plugindata]-- oops not true. It was true in the past when (apparently) most plugins did not save information.

This thread over at LOTROInterface the other day made me look at things much closer...
http://www.lotrointerface.com/forums...ead.php?t=1756

In fact, not only do there appear to be VIOLATORS of "rational naming of data files," but it appears the LPC (java version) is also guilty -- at least I'm guessing the file which I only just noticed in PluginData called "PluginOptins.xml" comes from LPC -- ARGH... worse than that -- It's Turbine's! I believe that file belongs to the the Turbine Plugin Manager!

But seriously. It does look like, at least with all the Plugins I use, that naming convention, "<plugin-name>.plugindata" is being used by all. (I don't use Palantir, which is apparently a violator.)

Again under "AllCharacters" is "ChacterList.plugindata" -- which, and here I'm guessing as I don't see any obvious clues in the file -- this file belongs to the Turbine Plugin Manager.

[Garan]

Again under "AllCharacters" is "ChacterList.plugindata" -- which, and here I'm guessing as I don't see any obvious clues in the file -- this file belongs to the Turbine Plugin Manager.

I think CharacterList.plugindata is an AltInventory file (it was originally intended to work with multiple plugins but is still poorly named). It is one of the files that got named early on in the development of the plugin - most of my other .plugindata files have some form of prefix indicating to which plugin they belong.

[lunarwater]

In fact, not only do there appear to be VIOLATORS of "rational naming of data files," but it appears the LPC (java version) is also guilty -- at least I'm guessing the file which I only just noticed in PluginData called "PluginOptins.xml" comes from LPC

Plugin Compendium does not write out to PluginOptions.xml. All configuration options are stored in a file located at [User Home]/.PluginCompendium/lpc-usersettings.properties for java version. Information regarding installed plugins are kept intentionally in a file with a ".plugincompendium" file extension. Let hope no one goes to the length of naming something that collides with that monstrosity of a extension

The plugindata naming convention could become a problem as you stated, but I've found most authors very reasonable once notified of potential problems, to correct any bugs found in their plugins.