Enable Oolite development (2)

[Cholmondely]

Sorry to be a pain, Sir Hiran of the Nexus, but might it be an idea to make the "coloured displays" (Expansions, Conflicts, Incompatible with Selected Oolite version etc) into "buttons" which then sort one's collection of 365,248 OXPs and just display those with conflicts, for example?


Apologies: RL™ has recently precluded doing too much in terms of Mr Gimlet rewriting...

[Cholmondely]

1) On the "about" page you might wish to change " <p>And eventually show gratitude by spending me some drink.</p>"

For example, to: <p>And eventually show some gratitude by buying me a drink.</p>




2) OXPs/OXZs GUI : For OXPs which have no manifest.plist (once an OXP has been clicked on):

This OXP only contains a "requires.plist".
These contain no useful information. Consider adding a "manifest.plist"!

And possibly either a link to https://wiki.alioth.net/index.php/Manifest.plist or to a "Manifest.plist generator" if you write one!




3) OXPs/OXZs GUI:

For the "Filter" box up top: I find the "And contains RE" ".*" confusing. I know you told me what RE means, but I've forgotten the exact terminology, and find it unfamiliar (woes of a dumb pilot).

For the "Expansion Set" box up top: again, confusing. Might renaming it "Manage this "set" of Expansions" be an improvement?

For the "Misc" box up top: perhaps change "Reload" to "Update page"




4) "Oolite Versions GUI": "Saving" alternatives

Well done, kid!
Your configuration is now saved in /Users/accountname/.oolite-starter.conf.
You can now think about what you need for launching.

Your configuration has been stashed away in /Users/accountname/.oolite-starter.conf.
When you are ready to get out of here, kick off by pushing the "Start Game" button up top! But don't forget to visit the F8/8 marketplace first.

All right there!
We've stored your configuration in /Users/accountname/.oolite-starter.conf.
If you are all finished, you can get yourself out of here and get your ship ready to undock.



5) I did not notice a "dumb pilot safety-catch" for the delete option on the "Oolite Versions" GUI for 0.1.18-abukir.2

Kiddo! Are you really really sure that you want to do this?

button: I really really want to!


Great! Getting rid of stuff!! But are you sure?

button: I'm sure!


Too much clutter causes confusion, kid. Its a good choice to cut down the clobber - but do you want to change your mind?

button: No way! Chuck it!





Note: Are there any other Mr Gimlet's which I've missed?

[hiran]

1) On the "about" page you might wish to change " <p>And eventually show gratitude by spending me some drink.</p>"

For example, to: <p>And eventually show some gratitude by buying me a drink.</p>




2) OXPs/OXZs GUI : For OXPs which have no manifest.plist (once an OXP has been clicked on):

This OXP only contains a "requires.plist".
These contain no useful information. Consider adding a "manifest.plist"!

And possibly either a link to https://wiki.alioth.net/index.php/Manifest.plist or to a "Manifest.plist generator" if you write one!




3) OXPs/OXZs GUI:

For the "Filter" box up top: I find the "And contains RE" ".*" confusing. I know you told me what RE means, but I've forgotten the exact terminology, and find it unfamiliar (woes of a dumb pilot).

For the "Expansion Set" box up top: again, confusing. Might renaming it "Manage this "set" of Expansions" be an improvement?

For the "Misc" box up top: perhaps change "Reload" to "Update page"




4) "Oolite Versions GUI": "Saving" alternatives

Well done, kid!
Your configuration is now saved in /Users/accountname/.oolite-starter.conf.
You can now think about what you need for launching.

Your configuration has been stashed away in /Users/accountname/.oolite-starter.conf.
When you are ready to get out of here, kick off by pushing the "Start Game" button up top! But don't forget to visit the F8/8 marketplace first.

All right there!
We've stored your configuration in /Users/accountname/.oolite-starter.conf.
If you are all finished, you can get yourself out of here and get your ship ready to undock.



5) I did not notice a "dumb pilot safety-catch" for the delete option on the "Oolite Versions" GUI for 0.1.18-abukir.2

