installer

[Hoopy]

There's a LOT of OXPs, a lot of versions, a lot of new bug fixes, a lot of new OXPs and a lot of incomplete/in progress OXPs and I'm beginning to get a bit lost in it all.

Do you think there's a need for an application that would check which OXPs and which versions you had, check the OXPs on the wiki and then give you the option of downloading any updates or new OXPs that were available?

Further features might include
- checking the version of Oolite you have vs the versions the OXP supports
- categorising the OXPs as mission, flavour, ships etc.
- listing the status eg: alpha, beta, new, bug fix, abandonned etc
- autmatically download any OXPs required by the one you're downloading

Any thoughts?

I think it would be especially useful for new players who are a bit scared of OXPs and experienced/returning players looking for any new misions.

[another_commander]

I think it's a very good idea, provided that someone is willing to take ownership of this task.

[Hoopy]

As I was writing it I did sort of wonder if I was volunteering myself...

If enough people think it'd be useful then I'll try and find some time to get a proper list of requirements and investigate things like how it would talk to the wiki etc.

[edit] and of course how it might be integrated into the oolite distribution (or if it should remain separate)

[Cmdr. Maegil]

I fully agree with the idea, had even suggested this some time ago.

Should I understand we're talking about a search engine? I like the described features, and (couldn't find my post) here are my two bits:

- the OXPs should be ranked as to their type (ships, mission, flavour, etc.), difficulty (novice/experienced/insensitized), and machine requirements (low/medium/high).
-don't forget to put a list for manual (un)ticking

[Ark]

I also think that this is a very good idea

I would prefer it as an external program but distributed via oolite installer.

But I am not sure how you are planning to create such a program. I mean the concept is simple a standalone program inside oolite directory that will search the addone folder, find the versions of oxps and compare them with the version inside wiki.
Is that what you want to do? because if so I think there are some serious obstacles.

1.How that program will determine the version of the installed oxps.
2.How that program will determine the version of the wiki oxps.Most of the oxps in wiki do not have a version number. Some of them just say upgraded (upgraded from what version ?)
3.The version number is not in a separate column but in the column of oxp’s name.
4.It seems that in some cases the version of wiki is not the newest one.
For more details

https://bb.oolite.space/viewtopic.php?t=4095

But the last is not a very serious problem because I am planning to track all those cases (yes there are more !!!) and report them so someone with a wiki account would be able to upgrade them.

[Eric Walch]

1.How that program will determine the version of the installed oxps.
2.How that program will determine the version of the wiki oxps.Most of the oxps in wiki do not have a version number. Some of them just say upgraded (upgraded from what version ?)

Best would be to add a info.plist inside the oxp with a well defined structure. But only problem is how getting all those programmers to use this.

When I worked on Lovecats I encountered an essential function that only worked from Oolite version 1.65 and up. Still the requirements.plist said: minimum requirements 1.07 ??

So you can hardly count on those figures and it remains pure handwork to determine witch version is what.

[JensAyton]

Checking version requirements for legacy scripts could be added to the OXP verifier. Problem is that this would require accurate information on when all the methods were added, which isn’t easily available (the source code has changed repositories, so even the easy-but-labour-intensive method isn’t an option). Checking for methods introduced since 1.65 would probably be doable.

[Ark]

Best would be to add a info.plist inside the oxp with a well defined structure.

An info.plist (with the name and the version of the oxp) will be helpful for at least one more case.The case that some oxps require the existence of a specific version of another oxp. For example the requirements of Galactic Navy is not only a specific version of oolite but also a specific version (and above) of behemoth oxp.

But only problem is how getting all those programmers to use this.

You can not

[Hoopy]

the installer would need to have some place on the web where it could get an index of all the OXPs. Or preferably a directory containing all the OXPs where each one had a well defined info file as described by Eric.

I guess it would just have to ignore all OXPs without an info file. But such a file would be pretty simple so could easily be added.

[Ark]

I guess it would just have to ignore all OXPs without an info file. But such a file would be pretty simple so could easily be added.

In 160 or more OXPs ?
I assume you are talking for the new ones. Not the the old (arlready be on the Wiki)

[Hoopy]

it's still not that much effort. Or perhaps we could just create a default one and apply it to all existing OXPs and then correct it whenever any discrepancy is reported.

