OoliteStarter

[hiran]

And, by the way, your latest tweaks don't work on the AppleMac: I'm using 0.1.28 uxbridge 10 - I can't use the menu to "enable" anything, and I now get an error message most times I try opening it up - java.lang.NullPointerException: Cannot invoke "java.util.List.stream()" because "this expansions" is null

That version is one month old and has received two more followups on that experimental branch before considered stable. It is possible that I stabilized such issues in the meantime already. But to really tell I need the logfile so I know where/why that error is coming up.

You will need to remind where I find the logfile. Sorry! I got a message about the new nightly - but nothing about the new OoliteStarters.

For brand new players who are not programmers, I'm not sure that information about nightlies is helpful.

The logfile is just besides the Oolite logs, i.e. $HOME/.Oolite/Logs

I do believe the message about new Oolite versions is helpful. I look at the traffic statistics on Github regularly. Since I introduced that message more players look at the Oolite project at all, and the download count for the latest prerelease (1.91) is higher than for the latest release (1.90). This although on the website we advertise the latest release only.

But true: As long as you do not care about the Oolite version, reminders for new OoliteStarter versions are not displayed either. I did not want to overload the user with too many update requests. Maybe I chose an unsuitable approach for your behaviour.

[Cholmondely]

Don't see it there, I'm afraid!! Just the Oolite latest/previous logs.

[hiran]

Ping!

Is anyone using OoliteStarter? Has anyone tried that latest experimental version?
In case no problems are reported for another week I'll assume it works ok and will create the stable version.

[hiran]

Aha. I just stumbled over this video: https://www.youtube.com/watch?v=QWHaEmKpMyw

@arquaebus:
Newer versions of OoliteStarter check for updates once a week. If there is a new version of OoliteStarter, or a new version of Oolite you are being told.
For updated OXPs you get a dialog box like this popping up:



It asks you to approve removal of the previous and installation of the newer OXP. After that you have the application screen in front of you.

The OXPs marked up red have problems. Either other OXPs are required but not installed, or they cause conflict with something that is installed.
Red on the left side means 'do not install', as you would create problems. Red on the right side means you have problems already and had better resolve them.
Yellow is trying to get your attention. Yellow on the left means 'install this' as it would install an otherwise missing OXP (required by something else). Yellow on the right means 'do not uninstall', as it is required by something else that is installed.
The exact reason for the colors is actually displayed in the OXP details - the text below. Later versions of OoliteStarter do even bring up the color coding into he text so you can more easily correlate. Take a look at that in practice:



You can see in the left list one OXP is selected (blue background). But it also has a red marker on the left. The text below shows the details, and there is a red marker with an explanation: There are two OXPs that are not installed but required for this one to work.


Somehow I cannot believe you prefer to go through the list of expansions in-game just for the font size...
I am not planning to provide a font scaling as a feature for OoliteStarter. It exists implicitly, but we need to figure out how to apply it.
Could you verify whether something here is usable?
- https://superuser.com/questions/652606/ ... plications
- https://www.formdev.com/flatlaf/system-properties/ (check the flatlaf.uiScale system property)

[phkb]

Bringing this here as requested!

To recreate the issue, you will an older version of an OXP: Lets use Galactic Registry, as it has no dependancies.
Previous version here: GalCopGalacticRegistry_5.9.oxz

I'm going to simulate what OoliteStarter is doing here (because otherwise I'd have to have a legitimate update to perform). So, rename the older 5.9 version to "[email protected]" and put it into the Managed AddOns folder of a clean installation of Oolite.

Next, start Oolite. The game will start OK, Galactic Registry should be available from the F4 screen, all is good.

Restart Oolite, but this time go into the "Manage Expansion Packs" menu. Update the expansions list, and then find GalCop Galactic Registry in the list. It should be highlighted in cyan, indicating there is an update ready to install.



Curiously, Oolite isn't detecting the version number of the installed version.

Anyway, do the update.



Notice it says "2 packs have been installed here" after the update. That's strange, because there is only one pack actually installed.

Select "Return to Menu"

This is what you then see:



Looking at the Managed AddOns folder, you see this:



Because of the filename of the old version, Oolite did not remove/overwrite the old one. It left it in place and added the new version to the mix, resulting in the duplication error.

[hiran]

Thank you phkb for describing the issue. Looking at an older post I'd say Oolite behaves as expected yet the in game manager does not.

See THIS OLD POST of mine. Basically you can rename an OXZ to anything you like and the game will still recognize it. However, you will have to do some extra file management in order to keep things straight when you download newer versions of the same OXZ. The new file and the old renamed file will both be kept by the In Game File Manager and you will get duplicate file warnings when you exit the In Game File Manager. The key to this renaming is to NOT make any changes to the manifest.plist within the OXZ. If you make changes to the name as it is listed in the manifest.plist then the OXZ will no longer be recognized by the In Game File Manager which will lead to multiple problems.

