Enable Oolite development (2)

[Redspear]

A relatively easy, 'quick win' might be to rethink the screenshots on the oolite.space site.

Rather than just a showcase (the value of which I don't wish to belittle), it could also be a reference.

So, perhaps some links to HUD images, planet texture possibilities, non standard ships; all in close up/detail rather than combination/cinematic composition. I'm not imagining just more images but also being able to go to the sight and select a category to see what's on offer.

Similar is done with regards HUDs on the Wiki but what I'm suggesting wouldn't require the same amount of text and wouldn't require visiting another site, the link to which may have been missed or seem superfluous to the person just wanting to give the game a 'quick' try.

[cim]

The more I consider it, the more I think that the simplest and least radical answer might actually be in a revamp of the Expansions Manager. Specifically, an addition to the category list such that there would be a "bundle" or "preset" category that sorts to the top, where all of the multi-OXP-loading OXPs would sit. They would appear right at the top. Then, we could build different "Alt-lites" using those bundle OXPs, in the style of the ones that already exist, but designed minimally and specifically for new player onboarding.

The game itself doesn't define categories, and sorts the existing ones alphabetically, so all you need to do is think of a synonym for "bundle" that begins with an A (or an _ if you're desperate) and start using it as a category. The manager page on the website would need updating to know about it so that you could get that category into the manifests list, but the game itself wouldn't.

Or you could make up a category with a less contrived name than "A Bundle" and make a minor patch to the expansion manager's sorting to put it at the top.

Other aspects of the EM would need to be updated as well. Not specifically to serve the above idea but to clean up some things that the EM currently doesn't do in the most obvious or expected way. For example, there should be filters for a) all OXPs, b) installed only, c) not installed only, d) needs updating only, e) whatever other filter concepts we might want to add. There should also be a way to get a top level list of the categories so you can select only the category you want to look at. (Right now getting to the ships OXPs is a bit of a process.)