[Svengali]

Best would be to add a info.plist inside the oxp with a well defined structure.

An info.plist (with the name and the version of the oxp) will be helpful for at least one more case.The case that some oxps require the existence of a specific version of another oxp. For example the requirements of Galactic Navy is not only a specific version of oolite but also a specific version (and above) of behemoth oxp.

Or perhaps we could just create a default one and apply it to all existing OXPs and then correct it whenever any discrepancy is reported.

So what do we need. An entry for the OXP-name, OXP-version, Oolite-beginning-version (minimum), Oolite-exclusive-version (only working with), required-other-oxps, required-other-oxps-version (minimum), required-other-oxps-exclusive-version (only working with)?

[JensAyton]

Remember, we already have requires.plist. Requirements should be kept there, since old versions won’t look anywhere else.

“Info.plist” has a specific usage in Mac and GNUstep apps, so I’d go with “manifest.plist” or “oxp.plist” or some such.

In a manifest.plist, I’d include:

• Human-readable name
• OXP identifier
• OXP version
• Author name
• Copyright notice
• License name
• Possibly contact and web site info (for utilities such as the downloader); would also be indexed for Spotlight under Mac OS X.
• Your clever idea here.

All fields would be optional, except perhaps OXP identifier (that is, the plist would be ignored if no identifier is specified).

I’m not sure whether dependencies should be declared in the new plist or requires.plist. Using requires.plist makes semantic sense, since it declares a requirement. It would also mean that versions from 1.69 which didn’t understand dependency declarations would reject the OXP, even if the necessary dependencies were there. However, 1.65 wouldn’t.

Either way, dependency declarations would look something like this:

Code: Select all

"required-oxps" =
(
    "ahruman-super-oxp", // any version
    {
        name = "ewalch-mega-oxp";
        version = 1.5;  // minimum required version (optional)
        max-version = 1.7;  // maximum compatible version
    }
)

As for “Oolite-exclusive-version”, 1.69 and later support “max-version” as well as “version” in requires.plist.

[Ark]

In a manifest.plist, I’d include:

• Human-readable name
• OXP identifier
• OXP version
• Author name
• Copyright notice
• License name
• Possibly contact and web site info (for utilities such as the downloader); would also be indexed for Spotlight under Mac OS X.
• Your clever idea here.

All fields would be optional, except perhaps OXP identifier (that is, the plist would be ignored if no identifier is specified).

Maybe also a release date (useful for some oxps that does not have a version number - or maybe by making the oxp version mantatory so the opx authors will stop using all that upgrated and wip instead of a version number in their oxps).

Using requires.plist makes semantic sense, since it declares a requirement. .

It seems the most logical approach. There are not so many oxps that have a depentency with other oxps but in the future will be more. We sould aim to the future.

Either way, dependency declarations would look something like this:

Code: Select all

"required-oxps" =
(
    "ahruman-super-oxp", // any version
    {
        name = "ewalch-mega-oxp";
        version = 1.5;  // minimum required version (optional)
        max-version = 1.7;  // maximum compatible version
    }
)

As for “Oolite-exclusive-version”, 1.69 and later support “max-version” as well as “version” in requires.plist.

It looks good - somethig like that (inside the requires.plist)

[JensAyton]

Code: Select all

        name = "ewalch-mega-oxp";

Should be “identifier”, not “name”.

A thought occurs to me: with explicitly declared dependencies, should dependencies be made explicit? For instance, if Ahruman’s Super OXP used a ship from Eric Walch’s Mega OXP, and declared a dependency in requires.plist, should references to the used ship look like this:

Code: Select all

like_ship = "ewalch-mega-ship";

or like this:

Code: Select all

like_ship = "ewalch-mega-oxp:mega-ship";

This would avoid the entire conflicting-names issue for OXPs with a manifest.plist (obviously references to things in Oolite wouldn’t require a namespace). For OXPs without a manifest.plist, the old behaviour could probably be maintained – although inter-OXP dependencies in 1.65 and earlier were effectively bugs since they could cause Oolite to hang.

I think this would be a fundamentally better approach, but it would also complicate the implementation and probably make the whole manifest thing an after-next-stable feature.