On we go...
Most importantly, as you'll already have seen, the nightly builds are now pointed at the 1.79 developments, so you can try out all this new stuff yourself much more easily. Take a backup of your savegames first just in case, though! We've got a few bug fixes in already from early testing, and I expect to be doing quite a bit more over the next couple of weeks.
Thanks to CaptSolo and Griff, the asteroid models are now also updated and retextured.
Now, a couple of big changes which we've been working on in the last few weeks, which you should be able to try out in tomorrow's build.
Expansion pack format
The first is a new format called OXZ for distributing expansion packs: the old format still works, but this one is designed for ease of end user distribution - it's just a single file (with an .oxz extension) which you can download and place in your AddOns folder.
Here's an OXZ version of Camera Drones if you want to give it a go.
The OXZ is basically just a renamed ZIP file, with the various folders of an OXP as subfolders within it. At the top level of the structure there is a new file called
manifest.plist, which looks like this:
Code: Select all
{
identifier = "oolite.oxp.cim.camera-drones";
version = "1.3";
title = "Camera Drones";
required_oolite_version = "1.77";
description = "Drone cameras which provide a variety of alternative external views for your ship";
category = "Equipment";
author = "cim";
license = "CC-BY-SA 3.0";
download_url = "http://compsoc.dur.ac.uk/~cim/oolite/Camera_Drones_1.3.oxz";
information_url = "http://wiki.alioth.net/index.php/Camera_Drones";
}
and is used instead of
requires.plist. It has a lot of fields - only the first four are required by Oolite, though many of the others are worth entering. I'll put some documentation of what fields are available and what they're used for up on the Wiki soon.
You can also explicitly specify dependencies - if an OXZ requires another OXZ to function, or conflicts with one, you can add an entry and it won't try to load it unless the requirements are met. Obviously this is only generally useful for OXZs since the existing OXPs don't have a manifest.plist (though there's nothing to stop you adding one - it's harmless in 1.78 or earlier and will be processed for OXPs as well as OXZs in 1.79 or later)
The filesystem within an OXZ is explicitly case-sensitive, so this should stop some problems with OXPs developed on Windows not working properly on Mac or Linux.
OXP format continues to work as before, of course.
Sound changes
The second big change came out of that one, due to a problem with accessing sounds inside zip files in the SDL sound library we were using on Windows and Linux. We've now moved to OpenAL for sound support, across all three supported operating systems. OpenAL is a
positional sound library, so rather than just simple stereo or mono sounds, it can make sounds appear to come from any specified direction. You'll now be able to hear where those hits on your hull are striking, if you have a good enough sound set up, and at least be able to tell the difference between "hit on left side" and "hit on right side" even just with headphones.
For OpenAL to position a sound, it has to be recorded as mono. Previously this hasn't mattered and a lot of sound sets - including Oolite itself - have had a random mix of stereo and mono sounds. In general - and OXPers may be able to find exceptions to this rule, which is why we're not enforcing it within Oolite - you should probably make the contents of the Sounds folder mono and the contents of the Music folder stereo.
The SoundSource JS object now has three extra properties, all of which can safely be changed while a sound is playing:
-
positional (whether the sound is positional [1])
-
position (where the sound is coming from relative to the player. This is a vector, in player-ship coordinates, with the player being assumed to be at the origin)
-
volume (the relative volume of the sound from 0 to 1)
[1] Strictly, all mono OpenAL sounds are positional. Setting this to false forces the position to be the same as the listener.
If you're compiling your own, then on Linux, you'll need to install libopenal-dev or a similarly-named package from your distribution. Windows dependencies are included, and it's a system library on Mac OS, so those should be fine.
