OXP to Debug Console communication

[hiran]

Now that I have a world script running, I'd like to fire off messages to the Debug Console.
This seems to work with

Code: Select all

log(message);

and slightly more flexible with

Code: Select all

consoleMessage(colorCode, message);

But in both cases I can only send string values transported in packet type console output. Is there a chance to invent new packet types and send more structured items such as dictionaries or arrays?

[hiran]

No one knows about this? Would it mean it simply cannot be improved?
Then I will stop investigating and try to get most out of a pretty low level functionality.

[Cholmondely]

No one knows about this? Would it mean it simply cannot be improved?
Then I will stop investigating and try to get most out of a pretty low level functionality.

The debug console was written by Ahruman, I think, who either has been reunited with Giles the Creator in the Transcendental Glorious Galaxy (known to the inner initiates as The Ninth) as he too attained Maximal Occultation or has since been ingested by the Witchspace Lobster and his Hognose-flying militant missionary minions.

But cag might just know something about it. With our wondrous and wonderful non-alerting pm's, why not quote of his posts such as this one...

done.

and see what happens?

[cag]

Now that I have a world script running, I'd like to fire off messages to the Debug Console.
...
But in both cases I can only send string values transported in packet type console output. Is there a chance to invent new packet types and send more structured items such as dictionaries or arrays?

As you're using the Debug Console, there are a few functions in Basic-debug.oxz's oolite-debug-console.js which engage when you query data from the console. E.g. :d player.ship. You could do something like

Code: Select all

for( let prop in player.ship ) {
	log(prop + ': ' + console.script.prettify(player.ship[prop]));
}

but you have no control over when/how deep it'll recurse. JS has rudimentary formatting tools, so I just roll my own. There is a cagsdebug.js in both Telescope 2.0 and Station Options. For tabulated data (like from profiling), either change debug console font to a fixed width one or, better still, just select the output (Ctrl-Shit-End) and copy/paste into a proper editor.

New packet types would involve changes in the core game as well as debug console(s). Don't hold your breath!

[Cholmondely]

Now that I have a world script running, I'd like to fire off messages to the Debug Console.
...
But in both cases I can only send string values transported in packet type console output. Is there a chance to invent new packet types and send more structured items such as dictionaries or arrays?

As you're using the Debug Console, there are a few functions in Basic-debug.oxz's oolite-debug-console.js which engage when you query data from the console. E.g. :d player.ship. You could do something like

Code: Select all

for( let prop in player.ship ) {
	log(prop + ': ' + console.script.prettify(player.ship[prop]));
}

but you have no control over when/how deep it'll recurse. JS has rudimentary formatting tools, so I just roll my own. There is a cagsdebug.js in both Telescope 2.0 and Station Options. For tabulated data (like from profiling), either change debug console font to a fixed width one or, better still, just select the output (Ctrl-Shit-End) and copy/paste into a proper editor.

New packet types would involve changes in the core game as well as debug console(s). Don't hold your breath!

Just to point out that Hiran's expertise does not (yet) lie in JavaScript, but rather Java itself and other such languages...

[hiran]

Now that I have a world script running, I'd like to fire off messages to the Debug Console.
...
But in both cases I can only send string values transported in packet type console output. Is there a chance to invent new packet types and send more structured items such as dictionaries or arrays?

As you're using the Debug Console, there are a few functions in Basic-debug.oxz's oolite-debug-console.js which engage when you query data from the console. E.g. :d player.ship. You could do something like

Code: Select all

for( let prop in player.ship ) {
	log(prop + ': ' + console.script.prettify(player.ship[prop]));
}

but you have no control over when/how deep it'll recurse. JS has rudimentary formatting tools, so I just roll my own. There is a cagsdebug.js in both Telescope 2.0 and Station Options. For tabulated data (like from profiling), either change debug console font to a fixed width one or, better still, just select the output (Ctrl-Shit-End) and copy/paste into a proper editor.

New packet types would involve changes in the core game as well as debug console(s). Don't hold your breath!

To be precise I am not using the Debug Console but make use of the Debug Console Protocol. Which means I have some other application imitating a Debug Console, and it can actively query for values from Oolite but it can also wait for Oolite to emit messages. So far the communication is heavily based on polling values, which is not really to my taste. I'd rather like to switch towards an event based model, where some OXP would be telling the Debug Console about important world events.

