Re: Oolite Flavours
Posted: Sun Apr 21, 2024 11:24 am
Would this be relevant?
- Time Saver or Ain't Got All God Damn Day Flavour
For information and discussion about Oolite.
https://bb.oolite.space/
True.
...close enough.phkb wrote: ↑Wed Apr 24, 2024 12:20 am- 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.
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.
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.
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.
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:
Thanks!
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.phkb wrote: ↑Thu Apr 25, 2024 5:42 amFlavours
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.
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?phkb wrote: ↑Thu Apr 25, 2024 5:42 amIt 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.
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.phkb wrote: ↑Thu Apr 25, 2024 5:42 amInstalling FlavoursFirst 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!
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.
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.
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=21586phkb wrote: ↑Thu Apr 25, 2024 5:42 amManagedAddOns 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.
Thanks a lot for this feedback.
Well, I would argue it only *half* works with Oolite, as long as you only use OoliteStarter.
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.
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.hiran wrote: ↑Thu Apr 25, 2024 6:51 amPlus 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.
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.
So it is sufficient to detect conflicts based on OXPs.phkb wrote: ↑Thu Apr 25, 2024 7:27 amFor 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.
I can follow. So let's enable mix and match and see where we end up.phkb wrote: ↑Thu Apr 25, 2024 7:27 amThis 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 had some text there, then decided to make use of Mr Gimlet. Is that sufficient? What should the explanation be?
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.Cholmondely wrote: ↑Thu Apr 25, 2024 8:28 amIf the coding won't allow addition, then should we opt for several variant flavours which are very different?
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.phkb wrote: ↑Thu Apr 25, 2024 7:05 amWell, 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.