OXP Distribution

From Elite Wiki
Jump to: navigation, search

Making sure that users can easily find, download, understand, and install your OXP helps making it more popular and keeps requests for help to a minimum. The following best practices help you achieve that.

General

  • Make sure that the file names in your plists precisely match the actual file names, including the capitalization. File names on non-Windows systems (and even on Windows when using OXZ format) are case-sensitive.
  • Include requires.plist and manifest.plist in your OXP (if using OXZ format, requires.plist can be omitted)
  • Avoid file names with spaces. They make it harder for people who use the command line.
  • Avoid the use of generic names for textures, models, scripts, and keys in .plist files as they may lead to conflicts with other OXPs. Prefixing the names with the OXP name is recommended (e.g. "MyOXP_MetalTexture.png" not "MetalTexture.png")

Distribution in OXP format

The OXZ format has very specific rules, but OXPs distributed as a .oxp folder inside a compressed file do not. These recommendations will help with distributing in that format

Packaging

  1. Create a directory named after your OXP, e.g. "MyNewOXP_x.y.z_yyyy-mm-dd". Make sure this directory does not end with the .oxp suffix.
    • Replace x.y.z with the version number, e.g. 1.0.0 for the initial release, or 1.0.1 for a small follow-up bug fix release.
    • Replace yyyy-mm-dd with your OXP's new release date (yyyy: year, mm: month, dd:day), e.g. 2011-03-05 for March 5th, 2011.
  2. Inside "MyNewOXP_x.y.z_yyyy-mm-dd", add the readme, the license, and additional files, and the actual OXP directory, named MyNewOXP_x.y.z_yyyy-mm-dd.oxp. Make sure this directory does end with the .oxp suffix.
    • If you prefix the names of the readme and license files with MyNewOXP you are making it easier for users to keep all files that belong to OXPs in one place.
    • If you instead put the readme etc. files into the .oxp directory then Mac users will have a harder time finding them as .oxp directories are presented as packages.
    • Several OXP authors put a copy of the readme and manuals in both the main folder and the OXP folder. This covers most situations/OSes.
    • See the Licensing OXPs thread on the Oolite Bulleting Board for information about licensing.
  3. Inside the MyNewOXP_x.y.z_yyyy-mm-dd.oxp directory add the Config, Models, etc. directories that make up your OXP.

Example:

MyNewOXP_1.0.1_2011-11-17
+- MyNewOXP readme.txt
+- MyNewOXP license.txt
+- MyNewOXP_1.0.1_2011-11-17.oxp
   +- Config
   +- Models
   +- Shaders
   +- Textures

Distribution

  1. Create a zip file based on the "MyNewOXP_x.y.z_yyyy-mm-dd" directory and name it "MyNewOXP_x.y.z_yyyy-mm-dd.zip"
    • While there are other, more efficient compression tools (such as rar, 7z), zip is available out-of-the-box on all operating systems that are officially supported by Oolite.
    • If you are working on a Mac, please use either a compression tool like YemuZip, or the "compress" command from the context menu in Finder followed by a run through ZipCleaner. Otherwise, OS X specific files that are not relevant for other platforms will be included and lead to confusion.
  2. Upload the zip file to an easily accessible online storage. Most OXP authors use box.com for distribution nowadays. It is free up to 5GB and does not annoy your users with advertisements.

Announcement

When you start work on an OXP and wish to make this known start a new thread in the Expansion Packs forum of the Oolite Bulletin Board (BB). The title of the thread should be the name of the OXP preceded by [WIP] as long as the OXP is under development. When you decide your OXP is finished, it is recommended that you change [WIP] to [Release].

  • Screenshots in the BB post are much appreciated.
  • Create a wiki page for your OXP if you can, or ask around the BB for help with setting one up.
  • At the very least, provide enough information for creating a one-liner in the OXP List.

From Oolite v1.80 you should use the new OXZ format, which is required to appear in the in-game oxz manager. Please read The All-in-One Guide to OXZ Packaging and Distribution.

Updating

  1. Always update the version number, no matter how small the change is.
  2. Update your readme file with a new entry to the version history.
  3. Rename the directories based on the release date of your new version, create a new zip file, and upload it.
  4. Both modify the first post in the OXP thread that you created, and post a new message in the same thread. In the first post, update the download location and provide up-to-date version information. In the new message, mention that there is a new version and give whatever other information is necessary.
    • If you only modify the first post, then the BB will not show that the thread changed. If you only add a new post, users will miss the new version if they only look at the first post.

Packaging Retexture/Remodel OXPs

If you are making an OXP which adds alternative versions of the core Oolite ships or replaces the core Oolite ships entirely we suggest you follow these guidelines to ensure compatibility with similar OXPs. This modular format also allows end-users to easily customise their 'mix' of ships.

  • Firstly create an OXP named ShipSetName_Resources.oxp or similar. This should include the Models, Shaders, and Textures folders required for your ships. As is generally advised the names of the individual models, shaders and textures should be unique.
  • Secondly create two separate OXPs named ShipSetName_Replace.oxp and ShipSetName_Addition.oxp or similar. These should contain the Config folder for your ships. End users can install one or the other depending on whether they want your ships to replace the core Oolite ships entirely, or if they want your ships to appear in addition to the core Oolite ships, or in addition to another retexture OXP which has replaced the core Oolite ships.
  • The shipdata.plist in ShipSetName_Addition.oxp should reference each ship with a unique identifier. For example your version of the adder may be referenced as "ShipSetName_adder". You will also need to include a shipyard.plist referencing the ships that are player purchasable. You should use like_ship to copy the template entries from the main ship data, for example
"ShipSetName_adder" = {
  like_ship = "oolite_template_adder";
  /* Your modifications for any parameters you want to change like
   * model, shaders, textures, weapon and view positions go here */
};
  • The shipdata.plist in ShipSetName_Replace.oxp should reference ships that are the direct equivalent of an core Oolite ship with the same name as is used in the core game's shipdata.plist (this file is found in Oolite\Oolite.app\Resources\Config). For example your version of the adder would be referenced as "adder". This will result in your ships replacing the equivalent core Oolite ships entirely. If your package includes a version of the "cobra3-player", new Jamesons will start the game flying your version. Any ships which do not have a direct equivalent in the core game's shipdata.plist should retain their unique name. You will only need to include a shipyard.plist if you are including ships which do not have a direct equivalent in the core game's shipdata.plist.
"adder" = {
  like_ship = "oolite_template_adder";
  /* Your modifications for any parameters you want to change like
   * model, shaders, textures, weapon and view positions go here */
};


  • End users will need to download the ShipSetName_Resources.oxp and either the ShipSetName_Addition.oxp or the ShipSetName_Replace.oxp depending on their preference. In general end users cannot install multiple 'replacement' type retexture OXPs without them conflicting. However they can install one 'replacement' type retexture OXP, and as many 'addition' type retexture OXPs as they wish to achieve more variety of ships in game. Providing your retexture/remodel OXP in this format facilitates this end user choice.