Page 12 of 19
Re: Enable Oolite development (2)
Posted: Tue Jul 25, 2023 10:07 pm
by Cholmondely
I see two scenarios developing: either Oolite Starter ends up replacing the in-game Expansions Manager - or it ends up being used by a handful of players.
In the first scenario, Arquebus is spot on - replace the Expansions Manager colour scheme with something superior. In the second, I would have thought that it is better to buttress the comprehension of the EM colour scheme.
Or you could give the ever-suffering player choice with your about-to-be-written Oolite Starter Preferences GUI!
Re: Enable Oolite development (2)
Posted: Wed Jul 26, 2023 2:34 am
by arquebus
I feel like I'm spot on in the second scenario, too. No one's going to be using *both* the in-game manager and hiran's manager. It's going to be one or the other. So the color-coding between them does not need to match. It doesn't matter if it's a handful of players, all of the players, or one player: the two managers' functions overlap, which makes one or the other redundant for any given player. (Yes, the Starter does *more*, but to the extent that it manages expansions the way the in-game one does, they do the same thing.)
The only circumstance in which it would be important to match the color coding is if you're anticipating players (of any number) will want to use both. And they absolutely will not. They'll either stop using the Starter (for whatever reason), or stop using the in-game manager. No one's going to be switching between the two back and forth.
Re: Enable Oolite development (2)
Posted: Wed Jul 26, 2023 4:36 am
by hiran
Thank you for the feedback.
I agree there is no need to have a 100% same look and handling - especially where funtionality is superior or more convenient.
Still the question is how it would best support the player.
While there could be magic buttons to do something I so far preferred to increase visibility. And that means to some degree I have to use UI elements to render information.
I used one color to raise the user's attention to specific UI elements. It should guide to missing/problematic expansions. (BTW: problems never occur on expansions that are not installed or disabled. So if you want to narrow down problem search either filter for enabled expansions, or go for the Problematic ones directly) The exact reason is not yet rendered, the player would have to fiddle around to understtand it.
Once that is fixed I want to offer comfort functions for easy fixups.
Re: Enable Oolite development (2)
Posted: Wed Jul 26, 2023 10:32 am
by Cholmondely
Just downloaded Zecch7.
Colours look cheery!
I'm not too sure how accurate the listings of conflicts & missing dependencies actually are - I play just fine with what I have currently got installed.
0) The "OLERC" oxp coding needs a key somewhere on that screen (bottom right, perhaps?)
1) I just bug-fixed my Aquatics, changing the version number in the manifest.plist
I see a blue "No Download" - does this mean that my Aquatics is not a download or that there is no download of my renumbered version available? Or both?
2) I see the deep yellow "Install+" tag for oxp's where I already have the dependencies (but they are probably not in an OS recognised folder - I need to check)
3) For Dictators.oxz OS tells me that I'm missing dependencies. I'm not. I tweaked Astrofactory and it is now an oxp in the AddOns folder with a new version number (2.4.1) The wrong AddOns folder was identified - and I don't think it was the one I originally set back in v.0.1.15 - this might also explain the erroneous conflicts warning...
Will carry on investigating...
Edited to add:
These folders seem to be breeding! Just found a "ManagedDeactivatedAddOns" folder tucked away in GNUStep>Lbrary>ApplicationSupport>Oolite with some OXZs in it.
ReEdited to add:
I've two copies of Behemoth. The original .oxz is in ManagedDeactivatedAddOns, and the tweaked .oxp is in "AddOns" (but with the original untweaked manifest.plist).
But gazing at my tweaked Galactic Navy.oxp (with a manifest.plist added in) indicates that Behemoth is missing!
+ I also wonder if there might be point in adding a small "comments" box to enable the player to make comments about the oxps?
+ Am I correct in presuming that OS does not recognise oxps which do not have a manifest.plist?
Re: Enable Oolite development (2)
Posted: Wed Jul 26, 2023 8:59 pm
by hiran
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
Just downloaded Zecch7.
[...]
I'm not too sure how accurate the listings of conflicts & missing dependencies actually are - I play just fine with what I have currently got installed.
I agree this needs to be looked at with care. If we find bugs I'd like to document the situations to create a database of automated test cases so we can resolve situations and ensure they do not come back.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
0) The "OLERC" oxp coding needs a key somewhere on that screen (bottom right, perhaps?)
That status was a quick shot and we may want to render it completely differently, although right now I have no idea how that should be a representable status display. The current version is just good because it can participate in the Regex search - which is not necessary due to the drop-down filter.
A Legend? Also possible. Will give that a shot.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
1) I just bug-fixed my Aquatics, changing the version number in the manifest.plist
I see a blue "No Download" - does this mean that my Aquatics is not a download or that there is no download of my renumbered version available? Or both?
Some status may be redundant as it might show the same: Your expansion is not downloadable. If you delete it there is no way for a restore.
So the OLERC should indicate a noncapital O, and the blue tag "No download" is the same information in old-style Expansion Manager color code.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
2) I see the deep yellow "Install+" tag for oxp's where I already have the dependencies (but they are probably not in an OS recognised folder - I need to check)
Hmmm, that tag would indicate if you install, it would not just install one OXP but more. Currently only the fact is evaluated that there are dependencies, not even whether they are satisfied already. It may well be helpful information though to only indicate that (some or all of the) required expansions are still to be installed.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
3) For Dictators.oxz OS tells me that I'm missing dependencies. I'm not. I tweaked Astrofactory and it is now an oxp in the AddOns folder with a new version number (2.4.1) The wrong AddOns folder was identified - and I don't think it was the one I originally set back in v.0.1.15 - this might also explain the erroneous conflicts warning...
Will carry on investigating...
It is a complex issue, and we need to take care to come up with correct conclusions. Same here on my side - I tested until I found out it had to be enough. Hence also my attempt to have an automated testing database.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
Edited to add:
These folders seem to be breeding! Just found a "ManagedDeactivatedAddOns" folder tucked away in GNUStep>Lbrary>ApplicationSupport>Oolite with some OXZs in it.
ReEdited to add:
I've two copies of Behemoth. The original .oxz is in ManagedDeactivatedAddOns, and the tweaked .oxp is in "AddOns" (but with the original untweaked manifest.plist).
But gazing at my tweaked Galactic Navy.oxp (with a manifest.plist added in) indicates that Behemoth is missing!
I am sure no folder was created without your consent - yet it is easy to have them autocreated in so many places. Again, this needs careful testing.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
+ I also wonder if there might be point in adding a small "comments" box to enable the player to make comments about the oxps?
Such a comment box, or a 'star rating' would be easy to create. But where would we store such information?
It should clearly go into the Expansion Manager's catalogue so it can be shared with other users. The website needs to be upgraded for such stuff.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
+ Am I correct in presuming that OS does not recognise oxps which do not have a manifest.plist?
You may be right there.
According to
https://wiki.alioth.net/index.php/OXP_howto#Structure:
If the OXP is in the uncompressed OXP folder format, the .oxp folder must contain a requires.plist file. If it is in the compressed OXZ single-file format, it must contain a manifest.plist file.
I have never seen a
requires.plist
file. But maybe I was focusing on OXZ too much. Could you give me an example where to find that file? While we can at least identify an OXP for an OXP, almost no other information could be shared about it:
https://wiki.alioth.net/index.php/Requires.plist
Edit: The next pre-release
0.1.17-zecchino.8 will cover requires.plist as per documentation.
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 12:03 am
by Cholmondely
hiran wrote: ↑Wed Jul 26, 2023 8:59 pm
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
Just downloaded Zecch7.
[...]
I'm not too sure how accurate the listings of conflicts & missing dependencies actually are - I play just fine with what I have currently got installed.
I agree this needs to be looked at with care. If we find bugs I'd like to document the situations to create a database of automated test cases so we can resolve situations and ensure they do not come back.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
0) The "OLERC" oxp coding needs a key somewhere on that screen (bottom right, perhaps?)
That status was a quick shot and we may want to render it completely differently, although right now I have no idea how that should be a representable status display. The current version is just good because it can participate in the Regex search - which is not necessary due to the drop-down filter.
A Legend? Also possible. Will give that a shot.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
1) I just bug-fixed my Aquatics, changing the version number in the manifest.plist
I see a blue "No Download" - does this mean that my Aquatics is not a download or that there is no download of my renumbered version available? Or both?
Some status may be redundant as it might show the same: Your expansion is not downloadable. If you delete it there is no way for a restore.
So the OLERC should indicate a noncapital O, and the blue tag "No download" is the same information in old-style Expansion Manager color code.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
2) I see the deep yellow "Install+" tag for oxp's where I already have the dependencies (but they are probably not in an OS recognised folder - I need to check)
Hmmm, that tag would indicate if you install, it would not just install one OXP but more. Currently only the fact is evaluated that there are dependencies, not even whether they are satisfied already. It may well be helpful information though to only indicate that (some or all of the) required expansions are still to be installed.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
3) For Dictators.oxz OS tells me that I'm missing dependencies. I'm not. I tweaked Astrofactory and it is now an oxp in the AddOns folder with a new version number (2.4.1) The wrong AddOns folder was identified - and I don't think it was the one I originally set back in v.0.1.15 - this might also explain the erroneous conflicts warning...
Will carry on investigating...
It is a complex issue, and we need to take care to come up with correct conclusions. Same here on my side - I tested until I found out it had to be enough. Hence also my attempt to have an automated testing database.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
Edited to add:
These folders seem to be breeding! Just found a "ManagedDeactivatedAddOns" folder tucked away in GNUStep>Lbrary>ApplicationSupport>Oolite with some OXZs in it.
ReEdited to add:
I've two copies of Behemoth. The original .oxz is in ManagedDeactivatedAddOns, and the tweaked .oxp is in "AddOns" (but with the original untweaked manifest.plist).
But gazing at my tweaked Galactic Navy.oxp (with a manifest.plist added in) indicates that Behemoth is missing!
I am sure no folder was created without your consent - yet it is easy to have them autocreated in so many places. Again, this needs careful testing.
No way. They
must be trumbles in disguise. And I'm feeding them oxps!
hiran wrote: ↑Wed Jul 26, 2023 8:59 pm
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
+ I also wonder if there might be point in adding a small "comments" box to enable the player to make comments about the oxps?
Such a comment box, or a 'star rating' would be easy to create. But where would we store such information?
It should clearly go into the Expansion Manager's catalogue so it can be shared with other users. The website needs to be upgraded for such stuff.
Cholmondely wrote: ↑Wed Jul 26, 2023 10:32 am
+ Am I correct in presuming that OS does not recognise oxps which do not have a manifest.plist?
You may be right there.
According to
https://wiki.alioth.net/index.php/OXP_howto#Structure:
If the OXP is in the uncompressed OXP folder format, the .oxp folder must contain a requires.plist file. If it is in the compressed OXZ single-file format, it must contain a manifest.plist file.
I have never seen a
requires.plist
file. But maybe I was focusing on OXZ too much. Could you give me an example where to find that file? While we can at least identify an OXP for an OXP, almost no other information could be shared about it:
https://wiki.alioth.net/index.php/Requires.plist
Edit: The next pre-release
0.1.17-zecchino.8 will cover requires.plist as per documentation.
Here's a requires.plist example (from the Galactic Navy.oxp):
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>version</key>
<string>1.74</string>
</dict>
</plist>
And another (from griff_CobraIII_alternate_model_v1.3.1.oxp):
<Dumb pilot mode> I'm not terribly sure that they help </Dumb pilot mode>
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 4:52 am
by hiran
Cholmondely wrote: ↑Thu Jul 27, 2023 12:03 am
Here's a requires.plist example (from the Galactic Navy.oxp):
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>version</key>
<string>1.74</string>
</dict>
</plist>
And another (from griff_CobraIII_alternate_model_v1.3.1.oxp):
<Dumb pilot mode> I'm not terribly sure that they help </Dumb pilot mode>
You picked wisely. Now I know the wiki only had one example - the plist files can still be XML (yikes!).
Will add the Galactic Navy to my test cases.
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 8:51 am
by Cholmondely
hiran wrote: ↑Thu Jul 27, 2023 4:52 am
Cholmondely wrote: ↑Thu Jul 27, 2023 12:03 am
Here's a requires.plist example (from the Galactic Navy.oxp):
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>version</key>
<string>1.74</string>
</dict>
</plist>
And another (from griff_CobraIII_alternate_model_v1.3.1.oxp):
<Dumb pilot mode> I'm not terribly sure that they help </Dumb pilot mode>
You picked wisely. Now I know the wiki only had one example - the plist files can still be XML (yikes!).
Will add the Galactic Navy to my test cases.
Those examples contain the
entire contents of their respective
requires.plists - no information at all other then the minimum version of Oolite with the javascript improvements required to run them (from the Ahruman days when each new Oolite version allowed more and more scripting, and many oxps had to be continually updated: I am under the impression that developments since v.1.82 have been mostly bug-fixes in this respect). The
earliest BB reference is 2007.
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 8:17 pm
by hiran
Cholmondely wrote: ↑Thu Jul 27, 2023 8:51 am
hiran wrote: ↑Thu Jul 27, 2023 4:52 am
Cholmondely wrote: ↑Thu Jul 27, 2023 12:03 am
Here's a requires.plist example (from the Galactic Navy.oxp):
And another (from griff_CobraIII_alternate_model_v1.3.1.oxp):
<Dumb pilot mode> I'm not terribly sure that they help </Dumb pilot mode>
You picked wisely. Now I know the wiki only had one example - the plist files can still be XML (yikes!).
Will add the Galactic Navy to my test cases.
Those examples contain the
entire contents of their respective
requires.plists - no information at all other then the minimum version of Oolite with the javascript improvements required to run them (from the Ahruman days when each new Oolite version allowed more and more scripting, and many oxps had to be continually updated: I am under the impression that developments since v.1.82 have been mostly bug-fixes in this respect). The
earliest BB reference is 2007.
I'm just trying to download from
https://wiki.alioth.net/index.php/Galactic_Navy and see the message
This OXP is currently broken, i.e. it does not work with the current release of Oolite. Reason: Some versions of this classic OXP are broken: see Galactic Navy OXP for more detail.
That makes me think...
Next, from
https://wiki.alioth.net/index.php/Galactic_Navy_OXP:
This OXP requires the Behemoth OXP to function properly.
What? How can a OXP 'require' something? Especially if it does not fill in a manifest.plist?
Next, trying to download from
Galactic Navy 2021 download link
--> that link is no longer valid
The next link luckily gave me a download. And presumably I do not have to worry whether Oolite can run that OXP - I only need to detect that OXP in the filesystem proplerly. Plus I just learned there is an info.plist file that could get evaluated. Fresh meat for improvements...
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 8:22 pm
by Cholmondely
hiran wrote: ↑Thu Jul 27, 2023 8:17 pm
Cholmondely wrote: ↑Thu Jul 27, 2023 8:51 am
hiran wrote: ↑Thu Jul 27, 2023 4:52 am
You picked wisely. Now I know the wiki only had one example - the plist files can still be XML (yikes!).
Will add the Galactic Navy to my test cases.
Those examples contain the
entire contents of their respective
requires.plists - no information at all other then the minimum version of Oolite with the javascript improvements required to run them (from the Ahruman days when each new Oolite version allowed more and more scripting, and many oxps had to be continually updated: I am under the impression that developments since v.1.82 have been mostly bug-fixes in this respect). The
earliest BB reference is 2007.
I'm just trying to download from
https://wiki.alioth.net/index.php/Galactic_Navy and see the message
This OXP is currently broken, i.e. it does not work with the current release of Oolite. Reason: Some versions of this classic OXP are broken: see Galactic Navy OXP for more detail.
That makes me think...
Next, from
https://wiki.alioth.net/index.php/Galactic_Navy_OXP:
This OXP requires the Behemoth OXP to function properly.
What? How can a OXP 'require' something? Especially if it does not fill in a manifest.plist?
Next, trying to download from
Galactic Navy 2021 download link
--> that link is no longer valid
The next link luckily gave me a download. And presumably I do not have to worry whether Oolite can run that OXP - I only need to detect that OXP in the filesystem proplerly. Plus I just learned there is an info.plist file that could get evaluated. Fresh meat for improvements...
1) OXPs requiring other OXPs were a feature back in the days before the Expansions Manager/manifest.plist (2014) - the OXP just did not work properly if the other OXP was not loaded. Galactic Navy goes back to 2006!
2) I was working on GN but was utterly unable to fix the markets so I took it back down from the Expansions Manager listing. I should get back to it - but have no idea as to how to fix those markets!
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 9:07 pm
by hiran
Cholmondely wrote: ↑Thu Jul 27, 2023 8:22 pm
1) OXPs requiring other OXPs were a feature back in the days before the Expansions Manager/manifest.plist (2014) - the OXP just did not work properly if the other OXP was not loaded. Galactic Navy goes back to 2006!
Makes sense. The actual dependency is just there in code. And to prevent Oolite or OXPs from simply failing, they started to declare dependencies in the manifest.plist so problems can be prevented.
Cholmondely wrote: ↑Thu Jul 27, 2023 8:22 pm
2) I was working on GN but was utterly unable to fix the markets so I took it back down from the Expansions Manager listing. I should get back to it - but have no idea as to how to fix those markets!
If it is syntactical problems I can likely help. If it is about understanding the game play others on this forum for sure are a better help.
BTW this info.plist - it is mentioned on the Wiki but nowhere specified. Who knows something about that file?
Re: Enable Oolite development (2)
Posted: Thu Jul 27, 2023 9:19 pm
by Cholmondely
hiran wrote: ↑Thu Jul 27, 2023 9:07 pm
BTW this info.plist - it is mentioned on the Wiki but nowhere specified. Who knows something about that file?
This is the info.plist from Stranger's Dark Ray.oxp
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleGetInfoString</key>
<string>Dark Ray 0.1.2</string>
<key>CFBundleName</key>
<string>Dark Ray</string>
<key>CFBundleShortVersionString</key>
<string>0.1.2</string>
<key>NSHumanReadableCopyright</key>
<string>Stranger</string>
</dict>
</plist>
This seems to be the first BB mention:
https://bb.oolite.space/viewtopic.php?p=14785#p14785 (Feb 2006)
I'm not sure how common they are.
Re: Enable Oolite development (2)
Posted: Fri Jul 28, 2023 4:22 am
by hiran
That reference mentions info.plist for Oolite itself. Being an AppleMac project, it is the file that any application bundle should come with. MacOS will read and interprete that file. With that the specification should be here:
info.plist Reference.
I am more surprised that this same file would get applied to OXPs. They are no applications to MacOS and thus the information needs to be digested in Oolite.
I scanned the the Oolite source code and saw no evidence that the file
<someexpansion>/Index.plist
is read at all.
Re: Enable Oolite development (2)
Posted: Fri Jul 28, 2023 7:23 am
by Cholmondely
hiran wrote: ↑Fri Jul 28, 2023 4:22 am
That reference mentions info.plist for Oolite itself. Being an AppleMac project, it is the file that any application bundle should come with. MacOS will read and interprete that file. With that the specification should be here:
info.plist Reference.
I am more surprised that this same file would get applied to OXPs. They are no applications to MacOS and thus the information needs to be digested in Oolite.
I scanned the the Oolite source code and saw no evidence that the file
<someexpansion>/Index.plist
is read at all.
Index.plist?
I promise you, if these presumably useless (for two decades) info.plists allow your zecchini to recognise old .oxps, that I will not utter one single murmer of complaint!
Re: Enable Oolite development (2)
Posted: Fri Jul 28, 2023 7:35 am
by hiran
Cholmondely wrote: ↑Fri Jul 28, 2023 7:23 am
hiran wrote: ↑Fri Jul 28, 2023 4:22 am
That reference mentions info.plist for Oolite itself. Being an AppleMac project, it is the file that any application bundle should come with. MacOS will read and interprete that file. With that the specification should be here:
info.plist Reference.
I am more surprised that this same file would get applied to OXPs. They are no applications to MacOS and thus the information needs to be digested in Oolite.
I scanned the the Oolite source code and saw no evidence that the file
<someexpansion>/Index.plist
is read at all.
Index.plist?
I promise you, if these presumably useless (for two decades) info.plists allow your zecchini to recognise old .oxps, that I will not utter one single murmer of complaint!
Before elevating some artefact to a standard I think we should check how common it is already. So far it seems we have two OXPs, and know nothing about OXZs.
Still I'd not recommend creating a parallel standard since the real solution to this dilemma would be to simply collect information from Index.plist and requires.plist into manifest.plist, which is part of the OXP specification.