When I tried to write a simple world script handler that just forwards all events I found out that some events have additional data on them, such as `shipAttackedOther(other)` where this other is actually a whole ship entity. So my question intended to clarify how this additional data could efficiently be sent to the debug console.

I will take a look at cagsdebug.js - this seems promising.

[hiran]

JS has rudimentary formatting tools, so I just roll my own. There is a cagsdebug.js in both Telescope 2.0 and Station Options. For tabulated data (like from profiling), either change debug console font to a fixed width one or, better still, just select the output (Ctrl-Shit-End) and copy/paste into a proper editor.

New packet types would involve changes in the core game as well as debug console(s). Don't hold your breath!

I will take a look at cagsdebug.js - this seems promising.

Is there some hint where I can download the mentioned OXPs?

For the telescope, v1.15 is on the expansion manager despite some never version may exist. http://wiki.alioth.net/index.php/Telescope#Quick_Facts
In the station options beta download offered on http://wiki.alioth.net/index.php/Station_Options I could not find a cagsdebug.js either.

[cag]

Here's the file, no need to dl any oxz

https://www.dropbox.com/s/vawvbi5cvtzjg ... ug.js?dl=0

Some is Telescope specific. The most often used is the last, _showProps(). _reportError() is useful in a 'catch' statement to give more context on exceptions.

[cag]

... I'd rather like to switch towards an event based model, where some OXP would be telling the Debug Console about important world events.

When I tried to write a simple world script handler that just forwards all events I found out that some events have additional data on them, such as `shipAttackedOther(other)` where this other is actually a whole ship entity. So my question intended to clarify how this additional data could efficiently be sent to the debug console.

Try Norby's  LogEvents as a starting point and amplify the data you want to see. If nothing else, LogEvents spits out messages for all worldScripts events and you wouldn't have to poll as much (or at all).

[hiran]

... I'd rather like to switch towards an event based model, where some OXP would be telling the Debug Console about important world events.

When I tried to write a simple world script handler that just forwards all events I found out that some events have additional data on them, such as `shipAttackedOther(other)` where this other is actually a whole ship entity. So my question intended to clarify how this additional data could efficiently be sent to the debug console.

Here's the file, no need to dl any oxz

Try Norby's  LogEvents as a starting point and amplify the data you want to see. If nothing else, LogEvents spits out messages for all worldScripts events and you wouldn't have to poll as much (or at all).

Thank you. These two seem to be good starting points. I will take a close look at them.
Any copyright claims on this?

How would I best integrate it into my OXP? Should cagsdebug.js go into `/Config` (which means besides script.js), or should it reside unter `/scripts`? How would I invoke the functions from my script?

[hiran]

Checking norby's logevents it seems to only write to the logfile but not the debug console.
So I'd at least have to modify `/Scripts/logevents.js`line 441.

Not being a JavaScripter, this file has really lots of `this.$` stuff inside that feels strange compared to the simplistic approach I already have.

[cag]

... Any copyright claims on this?

How would I best integrate it into my OXP? Should cagsdebug.js go into `/Config` (which means besides script.js), or should it reside unter `/scripts`? How would I invoke the functions from my script?

As with most .js files in Oolite, there is near the top

Code: Select all

this.licence	 = "CC BY-NC-SA 3.0";

which is Creative Commons Attribution-NonCommercial-ShareAlike 3.0 which is close to being no copyright. Personally, I don't really care, at all - this is play, not work.

To integrate, you could place it in '/Scripts' & add it to your world-scripts.plist file, then you could access a function as worldScripts.cagsdebug._showProps(...). But a lot is Telescope specific, so you could just copy/paste a function into your own script. Or rename the file and customize it for your needs.

[cag]

Checking norby's logevents it seems to only write to the logfile but not the debug console.
So I'd at least have to modify `/Scripts/logevents.js`line 441.

Not being a JavaScripter, this file has really lots of `this.$` stuff inside that feels strange compared to the simplistic approach I already have.

That's not right, the debug console should echo all log statements.

Code: Select all

function log([messageClass : String ,] message : String)

If you do not pass the messageClass (i.e. pass 1 string, not 2), it will only write to the console.
What are you seeing in the debug console?

