I’ve been somewhat off Oolite work recently. Rather than procrastinate or go off and do something completely different, I’ve been working on something peripheral: the Mac-only debug OXP.
In 1.69,
Debug Menu.oxp works as an enabler – its presence, and the support files it contains, activates debugging code in Oolite. In the next release, it will contain the debug code itself, working like a plug-in. This means I can add loads of stuff to it without complicating the Oolite application much.
I’ve now added to items of stuff. The first is
F-Script. This is not yet another OXP scripting language; rather, it’s a dynamic scripting language which works directly with Objective-C objects. This makes it a very powerful (and very dangerous) debugging tool.
The other is an interactive JavaScript console. This makes it a lot easier to poke around at the JavaScript runtime: rather than writing a ship script, running Oolite, waiting for it to start, creating the appropriate ship type (the existing Debug Menu OXP already has a Create Ship… command) and looking to see what’s going on in the log, I can call methods and inspect properties in any ship’s script or Oolite-provided scriptable object. I expect this to be useful for OXP development as well as for implementing scripting support. :-) For extra fun, the console is partly implemented in JavaScript. Specifically, commands entered into the console are passed, unmodified, to a method in the script “oolite-mac-console.js”, which is part of Debug.oxp but can be overridden, allowing for a great deal of customization. It looks like this:
Bold lines prefixed with > are commands. In this example all the other lines are responses to the commands, but in general use warnings, errors and long messages pertaining to other scripts running in the game will also appear in the console.
The first three commands in the screen shot are your basic using-an-interactive-shell-as-a-calculator example. The first one uses invalid syntax to generate a warning (although the warning is somewhat unhelpful since it always points at an
eval command in the JavaScript part of the console implementation; a custom warning for this case would probably be helpful). The fourth command,
:dl player.position, is not JavaScript; it’s a macro.
Macros are (in this context) shortcuts for JavaScript commands. The line after the command shows the
expansion of the macro, that is, the code it’s translated to:
dumpObjectLong(eval("player.position")). This is followed by the results of running the
dumpObjectLong function. The next command,
:showM dl, shows the definition of the
dl macro. The macro could have been defined using the macro
:setM dl dumpObjectLong(eval(PARAM)), but this was not needed since it’s predefined in the console script. Macros provide a simple way to abbreviate commonly-used commands, and the macro system is implemented entirely in JavaScript for easy customization or replacement.
The sixth command simply demonstrates the ability to enter multi-line commands. This can be done by pressing option-return (this works in most Cocoa text fields, incidentally) or by pasting multiple lines.
The last one demonstrates the ability to get a colourful and unhelpful error message for typing something other than valid JavaScript code (or a macro).
Oh, those strange people who are addicted to white-on-black consoles will be relieved to know that the colours can be customized in a plist. ;-)
On matter of Mac-onliness:
Mac-only features obviously suck, but making these features cross-platform would require a great deal of extra work. It would either require me to implement a relatively complex UI system within Oolite, or to write a separate application to communicate with a debugger object within Oolite. The latter might end up being a good idea for the Mac side anyway, but porting such an application would require more active Linux and Windows developers with a greater familiarity with GNUstep. As it is, the debug OXP consists of tools that are useful to me in working on Oolite, which also happen to be useful for developing OXPs.