Oolite Flavours

[Redspear]

Would this be relevant?

• Time Saver or Ain't Got All God Damn Day Flavour
  •  Indestructible Injectors
  •  Masslock Reimagined
  •  Power To Engines
  •  Traffic Redistributer

[hiran]

Would this be relevant?

• Time Saver or Ain't Got All God Damn Day Flavour
  •  Indestructible Injectors
  •  Masslock Reimagined
  •  Power To Engines
  •  Traffic Redistributer

Meaningful stuff

@Cholmondely could you comment on the above? You seem to know each and every OXP and how it would match/tweak the gameplay...

[phkb]

Those four mods are all dealing with some aspect of the issue of long, boring trips from the witchpoint to the station.
- Indestructible Injectors does what it says on the tin: injectors can’t be damaged.
- Masslock Reimagined changes how masslocks work, reducing time spent mass locked by ships
- power to engines gives a speed boost to engines when weapons are offline.
- Traffic Redistributor changes top speeds of certain ships to again reduce mass lock time.

[hiran]

Sounds like they are a good set to speed up an existing game. But having those four exclusively (that's what a flavour is at the moment) would have little meaning I guess.

[Redspear]

Those four mods are all dealing with some aspect of the issue of long, boring trips from the witchpoint to the station.

True.

- Indestructible Injectors does what it says on the tin: injectors can’t be damaged.
- Masslock Reimagined changes how masslocks work, reducing time spent mass locked by ships
- power to engines gives a speed boost to engines when weapons are offline.
- Traffic Redistributor changes top speeds of certain ships to again reduce mass lock time.

...close enough.

Traffic Redistributer is now more about making the slower ships more common in the safer systems.

Sounds like they are a good set to speed up an existing game. But having those four exclusively (that's what a flavour is at the moment) would have little meaning I guess.

Depends on your definition of a flavour. For some this combination could turn the game from unplayably slow to reasonably well paced, which would have quite big meaning I'd have thought.

In my case (as author) oolite is NOT unplayably slow HOWEVER after my first few hours of playing it was the number one turn off to returning to the game. In fact if it wasn't for the mods (others and the prospect of eventually creating my own) then I'm not sure that I would have.

So 'little meaning' I'd disagree with but 'little flavour' is up to others to decide.

[phkb]

Sounds like they are a good set to speed up an existing game. But having those four exclusively (that's what a flavour is at the moment) would have little meaning I guess.

I haven’t played with the latest OoliteStarter, so I could probably answer my own question if I went and looked, but can you select multiple flavours to be installed, or is it one flavour at a time?

[hiran]

I haven’t played with the latest OoliteStarter, so I could probably answer my own question if I went and looked, but can you select multiple flavours to be installed, or is it one flavour at a time?

If you activate a flavor it is interpreted as you want to go to a specific combination of expansionns. Wherever you are at that moment, OoliteStarter will compute what needs to be installed and what needs to be removed and offer that list of actions to be confirmed. Once confirmed it will be implemented.

That means applying 'Vanilla' will remove all OXPs. So if I placed Redspear's time saver into a flavour it would be those OXPs only. My gut feeling is these four should be integrated into one or more of the existing ones.

Let's change the logic as a play of mind. Flavours add up. Adding hot spice to any food will make that food hot, right? But how much Vanilla could/should you add to remove a spice? Or would we reach there by unselecting everything else?

So if flavours can be activated or deactivated, how would an activated Vanilla impact the manually triggered installation? Would it prevent that, or would it simply deactivate that flavour?

I'm not against such logic but would need a user understandable concept. Right now it is easy:
If someone claims to play a flavour we know which expansions are involved.

Otherwise just create an expansion set and share that with others. Not every combination has to go into a predefined set.

Last: The flavours are not part of OoliteStarter. Instead they get downloaded from the website. I am happy if others join in and create their taste of Oolite. All you need is to tweak the files at https://github.com/OoliteProject/oolite ... .0/flavors

[phkb]

I've just installed the latest version to check this out for myself. It's looking a lot smoother since I last installed it! Nice work everyone!

Flavours
Just looking at the Flavours tab, I find myself wanting to know a bit more about each flavour. There needs to be a way to display more detail for those who want it: at minimum, a list of each mod included in the flavour, and ideally, why it was included and what it will do to your game experience.

Ic you activate a flavor it means you want to go to a specific combination of expansionns.

It would also be nice to be able to select multiple flavours. Say, for instance, I want the beginner's set and the depth set. At the moment, there is no clear way I could achieve that. I can't even see what mods are included in each, so I couldn't go and put the list together myself. If we could be modular with how the flavours are installed, it would allow something like Redspears "Ain't Got All God Damn Day" Flavour to address specific issues players have encountered in the game.

Installing Flavours

OoliteStarter will compute what needs to be installed and what needs to be removed and offer that list of actions to be confirmed. Once confirmed it will be implemented.

First of all, the UI is a bit inadequate here. In this example, I had one pre-existing OXP installed. I then double-clicked on the "Beginner's set", and got this:


I don't think the icons are particularly clear for what is taking place. Why a yellow exclamation in a warning triangle? To me that indicates a problem of some sort. I can kind of see the reason for the trash can "to be deleted" icon, but I think this would be a lot simpler with just a red minus "-" for the OXP's to be deleted, and a green plus for those that will be added.

The other problem with this dialog is that the "..." icon is leading me to believe there is a popup menu or something that will enable me to take action on a single entry. For example, if I *don't* want to delete "Super Systems" in my screen shot above. But no amount of clicking (left, right, double), brings up any way to tell the UI "please don't delete my OXP!". I honestly don't want to click on "OK" because I don't want to find out afterwards that I should have taken a backup before starting!

Confusingly, after I pressed "OK" to confirm the changes, it *didn't* delete that OXP anyway. It just left it in there. Is that what's supposed to happen?

The issue with removing existing mods when installing a new flavour only really impacts one set: "Strangers World Set". That one set is so complex and in depth, it honestly should have been set up as a scenario in Oolite originally (rather than having it as a standard mod with an implicit assumption it will be compatible with everything, even if it isn't). But regardless, it's the one that is most likely to cause conflicts, and so yes, in that case I would potentially delete everything else and just install SW. All the others, though, are probably fine to mix and match with.

ManagedAddOns folder content
Final issue: There's a problem when switching between OoliteStarter and the built-in manager when updating OXP's. I put in an older version of an oxp, using the same naming convention as Oolite starter (ie "[email protected]"). I then started Oolite, went into the Expansion Manager, updated the OXP list, and found the OXP that needed updating. Everything looked fine until I applied changes. Oolite didn't delete the file with the "@" in the filename, resulting in both OXP's (previous version and current version) in the ManagedAddOns folder. And of course, Oolite reported errors on the title screen about one OXP appearing to be a duplicate of another and so wasn't loaded.

As an experiment, I changed the "@" symbol to underscore ("_"), and Oolite still wasn't able to delete the old file. The only way I could get things to work properly was to remove the version number entirely from the file in ManagedAddOns. As soon as a version number is added to the filename, Oolite can't find the old file to remove it (or what is probably happening is that Oolite is assuming the file being downloaded will have the same name as the one in the ManagedAddOns folder, and so it will overwrite the existing one).

I think, if you're going to inject files into the ManagedAddOns folder, you need to do it the way Oolite expects you to, with just the identifier as the filename.

Anyway, that's my two cents worth. It's come a long way and looking better and better each time.

[hiran]

I've just installed the latest version to check this out for myself. It's looking a lot smoother since I last installed it! Nice work everyone!

Thanks!

Flavours
Just looking at the Flavours tab, I find myself wanting to know a bit more about each flavour. There needs to be a way to display more detail for those who want it: at minimum, a list of each mod included in the flavour, and ideally, why it was included and what it will do to your game experience.

Currently the interface supports title and description. We can put anything we want in there. I can add a detail view showing the involved expansions though.

Ic you activate a flavor it means you want to go to a specific combination of expansionns.

It would also be nice to be able to select multiple flavours. Say, for instance, I want the beginner's set and the depth set. At the moment, there is no clear way I could achieve that. I can't even see what mods are included in each, so I couldn't go and put the list together myself. If we could be modular with how the flavours are installed, it would allow something like Redspears "Ain't Got All God Damn Day" Flavour to address specific issues players have encountered in the game.

This can create trouble I wanted to avoid so far. I'd guess for a predefined set of expansions we ensure only meaningful and compatible expansions are included. If you combine two or more such sets conflicts may arise. How should they get handled?

Installing Flavours

OoliteStarter will compute what needs to be installed and what needs to be removed and offer that list of actions to be confirmed. Once confirmed it will be implemented.

First of all, the UI is a bit inadequate here. In this example, I had one pre-existing OXP installed. I then double-clicked on the "Beginner's set", and got this:


I don't think the icons are particularly clear for what is taking place. Why a yellow exclamation in a warning triangle? To me that indicates a problem of some sort. I can kind of see the reason for the trash can "to be deleted" icon, but I think this would be a lot simpler with just a red minus "-" for the OXP's to be deleted, and a green plus for those that will be added.

The other problem with this dialog is that the "..." icon is leading me to believe there is a popup menu or something that will enable me to take action on a single entry. For example, if I *don't* want to delete "Super Systems" in my screen shot above. But no amount of clicking (left, right, double), brings up any way to tell the UI "please don't delete my OXP!". I honestly don't want to click on "OK" because I don't want to find out afterwards that I should have taken a backup before starting!

Point taken. I reused an already existing view but will improve it. And yes, at this time it is an all or nothing: Approve the list or not.

Confusingly, after I pressed "OK" to confirm the changes, it *didn't* delete that OXP anyway. It just left it in there. Is that what's supposed to happen?

That should not happen - or at least not without user notification. Can you give me details how to reconstruct that situation? Feel free to open an issue.

The issue with removing existing mods when installing a new flavour only really impacts one set: "Strangers World Set". [...] All the others, though, are probably fine to mix and match with.

That references the current state but is no guarantee for the future. Plus you already state not all flavours are compatible to each other. How should we handle that? I introduced flavours to make it easier for the user, not more complex. Please be aware we can still manually choose what to install and then export that information as expansion set.

ManagedAddOns folder content
Final issue: There's a problem when switching between OoliteStarter and the built-in manager when updating OXP's. I put in an older version of an oxp, using the same naming convention as Oolite starter (ie "[email protected]"). I then started Oolite, went into the Expansion Manager, updated the OXP list, and found the OXP that needed updating. Everything looked fine until I applied changes. Oolite didn't delete the file with the "@" in the filename, resulting in both OXP's (previous version and current version) in the ManagedAddOns folder. And of course, Oolite reported errors on the title screen about one OXP appearing to be a duplicate of another and so wasn't loaded.

There was a reason why I introduced addition of the version number, and it works well with Oolite. It just does not when mixing OoliteStarter and the in-game expansion manager. I eat my own dogfood, which means I have completely stopped using the in-game manager. Hence asking for viewtopic.php?t=21586

Anyway, that's my two cents worth. It's come a long way and looking better and better each time.

Thanks a lot for this feedback.

[phkb]

There was a reason why I introduced addition of the version number, and it works well with Oolite.

Well, I would argue it only *half* works with Oolite, as long as you only use OoliteStarter.

I think it's important that OoliteStarter not break anything in Oolite in how it operates. And here's the thing: there is no reason to actually put *anything* into the ManagedAddOns folder. If users have downloaded mods using the internal DM, then, sure, move them into the "Deactivated" folder if they choose to do so via OoliteStarter. But you can put *every single OXZ into the "AddOns" folder*, with versioning etc, and then Oolite will work fine. It won't try and do anything with OXZ's in that folder (or subfolders thereof). It won't automatically update them, but at this point the user is probably using OoliteStarter and it can handle the updates, so that's fine. If they choose to stop using OoliteStarter, Oolite will tell them an update is available, but it can't be performed because it's installed in AddOns. They could then either delete it and reinstall it (so it goes into ManagedAddOns), or manually update it themselves. Either way, nothing is broken, and it's a relatively straightforward process to explain to someone why their mods aren't auto-updating.

If you really need to have version numbers in the filename, then just don't use ManagedAddOns.

[phkb]

Currently the interface supports title and description. We can put anything we want in there. I can add a detail view showing the involved expansions though.

I deflinitely think we need an expanded section that has a lot more detail. The title and summary are great for the main screen and menu, but if we want people to make informed decisions, the detailed view needs to give them as much info as we can put together.

This can create trouble I wanted to avoid so far. I'd guess for a predefined set of expansions we ensure only meaningful and compatible expansions are included. If you combine two or more such sets conflicts may arise. How should they get handled?

Plus you already state not all flavours are compatible to each other. How should we handle that? I introduced flavours to make it easier for the user, not more complex. Please be aware we can still manually choose what to install and then export that information as expansion set.

For everything other than the SW mods, I would expect conflicts have been included in the manifest.plist. Even SW does this to a certain extent. So there will be a natural conflict resolution happening that way.

That said, I would expect our "flavours" to have had some thought go into them to ensure the best possible compatibility with other mods.

This does all come back to the concept behind flavours: Are they supposed to be a single flavour, or are they designed to be a patchwork of smaller sets that players can add to their own taste? The problem with having a single flavour can be seen on the current flavour list. Additional Planets and Stations is a flavour on it's own. But just adding extra planets and station would end up being rather empty: all those stations and planets, and nothing to do. What about missions. Ah, there is a G1 Missions and Activities. But why do I have to uninstall Additional Planets and Stations to get missions?

The way the current flavour set is portraying itself is that you *can* mix and match, but what you're actually asking the player to do is to choose between them. (And the lack of additional information means it's unclear if things like the "Beginner Set" is included in all the other sets).

I'd suggest it's harder (and I mean a *lot* harder) to come up with cohesive, comprehensive "flavours" that are completely standalone, and much easier to build smaller suites of targeted mods that address a particular issue or expand a certain part of the game.

Regardless of which way we end up making this work, the Flavour page needs some helper text at the top, explaining what the options below will do.

[hiran]

Currently the interface supports title and description. We can put anything we want in there. I can add a detail view showing the involved expansions though.

I deflinitely think we need an expanded section that has a lot more detail. The title and summary are great for the main screen and menu, but if we want people to make informed decisions, the detailed view needs to give them as much info as we can put together.

It is easy to show the list of expansions. If more information is required what is the source? Should ae introduce a long description field? And who generates the content? Currently I am happy to have the single sentence - it's all I've got.

For everything other than the SW mods, I would expect conflicts have been included in the manifest.plist. Even SW does this to a certain extent. So there will be a natural conflict resolution happening that way.

That said, I would expect our "flavours" to have had some thought go into them to ensure the best possible compatibility with other mods.

So it is sufficient to detect conflicts based on OXPs.
What would OoliteStarter do if a conflict occurs?

This does all come back to the concept behind flavours: Are they supposed to be a single flavour, or are they designed to be a patchwork of smaller sets that players can add to their own taste? The problem with having a single flavour can be seen on the current flavour list. Additional Planets and Stations is a flavour on it's own. But just adding extra planets and station would end up being rather empty: all those stations and planets, and nothing to do. What about missions. Ah, there is a G1 Missions and Activities. But why do I have to uninstall Additional Planets and Stations to get missions?

The way the current flavour set is portraying itself is that you *can* mix and match, but what you're actually asking the player to do is to choose between them. (And the lack of additional information means it's unclear if things like the "Beginner Set" is included in all the other sets).

I can follow. So let's enable mix and match and see where we end up.

Regardless of which way we end up making this work, the Flavour page needs some helper text at the top, explaining what the options below will do.

I had some text there, then decided to make use of Mr Gimlet. Is that sufficient? What should the explanation be?

[Cholmondely]

I'd expected that the flavours would be additive, so one could combine Beginners and Depth or Stranger's World and Depth or even Redspear's "Masslock Minimisers" and Beginners. Hence my focusing on OXPs adding to different areas within the game (missions & activities, depth, beginners needs, etc.).


If the coding won't allow addition, then should we opt for several variant flavours which are very different?

These variants would inevitably overlap in part (eg all containing Systems OXPs such as Commies), but could create very different Ooniverses which are complete in themselves (and possibly displaying the myriad possibilities of Oolite)

There could be
a Stranger's World variant,
an Additional Planets variant (chosen by Redspear for playability - if we can twist his arm enough),
a "Thargoid menace" variant,
an Elite Trader variant,
...and, say, a Hermitage (very different focus to the game) and a SOTL Exploration.
And, I suppose, a Beginner's variant too.

Sadly, I doubt we have enough components for a "Pirates Career" Oolite, or a "Star Wars" Ooniverse.

[hiran]

If the coding won't allow addition, then should we opt for several variant flavours which are very different?

The code it not set in stone. I implemented a simple way and waited for feedback. As we have consensus here it makes sense to adapt the implementation.

Plus we can even change our mind at a later point in time.

[arquebus]

There was a reason why I introduced addition of the version number, and it works well with Oolite.

Well, I would argue it only *half* works with Oolite, as long as you only use OoliteStarter.

I think it's important that OoliteStarter not break anything in Oolite in how it operates. And here's the thing: there is no reason to actually put *anything* into the ManagedAddOns folder. If users have downloaded mods using the internal DM, then, sure, move them into the "Deactivated" folder if they choose to do so via OoliteStarter. But you can put *every single OXZ into the "AddOns" folder*, with versioning etc, and then Oolite will work fine. It won't try and do anything with OXZ's in that folder (or subfolders thereof). It won't automatically update them, but at this point the user is probably using OoliteStarter and it can handle the updates, so that's fine. If they choose to stop using OoliteStarter, Oolite will tell them an update is available, but it can't be performed because it's installed in AddOns. They could then either delete it and reinstall it (so it goes into ManagedAddOns), or manually update it themselves. Either way, nothing is broken, and it's a relatively straightforward process to explain to someone why their mods aren't auto-updating.

If you really need to have version numbers in the filename, then just don't use ManagedAddOns.

I raised this issue earlier. It's still having knock-on effects for me. Now, if I start the game from OoliteStarter and bypass the main menu etc., everything seems to work just fine. But if I start Oolite independently, I get massive red alert spam about duplicate OXPs, so much so that the menus are obliterated and I can't even see how to quit without Alt-F4'ing my way out.

Starter should absolutely not be tinkering with names etc. in such a way that launching Oolite independently completely breaks things. I cannot stress this enough. If filename changes are necessary for smooth operation of Starter's versioning feature, part of that feature should include renaming the OXP back to normal whenever it gets put into one of the active AddOn folders. It's already possible to get the version information from inside the manifest, there's no reason to be renaming things in the "live" directory. Leave that for storing copies outside of Oolite's field of vision.