The 'this' is a reference to the script, while the '$' is just a convention to prevent name clashes. So

Code: Select all

this.$thing = ...

declares/defines the $thing object (property, variable, function, etc.) as belonging to that script, limiting its scope. If you instead had

Code: Select all

var thing = ...

that would pollute the global namespace, meaning that every script in every oxp would see thing, which would be bad (e.g. defining your own startUp like this would break all oxps). The convention is not rigid; I like to use '$' for variables and '_' for functions. Some will include their oxp name in the prefix, which lets you know immediately where to look for the cause of an exception in your log file. (I find that to be too noisy and tend to lose focus; it's a personal choice)

The best way to learn this stuff is to copy a small oxp, like  Cargo Spotter, and mess around with it. If you want to know how somebody did something, view their script.
Oolite reference:
http://wiki.alioth.net/index.php/Oolite ... ject_model
For a JS reference, try
https://developer.mozilla.org/en-US/docs/Web/JavaScript

[hiran]

Checking norby's logevents it seems to only write to the logfile but not the debug console.
So I'd at least have to modify `/Scripts/logevents.js`line 441.

Not being a JavaScripter, this file has really lots of `this.$` stuff inside that feels strange compared to the simplistic approach I already have.

That's not right, the debug console should echo all log statements.

Code: Select all

function log([messageClass : String ,] message : String)

If you do not pass the messageClass (i.e. pass 1 string, not 2), it will only write to the console.
What are you seeing in the debug console?

The 'this' is a reference to the script, while the '$' is just a convention to prevent name clashes. So

Code: Select all

this.$thing = ...

declares/defines the $thing object (property, variable, function, etc.) as belonging to that script, limiting its scope. If you instead had

Code: Select all

var thing = ...

that would pollute the global namespace, meaning that every script in every oxp would see thing, which would be bad (e.g. defining your own startUp like this would break all oxps). The convention is not rigid; I like to use '$' for variables and '_' for functions. Some will include their oxp name in the prefix, which lets you know immediately where to look for the cause of an exception in your log file. (I find that to be too noisy and tend to lose focus; it's a personal choice)

The best way to learn this stuff is to copy a small oxp, like  Cargo Spotter, and mess around with it. If you want to know how somebody did something, view their script.
Oolite reference:
http://wiki.alioth.net/index.php/Oolite ... ject_model
For a JS reference, try
https://developer.mozilla.org/en-US/docs/Web/JavaScript

So meanwhile I compared some more of my OXP versus the logging OXP and I see some differences from the debug console side. Since both OXPs are installed currently I get two messages per event - that is no surprise. It seems to me the logging OXP tries to make the events slightly more human readable. Just compare these two lines which both describe the same event:

Code: Select all

receivedLogMessage({color key=log, message=playerBoughtCargo(liquor_wines, 1, 268), packet type=Console Output})
receivedLogMessage({color key=log, message=bought 1 Liquor/Wines for 26.8 credits, packet type=Console Output})

I want to keep parsing to a minimum and am therefore more focused on events with more complex objects like

Code: Select all

receivedLogMessage({color key=log, message=shipSpawned([Ship "COMLR-Satellite" position: (-251607, 522100, -1.03894e+06) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT]), packet type=Console Output})

But refining this is still to come. A showstopper is already that when starting OoliteCommuncator and then starting Oolite I do not know how to ensure either the logging or my own OXP are actually installed and get started. Without them the above events will simply not happen at all.

So how could I install an OXP automatically? How would OoliteCommunicator find the Addons folder at runtime to inject the OXP just before Oolite gets started? Or can I do such stunts via the debug console?

[phkb]

So how could I install an OXP automatically? How would OoliteCommunicator find the Addons folder at runtime to inject the OXP just before Oolite gets started? Or can I do such stunts via the debug console?

There is currently no JS interface to disable or enable an OXP, unless the OXP gives you one itself. I've done this in a couple of mine - having a $disabled flag or some such to quickly turn things on or off. So, if you're looking for a way to harmonise two player's game worlds, the facilities aren't currently available to do this programmatically. You might be stuck with some manual intervention, I'm afraid.

However, you can check to see if an OXP is installed using worldScripts or worldScriptNames.