OoliteStarter

[hiran]

Introduction to Oolitestarter

Oolitestarter is a versatile, open-source tool that is designed to simplify the process of setting up and managing OOlite, an open-source space flight simulator. Oolitestarter was created to assist users in configuring OOlite for various purposes, including gameplay, modding, and development. By streamlining the process, Oolitestarter helps users save time and effort, making it easier for them to enjoy the OOlite experience.
Purpose of Oolitestarter

The primary purpose of Oolitestarter is to provide a user-friendly and efficient method for setting up, managing, and maintaining OOlite. Some of the key purposes of Oolitestarter include:

Automating the installation process: Oolitestarter automates the process of downloading and installing OOlite, including all its dependencies and required software, saving users the hassle of manually searching and downloading individual components.

Configuring game settings: Oolitestarter allows users to configure various game settings, such as graphics, audio, and control schemes, tailoring the OOlite experience to individual preferences.

Supporting modding and development: Oolitestarter makes it easier for users to install and manage mods, as well as create their own modifications and development environments, fostering a thriving OOlite community.

Updating and maintaining OOlite: Oolitestarter keeps users informed about updates and new releases, ensuring that their OOlite installation stays up-to-date and compatible with the latest game patches and mods.

Ensuring compatibility: Oolitestarter ensures that OOlite is installed and configured correctly, helping users avoid common issues such as crashes, graphical glitches, and incompatibilities with their system.

In summary, Oolitestarter serves as a valuable tool for users who want to enjoy the OOlite experience without the burden of manually setting up and managing the game. By automating and streamlining the process, Oolitestarter makes it easier for users to install, configure, and maintain their OOlite installations, while also supporting modding and development efforts within the community.
Authoritative Reference Titles

OOlite Wiki: The OOlite Wiki (https://wiki.oo-category.org) is a comprehensive resource for information about OOlite, including its features, gameplay, mods, and development. It provides valuable information on how to use Oolitestarter and troubleshoot common issues.

Oolite Forums: The Oolite Forums (https://forum.oo-category.org) serve as a hub for the OOlite community, where users can discuss the game, share mods, and seek assistance with installation and configuration. The forums are a great place to find information on Oolitestarter and learn about its features and capabilities.

GitHub repository: The Oolitestarter GitHub repository (https://github.com/oo-category/Oolitestarter) is the official source for Oolitestarter, providing users with the latest version of the tool, documentation, and information on how to contribute to the project. This is an essential resource for understanding the inner workings of Oolitestarter and staying up-to-date with its development.

[hiran]

in this thread we can see that the presence of OoliteStarter increases the success of Oolite. Quite dramatically indeed. When the links in the download boxes were removed, download numbers were dropping. Just when we restored the links again we can already see the numbers rising. I am looking at both

• https://github.com/OoliteProject/oolite/graphs/traffic
• https://github.com/HiranChaudhuri/Oolit ... hs/traffic

So now the question is: what can we do to make it even easier/comfortable for users to get along with Oolite?
Should the starter automatically check for new versions of Oolite? Should it automatically download them?
What about expansions? Should the latest versions also be installed automatically?
If only on user request, is the UI or the theme good enough?

I'm interested to hear your opinions, dreams, visiions or the itches that you may have with the current setup.

[arquebus]

Some notes:

1) There are chunks of time where the program is churning in the background but not offering feedback. For example, when reloading the OXP list, it can take up to a minute, and during that time the UI is locked out and there's no visual feedback. So it looks like the program froze. This is especially a problem at program load. It "freezes" for an exceptionally long time. Maybe a progress bar, if possible?

2) I think the Starter should definitely download new versions (on request/confirm), and also have a checkbox or somesuch to allow the user to download a non-stable release (aka 1.91).

3) I go back and forth on having the latest OXPs auto-update. Maybe this should be a checkbox, or a pop up asking the user YES/NO at start. You do run into a couple of problems if you allow the auto-update, though.

