Oolite Bulletins

I noticed the macro time is not yet part of trunk. But you can easy add it to your macros by typing in the console: After that the :time works as advertised in the previous messages

Actually, it was checked in on the 15th of June. The issue is that macros in debugConfig.plist aren’t merged with the ones in preferences like they should be.

I suggest using the following canonical definition of :time, which doesn’t include the overhead of compiling your expression in the profile:

Thanks. Works perfect. Very interesting to get a feeling how long commands take.

console.profile(function() { system.countShipsWithPrimaryRole("pirate") }) console.profile(function() { system.shipsWithPrimaryRole("pirate") }) console.profile(function() { system.filteredEntities(this, function(entity) { return entity.isShip && entity.isPirateVictim}) }) Just counting pirates is much faster than creating an array of them. The difference is much greater than I would have thought. And I thought that a filtered entities with isPirateVictim would take much longer than isPirate because there are many more strings to compare. To my surprise both were just as fast. (At least the native time. JS has something to do in the last one)

Odd, here the last one takes four times as long native – and that’s counting the JSFunctionPredicate line as non-native.

A handful of oddly interrelated JavaScript changes:

• Mission variable names may no longer begin or end with underscores.
• Script names may no longer begin or end with underscores or whitespace.
• The call() debug method has been renamed callObjC() for clarity, and to avoid confusion with the completely different, standard Function.call() method.
• The debug OXP no longer pollutes all objects with “call” (or “callObjC”) and “inspect” properties visible to for (x in y) iteration.
• for (x in y) iteration now works on missionVariables.

All JavaScript class reference pages are now up-to-date for 1.74 (and 1.74.1). I don’t take any responsibility for other types of reference pages.

All information about deprecated properties has been removed, as has information about when properties were added for versions earlier than 1.74. If you feel some strange urge to target obsolete test releases, the old versions are there in the page histories.

The Materials in Oolite documentation is now up to date.

When the player enters a post-nova system, two groups of asteroids are spawned to represent debris of explodificated planets. Previously, these were susceptible to overheating at the usual rate, which meant the player always arrived just in time to see the last debris burn up. As of r3728, the spawned debris instead uses a new standard role, “cinder”. The default cinder objects are like_ship copies of standard asteroids and boulders with their heat_insulation set to 10000: Since a separate role is used for this rather than manipulating normal asteroids, OXP-defined asteroids which don’t replace the standard ones won’t be used as cinders, unless the OXP is updated.

Additionally, the heat_insulation for normal asteroids has been raised to 5, and for boulders to 3.

That's a very simple and therefore a very "cool" fix - nice one Ahruman.

Today I addd a size check for docking/launching ships to trunk. This should prevent the buggy behavior of oversized ships squeezing through the docking slot. Although its in the first place an oxp error of assigning wrong roles, I think the core game should also try to prevent this.

Ships that ask docking permission with the docking computer and are to big, are now denied permission. When using the "dockingAI.plist" to dock, this AI will return to the original AI with a message: "DOCKING_REFUSED". When a trader ship receives this message it will go sunskimming instead.

Ships that are in the launch queue and are too big are just removed before launch. The player won't see any evidence, but the fact is logged so oxp developers do know there is a problem with the ships size.

The check is very strict: there is no margin to allow for just a little to big. Ships that are just 1 meter to big will be denied by the station, even when 1 meter to big does not show by sight.

I have been using it now for 3 months on my computer without problems. There are only very few ships around that are just a bit to big. In Griffs ships set there were two, but Griff already fixed that 3 months ago. The buoy tugger in buoy repair it also just to big. We knew this already on the initial release, but now have a good reason to fix that in a future release. (Currently the tugger always sustains energy damage during docking because it is oversized)

This feature should not affect player ships that are to big, unless the docking computer is used.

-----

A new AI command "thargonCheckMother" is added in trunk to replace the current check for mother ship. By using this new command it will become more rare that the drones lose control in a crowded sky when there is still a mothership in range.

Aww, shucks .

There goes the fun of making a Baakili super-dense, trying to dock and blow up hurling the station to Solar orbit ...

Joysticks and analogue game pads are now supported under Mac OS X (10.5 and later). (Contributed by Alex Smith)

Wow, that's pretty big news for a lot of people!

I don't have a Mac and even I'm pleased (on behalf of Joystick free Mac users)

Before:


After: