Oolite Bulletins

Debug.oxp for Oolite 1.70 is now available. Removed, buggy

Documentation forthcoming, but in short, it does what DebugMenu.oxp did for Oolite 1.69, only better, and also adds an integrated interactive JavaScript console. (This can also be used to issue legacy scripting commands to the player, in the form “:: script_method”.)

The OXP also enables support for external JavaScript consoles on all platforms, but since no external consoles exist (except a simplistic command-line one for OS X only), I’m posting this in the Mac thread.

This time for real: Debug.oxp for Oolite 1.70 is now available, with some docs.

What's required for the console?

The console is based around a TCP protocol, documented here. The fun part is that it’s based around XML plists, for the convenience of Oolite. At the time I implemented it, I believed Apple’s CoreFoundation library, which implements plist support, was portable, but this appears to be… not quite the case. Anyhow, there’s a CoreFoundation-based command-line implementation in the repo at tools/simpleDebugConsole. I’ve also started on a Python implementation based on Twisted.

The client side of the protocol implemented in Oolite is known to work under Windows when communicating with a Mac running the simpleDebugConsole.

Why not make it simple plain text, and have Oolite listen, then you can just use telnet? (Or PuTTY on Win32 given the dreadfulness of the Win32 telnet client)

Woo yay! Thanks for all your hard work.

Throw in a fat man in suit, and Christmas has come early.

winston wrote:

Why not make it simple plain text, and have Oolite listen, then you can just use telnet? (Or PuTTY on Win32 given the dreadfulness of the Win32 telnet client)

Because that’s more work while supporting the same feature set. Ease of maintenance on Oolite’s side is the priority.

(Also, making Oolite the server would make reporting early issues more problematic.)

Edit: also, Oolite is quite frankly so full of bugs, strange interactions and other potential security concerns (combined with file I/O) that I wouldn't want to be responsible for having open to the intertubes.

*bustles back into room*

Furthermore, fourthly, plain text in a telnet-friendly sense would be insufficient to capture the semantics of the data already exchanged between the console script and the integrated console at the time the TCP protocol was suggested.

Fair enough. (Note in the case of Oolite doing the listening, you can bind to 127.0.0.1 then you don't expose anything to the intertubes.)