Are OXZ's an improvement ...

[Wildeblood]

Here's a thing: in the last hour or so, someone downloaded the previous to current version of Trading Assistant. That implies they did not select "update expansions list" before they selected "install expansion pack".

Either a nag screen to "Ensure you have the most up-to-date list of expansions available", or words to that effect, needs to be included, or more simply, the advice on the Oolite.org website to use a different download URL for each new version should say the opposite: use the same download URL if possible.

[Neelix]

Here's a thing: in the last hour or so, someone downloaded the previous to current version of Trading Assistant. That implies they did not select "update expansions list" before they selected "install expansion pack".

Either a nag screen to "Ensure you have the most up-to-date list of expansions available", or words to that effect, needs to be included, or more simply, the advice on the Oolite.org website to use a different download URL for each new version should say the opposite: use the same download URL if possible.

Perhaps when starting the expansion pack manager the install option should be disabled until the list has been updated?
Allow browsing the list, but if a download is attempted advise need to updating list before installation can take place.

- Neelix

[cim]

Either a nag screen to "Ensure you have the most up-to-date list of expansions available", or words to that effect, needs to be included, or more simply, the advice on the Oolite.org website to use a different download URL for each new version should say the opposite: use the same download URL if possible.

Different download URL stops people downloading a 100Mb expansion only to find out that their list wasn't up to date and it won't install. You can always delete the old version's file.

Perhaps when starting the expansion pack manager the install option should be disabled until the list has been updated?

The list is already bigger than about half the OXPs available through it.

It should be easy to add an "N days old" notice for it, though.

[Zireael]

It should be easy to add an "N days old" notice for it, though.

That's a brilliant solution!

[maik]

Perhaps when starting the expansion pack manager the install option should be disabled until the list has been updated?

The list is already bigger than about half the OXPs available through it.

It should be easy to add an "N days old" notice for it, though.

How about implementing a check e.g. at startup that gives you the timestamp of the latest version of the list on the server which you can then compare to the timestamp of the downloaded version. When a player then enters the OXZ manager, you could inform him if the list needs an update or not.

This would cost you a single request to check at startup which can even be answered by a static response (file generated when updating the list), and a download of the list only on request from the player. Or, you could make it more expensive and precise if you did the check everytime the player entered the OXZ manager.

[cim]

Or, you could make it more expensive and precise if you did the check everytime the player entered the OXZ manager.

That would be preferable, since it would mean that you could start the game up without needing {1} internet access. Even then it still means you need internet access to remove managed OXZs, which you shouldn't.

{1} A large startup delay while the network connection times out isn't strictly needing internet access, but it's close enough.

I think in practice it's safe enough to assume that any list >24 hours old is out of date for at least one entry, though whether that matters depends on how many OXZs you have and how much you care about them being up to date.

[cim]

OXZ's need to undergo a substantial amount of sanity checking before they should be made available.

Agreed, though I'm not sure how to automate it.

Validating the OXP before packaging won't catch everything since the OXZ format is stricter - filenames are case-sensitive even on Windows, manifest is required. Authors wanting to distribute OXZs should probably also use that as their testing format while developing.

Catching missing dependencies is also tricky - if the author happens to have the dependency installed, the files will show up as present.

There certainly is more that can be done with the OXP verifier functions, though.

[JensAyton]

The list is already bigger than about half the OXPs available through it.

It should be easy to add an "N days old" notice for it, though.

The current list zips down to 30 kB. 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 (modulo normal HTTP caching behaviour).

Validating the OXP before packaging won't catch everything since the OXZ format is stricter - filenames are case-sensitive even on Windows, manifest is required.

The existing OXP verifier already checks case sensitivity. It also has infrastructure for checking if files are not provided by the OXP itself; checking whether they’re provided by declared dependencies shouldn’t be hard. If I was maintaining the verifier today, I’d make not having a manifest a warning for OXPs.

[Thargoid]

Authors wanting to distribute OXZs should probably also use that as their testing format while developing.

