Hey guys,

I just wanted to say that some of the callouts / various API plugins should probably change the way they announce updates and the like to users. I was debugging FC and I hadn't updated any other plugins as I wasn't using them (I forgot to take them out of the LSPDFR folder beforehand). When the game started, I got about 10-15 notifications (not from 10-15 unique plugins) on the left all at once. They were popping up too quickly to read and one had an auto opening video (which you could cancel, however it was hidden by the other update notifications).

Personally, I think this will likely just confuse and overwhelm the user. I think some of the plugins have some common libraries (couldn't tell what was out of date :^] ) so if you have multiple plugin groups that check for updates please make a system where they will show up in one popup, not 3 popups per plugin.

That said, I was thinking about something.

A lot of plugins are starting to have some common features. Player agency detection, update detection, etc. What if we got some developers to work together and make a common plugin library that did all of that?

Instead of each callout popping up a notification about updates, it could register a method with the library that checks for updates and then tells the user something along the lines of "<number> of your plugin(s) need updating. Press <key> to display."

 

It could maybe even include a configuration tool for any plugin that wanted it. A plugin just specifies maybe an XML file that lays out what the INI should have (and the value type), puts it in maybe LSPDFR/Configs and then when the user opens the configuration tool it loads all of the config files and gives the user a nice simple WPF GUI to edit their INI files with.

Additionally, we could make it detect proper installation of each plugin with a plugin developer defined file (wouldn't be too hard - we could even automatically generate it).

Thoughts?

Edited February 12, 201610 yr by goigle

I've had a conversation with MulleDK19, the developer of RPH, about an unrelated subject, but along the lines of cross plugin communication. 

He told me that it wasn't possible, because each plugin runs in its own little world, so to speak. Because they run in separate AppDomains, each plugin has no idea what other plugins are running. 

I agree though, update prompts should just be one simple notification, and that's it. 

 

5 hours ago, Stealth22 said:

I've had a conversation with MulleDK19, the developer of RPH, about an unrelated subject, but along the lines of cross plugin communication. 

He told me that it wasn't possible, because each plugin runs in its own little world, so to speak. Because they run in separate AppDomains, each plugin has no idea what other plugins are running. 

I agree though, update prompts should just be one simple notification, and that's it. 

Surely it's still possible to produce a common library that plugins use as a reference though, no?

You can access other AppDomains within your plugin, and LMS has provided an example of this before (for accessing certain LSPDFR features without being an LSPDFR plugin). Although it's a bit ugly.

I'd certainly be happy to add something like this in LSPDFR, but it would probably need to be limited to API plugins by-design.

5 hours ago, Cyan said:

You can access other AppDomains within your plugin, and LMS has provided an example of this before (for accessing certain LSPDFR features without being an LSPDFR plugin). Although it's a bit ugly.

I'd certainly be happy to add something like this in LSPDFR, but it would probably need to be limited to API plugins by-design.

MulleDK19 told me that if LSPDFR managed this sort of thing, it would work fine...for LSPDFR plugins anyway. 

A RPH plugin that reads the version of each of the .dlls inside Plugins folder and them compares it with a version in a server you have should work, right? The version in a server can be the .json you can download with the lcpdfr.com API or one you get from a repository you made on github, the author could especify the URL in a XML file, or maybe even with an assembly attribute for a cleaner Plugins directory. After the checks prompt the user with a GUI with the outdated plugins, it won't stop them from running but at least the user will know which ones are outdated. This is how it's done in Kerbal Space Program.
It could also be extended to detect the .dlls in the Plugins\LSPDFR

Shared plugin resources of some type must be possible, see @albo's albocommon.dll for example. 

21 hours ago, Stealth22 said:

I've had a conversation with MulleDK19, the developer of RPH, about an unrelated subject, but along the lines of cross plugin communication. 

He told me that it wasn't possible, because each plugin runs in its own little world, so to speak. Because they run in separate AppDomains, each plugin has no idea what other plugins are running. 

I agree though, update prompts should just be one simple notification, and that's it. 

Even then, for now we can create a common library for doing simple things many plugins already recreate.

If I started work on the configuration tool / library I mentioned, would anyone be interested?

10 hours ago, Stealth22 said:

MulleDK19 told me that if LSPDFR managed this sort of thing, it would work fine...for LSPDFR plugins anyway. 

I was thinking of this only applying to LSPDFR plugins so that shouldn't be a problem

9 hours ago, alexguirre said:

A RPH plugin that reads the version of each of the .dlls inside Plugins folder and them compares it with a version in a server you have should work, right? The version in a server can be the .json you can download with the lcpdfr.com API or one you get from a repository you made on github, the author could especify the URL in a XML file, or maybe even with an assembly attribute for a cleaner Plugins directory. After the checks prompt the user with a GUI with the outdated plugins, it won't stop them from running but at least the user will know which ones are outdated. This is how it's done in Kerbal Space Program.
It could also be extended to detect the .dlls in the Plugins\LSPDFR

I wonder if it'd even work as just an API plugin that worked as a library as well?

The plugin part would handle checking for updates via the config files and notifying users, and then the library part is self explanatory.

It could also be split up, it doesn't really matter.

18 minutes ago, goigle said:

I wonder if it'd even work as just an API plugin that worked as a library as well?

The plugin part would handle checking for updates via the config files and notifying users, and then the library part is self explanatory.

It could also be split up, it doesn't really matter.

It can be the same file, the plugins authors will only need to reference this file to add the attribute and once this updates checker is loaded through the RPH console it will get all .dlls(from the Plugins folder and the subfolders so it detects the LSPDFR callouts plugins too), read the attribute, compare the version got from the url and the one the .dll has, if any update is avalaible prompt the user and finally unload the updates checker. 
I don't think it will be really difficult to code.

If you want to start working on this I will help for sure, if you host it on github, it will be even better because anyone could improve it.

2 hours ago, alexguirre said:

It can be the same file, the plugins authors will only need to reference this file to add the attribute and once this updates checker is loaded through the RPH console it will get all .dlls(from the Plugins folder and the subfolders so it detects the LSPDFR callouts plugins too), read the attribute, compare the version got from the url and the one the .dll has, if any update is avalaible prompt the user and finally unload the updates checker. 
I don't think it will be really difficult to code.

If you want to start working on this I will help for sure, if you host it on github, it will be even better because anyone could improve it.

yup I planned on having it on GitHub with some OS license, I'll work on it sometime tomorrow and post something here

4 hours ago, goigle said:

yup I planned on having it on GitHub with some OS license, I'll work on it sometime tomorrow and post something here

I suggest a strong copyleft license, such as GNU GPL V3

Quote

 

You may copy, distribute and modify the software as long as you track changes/dates in source files. Any modifications to or software including (via compiler) GPL-licensed code must also be made available under the GPL along with build & install instructions.

 

Basically means that any derivatives must also be open source but it removes liability for the authors..

Edited February 13, 201610 yr by AlconH

3 hours ago, AlconH said:

I suggest a strong copyleft license, such as GNU GPL V3

Basically means that any derivatives must also be open source but it removes liability for the authors..

But then all derivatives must be GPL. I'm not sure where referencing GPL code in .NET, then using an attribute from it stands legally, as I'm not sure whether it's considered a derivative work at that point, as you'd only be using an attribute. Generally, using GPL libraries in your code is considered a derivative work, and you must provide the source code to your own code.

OP, You're most likely talking about my plugins.

I've overhauled the way the updates notifications are displayed in the latest updates of my mods. Update my mods and you'll be fine. Alternatively, you can opt out of update notifications from any of my INI files.

As for a video opening, this is because you've made a mistake in your installation of my mods.

I personally think the update notifying options from LSPDFR are sufficient - being able to get a string of the current version number is really all we need as long as we provide an option to disable notifications.

Edited February 13, 201610 yr by Albo1125

Perhaps we could just put an updates.ini file in the LSPDFR plugins folder with one entry, and all plugin authors could check that file to see if updates are enabled. That would let users only have to make the choice once to allow or not allow auto-update-checks, instead of having to modify it in every single mod's INI file. 

1 hour ago, PNWParksFan said:

Perhaps we could just put an updates.ini file in the LSPDFR plugins folder with one entry, and all plugin authors could check that file to see if updates are enabled. That would let users only have to make the choice once to allow or not allow auto-update-checks, instead of having to modify it in every single mod's INI file. 

Now there's a good idea 

I don't think we need to develop a separate library for this. People are unable to install things properly as it is. This will only confuse people or cause errors if our plugins can't find the required files. 

If we're going to do anything at all, let @Cyanadd it to LSPDFR. But personally, I think even that is overkill. Just a simple notification, with the ability to disable it, is good enough. 

On Saturday, February 13, 2016 at 10:24 AM, Cyan said:

But then all derivatives must be GPL. I'm not sure where referencing GPL code in .NET, then using an attribute from it stands legally, as I'm not sure whether it's considered a derivative work at that point, as you'd only be using an attribute. Generally, using GPL libraries in your code is considered a derivative work, and you must provide the source code to your own code.

I was thinking MIT, I really don't care if someone copies code

 

On Saturday, February 13, 2016 at 0:17 PM, Albo1125 said:

As for a video opening, this is because you've made a mistake in your installation of my mods.

It wasn't just your plugins, and they were configured fine before the game updated. The misconfiguration isn't really the point though.

Thanks for taking the time to help solve the issue though! It was not just you though (I only have one of your plugins installed).

 

On Saturday, February 13, 2016 at 2:55 PM, PNWParksFan said:

Perhaps we could just put an updates.ini file in the LSPDFR plugins folder with one entry, and all plugin authors could check that file to see if updates are enabled. That would let users only have to make the choice once to allow or not allow auto-update-checks, instead of having to modify it in every single mod's INI file. 

yeah that would work too

 

doesn't really matter in the short term anyway, I got stuck at work because our alarms wouldn't activate and had to spend the night :^)

Edited February 15, 201610 yr by goigle

On 2/13/2016 at 3:24 PM, Cyan said:

But then all derivatives must be GPL. I'm not sure where referencing GPL code in .NET, then using an attribute from it stands legally, as I'm not sure whether it's considered a derivative work at that point, as you'd only be using an attribute. Generally, using GPL libraries in your code is considered a derivative work, and you must provide the source code to your own code.

Damn, forgot about that. Maybe LGPL? It's been a while since I've done much licensing so I'll admit I'm a little rusty.

I decided to go a different way with this:

 

rather than an actual plugin it'll be a standalone tool ran outside of the game that can be bundled with plugins, and as of right now I'm looking at the MIT license.