Oolite Bulletins

Paradox wrote:

I downloaded the OXP version of the resources, But the in game manager does not recognize that.

This is because the manager doesn't recognize OXPs and OXZs as such, it recognizes manifest.plists and OXPs don't have those. manifest.plists were introduced to allow the manager to work which is why OXZs must have them. I believe that it is possible to add a manifest.plist to an OXP as well, and that the manager will recognise it, but I don't expect any authors will retro-actively fit manifests to their OXPs especially if these have already been replaced by an OXZ.

Diziet Sma wrote:

If you manually download an OXZ from the wiki, so long as you place it in /GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns the Oolite Expansion Manager will recognise that you have the necessary resources installed.

It will, but you'll confuse it when it comes to upgrade time. Any OXZs you download yourself should go in the normal AddOns folder.

Diziet Sma wrote:

Umm.. no, you can't.. only Maik can delete files that have been uploaded to the wiki.

Overwrite with a 1-byte file, then. Something which will cause a quick download failure.

JensAyton wrote:

I don’t think this is anywhere near large enough to justify using stale data when the player has explicitly entered the OXZ manager screen

Having thought about it a bit more, you're right - there are later potential features for the OXZ manager for which it working smoothly without requiring connectivity would be useful, but for now it can run an update when entering the manager.

Smivs wrote:

Paradox wrote:

I downloaded the OXP version of the resources, But the in game manager does not recognize that.

This is because the manager doesn't recognize OXPs and OXZs as such, it recognizes manifest.plists and OXPs don't have those. manifest.plists were introduced to allow the manager to work which is why OXZs must have them. I believe that it is possible to add a manifest.plist to an OXP as well, and that the manager will recognise it, but I don't expect any authors will retro-actively fit manifests to their OXPs especially if these have already been replaced by an OXZ.

Actually the expansion manager does recognize oxps with manifest.plist .

example :
Random hits latest version is only downloadble through the expansion manager as oxz
I installed/downloaded it through the expansion manager, moved the oxz files to my Downloads/Oolite Addons folder .

I started oolite, found the expansion manager correctly listed them as not installed.
Then i created appropriate folders in my ~/.Oolite/Addons folder and copied the oxz contents in there.

Upon next start of Oolite, the expansion manager 'install expansion pack' correctly showed both RH expansions as installed.
'List installed expansions' did not show them.

Personally i plan to release both oxp and oxz versions of all my oxps.

Lone_Wolf wrote:

Then i created appropriate folders in my ~/.Oolite/Addons folder and copied the oxz contents in there.

Why not just put the oxz-file into the AddOns folder? There's no need to unzip it unless you are going to tweak it.

Lone_Wolf wrote:

'List installed expansions' did not show them.

This should probably be different. I would expect to see local oxzs too.

Lone_Wolf wrote:

Personally i plan to release both oxp and oxz versions of all my oxps.

Why is that? Unless your oxp is meant to work with earlier versions of Oolite of course. Your call of course as an author, I'm just curious.

spara wrote:

Lone_Wolf wrote:

Then i created appropriate folders in my ~/.Oolite/Addons folder and copied the oxz contents in there.

Why not just put the oxz-file into the AddOns folder? There's no need to unzip it unless you are going to tweak it.

oxz-files don't have a version number, i like to keep track of things i install/use through a filemanager.

spara wrote:

Lone_Wolf wrote:

'List installed expansions' did not show them.

This should probably be different. I would expect to see local oxzs too.

Agreed, hope it will come in 1.80.1 / 1.82

spara wrote:

Lone_Wolf wrote:

Personally i plan to release both oxp and oxz versions of all my oxps.

Why is that? Unless your oxp is meant to work with earlier versions of Oolite of course. Your call of course as an author, I'm just curious.

personal preferences :
When i have to choose between control and ease-of-use i tend to choose control.
I will continue to develop using oxps as they give me more control.
My workflow will look like this :

create/adjust oxp
test & fix
once correct, update manifest.plist & readme file
pack oxp file & oxz file
upload oxp file
update forum thread
upload oxz
update wiki page

I do understand why oxz was introduced, so the best option for me seems to be to release both.

Lone_Wolf wrote:

oxz-files don't have a version number, i like to keep track of things i install/use through a filemanager.

If I don't want to use the manager for download, I download straight from the Oolite Expansion Packs page. Those oxz-files usually have version number.

Lone_Wolf wrote:

My workflow will look like this :

create/adjust oxp
test & fix
once correct, update manifest.plist & readme file
pack oxp file & oxz file
upload oxp file
update forum thread
upload oxz
update wiki page

That's about the same as it's for me, except that I don't pack oxps into zip files anymore and upload them. Fewer things to update and maintain . The way I see it, oxz is already a zip file. And I always put a version number to the file name.

How about have a desktop link (or a link in Oolite's start menu folder) to the location of OXZs for the Windows install of Oolite?
That way, people can actually FIND the files.

Switeck wrote:

How about have a desktop link (or a link in Oolite's start menu folder) to the location of OXZs for the Windows install of Oolite?
That way, people can actually FIND the files.

You're not supposed to find them. a_c referred to that upthread as "tampering". It's supposed to be a system that is completely managed from within Oolite, and that "just works".

The problem, of course, is that many OXPs do not work properly and require tweaking (or wholesale re-writing). That is not a problem with Oolite or the download manager, it is a problem of quality control.

Here's something to think about: suppose everyone with a user login at oolite.org had a hard limit on the number of OXZs they could add to the system. Say 10. No exceptions for anyone. Would that encourage a focus on quality, rather than quantity, of OXZs available through the manager? (No, let's say 5.)

If/when someone wants to install Oolite on another computer...like one with no internet access...it'd be good if they could copy the OXZs over to that install.
So yes, there are reasons to have access to the folder besides "tampering" with the files.

Wildeblood wrote:

Here's something to think about: suppose everyone with a user login at oolite.org had a hard limit on the number of OXZs they could add to the system. Say 10. No exceptions for anyone. Would that encourage a focus on quality, rather than quantity, of OXZs available through the manager? (No, let's say 5.)

