installer

Discussion and information relevant to creating special missions, new ships, skins etc.

Moderators: another_commander, winston

Post Reply
User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

installer

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5835
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

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

User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

Post by 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)

User avatar
Cmdr. Maegil
Sword-toting nut-job
Sword-toting nut-job
Posts: 1294
Joined: Tue Feb 27, 2007 10:28 pm
Location: On the mend in Western Africa

Post by 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
You know those who, having been mugged and stabbed, fired, dog run over, house burned down, wife eloped with best friend, daughters becoming prostitutes and their countries invaded - still say that "all is well"?
I'm obviously not one of them.

User avatar
Ark
---- E L I T E ----
---- E L I T E ----
Posts: 664
Joined: Sun Dec 09, 2007 8:22 am
Location: Athens Greece

Post by 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

http://www.aegidian.org/bb/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.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

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

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

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

User avatar
Ark
---- E L I T E ----
---- E L I T E ----
Posts: 664
Joined: Sun Dec 09, 2007 8:22 am
Location: Athens Greece

Post by Ark »

Eric Walch wrote: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.
Eric Walch wrote:But only problem is how getting all those programmers to use this.
You can not :(

User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

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

User avatar
Ark
---- E L I T E ----
---- E L I T E ----
Posts: 664
Joined: Sun Dec 09, 2007 8:22 am
Location: Athens Greece

Post by Ark »

Hoopy wrote: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 ? :shock:
I assume you are talking for the new ones. Not the the old (arlready be on the Wiki)

User avatar
Hoopy
---- E L I T E ----
---- E L I T E ----
Posts: 438
Joined: Wed Oct 03, 2007 8:54 pm
Location: Durham, England

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

User avatar
Svengali
---- E L I T E ----
---- E L I T E ----
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Post by Svengali »

Eric Walch wrote:Best would be to add a info.plist inside the oxp with a well defined structure.
Ark wrote: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.
Hoopy wrote: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)?

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

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

User avatar
Ark
---- E L I T E ----
---- E L I T E ----
Posts: 664
Joined: Sun Dec 09, 2007 8:22 am
Location: Athens Greece

Post by Ark »

Ahruman wrote: 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).
Ahruman wrote: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.
Ahruman wrote: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)

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Ahruman wrote:

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.

Post Reply