OoliteStarter

[hiran]

Here is something to look at:
https://github.com/HiranChaudhuri/Oolit ... uxbridge.1

I tried to create components closer to the wireframe V7 without spending too much work. You will have to turn on and off the UI components via the menu. The actual component sizes do not yet matter - they will depend on the window size which is under the user's control.

As a result you can play around with the combinations, and you can even have the old and new interface side by side. Components that deliver same functions have the same border color.

Interested to hear some feedback...

[arquebus]

That's a great start! I have one question from my brief tinker with it: in this version does the installed set change depending on the save selected? I've only ever had one save so I don't even know if the earlier versions did that or not.

[hiran]

That's a great start! I have one question from my brief tinker with it: in this version does the installed set change depending on the save selected? I've only ever had one save so I don't even know if the earlier versions did that or not.

I do not think I clearly understand your question. Let me try to clear this up:
The Expansion Manager allows you to install and uninstall expansions (be it oxz or oxp). I think you refer to the combination of currently installed expansions as the 'installed set'.

The old interface allows to write the names/versions of the expansions in the 'installed set' to a file. This file I call 'expansion set' and the file's extension is 'oolite-es'.

Now either you modified your 'installed set' or you receive an oolite-es file from somewhere else. In both cases the expansions in your installation set and in the file diverge.

When loading a file the old interface would restore the file's content: remove expansions that are installed but not on the file, and install expansions that are in the file but not installed.
This behaviour does not allow to combine expansion sets.

[arquebus]

That's a great start! I have one question from my brief tinker with it: in this version does the installed set change depending on the save selected? I've only ever had one save so I don't even know if the earlier versions did that or not.

I do not think I clearly understand your question. Let me try to clear this up:
The Expansion Manager allows you to install and uninstall expansions (be it oxz or oxp). I think you refer to the combination of currently installed expansions as the 'installed set'.

The old interface allows to write the names/versions of the expansions in the 'installed set' to a file. This file I call 'expansion set' and the file's extension is 'oolite-es'.

Now either you modified your 'installed set' or you receive an oolite-es file from somewhere else. In both cases the expansions in your installation set and in the file diverge.

When loading a file the old interface would restore the file's content: remove expansions that are installed but not on the file, and install expansions that are in the file but not installed.
This behaviour does not allow to combine expansion sets.