Currently available filters are:
- all
- installed and can be updated
- not yet installed
- keyword search (searches title, description and category, so you can do a keyword search on "ship" and you'll get most of what you want)
- author search
- tag search
- age search (last updated in X days)
(there isn't one for "installed, whether or not it can be updated", but that would be an easy addition for someone wanting to learn core game coding)

The means for *setting* the filter aren't ideal (or, apparently, obvious - the default keybind is "f" while in the manager) but the filtering itself is already possible.


The wider problem is that the text UI engine for Oolite is designed for producing text displays of the sort found in the original Elite. I had to extend it a fair bit to get the expansion manager to work at all, and it's running pretty much at the limits of what's possible already. If you want better non-viewscreen UIs someone is going to have to write a new UI engine that supports them first. It'd obviously have benefits to OXP writing as well - though you'd need to keep support mission.runScreen()'s access to the current text UI for compatibility.

Do we have anyone capable of programming Objective-C?

The answer to this is almost certainly no - it's a pretty obscure language, especially nowadays. However, anyone capable of programming C or C++ should be able to figure out how the differences work pretty quickly by reading a bit of existing code, and anyone capable of programming other C-like languages shouldn't be much behind. The memory management is different to what you might be used to from C / Java / C# / PHP but doesn't take that much learning. Don't let not knowing Objective-C specifically stop you trying.

[Cholmondely]

A relatively easy, 'quick win' might be to rethink the screenshots on the oolite.space site.

Rather than just a showcase (the value of which I don't wish to belittle), it could also be a reference.

So, perhaps some links to HUD images, planet texture possibilities, non standard ships; all in close up/detail rather than combination/cinematic composition. I'm not imagining just more images but also being able to go to the sight and select a category to see what's on offer.

Similar is done with regards HUDs on the Wiki but what I'm suggesting wouldn't require the same amount of text and wouldn't require visiting another site, the link to which may have been missed or seem superfluous to the person just wanting to give the game a 'quick' try.

Agreed.

How about mixes of the following?

HUDs: Vimana, Dangerous, Deeper Space, Steampunk, Sniper System, Xenon, Z-Groovy MilHUD, one of the KW's Docked HUDs

Ships: (I'm no expert here) Odyssey, a long Imperial Tanker/Freighter, Andromeda, Emerald Liner, Navy Light Destroyer

A Galactic Navy (Facelift) shot (without station, I think)

Stations: Hathor, Nephthys, Torus, Trader OutPost, Superhub, Lave Academy, Mining Outpost, Salvage Gang, Tetrahedron Depot, Tionisla Chronicle Array

Skies: Zygo-Ugo's Nebulae, Glowroids, Griff's Icesteroids, Griff's Asteroids

Planet Textures: FPO Lave, FPO Vetitice, BPlanets Onrira, Povray Iona, Povray Larais, Povray Qutiri

I'm just trying to select stuff which looks the best. Criticism needed!

[hiran]

[...]
The wider problem is that the text UI engine for Oolite is designed for producing text displays of the sort found in the original Elite. I had to extend it a fair bit to get the expansion manager to work at all, and it's running pretty much at the limits of what's possible already. If you want better non-viewscreen UIs someone is going to have to write a new UI engine that supports them first. It'd obviously have benefits to OXP writing as well - though you'd need to keep support mission.runScreen()'s access to the current text UI for compatibility.

Yes, this is the issue and I would not blame anyone for that. Oolite was wanted to behave that way, this goal was achieved and it is ok.
Just for some of the menus I'd like to have a different UI, and I totally understand that with the current technology this will be difficult to achieve.

Do we have anyone capable of programming Objective-C?

The answer to this is almost certainly no - it's a pretty obscure language, especially nowadays. However, anyone capable of programming C or C++ should be able to figure out how the differences work pretty quickly by reading a bit of existing code, and anyone capable of programming other C-like languages shouldn't be much behind. The memory management is different to what you might be used to from C / Java / C# / PHP but doesn't take that much learning. Don't let not knowing Objective-C specifically stop you trying.

An obscure language, and learning that just for one leisure time project does not show any value. Even if I learned it I would be exposed to the above limitations. Hence my thoughts are going another direction.

For example, there is no need for the expansion manager to stay in-game. We can create another executable that shows a UI which allows to install/remove/activate/deactivate expansions, then launch the original game. In a far future it could allow several versions of the game to be installed in parallel and you choose which savegame/OXP combination/Oolite version to launch.

This would not yet resolve other in-game UIs like the station menu, but it would allow us to break free and revamp the expansion manager with features mentioned in this thread.

[arquebus]

For example, there is no need for the expansion manager to stay in-game. We can create another executable that shows a UI which allows to install/remove/activate/deactivate expansions, then launch the original game. In a far future it could allow several versions of the game to be installed in parallel and you choose which savegame/OXP combination/Oolite version to launch.

I think this is a fantastic idea. There are a few things that an externalized manager could potentially do that would revolutionize how players interact with the OXPs:

1) Basic OXP management as in the current method but with extra, fast-acting filters and a scrollable list
2) Ability to maintain multiple OXP sets

which leads me to:

3) Ability to save OXP sets as a file that the externalized manager can read in, making it so that players can create and share their own mod sets. The externalized manager could include the "new player start" mod sets by default but I could, for example, post a link to the mod set that I use in my YouTube playthrough so that other players could try out a game that looks/feels like mine. These could show up on the wiki under their own category. This would also relieve some analysis paralysis pressure on people deciding what should be included in a "new player start" mod set. Don't like the new player start mod set? Make your own, link it on the wiki, promote your alternative.

[hiran]

3) Ability to save OXP sets as a file that the externalized manager can read in, making it so that players can create and share their own mod sets. The externalized manager could include the "new player start" mod sets by default but I could, for example, post a link to the mod set that I use in my YouTube playthrough so that other players could try out a game that looks/feels like mine. These could show up on the wiki under their own category. This would also relieve some analysis paralysis pressure on people deciding what should be included in a "new player start" mod set. Don't like the new player start mod set? Make your own, link it on the wiki, promote your alternative.

I like that idea!
And such a expansion set would also come handy for developers if they be contained in bug reports.

It is some early draft - but who wants to try?
https://github.com/HiranChaudhuri/Oolit ... r/releases

[hiran]

3) Ability to save OXP sets as a file that the externalized manager can read in, making it so that players can create and share their own mod sets. The externalized manager could include the "new player start" mod sets by default but I could, for example, post a link to the mod set that I use in my YouTube playthrough so that other players could try out a game that looks/feels like mine. These could show up on the wiki under their own category. This would also relieve some analysis paralysis pressure on people deciding what should be included in a "new player start" mod set. Don't like the new player start mod set? Make your own, link it on the wiki, promote your alternative.

I like that idea!
And such a expansion set would also come handy for developers if they be contained in bug reports.

It is some early draft - but who wants to try?
https://github.com/HiranChaudhuri/Oolit ... r/releases

Here we have proof that the in-game expansion manager did not amuse all players.
https://bb.oolite.space/viewtopic.php?f=2&t=19493

But we may still need to talk about how installing some expansion set should be done:

- A user would create some combination of expanions and decide to store or export that. The result is some file on disk.
- Another user would decide to import such a file, and then what? Would all his existing OXPs be deleted? Would the new ones just be loaded in addition? Shall such behaviour be configurable?

I assume we'll start with simple steps. It means a fixed set of expansions can be transferred from one user to another. So no merging - expansions active here shall get active there. Missing expansions need to be marked up and eventually downloaded. Those that are too many will simply be moved to another directory (=deactivated).