There are some ... strange ... situations in the update list that appear to be due to goofy OXP data (not the Starter's fault). For example:

BGS (2.5.4, the current version) has two "update" options: BackGroundSet 1.10.8 and BackGroundSet 1.10.9

Market Observer (3.7) offers an "update" to version 2.3.2 from 3 years ago.

The Date column only shows the date, I think, when Starter believes it's the most recent version. But in the two above cases, the versions *without* dates are the most recent ones.

There may be more; these are just the ones I'm spotting with my current OXP set.

[arquebus]

While I'm at it, there are some weird things going on with the "problematic" bucket still.

For example, the Fer-de-Lance 3G OXP shows a conflict with... itself.

Also, Telescope v2 is showing a conflict with HUD Selector, which, ok, sure, but really? Does it *really* conflict? I don't think I've noticed an issue, and I have a suspicion that Telescope v2 and HUD Selector will be among the most popular OXPs. If they're not really in conflict, having them flagged as problematic could prevent players from using both.

These two issues are technically not something that Starter should really be dealing with, but I think there is a case to be made that Starter should, at least in some limited circumstances, "patch out" errors/problems in OXP categorization/display/etc.

Oh and while I'm at it #2:

I continue to believe that it is important for Starter to identify the OXP that flags another as incompatible, when looking at that flagged OXP. In the above example of Telescope v2 and HUDSelector, HUDSelector shows up in the problematic list, but it has no Conflicts in that field. So an unfamiliar user may not understand what it's doing there. Starter is obviously able to identify HUDSelector as the target of a conflict check, so it shouldn't be difficult to display what that conflict check is. Maybe a field "Conflict Reported By" or something.

[arquebus]

I think that with a few iterations, and maybe some additional UI love, Starter could be listed as the preferred method for OXP management. Essentially deprecating the Expansions Manager inside Oolite.

My vision is as follows:

1) New player downloads THE PACKAGE, which includes BOTH Oolite version 1.9.x and Oolite Starter version 1.x.
2) New player DOES NOT run Oolite directly, EVER. Oolite Starter is advertised and positioned as the "official launcher" for the game.
3) The Expansions Manager option in the main game menu gets relabeled as "Expansions Manager (Legacy)". Still usable, but explicitly not preferred.
4) A button added to the Starter opens the manual AddOns directory for players to add OXPs that are not in the Manager. Alternatively, there would be a process where you can use a loading interface to select an OXZ or an OXP folder to add, and never have to open the AddOns directory at all.

To get there I think Starter will need a fairly sizable overhaul of the UI to make it more user friendly (particularly the tagging system). At minimum it should be as visually clear (color-coded) as the existing in-game Expansions Manager.

[Wildeblood]