Apparently it is not sufficient to keep the manifest as is. The problem may only show up when upgrading OXPs via in game after they were installed by OoliteStarter.

I'll play with the described scenario. And as we can neither change nor deactivate the in game manager there has to be a change outside the game.

[Cholmondely]

Thank you phkb for describing the issue. Looking at an older post I'd say Oolite behaves as expected yet the in game manager does not.
...

Apparently it is not sufficient to keep the manifest as is. The problem may only show up when upgrading OXPs via in game after they were installed by OoliteStarter.

I'll play with the described scenario. And as we can neither change nor deactivate the in game manager there has to be a change outside the game.

I don't understand this.

The Manifest.plist and in-game Expansions Manager used to work perfectly, as far as I could ascertain.

What has changed?

[hiran]

I don't understand this.

The Manifest.plist and in-game Expansions Manager used to work perfectly, as far as I could ascertain.

What has changed?

The expansion manager has not changed. The expansions have not changed (ok they are compatible).

Oolite is quite flexible on filenames in the addons and managedaddons directory. But the expansion manager only supports one way.

When I developed OoliteStarter I obviously tested against Oolite, not the in game expansion manager and came up with a different naming scheme. And it is only a problem when users mix these two.

[hiran]

Restart Oolite, but this time go into the "Manage Expansion Packs" menu. Update the expansions list, and then find GalCop Galactic Registry in the list. It should be highlighted in cyan, indicating there is an update ready to install.



Curiously, Oolite isn't detecting the version number of the installed version.

I have the same result and am also wondering. It must know the version number to detect an update is available yet it does not show.

[hiran]

I tested some more and found some interesting effects in OoliteStarter.
I also found out that the in game expansion manager is peculiar enough it only detects the installed expansion's version if it has the one very special name.

So I adapted OoliteStarter. No more version numbers in expansion filenames any more. Please take a look at OoliteStarter 0.1.31-furbelow.1.

[hiran]

It would also be nice to be able to select multiple flavours. Say, for instance, I want the beginner's set and the depth set. At the moment, there is no clear way I could achieve that. I can't even see what mods are included in each, so I couldn't go and put the list together myself. If we could be modular with how the flavours are installed, it would allow something like Redspears "Ain't Got All God Damn Day" Flavour to address specific issues players have encountered in the game.

Changed, as it was requested by someone else a long time ago. Now you can choose to install a flavour additionally to whatever you have, or exclusively by installing the missing and removing anything not part of the flavour.

I don't think the icons are particularly clear for what is taking place. Why a yellow exclamation in a warning triangle? To me that indicates a problem of some sort. I can kind of see the reason for the trash can "to be deleted" icon, but I think this would be a lot simpler with just a red minus "-" for the OXP's to be deleted, and a green plus for those that will be added.

The other problem with this dialog is that the "..." icon is leading me to believe there is a popup menu or something that will enable me to take action on a single entry. For example, if I *don't* want to delete "Super Systems" in my screen shot above. But no amount of clicking (left, right, double), brings up any way to tell the UI "please don't delete my OXP!". I honestly don't want to click on "OK" because I don't want to find out afterwards that I should have taken a backup before starting!

Thanks for bringing it up. This has been worked on.

Confusingly, after I pressed "OK" to confirm the changes, it *didn't* delete that OXP anyway. It just left it in there. Is that what's supposed to happen?

Not sure what/why it happened. Can I reconstruct the situation?

Final issue: There's a problem when switching between OoliteStarter and the built-in manager when updating OXP's.

This is fixed also.

Please have a look at OoliteStarter v0.1.31-furbelow.2

[Cholmondely]

Wondering if (if it's not too complex) there might be point in having two sets of Flavours:

Flavours (for different games)

Issue-solvers (for nobbling specific problems) - for dumb pilots like myself who need aid in combat, for Redspear's mass-lock sufferers, for crash-dockers and lastly for those who need to know what button does what.

I think that these are the four main issues which our neophytes have with Oolite.

[hiran]

Wondering if (if it's not too complex) there might be point in having two sets of Flavours:

Flavours (for different games)

Issue-solvers (for nobbling specific problems) - for dumb pilots like myself who need aid in combat, for Redspear's mass-lock sufferers, for crash-dockers and lastly for those who need to know what button does what.

I think that these are the four main issues which our neophytes have with Oolite.

Is this how OoliteStarter should handle flavours, or do you intend to provide flavours in four disciplines? The latter is better homed in the flavours thread.

[phkb]

Wondering if (if it's not too complex) there might be point in having two sets of Flavours:

Don't overthink it. As long as the flavour adequate explains what it's there for (what issues it might be seeking to resolve or the type of game it will provide) we can work with one category.

This is assuming we can keep the number of flavours to a managable level. But, we can do that, right?

Right?

[hiran]

Please have a look at OoliteStarter v0.1.31-furbelow.2

@arquaebus @phkb: Have you had a chance looking at that new release? Are the issues you brought up covered, or is there further work necesary?