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.
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.
aegidian wrote: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).
cim wrote: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.
aegidian wrote:1. disregard any files, OXPs, OXZs that aren't explicitly stated as dependencies.
This is the tricky bit, I think.
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.
Zireael wrote: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.)