Oolite Bulletins

Ahruman wrote:

The Energy Bomb has been removed from the non-strict game in favour of Q-mines because, well, it sucked. When a game with an energy bomb is loaded, a Q-mine will be awarded instead, or 900 credits if you don’t have any free pylons.

If anyone really wants a kill-everything machine, it can be done in an OXP these days. Oh, wait…

A bold and sensible decision! The e-bomb, was, historically, a get-out-of-jail-free-card that always seemed out of place in Oolite...

There was a problem where ships that used the same model but different material/shader dictionaries would end up using the same cache entry and therefore share materials. This has been fixed.

As a side effect, the format for scanned wormholes in saved games has to be changed, so loading a 1.73.x saved game with scanned wormholes in trunk/1.74 and forward will result in different ships being loaded a wormhole with no ships in it.

If you’re wondering how these could possibly be connected, that means you’re paying attention. :-)

So the existence of the wormhole is still tied, through a variable, to the ship that created it? Even though it is no longer in the system and the player is only scanning the wormhole? Strange indeed

Poro wrote:

So the existence of the wormhole is still tied, through a variable, to the ship that created it? Even though it is no longer in the system and the player is only scanning the wormhole? Strange indeed :?

Every ship that passes through a wormhole is stored (until the wormhole closes) so that you can follow them through to the other side.

To expand on what Ahruman said above: It is possible that, after scanning a wormhole, the player can choose a route to the destination system that results in them arriving earlier than the ship that has entered the scanned wormhole. Given that the players may choose to save their game at any time before the projected arrival time of the vessel travelling in the scanned wormhole, it is necessary that the details of the ship that has entered it are known next time the game is reloaded. This is the reason the travelling ship's data is saved in the savefile. This way, if you load the game at a later time and manage to arrive at the destination system earlier than the ship that generated the wormhole, you will be able to "meet and greet" it when its wormhole disgorges it on the other side.

Thanks for the explanation guys.

Some announcements from mount Devolympos:

1. As proposed by Giles, the energy bomb has been reinstated and will be available in the next stable release (“MNSR”). It will be disabled by default in the version after that, which will generally focus on more “visible” core game changes.
2. In keeping with this, fuel pricing will be unchanged in MNSR.
3. Lastly, the new planet code I’ve been working on will not be in MNSR either. (This is for reasons of time rather than gameplay impact.)

Ahruman wrote:

Some announcements from mount Devolympos:

1. As proposed by Giles, the energy bomb has been reinstated and will be available in the next stable release (“MNSR”). It will be disabled by default in the version after that, which will generally focus on more “visible” core game changes.
2. In keeping with this, fuel pricing will be unchanged in MNSR.
3. Lastly, the new planet code I’ve been working on will not be in MNSR either. (This is for reasons of time rather than gameplay impact.)

I'm saddened by all three pieces of news but understand - roll on post MNSR.

I'm certainly saddened by the latter two. I was really looking forward to the planet code.

Is there a link I can go through to read about this "new planet code"?

Poro wrote:

Is there a link I can go through to read about this "new planet code"?

If you are running Windows or Linux, you can give a go at the equivalent nigthlies and see the new planets first hand. You can also have a look here for the actual code. You will have to look at src/Core/OOPlanetDrawable.h/.m, src/Core/Entities/OOPlanetEntity.h/m and src/Core/Materials/OOPlanetTextureGenerator.h/.m for the actual implementation. Note that this is not finalized yet and I am not sure that any documentation other than the source itself exists.

DAT files can now store explicit per-vertex normals. In practical terms, this means you can export a model and the lighting will look right without mucking about with smooth and smooth groups (both of which are ignored if explicit normals are provided). An updated converter tool is available. (There is no converter that goes the other way, though.)

It’s possible for a DAT to include both vertex normals for 1.74 and later and face normals for earlier versions. In the somewhat unlikely case you want to do this, change include_face_normals to 1 near the top of Obj2DatTexNorm.py.

Note: Obj2DatTexNorm.py will generally produce a file with a higher vertex count (NVERTS) than Dat2ObjTex.py, because it needs one entry for each possible vertex/normal pair. In general, this won’t affect render performance, since Oolite has to expand the data into this form internally anyway (actually one entry for each vertex/normal/tangent/tex coord combination).

Split discussion to new thread.

As a side effect of cleaning up player-specific shader bindings, I’ve fixed some stuff related to handling ship velocity, and added two new Ship properties: velocity and thrustVector. If you want to do anything with these, read the note about inertialess thrust vs. inertial velocity; it’s confusing but important.

Ahruman wrote:

added two new Ship properties: velocity and thrustVector. If you want to do anything with these, read the note about inertialess thrust vs. inertial velocity; it’s confusing but important.

The difference is probably best seen with escape pods after ejecting at injector speed. The thrust is trying to fly the ship with a slow speed of 50 towards the planet, while the velocity inherited from the mother ship is often much higher and in a different direction and only slowly decreasing. Best seen when looking at the strange angle between the direction of the exhausts plume and the pods nose during its first minute of flight until its speed decreased to its final speed.