Oolite Bulletins

.. or are they a step toward an improvement?

Or is that they are not an improvement but just a different way of doing things is is in some ways better and in other ways worse?

I can see the reasoning that would say they were an improvement but in practice I find them a step backwards, especially when some expansions no longer get supplied as an OXP.

Looking at the Pro's it should be easier to see if there is an update for an installed OXZ and it may be easier to upgrade. That is all the Pro's I can think off.

Now the Con's.
The manager cannot work with existing OXP's you you end up sorting through folders anyway. It also does not handle dependencies well, just a vague you may need to add or remove other expansions, this may be manually if it is an OXP or through the manager but possibly on a different page.
With the limited screen space in game you have to move around a lot to find stuff, and it may not be where you think it is or in some cases it may have a name that is different.
Downloads are so slow that it is not worth trying anything over a couple of Mb. At least if you had a slow download of an OXP you could still use the system to check emails, surf the forums or anything else.
Having used the manager to install an extension you then need to ferret about through to a 6th or 7th level folder to find it so you can extract and read the readme. I know not many people read them but now they have an excuse.
Next is perhaps the biggest problem, what to do with a broken OXZ? There are, for example, several extensions that reference a core ship model which no longer exists, the solution was easy, you change the reference to a similar ship that does exist. The same problem occurs with corrupt png files, on systems where Oolite has to be compiled they are often using the newest version libpng which catches thousands of errors, these png's can easily be corrected in an OXP. Both these scenario's are more difficult with OXZ's as you cannot edit inside the compressed file so you need to extract the OXP, correct the errors then I usually just move it to Addons and delete the OXZ.

So for Joe User who never reads manuals or log files OXZ's maybe of use, Jane User who knows her way around her system and wants everything working as it should would probably prefer not to use OXZ's but has to due to more extensions not being offered as OXP's. I'm with Jane on this.

I have a few comments on some of the points raised:

What needs to be clear here is that OXZs are managed expansion packs As such, they are not meant to be tampered with and therefore any concern about editing files within them should not be a concern in the first place. In the same context, the answer to the question "what to do with a broken OXZ" is "remove it". If anyone wants to tamper with files, they can always unzip and install as standard OXPs.

The format was created after repeated requests by people who wanted exactly that: a managed system for handling expansions, with which a non-techie user would have no problem or difficulty. I think that this was delivered in the best possible way, considering also the limitations of the Oolite GUI itself. Regarding the argument about restricted screen space resulting in long searches etc., this is true, however cim has already stated the intention improve on that by creating basic search filters, so I expect it to not continue to be an issue. Remember, this is the first iteration of the OXZ manager we are seeing here and of course things can (and will) get better.

Finally, regarding the comment about slow downloads. I would think that each individual's connection will have a lot to do with it. I am downloading at very good speeds here (and I normally test with the 103MB file of Random Hits Resources) and I have had lightning speeds when I tried at a few wireless hotel connections. By lightning speeds I mean the entire 103MB donwloading complete in something like 20 seconds or so. So that's almost definitely not a problem with Oolite nor the expansion management system.

Some more pros:

* Easy of newcomers to see that there are expansions to be had / added to the game
* Easy to see which OXZ already installed
* More integrated system
* No need to understand file structures or whatnot.

I like the OXZ system, but also use the OXP system in certain cases.
For me OXPs fall into two types:
1. those I don't/can't mess about with.
2. those that I do small changes to suit my tastes.

For type 1 the OXZ system is great and I use it.
For type 2 the OXZ system is a problem. Currently I am using some OXPs I had from 1.77 as the OXZ would revert them to the standard.
In the future I could unZIP any OXZ I need and alter it and use it as a OXP without a problem, as I've learnt a little from 1.77.
So no real issue

tinker wrote:

Now the Con's.
The manager cannot work with existing OXP's you you end up sorting through folders anyway. It also does not handle dependencies well, just a vague you may need to add or remove other expansions, this may be manually if it is an OXP or through the manager but possibly on a different page.

I agree the dependencies part could use some work.. hopefully this will be resolved in 1.82.

tinker wrote:

Downloads are so slow that it is not worth trying anything over a couple of Mb. At least if you had a slow download of an OXP you could still use the system to check emails, surf the forums or anything else.

I'm not sure how you're defining 'slow'.. it's generally pretty fast for me, and I'm in Australia downloading from a server in the UK. 100MB+ files take a few minutes, but that's still not too bad.