[Alnivel]

Here we have proof that the in-game expansion manager did not amuse all players.
https://bb.oolite.space/viewtopic.php?f=2&t=19493

But we may still need to talk about how installing some expansion set should be done:

- A user would create some combination of expanions and decide to store or export that. The result is some file on disk.
- Another user would decide to import such a file, and then what? Would all his existing OXPs be deleted? Would the new ones just be loaded in addition? Shall such behaviour be configurable?

I assume we'll start with simple steps. It means a fixed set of expansions can be transferred from one user to another. So no merging - expansions active here shall get active there. Missing expansions need to be marked up and eventually downloaded. Those that are too many will simply be moved to another directory (=deactivated).

Have you decided how the switching of extensions will be organized?

Will there be just a list of oxps each one can be toggled separately, as is now?
Or the sets inside the starter and only one of them can be active at a time?
Or the sets that will be possible to turn on-off individually?

I would prefer the second option and upon import to have a choice, add it as a new set or add it to the active set.
This will allow creating both complete sets that have everything you need according to the author's vision, as well as partial sets to expand the first ones.


Also, I've tried your OoliteStarter v0.1.2, and in the terminal output, I got a bunch of exceptions and warns, mostly about manifest parsing, but the app functionality still works fine.
The default configuration doesn't work for me, the launcher couldn't find the game executable, but it was able to find my saves and oxps. I managed to make it work with the config file, however not as "configuration.properties", but as "oolite-starter.properties".

[hiran]

Thank you for the feedback!

But we may still need to talk about how installing some expansion set should be done:

- A user would create some combination of expanions and decide to store or export that. The result is some file on disk.
- Another user would decide to import such a file, and then what? Would all his existing OXPs be deleted? Would the new ones just be loaded in addition? Shall such behaviour be configurable?

I assume we'll start with simple steps. It means a fixed set of expansions can be transferred from one user to another. So no merging - expansions active here shall get active there. Missing expansions need to be marked up and eventually downloaded. Those that are too many will simply be moved to another directory (=deactivated).

Have you decided how the switching of extensions will be organized?

Not finally. I decided to approach the situation by first creating an 'export' function. Which means you can store the current combination on disk.
There may be a problem if someone has an expansion on disk that does not have a download URL. If we transport such a file to someone else, where would this someone else get the expansion from?

But as a first, we can export the used OXPs and assume we have download links.

Will there be just a list of oxps each one can be toggled separately, as is now?
Or the sets inside the starter and only one of them can be active at a time?
Or the sets that will be possible to turn on-off individually?

I would prefer the second option and upon import to have a choice, add it as a new set or add it to the active set.
This will allow creating both complete sets that have everything you need according to the author's vision, as well as partial sets to expand the first ones.

Seems my current approach is from a developer perspective. Your's from a user, and I think it is valid.
I'll try to create some basic code first, but the UI may need to turn upside-down later.
Anyway I'd appreciate help for designing the UI. Apart from functionality we may want to add some style, similar to the website.

Also, I've tried your OoliteStarter v0.1.2, and in the terminal output, I got a bunch of exceptions and warns, mostly about manifest parsing, but the app functionality still works fine.
The default configuration doesn't work for me, the launcher couldn't find the game executable, but it was able to find my saves and oxps. I managed to make it work with the config file, however not as "configuration.properties", but as "oolite-starter.properties".

Ha, some late change and not consistent. I updated the documentation for that. Thanks for spotting.

The exceptions come in since the Oolite-Starter is not based on a single URL like the builtin Expansion Manager. Instead, it tries to download the expansions list both from oolite.org and oolite.space. Obviously the first one fails and gives an exception which is not critical at this point.

The other exception comes since the OXPs on the Expansion Manger list do not always come with good values. My other project, the OoliteAddonScanner scans all the addons and creates an index of artifacts (all expansions, all ships, all equipment, ...) and already warns about inconsistences. We just never fixed them.

Rather than hiding I prefer to have something like that logged at least on the console. But as you said, they seem not critical right now. But I should ensure they are not logged with 'ERROR' priority.

[arquebus]

- A user would create some combination of expanions and decide to store or export that. The result is some file on disk.
- Another user would decide to import such a file, and then what? Would all his existing OXPs be deleted? Would the new ones just be loaded in addition? Shall such behaviour be configurable?

I assume we'll start with simple steps. It means a fixed set of expansions can be transferred from one user to another. So no merging - expansions active here shall get active there. Missing expansions need to be marked up and eventually downloaded. Those that are too many will simply be moved to another directory (=deactivated).

I think the expansions themselves should not be transferred; only the list of what they are. The expansions themselves would be downloaded via the manager, and if there are version differences, the user will be notified. The same with expansions not installed by the manager - the user would be notified that there are missing elements.

