Oolite Bulletins

Just pondering this business of different Jamesons played with different oxp's (one with Strangers World, one with Additional Planets, etc).

Might it be possible to list the loaded oxp's in each save file - and then run some sort of check on the game, loading the missing oxp's in the same way that the meta-oxp's cause the Expansions Manager to do? (eg - Addons for Beginners by Norby)

And could this be done by another .oxp - or would it require Vanilla game code changes?

One realises that this would only work for oxp's on the Expansions Manager. And maybe some of those which are not - but which include manifest.plists!

commander_STyx2909 wrote: ↑Sun Dec 13, 2020 2:11 pm

For a new user, it is a bit disturbing to navigate through all the OXPs. It is great there so many mods, don't get me wrong, but I think a bit of change would be welcome.
...
Also, instead of deleting OXPs when removing them, couldn't we move them into another folder?

1) Just to note Hiran's activity with his currently-named Oolite Start programme, overriding the Expansions Manager and meeting some of the suggestions at the top of this thread.

(Maybe it should be termed the Expansions Manager Manager? )


2) In the Manage Expansion Packs/Manage Manifests log-in:

Does filling in the fields create a new manifest.plist which is then inserted into the oxz?


3) The dependencies box at the bottom of the "manage manifests log-in" - am I correct in presuming that the "optional" dependency/oxp menu choice has no function whatsoever?

Cholmondely wrote: ↑Mon Jun 12, 2023 5:17 pm

1) Just to note Hiran's activity with his currently-named Oolite Start programme, overriding the Expansions Manager and meeting some of the suggestions at the top of this thread.

(Maybe it should be termed the Expansions Manager Manager? )


2) In the Manage Expansion Packs/Manage Manifests log-in:

Does filling in the fields create a new manifest.plist which is then inserted into the oxz?


3) The dependencies box at the bottom of the "manage manifests log-in" - am I correct in presuming that the "optional" dependency/oxp menu choice has no function whatsoever?

1) The starter provides OXP managing features, but it does more than that. Hence I would not rename it to 'Expansion Manager'. Also it may supercede the in-game expansion manager - but that one is still there and can be used.

Interesting: what happens if an OXP get disabled by the starter, then installed via the builtin?

2) If you refer to the web page where OXPs are registered: it used to update a database that was used to feed the expansion manager's knowledge about OXPs.
It did not touch the manifest.plist inside the OXP.

That is the main reason for the many discrepancies detected by OoliteAddonScanner.

3) I have no clue how optional dependencies are treated.

hiran wrote: ↑Tue Jun 13, 2023 5:11 am

1) The starter provides OXP managing features, but it does more than that. Hence I would not rename it to 'Expansion Manager'. Also it may supercede the in-game expansion manager - but that one is still there and can be used.

Interesting: what happens if an OXP get disabled by the starter, then installed via the builtin?

2) If you refer to the web page where OXPs are registered: it used to update a database that was used to feed the expansion manager's knowledge about OXPs.
It did not touch the manifest.plist inside the OXP.

That is the main reason for the many discrepancies detected by OoliteAddonScanner.

3) I have no clue how optional dependencies are treated.

Very interesting. I've just had a look at the "errors" in one of my OXPs.

When I wrote the manifest.plist inside the oxz, I was in "oxz-writing-mode". But when I filled in the manifest form in the "Manage Expansion Packs" screen on oolite.org, I was trying to publicise the oxz.
•Hence, for example, a much shorter text for the description, so that it would fit in the box. I felt no such constraints when I was working on the manifest.plist.
•I also renamed the oxz at that point to help publicise it, but having already uploaded it, I did not change everything in the manifest.plist.
•And I did not realise that "Dependencies" was referring to downloading OXPs - I thought it meant something obscure in Developer-speak!

Except for developers with special programmes which can read inside the oxz's without unzipping them, I don't see anybody reading the manifest.plist. I usually don't when I unzip other oxz's. I presume that the main functions of the manifest.plist are to place the license information inside the oxz and provide the identifier for the Expansions Manager and for Oolite.

Apart from making sure that the identifier and license details are identical, I'm not sure how much the discrepancies really matter (says the nit-picking wiki-editor!). I suppose, ideally, the Expansions Manager should either pick up on the discrepancies or create the manifest.plist itself (or extract the manifest.plist instead - it does reproduce the manifest.plist text at the screen bottom Codswallop - it does nothing of the sort!).

Not the most important thing. I do see your expansions manager manager as a vital improvement, though.

Edited to update

I tried to hammer the same nail - maybe too early.

https://bb.oolite.space/viewtopic.php?f= ... repository

MrFlibble wrote: ↑Fri Apr 19, 2024 1:16 pm

The HUD selector needs a version number name tweak. It ends up as a duplicate in ManagedAddOns when updated and is ignored.

Code: Select all

Old: [email protected]
New: oolite.oxp.Norby.HUDSelector.oxz

Fine when name changed to [email protected] and the old one deleted of course.

Does not the Expansions Manager sort out these issues? And so could not the game do this while loading?

I used the built-in manager to update, not the starter. Normally it works fine. As there was no @version suffix, the game preferred the older version and ignored the new one.

This is a slight difference how Oolite and OoliteStarter name the downloaded expansion.

Just the expansion name (without version number) limits you to only have one version installed. Whereas OoliteStarter is capable of juggling multiple version of an OXP in the same directory.

I found it necessary when reliably installing/disabling/enabling/removing OXPs might involve to have multiple disabled versions somewhere. The current version of OoliteStarter does not offer all it's capability to users so it does not matter.

It just becomes a topic when you use both Oolite and OoliteStarter to manage expansions.