At times, we’ve also referred to EMMSTRAN, the Even More Mythical STable Release After Next. As we approached the feature freeze, this has popped up in feature requests, bug reports and code comments for things we’ve chosen not to fix until after MNSR. But internally, we’ve had a simpler name for it: Oolite 2.0.
What is Oolite 2.0?
First of all, this is Oolite 2.0, the significant update, not Oolite II – The Sequel. It will still be based on Elite.
Secondly, everything here is preliminary. We’ve been bouncing around ideas for 2.0 for over a year, but development is just starting.
The main reason for the major version bump is that we’ll be removing a lot of backwards-compatibility features. In fact, Oolite 2.0 will not work with any current OXPs, and saved games will not be backwards-compatible (but Oolite 2.0 will be able to load 1.x saved games).
There will also be more player-visible changes than in 1.76. In particular, the graphics will be almost completely replaced (primarily based on Griff’s ships – his forum title stopped being honorary in late 2009). We hope to improve the graphics engine – a lot. We hope to implement positional audio using OpenAL. There will also be gameplay balance changes; for instance, as previously announced, the energy bomb will be going away. We’d like to implement NPC shields. Strict Mode will be removed. (If you want it, well, 1.7x will still exist.)
Oolite 1.75/1.76 is almost fully backwards compatible, not only with OXPs but with hardware. We no longer support Mac OS X 10.3, and the IRIX port hasn’t been maintained for a while, but apart from than that any system that runs 1.65 should run baseline 1.76, probably better. Oolite 2.0, on the other hand, will raise the bar; not very high, but still appreciably higher. It will require at least OpenGL 2.0, and probably some extensions. For the Mac, it will require an Intel Mac with Mac OS X 10.6. Our CPU baseline is likely to be low-end Core 2 Duos.
The process
Again, development is just starting. In fact, I’m about to make the initial 2.0 code repository public, which is why we’re announcing this now. 1.76 is obviously a priority, but starting 2.0 now lets us do some actually fun coding between bug hunting, and provides a sink for our creative impulses.
There are some technical administrative changes to the actual development process. The most noticeable one is that we’re switching to a different version numbering scheme, where odd minor versions are development versions and even ones are releases. The initial development will be 1.89, and the first test release will be 1.90.
Oolite 1.7x will be the stable, recommended version of Oolite for quite some time, and it will continue to be maintained with bug fixes and possibly minor feature updates. Even after 2.0 is released, 1.7x may be preferable to users on low-end systems, or Strict Mode hard-liners. It won’t be abandoned like 1.65 was.
What was that about OXPs?
The OXP community is the heart and soul of Oolite. Without OXPs, the past half a decade of Oolite development would have been pointless.
However, there is a great deal of cruft in the OXP development interface, especially in the configuration files. Breaking compatibility in a half-hearted way, defining “best practices” and making everyone go through repeated compatibility tests doesn’t appeal. It would be like the scripting interface development process, only without the fun. Instead, the goal is to simplify the OXP authoring process by removing multiple ways of doing the same thing and making configuration files and scripts more similar.
The plan is to make much of the OXP conversion process automated. This is reasonably easy for configuration files, but intractable for scripts and shaders. Scripts will probably need minor updates. Shaders will almost certainly need to be rewritten from scratch (although we hope to increase the amount of stuff you can do without writing custom shaders in the first place).
We fully expect controversy over the changes. If you have specific criticisms – or suggestions for things that should be removed or simplified – we’d like to hear them. But if your response amounts to “I like it just fine as it is”, we respectfully ask that you wait until you’ve seen what the alternative actually looks like.
Some specifics
Again, please remember that this is preliminary.
- There will be two expansion pack formats: a directory-based format similar to OXPs (tentatively called OXD), and a single-file format (OXZ) that’s essentially a zip file. The “end-user” version of Oolite 2.0 will only support OXZ, while OXD will be supported in the “developer” version. A single-file format is less confusing to users, and avoids file-system-specific issues like case sensitivity.
- Expansion packs will be required to have a “manifest” that specifies their name, version, and a unique identifier, along with some optional data. This will allow expansion packs to explicitly refer to each other – for example, to specify dependencies or load order constraints in the manifest.
- Property lists will be replaced with a format based on JavaScript. (If you’re familiar with JSON, this is essentially what you thought JSON was just before you became familiar with it. In particular, comments are permitted.) This solves two problems: we’ll be using the same parser on all platforms, and the syntax will be the same as in scripts instead of being confusingly similar yet different.
- While we’re at it, configuration file keys will change to camelCase, and match script properties as closely as practical. Shader uniform bindings (or their replacement, depending how things work out) will also use the same keys. This “shared vocabulary” should make expansion pack development more approachable and also make it easier to write complete and consistent documentation.
- Less stuff will be implicit, based on roles, scan classes or (worse) combinations of them. For example, all stations will need to have
isCarrier: truein their shipdata entries. - Similarly, there will be less flexibility in some situations. For example, there are currently at least five ways to specify colours (not counting special cases like the old flasher syntax). In 2.0, all colours will be specified as arrays of three or four numbers (RGB or RGBA components).
- The DAT model format will be replaced with a more efficient and more flexible format. The new format allows material properties to be specified in the model where they belong (which makes it easier to import them from other 3D mesh formats), and permits arbitrary vertex attributes; for instance, you could have multiple sets of texture coordinates, or per-vertex colours, as long as you write a shader to make use of them. The only requirement is that there’s a
positionattribute to use for geometry calculations. The syntax of the new format is identical to the new configuration syntax, but with extra constraints on the structure of the file. - Mission variables will support all JSON types directly. If you put a string in, it will always come out as a string, not be converted to a number.
Code: Select all
{
adder:
{
aftEjectPosition: [0.0, -4.5, -23.0],
aftWeaponPosition: [0.0, 0.0, -22.5],
AI: "scavengerAI.plist",
autoAI: true,
cargoSpaceCapacity: 5,
cargoSpaceUsed: { min: 0, max: 1 }, // likely_cargo = 1
cargoType: "CARGO_NOT_CARGO",
energyRechargeRate: 2,
exhaust:
[
[-5.75, 0.0, -22.5, 6.0, 4.0, 4.0],
[5.75, 0.0, -22.5, 6.0, 4.0, 4.0]
],
forwardWeapon: "WEAPON_PULSE_LASER",
forwardWeaponPosition: [0.0, 0.0, 22.5],
fuel: 7.0,
equipment:
[
{ equipmentKey: "EQ_ECM", probability: 0.01 },
"EQ_FUEL_SCOOP"
],
maxEnergy: 85,
maxFlightPitch: 2,
maxFlightRoll: 2.8,
maxFlightSpeed: 240,
maxThrust: 30,
missileLaunchPosition: [0.0, -2.5, 16.0],
missileCount: 1, // “missiles” is reserved for explicit array of identifiers, similar to JS Ship semantics.
model: "oolite-adder.oomesh",
name: "Adder",
portWeaponPosition: [-15.0, 0.0, -14.5],
roleWeights:
{
hunter: 1,
scavenger: 1,
shuttle: 1,
hermitShip: 1
},
scoopPosition: [0.0, -2.0, -7.5],
starboardWeaponPosition: [15.0, 0.0, -14.5]
}
}
)