tinker wrote:

Next is perhaps the biggest problem, what to do with a broken OXZ? There are, for example, several extensions that reference a core ship model which no longer exists, the solution was easy, you change the reference to a similar ship that does exist.

Which OXZs are you referring to? That should have been fixed during testing when the OXZ conversion was done. If it hasn't been, the maintainer should be informed.

tinker wrote:

The same problem occurs with corrupt png files, on systems where Oolite has to be compiled they are often using the newest version libpng which catches thousands of errors, these png's can easily be corrected in an OXP.

Well, if you're using a cutting-edge OS like Arch or Gentoo, an occasional hassle is to be expected. For 99.8% of Linux users, it's not a problem. Have you been in touch with Lone_Wolf about their proposed solution for this, yet?

So they are a step towards an improvement.

If most users fall in the Joe User category then that is fine, any improvements in things like dependencies and searching will only make it better.

There does need to be better testing of extensions before release I would suggest, GRS buoys for example gives as an error. YAH had an upgrade this week and, though I have not checked it yet, I assume most of the png's need to be repaired again so I will need to get the OXZ and extract the OXP and repair it before use. As this probably only affects 1% of Linux users I do not see it being fixed here and Arrch Linux devs seem to be of the opinion that it is a problem for Oolite to solve, not for them to require obsolete libraries.

As for d/l speed random hits resources takes 3 hours, immediately afterwards I did a 700 Mb d/l in 15 minutes, so I do not know where the slowdown is but I consistently get slow speeds through the manager and better speeds any other method.

tinker wrote:

...and Arrch Linux devs seem to be of the opinion that it is a problem for Oolite to solve, not for them to require obsolete libraries.

I will have to take exception to that. Speaking for myself only, I definitely don't see this as a problem and nothing needs resolving. Oolite gets distributed with a set of libraries that have been extensively tested and are known to be working and, as I don't have all the time in the world to dedicate to development, I'd rather use whatever little of it there is to work on the game itself, rather than on the libraries that support it. At least doing it this way I know that when a bug pops up it's because I did something wrong in the game's code and not because the latest version of libpng or whatever other library may have a subtle problem somewhere. Rolling releases may be nice, but they do have disadvantages too and that's probably the biggest one of them.

This is my personal opinion only of course, but I think that doing it this way has served us quite well up to this point.

tinker wrote:

Having used the manager to install an extension you then need to ferret about through to a 6th or 7th level folder to find it so you can extract and read the readme. I know not many people read them but now they have an excuse.

The readme should be a synopsis of the OXZs wiki page which is linked to from the manager, so anybody can read all they need to know about an OXZ before they even download it.

tinker wrote:

Next is perhaps the biggest problem, what to do with a broken OXZ? There are, for example, several extensions that reference a core ship model which no longer exists, the solution was easy, you change the reference to a similar ship that does exist.

