Suggestion for configuration of OXP's

[mvdw]

Hi All:

I used to play Elite way back in the day (on my Amstrad 8086 computer), then played privateer maybe 10-15 years ago (on my next computer, a 486). Many years and computers have passed under the bridge since then, so it was with some enthusiasm that I found, downloaded and played oolite. I LOVE it!!!! However, adding OXP's is a pain, particularly given there are so many - which to choose?

But, I have a (potential) solution. Those of you who use debian-based Linux variants will be familiar with the .deb package format; I propose something similar for the oxp packages. What this means is that every package that will be registered under this system would need a package file, that would contain information (in a particular format), with the following information (at least):

1. Where the OXP download lives;
2. Category (ships, missions, eye-candy) ???);
3. Dependencies (what other packages it requires, including versions);
3a. Conflicts (What other packages need to be de-installed for it to work)
4. Screenshots (so you can advertise your good work), and provide incentive for players to install;
5. Description;
6. License;
7. Version
8. Oolite version required (>=1.73, for example)
9. Recommended-for (who should install this - experience level, what you want out of the game, etc)

...And possibly other information. Of course, this packaging need not necessarily be done by the OXP creator, it can be done by someone else. It also means that there will need to be a central repository of all this information (BOOO!!! work for someone), and a utility program to organise it all (BOOO!!! work for someone). Ideally, there should also be a utility for package maintainers to create these packages easily (not OXP creators necessarily, and BOOO!!! work for someone)...

This facility would greatly enhance the gameplay, particularly for new-ish users. It would also allow meta-packages to be created of particular OXP combinations so you can share your own experience in the Ooniverse. For example, you could create a meta-package containing several missions, and a set of ships. This would just depend on those other packages, meaning you don't have to create an OXP specifically for it, but installing the meta-package installs the required other packages. The bonus with this is that the meta-packages will not have to keep updated copies of the dependencies - they are updated whenever the dependencies update. An example where this would be useful is in the RealisticShipyards OXP - it could conceivably be a meta package, that would just pull in all the ship dependencies. There would also be no need to manually install the extra missions it requires, as these would also be pulled in.

The configuration utility would have to create a couple of extra directories in the Oolite application folder, but that's no big deal; maybe hold a cache of downloaded files, as well as a list of the packages to get, and a place to get the packages. I'd suggest at first that these could all be text files - no need for digital signing at least initially IMO. Possibly also there could be a set of configurations cached, so that different game states can be saved and recovered later (different package sets can be saved for retrieval later).

I am sure you've heard it all before, and indeed something like this might already exist. If it does, it's not very well advertised to the casual first-time user, and if it doesn't, well it should in my opinion.

There is light on the horizon, though - if it doesn't exist I will volunteer to do all the work around the package format, writing the two utilities (cross-platform, of course!!), and hosting the repository of metadata on my own commercially-hosted web site (I have a 25GB site that I do not presently use much of, so will provide 15GB for free). There may even be room there for a mirror of most if not all of the currently-available OXP's.

BUT, and it's a big BUT, I would need to know that this would be (a) welcome, and (b) used. I don't really want to waste my own time and that of the package maintainers who will be creating the OXP containers.

Any other ideas, suggestions, flames, cold water to pour on the idea, others?? I know some or most of this information is already in the wiki, but it doesn't necessarily make it easy to automatically install OXP's, especially if there are conflicts involved. It would also make it relatively easy for a package creator to simply pull the required information off the wiki and put it in a package file (using the proposed package maintainer utility).

As I said, I am willing to put in the work, and even host the repository, but I'd like for this to be actually wanted before I could commit to that.

So, I'd initially like some feedback, firstly whether this is a good idea, secondly whether it's worth me putting a fair bit of time into it, and thirdly of course other suggestions for improvements.

Cheers,
mvdw (new user, but enthusiastic potential contributor).

[Cody]

Hi mvdw and welcome to ‘the friendliest forum this side of Riedquat’.

All that Wiki/oxp stuff is over my head… I’m just a veteran combateer in a Cobra III, but I’m sure you’ll get some feedback soon.
This sort of stuff seems to be fairly hot at the moment. Great first post.

[Smivs]

Hi, and welcome.
That's an impressive idea, and as you've guessed some of it is already either in place or being worked on.
Organising the OXPs is a hot subject at the moment...see this thread for the current thinking.
Also regarding hosting the OXPs, a site called OXP Central has been set up to bring them all together under one roof, but seems to be on hold at the moment. The prime mover seems to have been swallowed by a Black Hole
Regarding dependencies, I don't think there are many around the OXPs and normally these are taken care of by the Author either including the necessaries in their own OXP or making it clear in the 'readme.txt' that another OXP is required to make it all work. I accept that this is not perfect.
Having said all that, I like your Holistic approach and can see some real benefit from developing a system like the one you have outlined. It'll be interesting to see what others think.

[Kaks]

Hello mvdw, and thanks for the offer!

