Oolite Bulletins

arquebus wrote: ↑Thu Feb 29, 2024 11:09 pm

Should these be hard-coded buttons, or a loadable list (with defaults) like in my later UI iterations?

We can put a list of buttons/combobox entries/... into the UI and also the list of OXPs that is behind.
Alternatively we can put the buttons in the UI and the list of OXPs will be downloaded from somewhere (website? wiki? ...?)
Alternatively we can download both the list of buttons together with the lists of OXPs from somewhere.

Each of these approaches has advantages and disadvantages:
- Hardcoded means it will just work, whether online or offline. Updates however would only be available through updates of OoliteStarter.
- Downloaded on demand would mean the lists can be updated even when OoliteStarter is not updated. But when your machine is offline not even a list could be displayed.

I believe the latter does not add problems, since in offline mode the expansions cannot be installed anyway. Regardless of the mechanism we decide for - we need to have lists of OXPs.

I was thinking more about the list of collections, not the contents of those collections. In the last iterations of my UI workup, there was a list of sets that had a bunch of defaults (vanilla, Basic, etc.) but also the option to load new sets into the list.

Alternatively, we could just have some hardcoded buttons to select the collection, for all of the default options, and have a separate list for the ones you load in manually.

arquebus wrote: ↑Fri Mar 01, 2024 4:36 pm

I was thinking more about the list of collections, not the contents of those collections. In the last iterations of my UI workup, there was a list of sets that had a bunch of defaults (vanilla, Basic, etc.) but also the option to load new sets into the list.

Alternatively, we could just have some hardcoded buttons to select the collection, for all of the default options, and have a separate list for the ones you load in manually.

I strongly believe we are talking the same. Give me some rudymentary lists and I will show you what we can do with them.
Would actually place them on the website similarly like the expansions catalog so we can update them independently of the installed OoliteStarter version.

At least one expansion set I already know: Vanilla. It contains no expansions. You will be able to install it on top of whatever you have (which means nothing will be added), or you can install it such that all unneeded ones are being uninstalled. Which would mean to remove all installed expansions.

Not sure if what just happened is due to Starter or 1.91, but I figured I'd start here....

Loaded Starter. It tells me there's a new build of 1.91. I download it, run it. I check the expansions manager and run updates from there (not from Starter). There are a few. One of them doesn't "take" (groovy something or other) and keeps identifying as updatable. When I check the list of installed expansions I see that this one is in the list twice. So I exit and restart Oolite as a first step of testing. And suddenly I get a bunch of error messages about duplicate OXPs. I exit and then check the AddOns, and find that all of the OXPs I updated are duplicates of ones that have a version number of some sort after the name. I have no idea where those came from.

Are they from Starter? Are they from 1.91?

Anyway, I deleted all of the older ones (older date, not necessarily older version) and started Oolite again. No more errors.

arquebus wrote: ↑Sun Mar 03, 2024 10:59 pm

Not sure if what just happened is due to Starter or 1.91, but I figured I'd start here....

Loaded Starter. It tells me there's a new build of 1.91. I download it, run it. I check the expansions manager and run updates from there (not from Starter). There are a few. One of them doesn't "take" (groovy something or other) and keeps identifying as updatable. When I check the list of installed expansions I see that this one is in the list twice. So I exit and restart Oolite as a first step of testing. And suddenly I get a bunch of error messages about duplicate OXPs. I exit and then check the AddOns, and find that all of the OXPs I updated are duplicates of ones that have a version number of some sort after the name. I have no idea where those came from.

Are they from Starter? Are they from 1.91?

Anyway, I deleted all of the older ones (older date, not necessarily older version) and started Oolite again. No more errors.

OoliteStarter has the capability of installing an expansion in different versions. That has advantages and disadvantages.
Advantage: you have fine-grained control over what is on the disk
Disadvantage: such a setup can be confusing for users

Nevertheless, to be able to have different versions of one expansion the version number is appended to the directory name. So yes, the 'versioned' expansions come from OoliteStarter.

