Oolite Bulletins

arquebus wrote: ↑Fri Feb 09, 2024 6:04 pm

The other problem is that I am convinced we need to make it possible for new users to load presets. But some of those presets will include OXPs that must be installed manually (Local OXP List). Unless we have a very clear "fail message" that prevents users from using a preset with non-managed OXPs, we're going to have to provide a way for them to easily add them in. I don't think that workflow belongs on the Advanced screen.

I'm with you. OXZ installation is easy, but deciding for a meaningful combination is not.

arquebus wrote: ↑Fri Feb 09, 2024 6:04 pm

All of that said, I do understand the straightforward argument against having a Local OXP List separate from the managed list. They could be merged into a single list with some kind of visual indicator for which OXPs are local and which are not. Just know that if you remove the Load/Delete Local OXP buttons - regardless of what you do with the rest of the interface - you're cutting off a sizable set of non-managed OXPs that a basic user simply won't be able to access unless they go to the much more complicated Advanced screen.

Looking at the flow, would there be any problem if we mixed the ManagedAddons and the Addons? Oolite would not confuse them. OoliteStarter would not confuse them. But the difference is that OXPs - just like other OXZs are not on the expansion manager.

So to install them either the user downloads the file and drops it into a folder. Or he enters the URL into OoliteStarter and it will do the download instead to drop the file into the addons folder.
OXPs would never receive an update via the expansion catalog, but they can be removed. Apart from the download from URL there is not much difference to the OXZ handling.

arquebus wrote: ↑Fri Feb 09, 2024 6:04 pm

If we go that route, then I'd like to resurface my suggestion that the Oolite Starter presets should be zip files that include any non-managed OXPs used in the preset, which are then automatically installed into the non-managed AddOns directory when a preset is loaded in by a user.

That might work. Yet I'd raise the question why we should create presets from expansion that have not made it into the catalog.

Version 5B, with a combined list.



Edit to add:

We may also need to have a third color, for the left list. (Left list will never have Orange because that's a feature of the activation process, which is already completed.)

Active OXPs that are the dependency of another active OXP should be flagged in that column of the left list. That way the user will know that if they remove that OXP, everything that depends on it will also be removed.

Oolite Starter basic screen should never intentionally put a user in a position where they'll get red error messages when they launch the game. If the user tries to do something that will cause that (i.e., remove a dependency), Starter should either prevent it (forcing the user to manually remove the OXPs that use it) or give an alert and ask Yes/No on removing the dependency and all of its children.

hiran wrote: ↑Fri Feb 09, 2024 6:24 pm

I'd raise the question why we should create presets from expansion that have not made it into the catalog.

I think the presets that are included with Oolite Starter should only use managed OXPs. But other users who create presets and make them available may not do that. Mine, for example, includes Contextual Jukebox and a few other OXPs that aren't managed. As far as I know, mine is the only preset that is "out in the wild" as it were, but presumably that can change.

Another question, unrelated to the above, but important:

How do we represent the active/inactive state of an OXP on the Available list (assuming version 5B, but question is the same for 5.1)? (I'm going to use "active" and "inactive" instead of "installed" / "not installed" in order to avoid confusion, since installed could also mean downloaded, which is not what I'm talking about here.)

Three options:

1) No representation - only way to know if something is active is to look in the left list.
2) Highlighting in the Available list - OXPs that are in the current set are bold/italic/underlined/etc. in the Available list
3) Remove active OXPs from the Available list - when you click the left arrow, the OXP "moves" from the right to the left; and vice versa with the right arrow

My personal preference is option number 3. I could be convinced of option 2 but I think there's a high value in having the two lists non-duplicating. That way, the "action" of clicking an arrow has a very identifiable, recognizable effect on screen. It's a proper move button, instead of a copy button.

I've seen mod managers do one or the other, and my feeling is that the ones that use option 3 are much easier to interpret visually. Maybe less of a concern with Oolite where the Available set is over 750 items long, I suppose - it's not like you're really going to be able to tell if a mod is off the list or not just by glancing at it.

