Open coman3 opened 8 years ago
KoalaHuman
commented
8 years ago It would be nice to have supported champions and/or addon type included as well, which later on can be used to sort/filter addons in the loader. Maybe tags also would be a cool thing, add fuzy search through all of these and you will create the best experience.
ghost
commented
8 years ago @coman3 , assemblies have no way to even communicate with each other, let alone be a dependency. If a plugin is failing to compile because you don't have the standard redistributables installed then it is your fault for not meeting the minimum requirements of elobuddy.
They have many more important things to be paying attention to than does one plugin and one user have this one dependency they should vs API calls not working, champion abilities casting improperly, etc.
There already is a version manifest available to the assemblies, I do agree with extending that to allow a "written for x version of core".
Also: No good plugin should have an external dependency that isn't already included with the EB framework (Example: SharpDX)
So one thing i have noticed, even with L$ if you install an addon that requires a library, and dont have the library installed, you will just receive a Compiling Error with no notification of missing libraries etc.
So the idea was to implement some kind of "manifest" file that states what libraries are needed, a friendly name for that addon (such as
^^B!g Fancy N@me^^) and the last tested version of LoL; allowing developers to state if there addon is definitely working for the current version of LoL etc. With that information you can then say that a library is missing, and suggest installing it.In the future, if you decide to limit access to specific types such as WebClient, having the manifest will allow the addon to ask the user if they grant that permission.
A reference to what im trying to suggest is Chrome's extension manifest.
If it's a shitty idea, feel free to close the issue im just blabbing it out haha