What I was thinking of was the idea of having each save in the save game list associated with a particular expansion set. That way you could switch between saves (that are completely different playthroughs) without having to load in an 'oolite-es' set as well (assuming that's how you saved the set in the first place).

I think it's important for the purposes of naming things clearly to distinguish between the things the program recognizes, the things the user needs and how to describe the latter.

Program:
Save games
Expansion Manager list
Downloaded OXPs/OXZs
Expansions in the managed AddOns directory
Expansions in the managed Deactivated AddOns directory
Expansions in the non-managed AddOns directory
Expansions in the non-managed Deactivated AddOns directory
oolite-es Expansion Set

User:
What are my save games?
What is in the list of expansions in Oolite's Expansion Manager, whether active or inactive?
What is the list of expansions that I have downloaded manually and used Starter to install, whether active or inactive?
On the current save game that I am about to play, what expansions (managed and non-managed) are going to be running?
What bundles of expansions can I load in from previously saved collections? (these are the oolite-es expansion sets)

Nomenclature:
Save Game List ("What are my save games?")
Expansion Manager OXP List ("What is the list of expansions in the EM?")
Local OXP List ("What is the list of expansions that I have downloaded manually?")
or: Available OXP List (if the two above lists are combined into one) ("What is the list of expansions available to me, locally or from the Manager?")
Current Expansion Set ("On the current save game that I am about to play, what expansions are going to be running?")
Preset List ("What bundles of expansions can I load in?")

Additionally, users will use the word "installed" to mean "currently in the active expansion directories (managed and non-managed), which will load when I launch the game" They will not use the word "installed" to mean "downloaded."

[arquebus]

At the risk of confusing things further, I think that every save game should be associated with an 'oolite-es' file behind the scenes. So that every time you select a save game, its associated 'oolite-es' file loads into the currently active OXP list. If you change anything in the list, either manually or by loading in an unrelated 'oolite-es' file, the 'oolite-es' file associated with that save gets updated.

It sounds like the way it is now, if you select a save game in Starter with the intention of launching Oolite into that save, you manually have to load an oolite-es file if the currently active set is not the same as the one you were using on that save. And you have to make your own oolite-es files if you're going to be playing with saves that have different active expansions. I'd like to avoid that if possible. It should be seamless, and not require user action.

I've noticed that creating an oolite-es file takes a long time, so perhaps there should be a "Save Current Set to Save Game" button of some kind, so it's not trying to dynamically update the oolite-es file every time you make a change.

[hiran]

At the risk of confusing things further, I think that every save game should be associated with an 'oolite-es' file behind the scenes. So that every time you select a save game, its associated 'oolite-es' file loads into the currently active OXP list. If you change anything in the list, either manually or by loading in an unrelated 'oolite-es' file, the 'oolite-es' file associated with that save gets updated.

Not literally an oolite-es but something like this is in place.

It sounds like the way it is now, if you select a save game in Starter with the intention of launching Oolite into that save, you manually have to load an oolite-es file if the currently active set is not the same as the one you were using on that save. And you have to make your own oolite-es files if you're going to be playing with saves that have different active expansions. I'd like to avoid that if possible. It should be seamless, and not require user action.

You do not have to have the expansion sets but yes they make life more comfortable. Differences between the 'installed set' and a savegame are already detected and displayed. All that is missing is an automatic sync.

I've noticed that creating an oolite-es file takes a long time, so perhaps there should be a "Save Current Set to Save Game" button of some kind, so it's not trying to dynamically update the oolite-es file every time you make a change.

Such a file does not take long for me. How do you know how long it takes actually? What are you measurimg?

I do have a rough idea what is going on behind the scenes, and it is unrelated to the UI we spoke about before. The problem so far is that - while running Oolite - the installed set chan change due to the in game Expansion Manager. When Oolite exits OoliteStarter rescans all expansions. The same that happens when OoliteStarter starts up. You already mentioned that this is taking ages for you. So a speedup here (only update differences) would help more than a fresh UI.

So ultimately we need more information about savegames on the screen, not less. The old UI is definitely more suitable, but we want an automatic way to fix expansion mismatch when resuming a savegame.
That will prevent switching the screens permanantly, and there should be no need to have the expansions functionality besides the Game Start Panel.

But let's discuss functionality - the reason I have not yet automated that:
How shall OoliteStarter fix discrepancies between a savegame and the installed set? Is it hard required to restore the exact same installed set? How can a user add expansions later in a game? What if the exact version of the OXZ is no longer available?

[Nite Owl]

Would it be correct to guess that all of this will be optional in much the same way as using the current in game Expansion Manager is optional. Completely understand the need to have an OXZ acquisition method that makes things as easy as possible for New Players. However, for the slightly more experienced Tweaker and Serial Renaming Types like myself the usual methods of acquisition do not always work to our advantage no matter how easy or sophisticated they are. In such cases nothing beats a simple download from the Wiki (or other file hosting site) that can then be modified to suit one's twisted desires without the need for the end result being recognized by a program other than Oolite itself.

[arquebus]

Would it be correct to guess that all of this will be optional in much the same way as using the current in game Expansion Manager is optional. Completely understand the need to have an OXZ acquisition method that makes things as easy as possible for New Players. However, for the slightly more experienced Tweaker and Serial Renaming Types like myself the usual methods of acquisition do not always work to our advantage no matter how easy or sophisticated they are. In such cases nothing beats a simple download from the Wiki (or other file hosting site) that can then be modified to suit one's twisted desires without the need for the end result being recognized by a program other than Oolite itself.

My hope - from my position in the heckler's cheap seats - is that the Oolite Starter will make it easier to manage those manual downloads and tweaks as well. But if Oolite Starter doesn't "recognize" something you've tweaked it'll probably not ever touch it, so it wouldn't interfere. I personally think that the manual downloading of OXPs (just that itself, not any tweaking) is not-quite-intermediate, late-stage-basic, and belongs on the basic Starter UI. The ability to load in (copy to the non-managed AddOns folder)/delete manual (local) OXPs should stay on that screen.

But, yes, I think we're all agreed that the Starter is technically optional, though my personal preference would be for it to be bundled with future downloads of Oolite, once it's in a finalized/finalizable state. If only because right now the Expansion Manager doesn't work without a manual file edit.

[arquebus]

You do not have to have the expansion sets but yes they make life more comfortable. Differences between the 'installed set' and a savegame are already detected and displayed. All that is missing is an automatic sync.

Ok, great!

Such a file does not take long for me. How do you know how long it takes actually? What are you measuring?

I'm measuring how long it takes for me to have control over the program again. I'm noticing a number of spots where it takes a really long time and the program effectively "freezes":

1) On startup, Oolite Starter can take up to 3 minutes to load (stays at the splash screen the whole time).
2) On refresh, it takes over a minute.
3) On oolite-es creation, it takes over a minute.