Diziet Sma, the guy (girl's name, long story apparently) who kind of semi-started OXP Central ( we just have the name at the moment, nothing else has been forthcoming ) has indeed gone MIA, but I'm pretty sure he won't begrudge someone else doing all the hard work! He's got a LAMP server, AFAIK. If you've got a similar setup, we could at worst end up with a main oxp site, and a mirror. Not a bad concept at all, as far as I'm concerned..

In other words, it all sounds good, and if you're ready & able to do so, by all means! Do ask any questions if you need our opinions and/or clarifications on various bits and bobs.
I'm sure we'll be able to provide some input there...

[Cody]

Diziet Sma, the guy who kind of semi-started OXP Central has indeed gone MIA,

Yeah, I'm just a little concerned about Diz.
He's based in Brisbane too (or was)... but we all know what RL can throw at you sometimes, usually without any warning.

[Thargoid]

It got a bit further than noted above, see here, although unfortunately when Dizzy fell off the world it was down for maintenance, and still is.

[Commander McLane]

see [url=http://oxpcentral.net[/url]here[/url]

Link doesn't work. Superfluous [/url].

[Thargoid]

see here

Link doesn't work. Superfluous [/url].

Does now - thanks.

[Smivs]

It's been dead for a few days now. I've been getting a 'taking forever to load' blank screen for the last few days. Before there was a 'Site under maintenance' screen, but even that's gone.
Not encouraging.

[mvdw]

OK, some really good feedback here. It seems there has been a couple of attempts to do similar to what I am suggesting. I guess the differentiator of what I am suggesting to what has been done before is that it will provide an automated way of installing/deinstalling OXP's and, perhaps more importantly, sets of OXP's.

I guess what I have been looking for was something more than the current wiki-based methods, where the OXP's are available as a download. Currently you have to read the wiki page, go to another page to download the OXP, open a file explorer, unzip, move some files around, restart Oolite and see how it all went. It's not very straightforward to install a whole stack of OXP's at once, and if you do so, it's not very clear which of the installed OXP's is the one causing you to be fatally attacked as soon as you leave the space-station

My method would be:

- Open the OxpTool utility;
- browse the available OXP's;
- select/deselect OXP's to install/deinstall;
- Press 'Go'
- OXP's magically appear/are deinstalled from the AddOns directory (including any other related ones - eg BigShips for ones that require that)

This would also allow you to see which of your installed OXP's have updates available, and install a newer version if wanted. Also, it would remove the need for those OXP's that require another OXP to keep a possibly-outdated copy of the requirement in their own distribution.

Insofar as compatibility with the wiki-based method, the two ways are not mutually exclusive. I'd suggest you still be able to download and install OXP's the manual way, but those would be outside the scope of the automated tool. OXP's would still be available from the main download site; in fact the extra packaging for the OxpTool utility would not need to be done by the original OXP author (license permitting).

I would of course make an OxpTool packaging utility available, so OXP's can be packaged with a wizard-style utility, then (optionally) uploaded to the central server.

If you've ever used the .deb style of application packaging under linux, I am proposing a very similar method here, with a utility that would be similar to Synaptic.

Cheers,
mvdw.

[mvdw]

I've done some further work on the specs:

- In the OoLite application directory, there will be an extra folder called "OxpTool". This will have the following structure:

OxpTool/
|------cache/
|------offline/
|------packages/
|------screenshots/
|------OxpTool.exe
|------OxpToolPack.exe
|------OxpTool.config

The "cache" folder will have a cache of all the downloaded Oxpp files

The "offline" folder will have a cache of all the Oxpp files that have been installed from elsewhere other than the central server. This allows you to, for instance, create your own packages to install using the tool, rather than doing a manual copy into the AddOns directory (which you can still of course do).

The "packages" folder has a collection of package description files. These files are just xml files that describe the package (things like licence, description, category/ies, author, packager, etc). This is so that you don't have to d/l the whole OXP just to see the description . Note that this folder will contain ALL the OXP files that are available on all the servers listed, including all the versions. This could in principle get quite large, but the software could delete old/deprecated versions that are not on any server any more.

The "screenshots" folder will have a set of screenshot files downloaded. These are downloaded on-demand, so the user can choose or not choose to get them on a per-package basis. This will be chosen when the user is browsing the OXP's availabale - there will be a "Get screenshot" button that when pressed will download the screenshots for display.

The two executables are the two programs for doing the installation and creation of packages, respectively. These may or may not be combined - I haven't decided on that yet.

The config file is just an xml file that contains things like server list, available package list, installed packages, etc.

Note that a package consists of 2 or 3 files:

- foo.maj.min.sub.oxpd -> The description file described above;
- foo.maj.min.sub.oxpp -> the actual package file (foo.oxp folder, zipped);
- foo.maj.min.sub.oxps -> A zip-format collection of screen shots (optional).

So the software will download from the list of mirrors a list of descriptions when asked, then populate the list of packages from its list in the packages folder. The user will be able to search the list, or browse the list, based on category or all; mark them to be installed or deinstalled, then press the 'go' button. The software will go to the server and fetch the actual packages asked for, and install them. It will keep the downloaded files in its own internal cache, which can of course be cleaned out whenever disk space is required.

Quite simple really, in principle...

[Lestradae]

Quite simple really, in principle...

You are, I take it, essentially talking about a mod manager for Oolite?

That sounds intriguing.

Can you do it? Because I guess the credo here is "If you want it, do it" ... I for one would definitely like something like that.