Kiddo! Are you really really sure that you want to do this?

button: I really really want to!


Great! Getting rid of stuff!! But are you sure?

button: I'm sure!


Too much clutter causes confusion, kid. Its a good choice to cut down the clobber - but do you want to change your mind?

button: No way! Chuck it!





Note: Are there any other Mr Gimlet's which I've missed?

Thank you! I spent some time and took your ideas, even if not always verbatim.
E.g. the dumb pilot safety catch can be misleading:

User presses delete. The question 'Kiddo! Are you really really sure that you want to do this?', answered with 'Yes' will lead to deletion.
BUT
User presses delete. The question 'Too much clutter causes confusion, kid. Its a good choice to cut down the clobber - but do you want to change your mind??', answered with 'No' will lead to deletion.

I would be the first to constantly flinch... nevertheless the next version should be a bit more user friendly.

[hiran]

Sorry to be a pain, Sir Hiran of the Nexus, but might it be an idea to make the "coloured displays" (Expansions, Conflicts, Incompatible with Selected Oolite version etc) into "buttons" which then sort one's collection of 365,248 OXPs and just display those with conflicts, for example?

I caught myself also clicking them - knowing nothing would happen. But your suggestion is a useful addon. Will check how/when to implement it.

Apologies: RL™ has recently precluded doing too much in terms of Mr Gimlet rewriting...

No worries. I had too much going on at that time, too.
But over time we'll get there.

[hiran]

So it looks like what is happening is this: if the Oolite expansion list includes more than one version of an expansion, for whatever reason, Oolite Starter will trigger the "updatable" flag on it because the older version exists in the list. Or something. Because each of these has weird listings in Oolite itself:

Yes, you figured it out. If several expansions have the same ID but different versions, they will become part of this list.
If 'installed' were a criteria, you would never see the alternatives so all of them have to be listed. With that you can not only upgrade but also downgrade.

These might just have to be handled as exceptional cases in Oolite Starter. Something is goofy with the expansion list.

I also agree it may look unusual. Very likely because usually you never get a downgrade offered.
Would it help to make it a requirement that at least one of the group needs to be installed?

[hiran]