Well, this is not the fault of the manager itself or the OXZ system. it is simply that the conversion clearly hasn't been done or tested properly - quality control is the responsibility of the author and you can't 'blame' Oolite for problems like this.
Doing a decent job of a conversion takes time (don't I know it!), and sadly it seems some may have been rushed through. Hopefully in time these will be corrected.

tinker wrote:

So for Joe User who never reads manuals or log files OXZ's maybe of use, Jane User who knows her way around her system and wants everything working as it should would probably prefer not to use OXZ's but has to due to more extensions not being offered as OXP's. I'm with Jane on this.

I totally disagree with this. The whole point of OXZs and the manager is to make life easier for users, both in terms of finding them (they are right there in the game now, not on some obscure wiki page), downloading them (you simply click on them now) and installing them (no looking for the special folder they have to go in, no wondering what you have to do with a zip file etc). And there is no reason why everything shouldn't work properly - indeed the opposite is true. In this they are a total success.
And of course, if you have the desire and know-how to tweak things to your taste, you are almost certainly savvy enough to do this.

another_commander wrote:

What needs to be clear here is that OXZs are managed expansion packs As such, they are not meant to be tampered with and therefore any concern about editing files within them should not be a concern in the first place. In the same context, the answer to the question "what to do with a broken OXZ" is "remove it". If anyone wants to tamper with files, they can always unzip and install as standard OXPs.

I strongly disagree with this. I strongly encourage people who download my ships, to modify them as they see fit. I include resources in an "Extras" folder to help them do just that. The point of mods, is to allow players to make the game whatever they want iti to be. And, as shown by the "Tinkerer's Workshop - OXP tweaking for fun and profit" thread, modifying oxps is a major part of that! Yes, can they go find the oxz, then rename it, then unzip it, then modify it, then move it to the Add Ons folder if they think they will want to make further changes... It is a bit of a pain.

My issues are the inability of the game to recognize the fact that I have an oxp that I downloaded from the wiki. Random Hits Resources is a good example for me as well. I too gave up trying to download them via the game after about 8 minutes. I have a 20 mb connection here in the states, and it only took me about 3-4 minutes from the wiki. Anyways, now of course the game does not acknowledge that I have the necessary resources. They still work in the game obviously, but, surely, something can be done to allow the game to acknowledge oxp's as well as oxz's.

Another issue, are oxz's with dependencies, that do not tell you, specifically, what those dependencies are. This is a problem with authoring, I understand, but an issue never the less.

Images. How many of these "newbies" for whom this system seems to be designed for, are going to download a ship oxz, when they have no idea what it looks like. If they have to come to the wiki to find out in the first place...

I do think the oxz's are a step in the right direction. But I also think more steps are needed.

My issues are the inability of the game to recognize the fact that I have an oxp that I downloaded from the wiki. Random Hits Resources is a good example for me as well. I too gave up trying to download them via the game after about 8 minutes. I have a 20 mb connection here in the states, and it only took me about 3-4 minutes from the wiki. Anyways, now of course the game does not acknowledge that I have the necessary resources. They still work in the game obviously, but, surely, something can be done to allow the game to acknowledge oxp's as well as oxz's.

If you placed the OXP in the correct folder, the game will recognize it.

tinker wrote:

There are, for example, several extensions that reference a core ship model which no longer exists...

This point is worth clarifying I think. All the old/original models and their textures are still included in the main game download. Although this adds bloat, they were left in to allow older OXPs which use them to continue to work. Whatever the problem is that you are referring to, it will not be due to lack of the models.

I have no problems at all with OXZs or the in-game Manager - if I need to tweak one, then it goes into AddOns as a normal OXP.

Zireael wrote:

My issues are the inability of the game to recognize the fact that I have an oxp that I downloaded from the wiki. Random Hits Resources is a good example for me as well. I too gave up trying to download them via the game after about 8 minutes. I have a 20 mb connection here in the states, and it only took me about 3-4 minutes from the wiki. Anyways, now of course the game does not acknowledge that I have the necessary resources. They still work in the game obviously, but, surely, something can be done to allow the game to acknowledge oxp's as well as oxz's.

If you placed the OXP in the correct folder, the game will recognize it.

I do place them in the correct folder. The game recognizes them. The oxz manager does not.

Paradox wrote:

I do place them in the correct folder. The game recognizes them. The oxz manager does not.

It will if there's a manifest.plist file in them. That's all it is seeking/recognizing in either location.

A lot of this is a consequence of the takeup of the OXZ format being rather faster than I expected - I was thinking we might have maybe 50 or 60 by now, based on takeup of previous new OXP features. I was expecting rather more time than there actually was to work on the interface before it really became an issue. So, 1.82 for that, but it's definitely on the list.

Wildeblood wrote:

It will if there's a manifest.plist file in them.

Indeed. If you do release OXP versions of OXZs, don't forget to include the manifest file in them as well.

Paradox wrote:

Another issue, are oxz's with dependencies, that do not tell you, specifically, what those dependencies are.

In the short-term, report bugs in the threads in the Expansion Pack forum if you have time.

I'm currently working on getting the OXZ manager to automatically download missing dependencies for you, if they're available in the index, which should help a lot with that and make it easier to distribute OXZs with multiple dependencies.

tinker wrote:

I consistently get slow speeds through the manager

There's a bug in Gnustep on Windows that causes serious problems when downloading anything above about 15Mb in size. 1.80.1 will have a workaround for that.

I've not heard of any similar problems on Linux, though (it doesn't download as fast as wget, but it's still a few Mb/s for me).

I'm sure this has been thought of/dealt with, but...

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.

OXZs must be sanity checked by Oolite on request and on them being downloaded. OXP folder hierarchies should be able to be tested on request.