I have a poor internet connection so I'll keep the post short.

To handle inactive but local expansions there is the chance to add a marker in the available list.
They could be greyed out in the active list. And we could add a flag whether they should be displayed at all - similar to hidden files in a file browser.

But we are getting somewhere. I'll try to start something and make it available in an early stage so we can have a look together.

How about configuration options?
- I want to work with presets
- I want to play on OXZ level
- I want to fiddle those OXPs
- I want to hack OXPs
- I want to cache OXP/OXZ locally

Depending on these choices the UI shows more or less complexity

I'm at work and I'm supposed to be working but I'm having too much fun thinking about this.

Here's Version 6. I've come around (it only took a few minutes!) on the change to a single combined OXP list.

Version 6 adds visual reference to the dependencies flag, and adds the user state of a currently selected OXP.

Only one OXP should be selected at a time. You can't have an OXP selected on the left and another one selected on the right. Whichever OXP is selected populates the info box at the bottom.

Note that the RED flag on the right is non-dynamic. If the OXP conflicts with anything on the left side, the RED is flagged. However, the flag on the left is dynamic. It can only get flagged RED if the user is currently selecting an OXP on the right that conflicts with the relevant OXP on the left.

There is no program state where the RED flag would appear on the left list without the user having selected an OXP on the right. If the user has overriden the alert and allowed a conflicting OXP to be activated, we can't re-use the RED flag for that indicator. We'll need to use a different flag (darker/lighter red?) for that.

Only one flag needs to be active at a time - no need for multiple flag columns. RED has higher priority than ORANGE, because it's a block instead of a notification.

hiran wrote: ↑Fri Feb 09, 2024 6:58 pm

How about configuration options?
- I want to work with presets
- I want to play on OXZ level
- I want to fiddle those OXPs
- I want to hack OXPs
- I want to cache OXP/OXZ locally

Depending on these choices the UI shows more or less complexity

I was going to make a similar suggestion, but didn't want to exponentially increase the amount of work people who are not me would have to do.

What I had in mind was:

* Basic Level 1 - Managed OXPs only. Saves, Current OXP List, Managed ("Repository") OXP List, nothing else
* Basic Level 2 - Saves, Current OXP List, Managed ("Repository") OXPs, Presets

* Intermediate Level 1A - Managed OXPs, Presets, Local OXPs, using a combined OXP list
* Intermediate Level 1B - As with Intermediate 1A, but available OXP lists are broken out like in version 5
* Intermediate Level 2 - Managed, Local, Presets, Version Control (multiple versions in Manager listed if available, etc.)

* Advanced - All of the above, access to the nuts and bolts, like the current Starter

One more thing to consider, mainly for the Advanced stuff:

Should Presets be loaded XOR, or OR? That is, when you load a Preset, should it replace your current set, or simply add to it? Should you be able to choose? Allowing Presets to add to an existing set (not just overwrite it) would make it possible for people to provide "custom experience" collections that don't assume the player is only playing with those OXPs. You could create a Preset that only has a particular set of ship OXPs in it, for example, and distribute that for people to slot into their existing active OXP set.

As I think about the various levels of interface, I realize I'm starting to succumb to feature creep a bit. I would probably only want to go as far as this:

hiran wrote: ↑Fri Feb 09, 2024 9:21 am

Switeck wrote: ↑Fri Feb 09, 2024 7:06 am

OXP/OXZ names can be pretty long, so please try to make the width of the Current OXP Set, OXP Repository List, and Local OXP List a bit wider each.

I sometimes have to deal with swapping out earlier versions of the same OXP, so would that appear as a separate column or are we to assume the OXP installed is the latest one?

Having three lists with eventually long names is a challenge. How would you arrange them?

