Oolite Bulletins

Ahruman wrote:

Cube-mapped planets now have their poles in the right place. (I set out to fix this and found that it already worked. Don’t know when that happened.)

Mystery solved: Eric fixed it in November, when I wasn’t paying attention. A bit of an anticlimax to find that my last major task was already done, but that’s a disappointment I can live with. ;-)

Ahruman wrote:

Mystery solved:

Yep, I only wrote something about changed rotation axis in the comment because the mapping itself was always correct for the cube maps. The sun now keeps shining above the main planets equator. Nothing should keep texture makers to add planets with ice caps now

-----
Update for thargoid containing oxps

The npc missile launches always had an interesting 'feature' that when the missile_launch_position was defined inside the bounding box, the missile got 10 m/sec extra speed for every meter it was from the outside of the bounding box. This resulted in launch positions close to the ships center having a very strong extra speed boost. Examples are the thargons from the thargoids that were thrown out at high speed, for the internal thargoids, while ox's that used a more correct position, like the Griff ones, didn't have that extra speed.

Somehow that looked wrong. And now it seems that even the direction was wrong: not away from the ship, but always along the same system vector, no matter of the position of the ship. The only thing preventing missiles from crashing was additional code that made missiles crash-proof during the first 0.25 seconds of their existence.

Anyhow, this code is now removed, resulting in a new problem: the missile_launch_position of thargoids was defined exactly behind the ship at the same position as the aft_eject_position. This will cause thargons to immediately crash into their mother. I examined many ox's with thargoids and all added the thargons wrong. The only exception are Griff his thargoids.

Trunk will now check for such wrong launch positions at [0,0,-x] and replace it with a default position. It will also write an error to the log to inform that the position was wrong, so that oxp makers know that they have to update their work.

Gold star for Griff!! *smug face*

Griff wrote:

Gold star for Griff!! *smug face*

Have five team points as well.

Custom docking ring models are no longer supported. The implementation of this feature was unsafe, and relied on old model loading code that is no longer used for anything else.

As a partial replacement, the new implementation uses a distorted regular polygon defined by three station properties: tunnel_corners (ranges from 4 to 128), tunnel_start_angle (in degrees; 0 means the first corner is straight up) and tunnel_aspect_ratio, which is the proportion of the tunnel’s width to its height.

The default values are 4, 45 and 2.67, which produces the same rectangular appearance as in 1.74. The rock hermit uses 6, 0, 1 for a hexagon.

Ahruman wrote:

As a partial replacement, the new implementation uses a distorted regular polygon defined by three station properties: tunnel_corners (ranges from 4 to 128), tunnel_start_angle (in degrees; 0 means the first corner is straight up) and tunnel_aspect_ratio, which is the proportion of the tunnel’s width to its height.

No triangular docks, then?

If you really, really want them, I can lower the limit. :-)

Edit: Actually, I lowered it anyway because purely arbitrary limits are silly.

Be like a giant shape-sorter for Boa Class Cruisers

Smivs wrote:

Be like a giant shape-sorter for Boa Class Cruisers

I like this idea. Although we're just talking about the tunnel effect which has no bearing on the actual dock size.

But of course you could do something like that with the actual dock subentity. I would of course prefer something in the shape of an Imperial Courier.

Commander McLane wrote:

Smivs wrote:

Be like a giant shape-sorter for Boa Class Cruisers

I like this idea. Although we're just talking about the tunnel effect which has no bearing on the actual dock size.

But of course you could do something like that with the actual dock subentity. I would of course prefer something in the shape of an Imperial Courier.

It'd end up looking like "Hole in the Wall"

DaddyHoggy wrote:

Commander McLane wrote:

Smivs wrote:

Be like a giant shape-sorter for Boa Class Cruisers

I like this idea. Although we're just talking about the tunnel effect which has no bearing on the actual dock size.

But of course you could do something like that with the actual dock subentity. I would of course prefer something in the shape of an Imperial Courier.

It'd end up looking like "Hole in the Wall"

I like it. Vets go go go.

Or maybe not

I forgot to mention this a while back: there’s a new special script called oolite-locale-functions.js, which defines functions that may need to be modified by localization OXPs (although the default implementations can also be customized by modifying descriptions.plist).

The public functions currently defined are formatInteger(value : number) and formatCredits(value : number, [includeDeciCredits : boolean, [includeCurrencySymbol : boolean]]). The first formats integers in a language-sensitive way – in particular, dividing it into groups with spaces. The second formats a value in credits.

formatCredits() is used wherever Oolite displays a currency value, including when expanding the description token “[credits_number]” for JavaScript (except when used directly in legacy scripts, as it may be used for arithmetic).

As discussed above, beacon icon data is now looked up by beacon code instead of primary role. Beacon codes of a single letter are always treated as letters, with no icon lookup.

I’ve finally added the much-needed entityDestroyed() ship script event. This fires immediately after a ship becomes invalid (i.e., before any other script code can run) regardless of what happened to it. There is one exception: when the game session ends (reset for a new session, or quit) the event doesn’t fire. Since there should be no way for a script to need to clean things up in this situation, I don’t think that should be a problem.

Ahruman wrote:

I’ve finally added the much-needed entityDestroyed() ship script event.

What will be the practical difference to shipDied() for scripting purposes? I understand that entityDestroyed() will trigger earlier. So what should be done in it, that shouldn't be done in shipDied()?