There are some ... strange ... situations in the update list that appear to be due to goofy OXP data (not the Starter's fault). For example:
...
The Date column only shows the date, I think, when Starter believes it's the most recent version. But in the two above cases, the versions *without* dates are the most recent ones.

There may be more; these are just the ones I'm spotting with my current OXP set.

There are indeed others. The problem is people including older OXZ versions (not in itself a bad thing) without ensuring their manifests specify the last compatible Oolite version.

[arquebus]

There are some ... strange ... situations in the update list that appear to be due to goofy OXP data (not the Starter's fault). For example:
...
The Date column only shows the date, I think, when Starter believes it's the most recent version. But in the two above cases, the versions *without* dates are the most recent ones.

There may be more; these are just the ones I'm spotting with my current OXP set.

There are indeed others. The problem is people including older OXZ versions (not in itself a bad thing) without ensuring their manifests specify the last compatible Oolite version.

True. I do think it's important to recognize that this is more or less a finite list at this point. So it might take a touch of work but it should be possible for Oolite Starter (i.e. hiran) to catalogue those discrepancies (among the ones in the Manager, not loose manual installs) and patch them out of the Starter - so that the Starter reflects correct data even if the OXPs themselves do not. Because I believe we are philosphically opposed to getting our fingers in other people's OXPs to fix those errors.

[Wildeblood]

Because I believe we are philosphically opposed to getting our fingers in other people's OXPs to fix those errors.

Speak for yourself. The people who packaged those older OXPs into OXZs weren't philosophically opposed to "touching other people's stuff". They were just in too much of a rush to check their work.

Much simpler to fix a few dodgy manifest files, where they need fixing, than have a third party application maintaining a master list of (in)compatibilities.

[phkb]

BGS (2.5.4, the current version) has two "update" options: BackGroundSet 1.10.8 and BackGroundSet 1.10.9

Market Observer (3.7) offers an "update" to version 2.3.2 from 3 years ago.

There are discrepancies between what was in the original expansion manager DB, and what is in the actual manifest file for each OXP.

For instance, in the original DB, BGS 1.10.8 has a minimum Oolite version set to 1.79, and the maximum Oolite version is set to 1.80.99. BGS 1.10.9 has a minimum Oolite version set to 1.81, but with no maximum, while BGS 2.5.2 has a minimum Oolite version of 1.88.

With Market Observer, version 2.3.2 has a min Oolite version of 1.79, and a max Oolite version of 1.80. MO version 3.7 has a min Oolite version of 1.82, with no maximum.

Basically, we'll need to (a) make sure OoliteStarter is checking the min/max Oolite versions in the manifest file and hiding things that don't apply to the version of Oolite you have selected, and (b) republish the oxps that are missing the extra information.

As an aside: If any one is curious, the old DB is still online and functioning.

[phkb]

Because I believe we are philosphically opposed to getting our fingers in other people's OXPs to fix those errors.

I don't really consider editing a manifest file constitutes "getting our fingers in other people's OXPs". It's just data that helps us share OXPs.

[hiran]

Thank you all for contributing to a constructive discussion.

I totally agree the the UI is not as intuitive as it should be. When I started developing there was a rough vision of improving expansion management but a lot more features or details popped up while implementing. The result is a UI that has grown in a short time and can show what is possible yet may not be intuitive any more.

Hence I am willing to look into a refactoring of the UI (and maybe underlying funktions if need be).

Yet the question would be: how do we get to a useful UI design? Do we have people with experience here? Do we want to discuss together?

So far I still see three main use cases for the starter:
- manage expansions
- manage savegames
- manage Oolite installations

Mr Gimlet is optional and can help clarify hairy situations or just add entertainment.

Can we already agree on that? If yes we could talk about how to present these use cases and go into details for each of them.

[arquebus]

Because I believe we are philosphically opposed to getting our fingers in other people's OXPs to fix those errors.

Speak for yourself. The people who packaged those older OXPs into OXZs weren't philosophically opposed to "touching other people's stuff". They were just in too much of a rush to check their work.

Much simpler to fix a few dodgy manifest files, where they need fixing, than have a third party application maintaining a master list of (in)compatibilities.

The vague consensus I've vibed from this forum is that folks don't want to tweak other people's stuff directly. New versions with different authorship, yes. New versions treated as if they were by the original author (so they continue to occupy the same slot in the Manager), no. I could be wrong.

[arquebus]

Yet the question would be: how do we get to a useful UI design? Do we have people with experience here?

My only experience has been complaining at indie devs for years and years until they test out my suggestions and discover that yes, I was right all along. Got a pretty good track record on that.

[arquebus]

So far I still see three main use cases for the starter:
- manage expansions
- manage savegames
- manage Oolite installations

I think more in terms of user flow than function, since UI organized by function always falls on its ass.

Here's what I envision. My ideas are certainly not definitive but I think they are a good way to reframe how we think about what the Starter is/is for.

Basic user flow:
* New user downloads Oolite package, readme says to launch Oolite Starter.
* Oolite Starter, never having been opened before on this computer, presents a setup screen that goes through some basic starting options for the new player: 1) vanilla experience, 2) vanilla-plus experience (updated UI stuff mainly), 3) bigger universe experience (a set of OXPs that add richness to the game universe, like market stuff, new station types, new ships, etc)
* Once the player has selected an option, the interface goes to a screen laid out with button functions on the left (start, quit, check for updates, go to OXP management screen, go to game install management screen, go to saves management screen) and the list of currently active OXPs on the right. The stuff on the right is non-interactive - any attempt to do so automatically goes to the OXP management screen.
* The OXP management screen being the most complex portion, it would need to be highly tuned for distinctive visuals: colors, icons, etc. It also needs to hide most of its more advanced functions, accessible only via user selection (by button, to a different screen with more complexity). The basic management layout should allow the new user to do exactly 3 things:

- look at the list of OXPs in the Expansions Manager
- install items from that list
- uninstall items from that list

(I think the basic interface should completely ignore the distinction between "downloaded" and "installed" and drop the "downloaded" status entirely.)

The basic management layout should also behind the scenes validate every action, so that conflicts are addressed *immediately*. The basic user should not have to actively start a validation. If Starter detects a conflict/dependency issue either upon install or uninstall, it should pop up a screen that walks the user through resolving (which should essentially be the user double-acknowledging that they want to do this action). For dependency issues, it should ask the user if s/he wants to remove all dependent OXPs as well. And for conflicts, it should ask the user if s/he wants to swap the conflicting OXPs or keep both.

I could go on, but really, it boils down to UI/UX organized by workflow rather than function. That alone would make Oolite Starter a best-in-class third party mod manager, better than pretty much all other mod managers for all other games.

[hiran]

So far I still see three main use cases for the starter:
- manage expansions
- manage savegames
- manage Oolite installations

I think more in terms of user flow than function, since UI organized by function always falls on its ass.

Here's what I envision. [...]

Without repeating everything, I can already tell I like your vision. We've already seen how an interface organized by function will look like, and I ran short in ideas how to design differently. Your approach seems very efficient for users.

What do others think about this version? And do we have still more ideas?