During that time I cannot click on anything or interact with the program in any way. I just have to wait.

But let's discuss functionality - the reason I have not yet automated that:
How shall OoliteStarter fix discrepancies between a savegame and the installed set? Is it hard required to restore the exact same installed set? How can a user add expansions later in a game? What if the exact version of the OXZ is no longer available?

There are really two/three major situations where Starter will have to handle changes external to itself:

1) Player starts a new game inside Oolite and changes expansions (or doesn't).
2) Player saves an existing game inside Oolite with a different set of installed expansions.
3) A variation of #1: player saves an existing game under a new name inside Oolite, with a different set of installed expansions.

I think there's a solution that resolves all three. If Starter detects that Oolite has quit, it scans the AddOns directories and the save game directory, and acts as follows:

Case 1: no changes to the save game directory, changes to AddOns directories -> Starter asks player if it should update or discard changes to the currently selected savegame
Case 2: changes to the save game directory, no changes to AddOns directories -> Starter copies the install set list from its currently selected savegame into the data it keeps for the new savegame(s) that it has just detected
Case 3: changes to the save game directory, changes to AddOns directories -> Starter asks the player two questions:

1) The list of installed OXPs has changed. Would you like to update one or more of your savegames with the new list? (Yes/No)
2) If Yes: Which savegame(s) would you like to update with the new list? (Checkbox list, Update button)

Alternatively, Starter could simply apply the list of OXPs in the AddOns directories to any new savegame files, but there's obvious cases where that would be less than ideal. In particular, the following scenario:

1) I load a savegame called "ExampleGame" via Starter into Oolite.
2) I make changes to the installed set using the Expansion Manager.
3) I play for a while.
4) I save the game.
5) I make a backup of the save called "ExampleGame Backup".
6) I quit the game.

At this point, Starter will see that the savegame list has changed, and it can easily assign the current AddOns to that savegame, but it doesn't know that I've actually been playing the original copy with that new set as well. So it needs to ask. Which then leads to:

7) Starter detects a new savegame and a changed AddOns directory.
8 ) "The list of installed OXPs has changed. Would you like to update one or more of your savegames with the new list?"
9) I click "Yes."
10) "Which savegames would you like to update with the new list?"
11) I check "ExampleGame" and "ExampleGame Backup".
12) Starter performs those updates.

[arquebus]

Question:

Can Oolite Starter detect changes at any time? Even while Oolite is running?

I've just thought of an edge case that my above solution doesn't handle.

1) I have ExampleSave and ExampleBackup already.
2) I load up ExampleSave, change the OXPs, save ExampleSave and ExampleBackup.
3) I quit Oolite.
4) Now Starter only knows that I've changed the OXPs to ExampleSave. It's not watching ExampleBackup because that's not the one it loaded.

However, if Starter is able to detect changes (timestamp changes specifically) in the savegame directory at any time, it could update its list of OXPs for those time-changed savegames to whatever is currently in the AddOns directories. It would mean sitting in the background keeping an eye on the save directory.

If it can do that, though, that would be the simplest solution, covering every case including the ones in my previous comment. Basically Starter would watch the save directory for any new or updated savegame files. Every time it detects a timestamp change or new file in the save directory, it would assign the current AddOns directories to that changed/created save.

However, if the player loads a save, changes the OXPs in the Manager and then quits without saving the game, Starter should ask if if the list should be updated for the savegame. This is necessary because of the edge case of A/B testing for issues. When I do A/B testing I don't save the game after each failed test because that would be pointless, but I do want to retain the test set so that I can modify it for the next one. If Starter doesn't ask if I want to update, it would revert the install list to what the savegame normally has, which would make incremental testing over multiple sessions harder.