hiran wrote: ↑Sun Mar 03, 2024 11:11 pm

Disadvantage: such a setup can be confusing for users

Very!

Can I suggest the following then? Instead of tracking and keeping various "versions" of OXP's by default, make that something an advanced user has to opt-in for. Put a checkbox in an options panel/menu somewhere. That way, the default method of dealing with expansions is just to have 1 copy of the latest, but if a user wants to keep track of versions and switch between them, they can turn the option on manually.

The default method should always be aimed at the new/inexperienced user. Advanced features should always be opt-in.

Hmmm.

There's lots of potential conflict here, but I don't know how to resolve it.

Clearly I "broke" things by updating via the expansion manager. Should not have done that. (I did it because I forgot that the updating option in Starter is in the old UI.)

I think fundamentally Starter should not be doing anything *weird* with the AddOns directories themselves. Any additional functionality that it provides (like versions) should come from other directories, and should only be activate-able if Starter is what loaded Oolite. In fact, Starter shouldn't touch anything in the default directories *until* it loads Oolite. When it's just running, with no Oolite launched, it should still leave that stuff alone. Any number of catastrophic things could cause Starter to shut down without cleaning up after itself. You'd still have the exceptional case where there's a catastrophe while Oolite is running, but I doubt there's any way around that short of Starter on-the-fly (non-permanently) patching Oolite to look at a different set of AddOn directories at launch.

phkb wrote: ↑Mon Mar 04, 2024 1:43 am

hiran wrote: ↑Sun Mar 03, 2024 11:11 pm

Disadvantage: such a setup can be confusing for users

Very!

Can I suggest the following then? Instead of tracking and keeping various "versions" of OXP's by default, make that something an advanced user has to opt-in for. Put a checkbox in an options panel/menu somewhere. That way, the default method of dealing with expansions is just to have 1 copy of the latest, but if a user wants to keep track of versions and switch between them, they can turn the option on manually.

The default method should always be aimed at the new/inexperienced user. Advanced features should always be opt-in.

I would not like to implement such a feature twice. Going for the more capable one allows me to not use a feature. And actually it was intended to be compatible to the existing model.

Currently the issue I see is that the identification of expansions does not work correctly. That is not to be compromised and I need to work on it.

arquebus wrote: ↑Mon Mar 04, 2024 5:44 am

I think fundamentally Starter should not be doing anything *weird* with the AddOns directories themselves. Any additional functionality that it provides (like versions) should come from other directories, and should only be activate-able if Starter is what loaded Oolite. In fact, Starter shouldn't touch anything in the default directories *until* it loads Oolite. When it's just running, with no Oolite launched, it should still leave that stuff alone. Any number of catastrophic things could cause Starter to shut down without cleaning up after itself. You'd still have the exceptional case where there's a catastrophe while Oolite is running, but I doubt there's any way around that short of Starter on-the-fly (non-permanently) patching Oolite to look at a different set of AddOn directories at launch.

The weird stuff is what we kind of asked for in the beginning. We wanted OoliteStarter to not only install, update and remove expansions. On top it should be able to deactivate expansions, which would be done by moving them to another directory.

viewtopic.php?p=289752#p289752

Now let's assume we deactivate expansion foo in version 1.0. Of course everyone would expect we can enable it again.
What should happen if inbetween foo version 2.0 gets released? So version 1.0 is deactivated to be restored later, and version 2.0 gets downloaded in parallel?

The current model is capable of handling these situations, yet the implementation is buggy.

hiran wrote: ↑Mon Mar 04, 2024 9:50 pm

The weird stuff is what we kind of asked for in the beginning. We wanted OoliteStarter to not only install, update and remove expansions. On top it should be able to deactivate expansions, which would be done by moving them to another directory.

To my mind, that's not the weird stuff. The weird stuff is renaming things that are in the AddOns directories. Adding, removing and cataloguing are not weird. But anything that the expansion manager cannot recognize - that's weird.