Seriously? You expect that to make any difference at to the quality of what's offered at all?

If anything that would just discourage me from sharing my work...
I make my OXPs primarily for myself, and while I enjoy being able to share them with others and get feedback I think having that kind of limit imposed would just cast a very off-putting shadow over the whole thing...

- Neelix

Wildeblood wrote:

Switeck wrote:

How about have a desktop link (or a link in Oolite's start menu folder) to the location of OXZs for the Windows install of Oolite?
That way, people can actually FIND the files.

You're not supposed to find them. a_c referred to that upthread as "tampering". It's supposed to be a system that is completely managed from within Oolite, and that "just works".

Then why do I include texture templates, original .obj files, and explicitly state in my OXPs that making changes to them are, in fact, highly encouraged? I'm an adult, I neither need, nor want, anyone telling me what I can and can't access or change in MY game.

Paradox wrote:

Then why do I include texture templates, original .obj files, and explicitly state in my OXPs that making changes to them are, in fact, highly encouraged? I'm an adult, I neither need, nor want, anyone telling me what I can and can't access or change in MY game.

This is fine and of course nobody can tell anyone what they can and can't change in one's game. However, if you want people to be able to tweak the expansions you release and you release them as OXZs, then you are doing it wrong. You should be releasing them as old-school OXPs.

aegidian wrote:

OXZ's need to undergo a substantial amount of sanity checking before they should be made available. Particularly with regard to dependencies, which should be subject to an exhaustive check to be certain that the files required are indeed where they are expected to be. This should form a part of the Oolite executable (since the parsers etc. are all built into it), so that any OXP can be machine tested by its author before it is zipped into OXZ form.

OXP's have the supreme benefit of being easy to edit and correct, but OXZ's can freeze a slight error into a user-discouraging sucky problem.

We need to make sure that such problems simply cannot occur, it's not enough to delegate that to OXZ's authors.

Then OXZ release needs to become a multi-stage process.

Firstly, the add-on is created as a OXP...and beta-tested and code reviewed before converting it to an OXZ and posting it on the auto-update server.

The more eyes we can get to look at an OXP, the better its quality is likely to become...so anyone should be able to download and test the OXP if they read about it on the forum.
Most of this needs to be done "in the open" on the appropriate OXP message thread, which means it will quickly become an extreme spoiler for the OXP.

We need LOTS of beta testers and code reviewers. At least 2 of each for each and every OXZ, though someone can wear both hats. The bigger and more complex OXZs will need even more help. Missions and campaigns are often especially nasty to test, since testing various scenarios requires insider's knowledge about what they do to set them up for thorough testing. Premade savegames by the authors at various points will be helpful but not enough in this regard.

Even the testing setups need consideration -- firstly with minimal other OXPs, to prevent conflicts and then with lots of OXPs to spot conflicts. Any OXPs/OXZs used while doing minimal testing need to be restricted to ones that help the testers do the testing. If that's too much to ask, at least list installed OXPs/OXZs.

Every active OXP/OXZ maker will probably have to be a volunteer for this to scale -- and besides someone like Thargoid, they'll have to test and/or review more OXZs than they make and release.

It is important that they can communicate regularly with the author/s, for timely releases.
This also requires getting along with the author -- there is no good reason to make this a hostile environment, as some of this will prove stressful enough as it is.

There will likely be lots of second-guessing the OXP/OXZ authors, because only extremely detailed documentation can explain why things are done rather than just how things are done.

Lots of work and rework.

Wildeblood wrote:

Here's something to think about: suppose everyone with a user login at oolite.org had a hard limit on the number of OXZs they could add to the system. Say 10. No exceptions for anyone. Would that encourage a focus on quality, rather than quantity, of OXZs available through the manager? (No, let's say 5.)

No! I already have 18 and still have a couple to convert, plus the new shipsets to do.
The problem as has been identified is a lack of quality control, and limiting numbers will not address this. I think there are a couple of things to note here. Firstly, there has been an unseamly rush to get OXZs out, and many started as OXPs which simply had a manifest.plist added to them. This would normally be OK, except they would not necessarily use all the new features of 1.80, or take into account the changes to things like roles. I confess I am guilty of this a bit myself and in retrospect perhaps I should have held back before issueing some of them as OXZs, although all are now fully 1.80 compliant.
The other issue that I see is the current trend to 'swap' and 'adopt' OXPs. I get the feeling that a lot of OXZs on the manager have not been posted there by the original author. This could be for many reasons, and is not in itself a bad thing, but I can see this being a source of problems as well, and is a trend that should probably be discouraged for all sorts of reasons.
There has been too much of a rush to convert, and I think that quality control has been the main victim of this. All we can do is hope that people recognise the problem, and that there is no hurry. We should all agree that future OXZ releases are complete, properly converted taking all the new 1.80 features and changes into account, and are fully tried and tested before release.