OoliteStarter

[arquebus]

Choosing one and installing is so similar I think of keeping expansion sets and flavours together.

Choosing and installing, yes. But what about building?

[hiran]

Choosing one and installing is so similar I think of keeping expansion sets and flavours together.

Choosing and installing, yes. But what about building?

It could be one single button that exports the currently installed expansions into an expansion set. A dialog would pop up asking for the destination of the file.

Alternatively let me have your suggestion about completly separating the functions. How would that look like?

[hiran]

Ok, I added expansion set capability again: v0.1.29-flavescent.3

With that I believe the feature set to be rich enough, and we have at least some basic functionality to cover each of them. Let's see if the UI still needs to be reshuffled.

We can also start looking at the documentation, tutorials and maybe some artwork. Currently it is plain dark.

[arquebus]

Starter is supposed to automatically update expansions that you have installed, correct?

If so... it does not.

I was making my OXP showcase video for next week and noticed that inside Oolite's manager I have a bunch of blue OXPs, even though I ran Starter before running Oolite.

[hiran]

Starter is supposed to automatically update expansions that you have installed, correct?

If so... it does not.

I was making my OXP showcase video for next week and noticed that inside Oolite's manager I have a bunch of blue OXPs, even though I ran Starter before running Oolite.

True, it does not auto update. Once a week it checks for updates. If updated OXPs are found it will say so. If an updated Oolite is found it will say so. And if a later OoliteStarter is available it will say so.

I decided not to auto-update anything. For OoliteStarter to update itself that would be a nut to crack.
For Oolite it would be heavily OS dependent but doable.
For OXPs it would be easily doable.

But there is no guarantee the new version is not broken, and there is no way to go back. Therefore the pattern is the same for all three: OoliteStarter notifies and the user decides and acts.

If you want to check/control the interval for update checks, have a look at the OoliteStarter configuration file.
The timestamp of last check is saved via the java preferences api and thus stored dependent on the operating system. On Windows this should end up in the Windows registry, on Linux there might be some hidden files in the user home.

[hiran]

I was making my OXP showcase video for next week and noticed that inside Oolite's manager I have a bunch of blue OXPs, even though I ran Starter before running Oolite.

I never use the in game manager, and through heavy testing all my OXPs are up to date anyway. Could you check thether the in game status 'blue' is in sync with OoliteStarter when you filter for updatable expansions?

[arquebus]

I was making my OXP showcase video for next week and noticed that inside Oolite's manager I have a bunch of blue OXPs, even though I ran Starter before running Oolite.

I never use the in game manager, and through heavy testing all my OXPs are up to date anyway. Could you check thether the in game status 'blue' is in sync with OoliteStarter when you filter for updatable expansions?

Aha! I see where I got confused. I assumed you were still color coding the updatable OXPs in the new interface. Yes, when I filter, it's the same list as the blues.

[arquebus]

A minor interface issue when updating:

I select the OXP to update on the left, then click the arrow. If the list has more OXPs, the list will refresh, but now the right arrow is inactive and the left arrow is active. If I click on the same OXP that's visually selected, the arrows flip to the correct status. So it looks like after a refresh the interface brings focus to the right side list, rather than where I just was (on the left).

Also, is there a chance of having a button for bulk updating?

I understand the desire to maintain caution regarding updates that might break things or break itself and never get fixed, but that's sufficiently rare these days (I hope) that a bulk update button would come in handy.

[arquebus]

Additionally, the list of updatable OXPs on the right side doesn't refresh after you update something, so once I was done, even if I unfiltered and then refiltered, the list showed that the same set of OXPs could be updated. But the left side filter showed nothing (as expected).

[hiran]

I was making my OXP showcase video for next week and noticed that inside Oolite's manager I have a bunch of blue OXPs, even though I ran Starter before running Oolite.

I never use the in game manager, and through heavy testing all my OXPs are up to date anyway. Could you check thether the in game status 'blue' is in sync with OoliteStarter when you filter for updatable expansions?

Aha! I see where I got confused. I assumed you were still color coding the updatable OXPs in the new interface. Yes, when I filter, it's the same list as the blues.

Maybe I should make them blue so migration is easier.

Bulk update should be doable. And I will check whether an update is an update rather than an install (the old version needs to be removed).

[phkb]

But there is no guarantee the new version is not broken

True, but how would anyone know? No OXP author *deliberately* posts broken code. So, if there's an update, the author had a reason and wants people to use the new version, and it makes life easier if they only have to debug one version.

Also, by not updating, you are asking an end-user, who may not be tech-savvy (and Oolite-OXP-savvy) enough to work out what any issue in their mix of OXP's is. How would they be able to tell that it was the most recent update to (for example) Extra Rock Hermits that made some other OXP play up?

My suggestion is that OXP's should auto update, perhaps with a prompt saying "Would you like to update these mods?" and then listing all the mods with updates. This keeps the control at the user's end, but makes it clear that updates are pending, and it's 1 click to get the updates installed.

And for those users who have hacked away at a particular mod to the point where it is quite different to the original and therefore don't want any auto-updates to happen on it, I can only recommend to them to change the identifier in their hacked version. Add "_hacked" to the end of the string. Job done. You won't see any updates for that OXP again.

[arquebus]

My suggestion is that OXP's should auto update, perhaps with a prompt saying "Would you like to update these mods?" and then listing all the mods with updates. This keeps the control at the user's end, but makes it clear that updates are pending, and it's 1 click to get the updates installed.

This is my view as well. At most, a notification asking yes/no, but initiated by the program, not the user. There's always a guardrails inflection point in these sorts of things, where too much guardrailing results in *less* control, not more. Without some form of automation here, the user base will continue to be all over the place in terms of versions (as it is now, since the expansion manager doesn't automate the process either). And the only way newer versions are going to get stress-tested properly is by having many users on that version.

I'd also venture to guess that one of the top 3 reasons people like using mod managers is because they automate and updating process, which is one of the most annoying parts of manual mod management. (Constantly checking for updates, never being sure if you missed one or not, etc.)

[hiran]

Aha! I see where I got confused. I assumed you were still color coding the updatable OXPs in the new interface. Yes, when I filter, it's the same list as the blues.

Also, is there a chance of having a button for bulk updating?

My suggestion is that OXP's should auto update, perhaps with a prompt saying "Would you like to update these mods?" and then listing all the mods with updates. This keeps the control at the user's end, but makes it clear that updates are pending, and it's 1 click to get the updates installed.

This is my view as well. At most, a notification asking yes/no, but initiated by the program, not the user.

All done. Please check v0.1.29-flavescent.4.

[hiran]

And, by the way, your latest tweaks don't work on the AppleMac: I'm using 0.1.28 uxbridge 10 - I can't use the menu to "enable" anything, and I now get an error message most times I try opening it up - java.lang.NullPointerException: Cannot invoke "java.util.List.stream()" because "this expansions" is null

That version is one month old and has received two more followups on that experimental branch before considered stable. It is possible that I stabilized such issues in the meantime already. But to really tell I need the logfile so I know where/why that error is coming up.

[Cholmondely]

And, by the way, your latest tweaks don't work on the AppleMac: I'm using 0.1.28 uxbridge 10 - I can't use the menu to "enable" anything, and I now get an error message most times I try opening it up - java.lang.NullPointerException: Cannot invoke "java.util.List.stream()" because "this expansions" is null

That version is one month old and has received two more followups on that experimental branch before considered stable. It is possible that I stabilized such issues in the meantime already. But to really tell I need the logfile so I know where/why that error is coming up.

You will need to remind where I find the logfile. Sorry! I got a message about the new nightly - but nothing about the new OoliteStarters.

For brand new players who are not programmers, I'm not sure that information about nightlies is helpful.