Are OXZ's an improvement ...

[Switeck]

Whilst those voiced are definitely valid (and there is no argument from me that those who may want to progress from downloaders to tinkerers and modders should be given all the tools and encouragement to do so) I would just like to remind people that the silent majority do exist and should not be forgotten in all of this discussion.

Which is why it's important to point those who care to become tinkerers and modders in the right direction.

With readmes that are easy to find.
With game instructions about what OXZs are and how they work.
And why OXZs are not in the AddOns OXP folder.

When an add-on doesn't work as players expected it to, or worse when they get killed by an out-of-place add-on's super-ship or super-missile and they think that's just the regular game...and "it's too hard, I don't want to play anymore"...we've lost them.

[Cody]

For most players who just want to be given blocks to build their own custom version of the game then the OXZ format is perfect.

<nods>

[Smivs]

Agreed here as well.
Just based on the OXZ downloads I get the feeling that many more players are now using expansions than before, and that the fact that the whole thing is more or less automatic and requires no input other than selection is one reason for this.
So on that basis the current OXZ via the manager system is fine.
On the other hand I am fully in agreement that this takes away a basic principle of Oolite, namely that everything should be open to easy tinkering.
Hopefully a re-jigged system can reconcile this and give an easy download which also allows for easy tinkering.

[aegidian]

For most players who just want to be given blocks to build their own custom version of the game then the OXZ format is perfect.

<nods>

Provided it doesn't discourage anyone from making their own customisations. Which, sadly, it currently does.

It's an okay format for delivering expansions, but a poor one for allowing mods to be easily accessed for customisation. And that's the baby that I'm concerned to ensure isn't thrown out with the bathwater.

[ClymAngus]

So, not compromising the silk smooth experience of the silent playing majority BUT;

also easing the seduction into the wonders of user made content......

It's a tall order. Keeping everyone happy.

[Smivs]

It's a tall order. Keeping everyone happy.

True, but if anyone can do it, we can

[JensAyton]

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.

This is where the thread started going very wrong for me. I first proposed OXZs as the one and only expansion pack format for Oolite 2.0, and the explicit use of zip files was chosen precisely so it would be easy to poke around in other people’s mods. The ability to do this (both with mods and original game data) is vital to a strong modding community, which is most of the value of Oolite. The purpose of a single file is to simplify the user experience for less technical users by treating the expansion pack as a single entity on all platforms. It is not to make it harder to “tamper” with them.

People shouldn’t add or remove files from Managed AddOns behind Oolite’s back, but this is completely orthogonal to the matter of file format. It makes perfect sense to manually add and remove OXZs in AddOns, and to copy them out of Managed AddOns to expand them and examine them.

It is therefore, not as worthy, or good, or valid, as the OXP folder hierarchy format. It should be deprecated.

I don’t think this is internally consistent, given that OXPs are packages in OS X, Oolite’s native environment. Unzipping an OXZ is no harder than showing the contents of an OXP, and both are significantly easier for a new user to deal with than an oddly-named folder (that may or may not contain user-oriented documentation and stuff).

Would that resolve the issue with opacity of OXZs? (On Windows, anyway. I assume similar things can be done on Mac OS?)

On Mac OS X, it Just Works; there is type metadata in Info.plist that specifies that OXZ is a subtype of Zip.

---

1. disregard any files, OXPs, OXZs that aren't explicitly stated as dependencies.

This is the tricky bit, I think.

OOFileScannerVerifierStage already implements case-sensitive checking for files that are either in the OXP being scanned or (optionally) built into Oolite. Adding support for dependencies shouldn’t be hard. It sounds like less work than adding zip support.

Frankly, I don't see many OXPs which will still attract people without updates/conversion. Maybe Anarchies and GalNavy...?

Assassins? I tend to think of the legacy script engine as basically Assassins Support Mode. (Actually, that’s a feature that should have been banned from OXZs.)

[aegidian]

It is therefore, not as worthy, or good, or valid, as the OXP folder hierarchy format. It should be deprecated.

I don’t think this is internally consistent, given that OXPs are packages in OS X, Oolite’s native environment. Unzipping an OXZ is no harder than showing the contents of an OXP, and both are significantly easier for a new user to deal with than an oddly-named folder (that may or may not contain user-oriented documentation and stuff).

I disagree. Zipped archives cannot be easily edited in place. Files in folder hierarchies (whether they are OSX bundles or not) can.