At the end yes, but not during developing. There are too many programs (at least under Windows) that won't play nicely with a zip file, and continually zipping and unzipping (or using temporary files outside of the OXZ zip) is a recipe for disaster - files getting lost, wrong versions being included and similar issues.

OXZs are very good for general distribution and for most users (those who actually want to just use them rather than fiddle with them), but for actual in-progress authoring then the older uncompressed OXP format is your friend.

[Diziet Sma]

Different download URL stops people downloading a 100Mb expansion only to find out that their list wasn't up to date and it won't install. You can always delete the old version's file.

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

[Diziet Sma]

Authors wanting to distribute OXZs should probably also use that as their testing format while developing.

At the end yes, but not during developing. There are too many programs (at least under Windows) that won't play nicely with a zip file, and continually zipping and unzipping (or using temporary files outside of the OXZ zip) is a recipe for disaster - files getting lost, wrong versions being included and similar issues.

OXZs are very good for general distribution and for most users (those who actually want to just use them rather than fiddle with them), but for actual in-progress authoring then the older uncompressed OXP format is your friend.

I can only assume you haven't tried cim's OXP/Z build scripts, then.. they make development using OXZ format a breeze. Just edit your files in your project's folder (can be anywhere on your computer), run the script, and a freshly-built OXZ will appear in AddOns. Test, rinse and repeat. Every time the script is run, the old OXZ is removed, and a new one is built on the spot and inserted. It gives you the best of both worlds, with practically no effort required. (it neatly solves all those 'lost' files and wrong version problems, too)

[Diziet Sma]

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.

Maybe I'm misunderstanding you here, but from my own experience, 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.

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.

This is due mostly to the fact that the current incarnation of the Expansion Manager reads the "dependency" field in the manifest.plist, which explicitly states which OXZ is required, but it doesn't display that information to the player. The same is true of conflicts. It will tell you there's a clash, but won't tell you which OXZ is the problem. As a workaround, I've now taken to specifically stating any dependency or conflict in the "comments" field, because I know that gets displayed to the player. See the two versions of the DTT Snakecharmer for an example.

[Zireael]

This is due mostly to the fact that the current incarnation of the Expansion Manager reads the dependency field in the manifest.plist, which explicitly states which OXZ is required, but it doesn't display that information to the player

I hope it gets displayed soon - btw, cim, thanks for the color changes!

[Neelix]

Authors wanting to distribute OXZs should probably also use that as their testing format while developing.

At the end yes, but not during developing. There are too many programs (at least under Windows) that won't play nicely with a zip file, and continually zipping and unzipping (or using temporary files outside of the OXZ zip) is a recipe for disaster - files getting lost, wrong versions being included and similar issues.

OXZs are very good for general distribution and for most users (those who actually want to just use them rather than fiddle with them), but for actual in-progress authoring then the older uncompressed OXP format is your friend.

I can only assume you haven't tried cim's OXP/Z build scripts, then.. they make development using OXZ format a breeze. Just edit your files in your project's folder (can be anywhere on your computer), run the script, and a freshly-built OXZ will appear in AddOns. Test, rinse and repeat. Every time the script is run, the old OXZ is removed, and a new one is built on the spot and inserted. It gives you the best of both worlds, with practically no effort required. (it neatly solves all those 'lost' files and wrong version problems, too)

I have to agree that these scripts make developing with OXZs a breeze, In addition to the testing OXZ that it puts in the Addons folder (which always has a new timestamp so you don't have to hold shift when starting Oolite) it also builds a both an zipped OXP and OXZ in the project folder with the version number in the file name. This means that if you increment your version number in the build script when you release it effectively archives your release versions because the next time you build it leaves the old ones in place.

That being said, being that it's done with shell scripting you would probably need something like cygwin to use them in windows.

- Neelix

[Paradox]

Paradox 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.
Maybe I'm misunderstanding you here, but from my own experience, 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.

Sorry Diz, I should have specified. I downloaded the OXP version of the resources, But the in game manager does not recognize that.