[arquebus]

Honestly this would all be moot if we could just eliminate the Expansion Manager entirely but I know that's not going to happen. It's actually still necessary for easy A/B testing, since I don't want to have to constantly Alt-Tab out to make changes via Starter.

[hiran]

So far you perceive OoliteStarter as a user, and you are guessing about the internal wiring. You are pretty good, while the truth is still a bit different.

First of all I do not have any doubt about the performance you perceive. The slow part is about updating the status - and this happens on startup as well as when you quit Oolite as well as whenever you press the 'Reload' button. Why so?

OoliteStarter shows status about savegames and expansions (be them installed or available). For this it downloads the expansion catalog and scans the hard drive. The duration depends on the amount of expansions and the speed they can be accessed. I think you had roughly 300 expansions which adds up to the time. Since I never thought about this time I never bothered to make it visible to the user - hence you see a freeze in the UI.

When I programmed it I was happy to have some function. And to ensure OoliteStarter would never show outdated information it would reload it whenever required. On startup that is required - without question. But it is also required whenever you close Oolite. After all you might have used the in-game Expansion Manager to install/upgrade/uninstall expansions and OoliteStarter just does not know. I hope you see the presence of the in-game manager causes impact for OoliteStarter.

Saving the active expansions with a savegame does not cost extra time. There is no oolite-es file that needs to be synced with a savegame. Now we are going into implementation: OoliteStarter installs an OXP into the AddOns folder before running Oolite. This OXP does nothing but wait for the `playerWillSaveGame` event. This will configure a mission variable with the set of active oxps, and the mission variable is part of the savegame file directly. When Oolite exits, OoliteStarter will remove that OXP again so the user does not notice.

To improve scan speed I can imagine several things:
- Reduce the full scan to the absolute minimum (when the user presses 'Reload'), and indicate progress graphically.
- Cache the results as much as possible (which would remove the wait time on startup)
- Perform updates in the OXP list when changes in the filesystem are detected

This is absolutely not UI related but requires some work on the inner bits.

[arquebus]

Saving the active expansions with a savegame does not cost extra time. There is no oolite-es file that needs to be synced with a savegame. Now we are going into implementation: OoliteStarter installs an OXP into the AddOns folder before running Oolite. This OXP does nothing but wait for the `playerWillSaveGame` event. This will configure a mission variable with the set of active oxps, and the mission variable is part of the savegame file directly. When Oolite exits, OoliteStarter will remove that OXP again so the user does not notice.

I love this, it's a very elegant solution. Is that how it works now or is that planned for the future?

To improve scan speed I can imagine several things:
- Reduce the full scan to the absolute minimum (when the user presses 'Reload'), and indicate progress graphically.

A progress indicator would help a lot. People perceive delays with a progress bar to be shorter than the same delay with no progress bar.

[hiran]

OoliteStarter installs an OXP into the AddOns folder before running Oolite. This OXP does nothing but wait for the `playerWillSaveGame` event. This will configure a mission variable with the set of active oxps, and the mission variable is part of the savegame file directly. When Oolite exits, OoliteStarter will remove that OXP again so the user does not notice.

I love this, it's a very elegant solution. Is that how it works now or is that planned for the future?

Take a look at the savegames. It is active already.

To improve scan speed I can imagine several things:
- Reduce the full scan to the absolute minimum (when the user presses 'Reload'), and indicate progress graphically.

A progress indicator would help a lot. People perceive delays with a progress bar to be shorter than the same delay with no progress bar.

Agree. This just did not yet happen.

[hiran]

But let's come back to some rules that we want Oolite games to follow.

It is possible to install Oolite. At that moment we have a vanilla game.
Then users can add expansions to their taste (via expansion sets or one by one - I don't care).
Eventually a user starts the game.

Shall it be possible to add expansions to an already running game? (as in: save the game, go to the expansion manager and install/change stuff, then resume the game) or shall new expansions only become effective for a game to be started fresh?

It would imply that when resuming a game we would enforce the correct set of expansions to be present. Those that were there at the start of the game, and nothing else.

Or shall we enforce the expansions from the game are present and we allow more expansions to be present? This would allow users to enrich their game over time.