I can see no point to zipping expansions, except for delivering a single file download. And if the user needs to unzip them to examine them, well, Oolite should be doing that as a matter of course rather than leaving them archived.

OXZ as a format is not in itself evil. I'm not being deliberately dense here, I understand perfectly well how easy it is to unzip an archive and edit it (but we are already seeing problems with authors creating zipped OXPs that don't work.) The problem is that the expansion manager's insistence on the OXZ format will discourage authors who are only tinkering with a few files in an OXP from thinking that their creative work is as valid as one that has been wrapped in the zip format. I'm gravely concerned it will lead to two tiers of development: those developing their expansions into OXZs - favoured by the expansion manager but requiring some considered diligence in packaging and ensuring they don't break the game, and those playing with the data they can find to alter the game in ways that might produce some very interesting expansions, but who might not want to have to go through an increasingly complicated process in order to share their results.

I would much rather see a proliferation of imperfect OXPs that might require a little clean up, to restricting users to much fewer, more correct OXZs.

Maybe I'm mistaken, but I believe our ideal end-user is not someone who just wants to play in the Ooniverse created by a few imaginative OXZ authors, it is someone who wants to pick, choose, create and enjoy a Ooniverse of their own.


I'm old, tired, and curmudgeonly. It's more than possible that my fears about the direction I think OXZs will take Oolite are entirely unfounded. But, I have yet to see a benefit from the OXZ format that I like that could not be achieved without it. Commander Aegidian out.

[Diziet Sma]

It is not to make it harder to “tamper” with them.

Unfortunately, as Aegidean and others have pointed out, it does make it harder to 'tamper' with them.. and regardless of intention, this is undesirable.

[JensAyton]

I can see no point to zipping expansions, except for delivering a single file download.

I maintain that OXPs appearing as a single file after download by default, consistently across platforms, is a major advantage for non-technical users, and this was the original point. (Quite often, an OXP download will unzip to Foo.oxp, which contain a Read Me file and another folder called Foo.oxp, which then contains some inscrutable stuff and also another copy of the Read Me; what goes where isn’t entirely obvious.)

However, to be fair, this is less of an issue with the built-in expansion manager. At one level, it would make sense for managed expansions to be unpacked into OXPs and separate releases to be OXZs. (OXZs do have a startup performance advantage, though. Perhaps managed ones could be renamed to foo.oxp.zip as an accessibility hint for people snooping around?)

[Norby]

offer an 'extract' command

This is a good solution imho. I think the user should be able to set the automatic unpack of all downloads.
If the identifier.version.oxp folders in AddOns are declared as managed folders then the manager will be able to update the contents of these.

[Neelix]

offer an 'extract' command

This is a good solution imho. I think the user should be able to set the automatic unpack of all downloads.
If the identifier.version.oxp folders in AddOns are declared as managed folders then the manager will be able to update the contents of these.

And then how would the manager tell the difference between one that's been tinkered with and one that hasn't? Generally I would think you'd want a warning at the very least before updating an OXP that you've modified.

- Neelix

[Lone_Wolf]

offer an 'extract' command

This is a good solution imho. I think the user should be able to set the automatic unpack of all downloads.
If the identifier.version.oxp folders in AddOns are declared as managed folders then the manager will be able to update the contents of these.

And then how would the manager tell the difference between one that's been tinkered with and one that hasn't? Generally I would think you'd want a warning at the very least before updating an OXP that you've modified.

- Neelix

That could be solved by calculating a checksum or hash for every file / folder in the oxz .
It could work as follows :
generate manifest.plist for inclusion in the oxz
when developer is ready to create oxz for uploading :
a tool calculates checksums, including 1 for the manifest.plist
the checksums are stored in a separate file, then the oxz is created with the checksum file included
this oxz is uploaded to the expansion manager site, which then checks manifest.plist for validity and the checksums for correctness.
If eeverything checks out, oxz is added to expansion manger list.
if not, error message : upload not accepted .

The oolite expansion manger list can then use the checksums at run-time to verify if the oxz has been changed or not.

[Neelix]

While in principle that may sound like a good idea, in this application and given the one of the goals seems to be to make the OXP creation process as simple as possible that sounds far too fiddly...

I would suggest the following: When extracting an OXP via the manager, it records checksums of the extracted files then run comparisons each time the list is compiled to see if it can still manage that OXP.

- Neelix