The problem is that the addon publishers need a way to publish to the repository. In Ubuntu (as it happens the distro I'm currently writing this message) this is done through being a centralized way of managing installations, updates, and dependencies. It contains a main repository which feature maybe 90% of your package-download needs, but also can be extended easily through PPAs and other Debian download repositories (mainly used by Node.js applications, many of which use electron). For the user it is the place to download new stuff (either through command line or Synaptic, to the GNOME Software Center for the less tech-savvy).
Let's assume (and probably not be too far from the truth) that OHM is the centralized place for downloading add-ons. The process is usually: Search > Download > Exctract and copy to Orbiter folder > For each dependency, redo those steps.
Even though it has been the standard method of modding forever here, it has several main problems: the end user might not know about all the dependencies, they might not know how and where to install the add-on, and the packages themselves are not really "standardized".
By that last statement, I mean that the guidelines to add-on publishing are just that: Guidelines that hope the add-on publisher will follow in order to simplify the process. But in reality, some people put their add-on into a folder into the archive, which defeats the purpose of any attempt at a naive automatic installation attempt (cf. my own attempt back in the day I was still using VB.NET and basically had no idea what I was doing :lol: ). Some other even completely go through the "zip standard" and offer exe installation (eg. Dan's addons).
What standard there is by this modding community is barely a general consensus (emphasis on the tautology) on what to do and what not to do (with some diverging methodologies like the "Doc" vs the "Add-on Docs" folder) because
everybody understands the role of every part of a published add-on.
Everybody understands how an add-on is made because this community is small enough that any newbie is quickly brought up to speed. In fact I'd go all the way to saying that understanding how to install an add-on (and therefore understanding how an add-on is made) is key to become part of the Orbiter community.
This may be reminescent of the "standard" .tar.xz packages that people would make available to the public for users to "install" (i.e. copy to a folder hopefully in the PATH variable) and then launch it. Then package managers like apt came in an imposed a standard on how (and therefore where) to install the files, and automated the creation of the nifty shortcuts that you can now search for, place on your desktop, instead of having to launch it directly (
/usr/bin/... uhh where did I put it again?). Note that Windows doesn't have a complete, "apt-like" standard yet, and that Chocolatey, the Windows Store and others are attempt at creating a standardized installation process. Publishers know that programs go to Program Files (except all the Electron installers that instead put the apps in %APPDATA% and that makes me mad).
So, coming back to Orbiter, how does that apply to modding and installing the numerous add-ons available in OHM? Well, I'm saying that through a "Orbiter Package Manager" the current "guideline" could be implemented and installations simplified to think less about installing and more about playing. This would also resolve the dependency problem as the OPM would automatically go through the same steps we manually go through now, and the tedious task of traversing the dependency tree would be done much faster, and all in one command.
The reasons why previous attempt have been unsuccessful is also because they based themselves on the current "modding status quo", or because they tried something too "out of place". I think a good implementation of such a "OPM" would be right between the two, and receive positive feedback from both users and creators.
But also, another (and maybe most important) reason they haven't took off is previous attempt were isolated and not publicly prototyped; that is people put the standard in place, and waited for it to magically become accepted. This is why I propose the following implementations (two, because the first would require changing OHM itself):
The "OHM rewrite" proposal:
- OHM would add a "dependency list" that would basically be an array of entries (separate versions would constitute separate entries, to keep the changes from being too complex). The dependency tree would be compiled by going through each dependency and finding their dependencies, and etc.
- A metadata file would be compiled for easy access from the package manager, an "enriched" index from where to base searches from both the user and the package manager itself as it looks through dependencies. This is why I mentioned JSON as it allows to store data in a nested way, but also in a non-mandatory way.
The JSON index would add metadata like Title, Author, Short and Long description, Dependencies and Recommendations; but also optional links to the repository (if open-source), the comment thread associated to it, and even others.
To keep backwards compatibility, any entry in OHM not having the "dependency list" will be downloaded as a standalone with a way of warning the user about possible unavailable dependencies.
The "Independant way":
- The JSON would be hosted somewhere where "maintainers" could add entries to the index. Dependencies would be a list of IDs from that same index, and the tree would be created in a similar way as before.
- The JSON index would still include many of the metadata, on which is added a "download link" that poins to the direct location of the package.
The package manager would be build the same way regardless of the aforementioned implementations and would provide 3 layers of interactions (similar to how Ubuntu is organized now):
- A command-line package manager that can be operated manually or be used in scripts
- A graphical package browser which allows a GUI to the package manager
- A graphical "Addon Center" which would allow the end user to search for add-ons and simply click "install". The software would then take care, in the background, of operating the package manager, hiding it behind a progress bar or some sort of visual feedback.
The third layer might look the same as the second, but is different in the way it is used (you would use the second layer when you know which package to install, while you would use the third layer to simply search and install "that shuttle addon that has all the buttons modeled" for example).
Having all of this set up allows the package manager to do more complex operations than just "install those addons". It could serve as a way to merge configuration files in a smart way (as many add-ons conflict in that term). However those more complex functions need to be discussed to provide a simple framework to build on and need a package manager that works on the "simple" operations before building on those foundations.
Anyway that post got wayy too long. Sorry.
TL;DR Here's a proposal of changing a few things in hosting on OHM and for the add-on makers to make everyone's lives better.
you'll have to install IPFS from https://ipfs.io/ and then run in a cmd/cli:
You can also try Foxyspider.