Now let's assume we deactivate expansion foo in version 1.0. Of course everyone would expect we can enable it again.
What should happen if inbetween foo version 2.0 gets released? So version 1.0 is deactivated to be restored later, and version 2.0 gets downloaded in parallel?

I'm not sure how this has to be done by renaming the expansions in the active AddOns directories.

Foo.OXP is in AddOns.
Foo.OXP gets deactivated.
(Deactivated) Foo.OXP gets renamed to include the version number.
Foo.OXP gets reactivated.
(Reactivated) Foo.OXP gets renamed to remove the version number.

That's how I'm imagining it should be, or something similar.

This would still accommodate your hypothetical above, because as soon as the v2 OXP gets moved to Deactivated, it gets renamed as v2, and so it can live alongside v1, and the player can reactivate either one. But once it hits the active AddOns directory it's got to have a name that the expansion manager recognizes, or all hell will break loose.

I just pushed my latest edits to OoliteStarter. In that I am focusing on two items:
- reduce filesystem scans to the very minimum. This has a strong effect for users with many expansions
- stabilize detection of expansions so we do not create conflict

I'd be glad to get feedback not only whether it works or works better but in case of problems something that I can track and fix.
Although right now I am not sure what I would need.

But a message saying what happened, what was expected and some information how to recreate the situation would definitely be a step forward.

Mac version. Got all the directories set up (and pointed the expansion manager at the right place).

Opened Starter.

Greeted with blue progress bar at the bottom and "rescanning...", no OXPs listed, Old Expansion Panel shows no OXPs listed ("No expansions found"), clicking Reload gives the "Could not reload" error message.

arquebus wrote: ↑Fri Mar 08, 2024 9:33 pm

Mac version. Got all the directories set up (and pointed the expansion manager at the right place).

Opened Starter.

Greeted with blue progress bar at the bottom and "rescanning...", no OXPs listed, Old Expansion Panel shows no OXPs listed ("No expansions found"), clicking Reload gives the "Could not reload" error message.

Great! Which version of OoliteStarter did you run? You say it did not show any expansions. What is the content of your ManagedAddons and Addons folders? What does the OoliteStarter logfile say? (to be found in $home/.Oolite/Logs)

uxbridge.6 is the version of Starter.
Managed AddOns has Xenon UI and Xenon UI Resources D, nothing else.
All of the other AddOn directories are empty.

Here's the log:

