Fixed yaw control. (Keyboard only; default to , and ., aka < and > on US and UK keyboards.) Disabled in strict mode.

Reimplemented data cache.

Tightened the retaining bolts on laser cannons, which had worked loose. (This affected AIs too, incidentally.)

Advanced Navigation Array can now actually be purchased (for any ship).

Stuff to do this weekend:

Fix streaming-audio crash bug.

Work out why mouse control sometimes isn’t working.

Bug-fix release 1.67.1-mac.

Look at dajt’s JavaScript branch.

What the new data cache means to you:

The data cache will be rebuilt when OXPs are added or removed. Specifically, it will be rebuilt if the folders Oolite searches for files change, or if any of their modification dates change. Adding or removing a file within an OXP should trigger this; changing a file generally won’t, so OXP developers may still hit stale cache problems, but users will not.

The cache has changed format (as if you care) and, under Mac OS X only, moved to ~/Library/Caches/org.aegidian.oolite/Data Cache.plist. The old cache will be deleted.

The cache is now flushed (written to disk) after startup loading and every time you dock, rather than when you save the game. I only mention this because someone once expressed bafflement at getting repeated “data cache must be rebuilt” messages.

I wrote some code a while back that added joystick support for yaw a while back (about a month ago). Last time I tried it it didn't work. Not sure why, but I haven't had the time to fix it yet. I also added view control via the hat switch that worked as of a couple of weeks ago. If anyone wants to look at it check it out over in this thread:

There is one problem: I added so many options to the joystick config page they no longer all fit on the screen. Haven't looked into fixing this, either.

I have one suggestion on the yaw (don't know if this is the right place): make it much less effective than pitch. Dogfighting was WAY to easy, at least with a joystick. I could see where the keyboard would be a bit more difficult, but I still think yaw effectiveness should be reduced.

I’ve been fiddling around with the JavaScript environment, and updated the relevant wiki page. I don’t think this should affect anyone, since as far as I’m aware the only JavaScript OXP scripts are my and dajt’s test scripts. Summary of changes:

Changed and unified capatalization conventions. All identifiers are written in camelCase. Methods, properties and global variables start with a lowercase letter. Classes and global functions start with a capital.

Standardized on USAlien spelling, as is the norm in programming (and in Oolite internally). The only case I noticed was Initialise -> initialize. (Hey, that’s how the OED spells it, too.)

Renamed some methods.

Changed some semantics. In particular, player.call(), Log(), LogWithClass(), mission.markSystems() and mission.unmarkSystems() can now take an arbitrary number of parameters, and awardCargo() now takes the type before the quantity (although ideally this would be exposed as player.cargo[type] += quantity instead).

I also added notes on things that are likely to change, and cases where I’m not sure of the design.

I’d like to be able to release an example of a reasonably big script converted to JavaScript. In order to do this, I’d need a test suite, i.e. a set of pilot files ready to activate each stage of the script. Anyone have something like that?

I’ve been spending most of the night changing the event handling. Instead of calling event handlers called STATUS_WHATEVER whenever the old script mechanism would run all the scripts, events are sent as and when noteworthy things happen. I won’t update the Wiki page now, what with it being four in the morning, but here’s my current test script. Almost all of it is known to actually work. Hopefully scripters will get some idea of how much more control this provides than the old "status_string equal STATUS_WHATEVER" approach. It’s also significantly more efficient. The “tickle” method is called at all the old polling opportunities, so if you do need that behaviour, or just idle updates, that’s possible too. (Remember, though, about the efficiency thing.)

Handlers for events that have an instantaneous effect are called didFoo(). For events that take time – mostly tunnel effects – there are willFoo()/didFoo() pairs.

Not specifically LoB… it’s an overexposure to Terry Pratchett fans that makes me write like that, although there’s certainly a lot of Monty Python culture in that crowd.

In a completely un-scripting-related move, I’ve experimented with additive blending of glowy effects. This basically means that glowy bits can’t make things darker, which increases realism and mostly makes things look subtly better, although the engine glow will need adjusting and I expect to get complaints about the lasers.

More fun with minor fix-ups: I’ve noticably improved performance of startup, respawn and script execution with about five lines of code. Specifically, for any passing coders, by caching the return value of -[Universe generateSystemData]. Who’d’a thunk it? Those profiler thingies are useful. :-) This should reduce periodic, combat, and ship-spawn stutter somewhat.

How exactly would one go about installing the example script posted above? I tried following the wiki instructions, i.e. copying the script code into a file called script.js, which I put in the Config directory, but when I run the latest SVN snapshot, I get this error message:

Firstly, the idea is to put it in an OXP, not in Oolite itself. Doing that will effectively replace the standard script, which is not generally desireable. That’s not the source of your problem, though.

”can't open o:” seems to be the gist of it. It’s getting “o” instead of “oolite.app/Resources/Config/script.js”. The most likely reason I can see is that -[NSString fileSystemRepresentation] is doing the wrong thing… which is weird, since (looking at the GNUstep source) it appears to be doing the right thing, or at least something insufficiently wrong for that problem to occur.

Try this: in -[OOJSScript initWithPath:andContext:] (src/Core/Scripting/OOJSScript.m, around line 80), add:

There seems to be a pattern. The path name of the script to load seems to be getting set to its first character only. So, oolite.app\etc.etc would become "o" and Addons\myoxp.oxp\etc.etc. would become "A". Not sure if this helps at all, though.