Enable Oolite development (2)

[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!

[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.

[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.

[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?

[hiran]

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.

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.

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.

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.

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.

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.

+ 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.

+ 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.

[Cholmondely]

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.

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.

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.

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.

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.

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!

+ 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.

+ 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):

Code: Select all

{ version="1.80"; }

<Dumb pilot mode> I'm not terribly sure that they help </Dumb pilot mode>

[hiran]

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):

Code: Select all

{ version="1.80"; }

<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.

[Cholmondely]

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):

Code: Select all

{ version="1.80"; }

<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.

[hiran]

Here's a requires.plist example (from the Galactic Navy.oxp):

Code: Select all

...

And another (from griff_CobraIII_alternate_model_v1.3.1.oxp):

Code: Select all

...

<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...

[Cholmondely]

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!

[hiran]

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.

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?

[Cholmondely]

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.

[hiran]

This is the info.plist from Stranger's Dark Ray.oxp

Code: Select all

...

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.

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.

[Cholmondely]

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!

[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.

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.