Page 7 of 19
Re: Enable Oolite development (2)
Posted: Fri Jun 16, 2023 2:35 pm
by hiran
timer wrote: ↑Fri Jun 16, 2023 1:36 pm
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.
Re: Enable Oolite development (2)
Posted: Fri Jun 16, 2023 2:57 pm
by timer
hiran wrote: ↑Fri Jun 16, 2023 2:35 pm
But I am not good enough with these Makefiles to figure out how exactly.
the same "trouble" ))
Re: Enable Oolite development (2)
Posted: Sun Jun 18, 2023 4:27 pm
by hiran
hiran wrote: ↑Mon Jun 05, 2023 8:17 pm
arquebus wrote: ↑Mon Jun 05, 2023 7:15 pm
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.
arquebus wrote: ↑Mon Jun 05, 2023 7:15 pm
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.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 7:18 am
by hiran
hiran wrote: ↑Sun Jun 18, 2023 4:27 pm
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:
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 7:29 am
by 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.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 8:57 am
by 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!
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 10:06 am
by hiran
Cholmondely wrote: ↑Thu Jun 22, 2023 8:57 am
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.
Cholmondely wrote: ↑Thu Jun 22, 2023 8:57 am
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?
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 1:51 pm
by arquebus
hiran wrote: ↑Thu Jun 22, 2023 7:18 am
Hmmm, no feedaback so far.
I'll be able to test next Monday!
That diagram is exactly what I was hoping for.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 3:49 pm
by Cholmondely
hiran wrote: ↑Thu Jun 22, 2023 10:06 am
Cholmondely wrote: ↑Thu Jun 22, 2023 8:57 am
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.
Cholmondely wrote: ↑Thu Jun 22, 2023 8:57 am
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.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 3:50 pm
by Cholmondely
arquebus wrote: ↑Thu Jun 22, 2023 1:51 pm
hiran wrote: ↑Thu Jun 22, 2023 7:18 am
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...)
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 5:44 pm
by hiran
Cholmondely wrote: ↑Thu Jun 22, 2023 3:50 pm
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...
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 6:17 pm
by Cholmondely
hiran wrote: ↑Thu Jun 22, 2023 5:44 pm
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:
arquebus wrote: ↑Thu May 25, 2023 6:27 pm
hiran wrote: ↑Tue May 23, 2023 7:54 pmFor 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.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 7:06 pm
by arquebus
Cholmondely wrote: ↑Thu Jun 22, 2023 6:17 pm
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.
Re: Enable Oolite development (2)
Posted: Thu Jun 22, 2023 7:19 pm
by hiran
arquebus wrote: ↑Thu Jun 22, 2023 7:06 pm
Cholmondely wrote: ↑Thu Jun 22, 2023 6:17 pm
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.
Re: Enable Oolite development (2)
Posted: Sun Jun 25, 2023 8:40 pm
by hiran
Cholmondely wrote: ↑Thu Jun 22, 2023 3:49 pm
hiran wrote: ↑Thu Jun 22, 2023 10:06 am
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.