And I agree at the start there should be no under-the-hood merging of expansion lists. At most you should be able to have multiple lists loaded at the same time, with errors thrown for mismatching/not-quite-duplicating OXP versions, etc., but I don't think that should be the default behavior. It's less intuitive as a management method.

Edit: I probably misinterpreted your wording, so ignore my first paragraph!

[hiran]

- A user would create some combination of expanions and decide to store or export that. The result is some file on disk.
- Another user would decide to import such a file, and then what? Would all his existing OXPs be deleted? Would the new ones just be loaded in addition? Shall such behaviour be configurable?

I assume we'll start with simple steps. It means a fixed set of expansions can be transferred from one user to another. So no merging - expansions active here shall get active there. Missing expansions need to be marked up and eventually downloaded. Those that are too many will simply be moved to another directory (=deactivated).

I think the expansions themselves should not be transferred; only the list of what they are. The expansions themselves would be downloaded via the manager, and if there are version differences, the user will be notified. The same with expansions not installed by the manager - the user would be notified that there are missing elements.

Sounds reasonable. Then I will not bother with expansions without download URLs - but we keep the user informed.
This is not yet perfect in my first releases, but let's get there.

And I agree at the start there should be no under-the-hood merging of expansion lists. At most you should be able to have multiple lists loaded at the same time, with errors thrown for mismatching/not-quite-duplicating OXP versions, etc., but I don't think that should be the default behavior. It's less intuitive as a management method.

Yes. Keep it understandable, otherwise users will not trust the code. And me neither.

Edit: I probably misinterpreted your wording, so ignore my first paragraph!

No worries. Your comment matched, and I share your line of thought.

In version 0.1.3 I added filtering of expansions. Just be aware where you enter arbitrary text I chose to use regular expressions. Those who know them will like it. Others should simply know that it is much more powerful than a plain string search. But this may fall due to 'keep it understandable' paradigm. Let's see.
In version 0.1.4 I am trying to add the expansion set handling.

For both filtering and expansion sets I'd like what you guys think.

[arquebus]

Sorry, I'm a little confused - the OoliteStarter link https://github.com/HiranChaudhuri/Oolit ... r/releases has headers mentioning OoliteAddonScanner, but I'm pretty sure the links there are to the OoliteStarter...?

[hiran]

Sorry, I'm a little confused - the OoliteStarter link https://github.com/HiranChaudhuri/Oolit ... r/releases has headers mentioning OoliteAddonScanner, but I'm pretty sure the links there are to the OoliteStarter...?

Where was my mind when my fingers typed the build script? You are dead right to be confused.
But it is just the title (the assets carry the correct name), and I fixed it.

Thanks for spotting.

[Cholmondely]

Just thinking about this. I'm sure that I'm not a typical Ooliter, but I do have a large number of nonstandard OXPs in my folders.

For some it is versions not found on the Expansions Manager (Tsoj's BGS version, GearsNSuch's newest version of Commies, etc: these alter the graphics and not the gameplay. But Alnivel's fix for Stranger's World does alter the gameplay. As does IronAss Lave and the other ship-adding OXPs in Murgh's IronAss suite.)

There are another group which I have personally tweaked (Thanks, NiteOwl!). Adding in Fast Docking to Liners and to the various OXP stations in Commies, etc.). Or my mangling of RedSpear's Weapon Laws.

Is this important? Or a sufficiently rare occurrence that it need not be bothered considering?

[hiran]

Just thinking about this. I'm sure that I'm not a typical Ooliter, but I do have a large number of nonstandard OXPs in my folders.

For some it is versions not found on the Expansions Manager (Tsoj's BGS version, GearsNSuch's newest version of Commies, etc: these alter the graphics and not the gameplay. But Alnivel's fix for Stranger's World does alter the gameplay. As does IronAss Lave and the other ship-adding OXPs in Murgh's IronAss suite.)

As long as these OXPs carry unique identifier/version combinations and reside in unique directories there should not be an issue.
My code does not delete any expansion - unless you click the remove button.

But you probably do not want to take the risk to loose any of those expansions, and you do not want to take the risk of my code having bugs. After all it is in an early stage right now.
In your case I'd do a backup copy of your OXP folder (that is, both the Oolite/AddOns and the ManagedAddons folders. Having such a copy might be wise anyway in case your computer crashes. After that you are free to go and test the OoliteStarter, play around, learn the behaviour and build trust. And I am looking forward to hearing your feedback.

There are another group which I have personally tweaked (Thanks, NiteOwl!). Adding in Fast Docking to Liners and to the various OXP stations in Commies, etc.). Or my mangling of RedSpear's Weapon Laws.

Is this important? Or a sufficiently rare occurrence that it need not be bothered considering?

Again, as long as the identifier/version is distinguishable from other expansions there should not be a problem with OoliteStarter.