I wouldn't -- I'd have 2 lists (installed and available-for-download, with different colors for those that "need" to be updated/out-of-date/conflicts) and push them up near the edges of the screen to maximize their area. (no need to waste space)
Ingame Name, Version, install/creation date, Filename columns. (Yes the info can be given below for each OXP if clicked on them individually, so maybe these columns can be hidden and/or sorted by?)
The arrows between the 2 can be labeled ADD and REMOVE, or if easily possible have that as mouseover text. It may seem trivial...so consider this a light suggestion.

Advanced can have 3 crowded lists, but for new users that's likely confusion city.

Swapping out earlier versions:
Does that mean remove installed OXPs in favour of new versions (which I would understand as upgrade), or do you intend to also remove an installed OXP and install a previous version (downgrade)?

I do a lot of up+down grades in testing when big changes don't go as planned. (example: I'm tweaking/testing/comparing Thargoid Witchspace Drive earlier versions, and a few modded versions I've made. I'm also looking for unexpected interactions it can have with my other OXPs, such as misjump inducer.)

Currently, I try to do everything manually...but I only have ~50 total OXPs installed while testing.
I do sometimes check with far more OXPs installed when I check for updates.

Any OXZ/OXP I use regularly tends to end up in the AddOns folder due to minor changes I make from the original OXZs. If the changes are more than cosmetic, I often post details of my changes on the appropriate OXP message thread...or PM the authors if they're still active.

A couple big issues (but not really bugs!) concerning the large-scale handling of many OXZs/OXPs that I'm dealing with is:
1.3rd party station "overpopulation", where I would see quite a few extra stations in each system when I really only want a couple for variety. This has caused me to try to come up with a "universal" station populator script...and removal of individual spawning rules in favor of more complex rules-and-exclusions for stations. I have yet to go back and redo the spawning rules so players can savegame at them, although I may have made that possible for 1 or 2.
2.Thargoids everywhere! (and lots of other ships in interstellar space too!) Try as I might, I'm at a loss to trace down every condition that spawns Thargoids and extra ships, especially in interstellar space after 3 unrelated misjumps. I probably need to un-zip every OXZ and do word-searches on all of their files for spawning conditions. This is a lot less trivial than it may sound due to the many methods that can be used to add ships and stations and the 100's of OXZs to do that on.

OoliteStarter is unlikely to be a useful tool to help me on those 2 big issues except for quick adding/removing OXPs.
I don't expect/want/need it to be.
I know my use-cases are ridiculous, I do ridiculous stuff!
I'm mainly mentioning these issues because I was asked why I add/remove installed OXPs and sometimes do downgrades.

Slight iteration, version 6.2:

Switeck wrote: ↑Fri Feb 09, 2024 8:26 pm

I wouldn't -- I'd have 2 lists (installed and available-for-download, with different colors for those that "need" to be updated/out-of-date/conflicts) and push them up near the edges of the screen to maximize their area. (no need to waste space)
Ingame Name, Version, install/creation date, Filename columns. (Yes the info can be given below for each OXP if clicked on them individually, so maybe these columns can be hidden and/or sorted by?)

These would, in my formulation, only appear in an Advanced screen. The Basic screen should not have any columns for version, dates, filenames. They're extraneous information that 99% of users absolutely will not need.

Also for basic users, updates would be handled when a save is loaded - a screen would pop up showing which OXPs from that set need to be updated, allowing the user to checkbox the ones to update and then click "Go". Basic users should never have to actively pay attention to the existence of OXP updates.

It would probably be better to have a longer Savegame list and a shorter Preset List (for groups of OXZs).
Doesn't take long to make 10+ savegames, but grouping OXZs may be something done occasionally/rarely.

Switeck wrote: ↑Fri Feb 09, 2024 8:43 pm

It would probably be better to have a longer Savegame list and a shorter Preset List (for groups of OXZs).
Doesn't take long to make 10+ savegames, but grouping OXZs may be something done occasionally/rarely.

The mockup isn't truly proportionally accurate but you're right, the list sizes should be swapped. Here's version 7: