Enable Oolite development (2)

[hiran]

Not before you pointed it out. Good to know.

it is from here
https://github.com/OoliteProject/oolite ... -137510231
the author may well still be in touch...

I think we can build a debian package when running the build with the correct parameters. But I am not good enough with these Makefiles to figure out how exactly.

If someone finds out I am willing to add that to the build system. Same for a Windows installer.

[timer]

But I am not good enough with these Makefiles to figure out how exactly.

the same "trouble" ))

[hiran]

Running 0.15 on Windows, it's not recognizing my deactivated AddOns folder -

"Directory for deactivated expansions C:OoliteAddOnsInactive not found"

The directory on my system is

C:\Oolite\AddOnsInactive

So it looks like the program is stripping the \

You ran into the same pitfall as so many other Windows/Java users. The solution is to either use forward slashes or duplicate backslashes.

- https://stackoverflow.com/questions/578 ... -backslash
- https://stackoverflow.com/questions/288 ... rties-file

We can improve the behaviour, although I'd like to focus on other parts first as it is a one-time effort to get this right.

And if I comment out the line the program looks for a directory that does not exist - it's looking for

C:\Users\<username>\GNUstep\Library\ApplicationSupport\Oolite\DisabledAddOns

(I would expect it to failback to a directory next to the one specified for the addons directory earlier in the config file)

While we may discuss about reasonable defaults, I think of a setup wizard that could autodetect the necessary files. Then both this and the above issue would be fixed within the application.

So I have something that allows editing the configuration via a UI. No need t twiddle configuration files manually.
Plus: We can configure multiple Oolite installations and then comfortably switch between them.

Check out the OoliteStarter v0.1.7-installations builds. If that produces positive feedback we can merge it into the master branch.

[hiran]

So I have something that allows editing the configuration via a UI. No need t twiddle configuration files manually.
Plus: We can configure multiple Oolite installations and then comfortably switch between them.

Check out the OoliteStarter v0.1.7-installations builds. If that produces positive feedback we can merge it into the master branch.

Hmmm, no feedback so far. I merged the code meanwhile, so there is the next release.
For the technically interested people: Expansion management now works like this diagram:

[phkb]

No feedback from me yet not because of lack of interest, but purely because I can’t install random apps on my work pc (security lockdowns). It will probably be a few months before I’ll be in a position to test this properly.

[Cholmondely]

No feedback from me due to bemused bamboozlement (the AppleMac versions of Oolite all share the same 2 folders, and the interface has changed in bewildering ways...)

But I amazed myself! Not only did I manage to download it, I even got it to run without having my hand held!

[hiran]

No feedback from me due to bemused bamboozlement (the AppleMac versions of Oolite all share the same 2 folders, and the interface has changed in bewildering ways...)

Depending on which version you were looking before, there are changes to be expected, yes. If something is unclear we may have to dicsuss about the UI on a general level. The target audience will probably not go for training or read much documentation. So the UI has to be simple and intuitive.

But I amazed myself! Not only did I manage to download it, I even got it to run without having my hand held!

This is great! If you can repeat it, maybe we are good to document the steps. Did you try the DMG or go for the generic build?

[arquebus]

Hmmm, no feedaback so far.

I'll be able to test next Monday!

That diagram is exactly what I was hoping for.

[Cholmondely]

No feedback from me due to bemused bamboozlement (the AppleMac versions of Oolite all share the same 2 folders, and the interface has changed in bewildering ways...)

Depending on which version you were looking before, there are changes to be expected, yes. If something is unclear we may have to discuss about the UI on a general level. The target audience will probably not go for training or read much documentation. So the UI has to be simple and intuitive.

But I amazed myself! Not only did I manage to download it, I even got it to run without having my hand held!

This is great! If you can repeat it, maybe we are good to document the steps. Did you try the DMG or go for the generic build?

The DMG flubbed the dub, yet again. So I got 0.1.8.generic.zip up and running. But I'm sure somebody here can help you sort out the .dmg.

[Cholmondely]

Hmmm, no feedaback so far.

I'll be able to test next Monday!

That diagram is exactly what I was hoping for.

Arquebus - I don't think that it is quite there yet - the oxp's are not yet assigned to specific save-games (but with the speed Hiran works at - and by next Monday...)

[hiran]

Arquebus - I don't think that it is quite there yet - the oxp's are not yet assigned to specific save-games (but with the speed Hiran works at - and by next Monday...)

So far I had not intended to marry them up. But I understand the point.
Could you confirm the OXPs in use are detected from the savegames and displayed on the savegame's detail panel?

Of course that requires you to save the game after having started it through OoliteStarter...

[Cholmondely]

So far I had not intended to marry them up. But I understand the point.

I think that the marriage will be main point of interest for most players (certainly for me!), although Arquebus did not mention it here:

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.

But with 750+ oxz's and another 400oxp's, a shot-gun marriage is the quickest way to keep things separate and sorted.

[arquebus]

I think that the marriage will be main point of interest for most players (certainly for me!), although Arquebus did not mention it

I do agree it would be valuable, though it is not *critically* necessary, as you could always create expansion sets named after your save games, and then manually pick the set before launching the save. Having that step be automated would be great, but it's not critical for the useful function of the manager.

[hiran]

I think that the marriage will be main point of interest for most players (certainly for me!), although Arquebus did not mention it

I do agree it would be valuable, though it is not *critically* necessary, as you could always create expansion sets named after your save games, and then manually pick the set before launching the save. Having that step be automated would be great, but it's not critical for the useful function of the manager.

What I see as extremely useful though is the OoliteStarter to indicate whether expansions are missing/too much. It would still be up to the player to correct but at least he/she/it would know.

[hiran]

This is great! If you can repeat it, maybe we are good to document the steps. Did you try the DMG or go for the generic build?

The DMG flubbed the dub, yet again. So I got 0.1.8.generic.zip up and running. But I'm sure somebody here can help you sort out the .dmg.

What I checked from development side:
The DMG is built on MacOS 12.6.6 21G646, validating the DMG afterwards using hdiutil verify <dmg> reveals that the file is valid.
I think that is as much as I can do on my side without having access to and knowledge about the Apple Mac.

Could someone help verifying whether the DMG download flubbs the dub or works? When reporting back, please also mention the OS you tested on.