2024-03-08 15:36:52,879 INFO oo.st.MainFrame [main] Args: []
2024-03-08 15:36:52,896 INFO oo.st.MainFrame [main] JVM: OpenJDK Runtime Environment 17.0.10+7
2024-03-08 15:36:52,896 INFO oo.st.MainFrame [main] OS: Mac OS X x86_64 14.0
2024-03-08 15:36:52,900 INFO oo.st.MainFrame [main] OoliteStarter 0.1.28-uxbridge.6 starting up...
2024-03-08 15:36:55,848 INFO oo.st.MainFrame [SwingWorker-pool-2-thread-1] Initialize UI...
2024-03-08 15:36:56,071 DEBUG oo.st.Oolite2 [SwingWorker-pool-2-thread-1] Oolite2()
2024-03-08 15:36:56,077 WARN oo.st.MainFrame$1 [AWT-EventQueue-0] statusChanged(INITIALIZING)
2024-03-08 15:36:59,455 WARN oo.st.Oolite [SwingWorker-pool-2-thread-1] Performed getAllExpansions() on 762 expansions in PT2.220488S
2024-03-08 15:36:59,456 WARN oo.st.Oolite [Thread-0] Performed getAllExpansions() on 762 expansions in PT3.376492S
2024-03-08 15:36:59,460 DEBUG oo.st.Oolite2 [Thread-0] installWatchers()
2024-03-08 15:36:59,484 WARN oo.st.MainFrame$1 [AWT-EventQueue-0] statusChanged(INITIALIZED)
2024-03-08 15:36:59,807 WARN oo.st.ui.ExpansionsPanel [SwingWorker-pool-2-thread-1] performed update() in PT2.573308S
2024-03-08 15:36:59,851 WARN oo.st.ui.ExpansionsPanel2 [SwingWorker-pool-2-thread-1] update()
2024-03-08 15:36:59,852 DEBUG oo.st.Oolite2 [SwingWorker-pool-2-thread-1] getExpansionListModel()
2024-03-08 15:36:59,852 DEBUG oo.st.ut.FilterAndSearchUtil [SwingWorker-pool-2-thread-1] getExpansionFilter(NONE, )
2024-03-08 15:36:59,859 DEBUG oo.st.ut.FilterAndSearchUtil [SwingWorker-pool-2-thread-1] getExpansionComparator(BY_TITLE)
2024-03-08 15:36:59,861 DEBUG oo.st.ge.SortedListModel [SwingWorker-pool-2-thread-1] SortedListModel(oolite.starter.generic.FilteredListModel@2f259076, ASCENDING, Comparator<Expansion>(BY_TITLE))
2024-03-08 15:36:59,877 WARN oo.st.ui.ExpansionsPanel2 [SwingWorker-pool-2-thread-1] setting filter AndFilter(Filter(!enabled), SearchFilter())
2024-03-08 15:36:59,877 WARN oo.st.ui.ExpansionsPanel2 [SwingWorker-pool-2-thread-1] setting comparator Comparator<Expansion>(BY_TITLE)
2024-03-08 15:36:59,877 DEBUG oo.st.Oolite2 [SwingWorker-pool-2-thread-1] getExpansionListModel()
2024-03-08 15:36:59,877 DEBUG oo.st.ut.FilterAndSearchUtil [SwingWorker-pool-2-thread-1] getExpansionFilter(NONE, )
2024-03-08 15:36:59,880 DEBUG oo.st.ut.FilterAndSearchUtil [SwingWorker-pool-2-thread-1] getExpansionComparator(BY_TITLE)
2024-03-08 15:36:59,880 DEBUG oo.st.ge.SortedListModel [SwingWorker-pool-2-thread-1] SortedListModel(oolite.starter.generic.FilteredListModel@20b9d4e9, ASCENDING, Comparator<Expansion>(BY_TITLE))
2024-03-08 15:36:59,880 WARN oo.st.ui.ExpansionsPanel2 [SwingWorker-pool-2-thread-1] setting filter AndFilter(Filter(enabled), SearchFilter())
2024-03-08 15:36:59,881 WARN oo.st.ui.ExpansionsPanel2 [SwingWorker-pool-2-thread-1] setting comparator Comparator<Expansion>(BY_TITLE)
2024-03-08 15:37:02,514 INFO oo.st.MainFrame [SwingWorker-pool-2-thread-1] Check for new version...
2024-03-08 15:37:02,587 INFO oo.st.GithubVersionChecker [SwingWorker-pool-2-thread-1] Update check skipped until 2024-03-13T19:26:51.515603Z
2024-03-08 15:37:02,591 DEBUG oo.st.OoliteVersionChecker [SwingWorker-pool-2-thread-1] GithubVersionChecker()
2024-03-08 15:37:02,597 INFO oo.st.OoliteVersionChecker [SwingWorker-pool-2-thread-1] Update check skipped until 2024-03-13T19:26:52.156424Z
2024-03-08 15:38:44,691 INFO oo.st.MainFrame [Shutdownhook] OoliteStarter 0.1.28-uxbridge.6 shutdown


This is strange. There is still a lot of debug output in that logfile but nothing related to 'could not reload'. It looks more like you started the application and then stopped it.

I will check if problems during reload might not be logged. Could you check if you posted the correct logfile (they rotate wich each invocation).

Ah, I also see some logging feature activated that I usually do not use. Did you try to reconfigure logging?