The Telescope OXP flags a conflict with the HUDSelector OXP, but the reverse is not true. So when I filter by "problematic" *only* the Telescope OXP shows up. I understand why that happens (because HUDSelector itself doesn't know about Telescope), but that's unexpected behavior for a naive/novice player. As soon as Oolite Starter detects that Telescope lists HUDSelector as a conflict, and then sees that HUDSelector is in the installed list, it should mark HUDSelector in some way so that it appears in the "problematic" list alongside Telescope.

That makes sense. If one OXP cannot be installed parallel to another one, that relationship is mutual. I will think about it.

Now, to the caveat. At least one OXP has an "invalid" list of conflicting OXPs. The OXP oolite.oxp.UK_Eliter.Ferdelance_3G has two conflicts listed in the conflict box:

oolite.oxp.Ferdelance_3G
oolite.oxp.UK_Eliter.Ferdelance_3G

At first I assumed Oolite Starter's behavior was to include the OXP itself in the conflict list, but having checked other conflicts, I discovered that you're not the one that put the second OXP there in that list! The creator of UK_Eliter Ferdelance put his own OXP in the conflict list - basically flagging it as conflicting with itself. Perhaps Oolite Starter should do a quick check to make sure the OXP itself is not listed as self-conflicting. (This may only be an error in this one OXP, though; I haven't checked others.)

That is some strange situation, you are right. Unfortunately we have more than just such discrepancies - I have the OoliteAddonScanner produce an index of Artefacts, running once a month. It emits a lot of warnings. Only few, not to say none of them have been addressed so far.

But coming back to OoliteStarter: It neither can fix faulty expansions, nor should it attempt to do so. It's purpose is to allow easy installation/uninstallation, and by visualizing such a strange situation it already proved it's value.
The fix however needs to be performed in the next version of this OXZ.

I believe Cholmondely is actively mulling over how to maintain existing expansions - be them OXPs or OXZs. And I am with him. Expansions that are out there unmaintained do cause problems after some time. Please have a look at https://bb.oolite.space/viewtopic.php?f=4&t=21386

[hiran]

---delete me---

I believe this is the message I am referring to.

My first reaction to asking for preconfigured sorting was "but what if I want it unsorted?" as there is no way to remove the sorting once set.
Until then OoliteStarter would show expansions in the sequence it obtained from the website.

Meanwhile I believe it is irrelevant. Showing unsorted results because no wish for sorting was expressed is an expert attitude. How should an ordinary user know that sorting is available at all? Now if OoliteStarter sorts on the first column per default, the caret gets visible. And that gives away the secret that sorting is available, even to inexperienced users.

Thus future versions will perform sorting on the first column as a default.

Plus I configured the regex search to be case insensitive, for pretty much the same reason. Though after I found out how that can be reversed again by power users.

[arquebus]

Meanwhile I believe it is irrelevant. Showing unsorted results because no wish for sorting was expressed is an expert attitude. How should an ordinary user know that sorting is available at all?

You could do it as a trinary selector instead of binary. Alpha ascending, alpha descending, unsorted. (The unsorted option would be the third selection from any column.) The default would be alpha ascending (carat showing), but you could get to Unsorted by clicking the header twice.

[arquebus]

But coming back to OoliteStarter: It neither can fix faulty expansions, nor should it attempt to do so. It's purpose is to allow easy installation/uninstallation, and by visualizing such a strange situation it already proved it's value.
The fix however needs to be performed in the next version of this OXZ.

That's fair!

[hiran]

Meanwhile I believe it is irrelevant. Showing unsorted results because no wish for sorting was expressed is an expert attitude. How should an ordinary user know that sorting is available at all?

You could do it as a trinary selector instead of binary. Alpha ascending, alpha descending, unsorted. (The unsorted option would be the third selection from any column.) The default would be alpha ascending (carat showing), but you could get to Unsorted by clicking the header twice.

Might be good from a user perspective. Java Swing does not offer it out of the box, so I will not go for it.

[hiran]

The Telescope OXP flags a conflict with the HUDSelector OXP, but the reverse is not true. So when I filter by "problematic" *only* the Telescope OXP shows up. I understand why that happens (because HUDSelector itself doesn't know about Telescope), but that's unexpected behavior for a naive/novice player. As soon as Oolite Starter detects that Telescope lists HUDSelector as a conflict, and then sees that HUDSelector is in the installed list, it should mark HUDSelector in some way so that it appears in the "problematic" list alongside Telescope.

That makes sense. If one OXP cannot be installed parallel to another one, that relationship is mutual. I will think about it.

Let's take another attempt. Each OXP has relationships to other OXPs in it's a manifest (the list may be empty and still valid):
Required, Conflict, Optional

So far these three lists are just displayed verbatim, but their semantic meaning is more than that:
Any OXP that requires another means the other one is required.
Any OXP that conflicts with another OXP means the other OXP would also conflict with this one.
Any OXP that optionally lists another one means these two work well together - one supports the other.

As putting all that into text might get complicated to read and understand, I am now thinking whether a graphical representation might help.
How about something like this? And would it be complete?



Such a display could allow us to perform browsing. If you identify some OXP is missing, click it to navigate to the details and get the install button.
Or a context menu with shortcuts to Install, Delete, Enable and Disable buttons.

[phkb]

I gave the Oolite Starter a spin on a VM (I can't install on my main machine due to corporate lockdowns).

It didn't immediately recognise that I had Oolite installed in the default location of C:\Oolite. I had to manually add it. I tried the "Scan" function, which could be sped up significantly by ignoring certain locations (eg C:\Windows, network shares)

However, the bigger issue was that it didn't recognise the structure I'd put into all my addons. I've created a series of subfolders inside my AddOns folder, that looks like this:

Code: Select all

c:\Oolite
	\AddOns
		\Activities.oxp
		\Ambience.oxp
		\Equipment.oxp
		... etc ...

Each one of those sub folders has a manifest.plist file, so Oolite just considers them as standard OXP's. But, while Oolite will search all the subfolders and find all the OXP's inside, Oolite Starter assumes they're all at the Addons folder level. And for a lot of players that would make sense. But given the amount of development work I do on the game itself and (one or two) OXP's, I need that structure to keep everything sorted in my head, as well as my code window.

I'm not sure if this is worth fixing, because, as mentioned, most players wouldn't have gone to these lengths themselves, and I'm probably not one of the target users for this. However, it is a notable limitation between what OoliteStarter can handle as compared to the game itself.

[hiran]

I gave the Oolite Starter a spin on a VM (I can't install on my main machine due to corporate lockdowns).

Thank you so much. I feel very proud right now.

It didn't immediately recognise that I had Oolite installed in the default location of C:\Oolite. I had to manually add it. I tried the "Scan" function, which could be sped up significantly by ignoring certain locations (eg C:\Windows, network shares)

Well-known places are now scanned first. That should give you ligntning speed for a standard setup, while the full scan is still supported.
But you do not have to wait until it is finished.

However, the bigger issue was that it didn't recognise the structure I'd put into all my addons. I've created a series of subfolders inside my AddOns folder, that looks like this:

Code: Select all

c:\Oolite
	\AddOns
		\Activities.oxp
		\Ambience.oxp
		\Equipment.oxp
		... etc ...

Each one of those sub folders has a manifest.plist file, so Oolite just considers them as standard OXP's. But, while Oolite will search all the subfolders and find all the OXP's inside, Oolite Starter assumes they're all at the Addons folder level. And for a lot of players that would make sense. But given the amount of development work I do on the game itself and (one or two) OXP's, I need that structure to keep everything sorted in my head, as well as my code window.

I'm not sure if this is worth fixing, because, as mentioned, most players wouldn't have gone to these lengths themselves, and I'm probably not one of the target users for this. However, it is a notable limitation between what OoliteStarter can handle as compared to the game itself.

That is a surprise to me. When I investigated whether the Addons folder is a flat or recursive structure somehow I figured out it is flat.
But it seems I was wrong there. While you may be the one user with need for such a feature, the amount of OXPs you are juggling is massive, and I would not like OoliteStarter to force you into a flat model. That would presumably a desaster, although...

Just thinking: It seems you ended up creating folders for categories. And you dropped every OXP into one of them, which means they all have exactly one main category. Did you notice OoliteStarter can sort OXPs based on their categories? Maybe that would be good enough for you to keep an overview?

No promise, but could you give me an example structure (a mini-version of your Addons-folder, just a couple of addons that show the structure) and I will take a look? Also let me know how you would expect OoliteStarter to behave. Are the category folders expansions? Are the expansions inside expansions? How many levels of recursion should we account for? What should happen if the buttons Disable/Enable/Delete are pressed?

[phkb]

Maybe that would be good enough for you to keep an overview?

It might be sufficient for some versions of the game I keep for testing. I don't have every OXP I use in every environment, so it might work for those. But for my main installation, it wouldn't work. I spend most of my time in a code window (using VS Code), and it keeps the folder structure in a window for me, so I can quickly collapse or expand whatever section I'm working on to quickly find what I need.

As for the folder depth, mostly it's just two deep - the main category, and then the OXP's. Except for Ships, where I've added another layer for the author (eg: Ace, Griff, KillerWolf, etc).

What I would expect is for the app to honour my folder structure. If I told it to disable an expansion, it would turn it off, and the put it back in the same spot if I asked it to turn it back on. In some ways, I think you're working too hard by actually moving folders/files into different folders. A simple rename, adding ".hide" or ".disabled" to the OXP folder or OXZ file would disable the AddOn quite effectively, with no chance that files could get lost in the move. Plus, it would be much easier to keep the users desired folder structure, because you don't have to remember where everything was to start with.

With that out of the way, here's some more feedback on the app so far.

I get an “Error” when I select “C:\Oolite” as the home folder for an Oolite installation. That should work as that is the folder used when Oolite is installed. It should be able to work out that there is an oolite.app folder in the one I selected and go from there. At the very least, the unhelpful "Error" dialog box should be given a more descriptive reason as to why it was an error.

Once the correct folder is selected, it continues.

Nice to have: right-click context menu on the different Oolite installations with “Select/Edit/Delete” options.

If you only have one installation, it should auto-select it when you go to the OXPs/OXZs tab. At the very least, you should get a message when you go to the Addons tab that you haven’t selected an Oolite installation to work with.

(As an aside, using “OXPs/OXZs” is rather unnecessary. No one needs to know the extensions – just call it “AddOns”, which is much clearer. I’m going to do that from here on.)

Once you have selected an installation and go to the AddOns tab, there is no visual cue about what installation you are working with. I’d suggest putting something above the “Filter” and “Expansion Set” groups, something like “Current installation: C:\…”. It could then be highlighted if the user comes to this page without selecting an installation. You should have the same piece of info on the "Start Game" tab.

Concerning the order of the tabs: The logical flow of the process is (1) Enter your installation(s), (2) Select your AddOns, and then (3) Launch Game. I think it would make more sense to put the tabs in that order.

Moving on to the expansion list, there is no need to have the Identifier in the grid - it's really only used internally. You could have it on the details side if you really want, but that is a confusing piece of information to have as the very first column in the grid. The title should be the first column. If users really want the identifier, make it an option somewhere.

The “Date” column is problematic. The format works well for sorting, but not for reading. Ideally a localised date format would make more sense. And is the time value important? I don’t think it’s completely relevant to anything to do with AddOns, so you could probably strip this back to to just the date.

I found the Status column confusing: It took me a little while to work out what the letters were referring to. I think, if the identifier column was removed, it might be possible to have 5 extra columns with just a checkbox in them for each of the different statuses.

There is also a need to have some tooltips on functions. For instance, what does “Reload” (on the AddOns page) actually do? What does “Reload”
do on the “Start Game” page? Tooltips will help users navigate the app without needing a guide.

The two chevrons to the right of the header row of the grid are (a) too small to use, and (b) not really required. You already have the slider so users can adjust the screen as required, but being able to fill the screen with one side or the other feels unnecessarily complicated. But maybe that’s just me.

Anyway, that's all for now.

[hiran]

Maybe that would be good enough for you to keep an overview?

It might be sufficient for some versions of the game I keep for testing. I don't have every OXP I use in every environment, so it might work for those. But for my main installation, it wouldn't work. I spend most of my time in a code window (using VS Code), and it keeps the folder structure in a window for me, so I can quickly collapse or expand whatever section I'm working on to quickly find what I need.

Fair enough. Let's work on that. Seems you do test different sets of addons on different versions of Oolte - juggling that is what I intended OoliteStarter to support.

As for the folder depth, mostly it's just two deep - the main category, and then the OXP's. Except for Ships, where I've added another layer for the author (eg: Ace, Griff, KillerWolf, etc).

What I would expect is for the app to honour my folder structure. If I told it to disable an expansion, it would turn it off, and the put it back in the same spot if I asked it to turn it back on. In some ways, I think you're working too hard by actually moving folders/files into different folders. A simple rename, adding ".hide" or ".disabled" to the OXP folder or OXZ file would disable the AddOn quite effectively, with no chance that files could get lost in the move. Plus, it would be much easier to keep the users desired folder structure, because you don't have to remember where everything was to start with.

So actually the depth is undefined, but it sounds the intermediate folders are just folders - no functionality expected on that level.
Do I understand correctly that these folder names end on .oxp and they have a manifest.plist file? How would I then distinguish an ordinary addon from such a folder?

Renaming a folder is indeed much easier and I would not have to recreate a similar directory structure elsewhere. I wish I had that information beforehand and will think about it.

With that out of the way, here's some more feedback on the app so far.

I get an “Error” when I select “C:\Oolite” as the home folder for an Oolite installation. That should work as that is the folder used when Oolite is installed. It should be able to work out that there is an oolite.app folder in the one I selected and go from there. At the very least, the unhelpful "Error" dialog box should be given a more descriptive reason as to why it was an error.

Once the correct folder is selected, it continues.

Could you give me a screenshot? Or maybe even the logfile (it resides in $HOME/.Oolite/Logs/oolite-starter.log).

Nice to have: right-click context menu on the different Oolite installations with “Select/Edit/Delete” options.

One of them could be a doubleclick even. Good idea!

If you only have one installation, it should auto-select it when you go to the OXPs/OXZs tab. At the very least, you should get a message when you go to the Addons tab that you haven’t selected an Oolite installation to work with.

When I thought about auto-selecting the first version that is added, I noticed some folders would get created straight away. That was a bit too much for my taste. But if I do not need additional folders because addons just get renamed this is in reach again.

(As an aside, using “OXPs/OXZs” is rather unnecessary. No one needs to know the extensions – just call it “AddOns”, which is much clearer. I’m going to do that from here on.)

Maybe we want to create a homogenous naming throughout development, the user interface and the wiki. Users will start using those terms and we can communicate more efficiently.

Once you have selected an installation and go to the AddOns tab, there is no visual cue about what installation you are working with. I’d suggest putting something above the “Filter” and “Expansion Set” groups, something like “Current installation: C:\…”. It could then be highlighted if the user comes to this page without selecting an installation. You should have the same piece of info on the "Start Game" tab.

Did you notice the window title? It is visible from all tabs - even from the taskbar.

Concerning the order of the tabs: The logical flow of the process is (1) Enter your installation(s), (2) Select your AddOns, and then (3) Launch Game. I think it would make more sense to put the tabs in that order.

That was the original sequence when I developed OoliteStarter. Until I noticed that when using the software you need to add versions once, change addons once in a while but always use the Start Game panel. And I switched. So which is 'better'?

Moving on to the expansion list, there is no need to have the Identifier in the grid - it's really only used internally. You could have it on the details side if you really want, but that is a confusing piece of information to have as the very first column in the grid. The title should be the first column. If users really want the identifier, make it an option somewhere.

Interestingly I base most of my decisions on the identifier. Probably because that is the name that I also see in relationships.
Probably the UI should completely hide the internal IDs, which justifies again my suggestion in https://bb.oolite.space/viewtopic.php?p=290453#p290453.

The “Date” column is problematic. The format works well for sorting, but not for reading. Ideally a localised date format would make more sense. And is the time value important? I don’t think it’s completely relevant to anything to do with AddOns, so you could probably strip this back to to just the date.

So far I did not care about the format at all - hence it is very technical. Yes, it should be more user friendly.

I found the Status column confusing: It took me a little while to work out what the letters were referring to. I think, if the identifier column was removed, it might be possible to have 5 extra columns with just a checkbox in them for each of the different statuses.

Again a relict from the early days that went in for testing and never got removed/replaced. Five columns with checkboxes? Let's see what we can use instead.

There is also a need to have some tooltips on functions. For instance, what does “Reload” (on the AddOns page) actually do? What does “Reload”
do on the “Start Game” page? Tooltips will help users navigate the app without needing a guide.

Point taken
The reload buttons will throw away the data OoliteStarter has and loads it fresh - much like a web browser:

On the addons tab information about existing addons is thrown away, the list of addons is retrieved from https://oolite.space as well as from the folders on disk.

On the savegame tab information about existing savegames is thrown away, the list of savegames is retrieved from disk again.

This automatically happens after OoliteStartup, and whenever OoliteStarter notices that Oolite terminated. A manual trigger is necessary if you modify the filesystem yourself. Meanwhile I am thinking of registering for filesystem changes that could eliminate the button completely.

The two chevrons to the right of the header row of the grid are (a) too small to use, and (b) not really required. You already have the slider so users can adjust the screen as required, but being able to fill the screen with one side or the other feels unnecessarily complicated. But maybe that’s just me.

The two chevrons' functionality is not required indeed. I never use them myself.
But I decided to have them there as a visual clue that the panels can be resized. It may help the occasional user.

Anyway, that's all for now.

It was a lot. Thank you for taking the time.