Oolite Bulletins

hiran wrote: ↑Sun Dec 12, 2021 6:18 am

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.

cag wrote: ↑Sun Dec 12, 2021 6:51 am

done.

hiran wrote: ↑Sat Dec 04, 2021 6:26 pm

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?

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

cag wrote: ↑Mon Dec 13, 2021 12:07 am

hiran wrote: ↑Sat Dec 04, 2021 6:26 pm

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!

cag wrote: ↑Mon Dec 13, 2021 12:07 am

hiran wrote: ↑Sat Dec 04, 2021 6:26 pm

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!

hiran wrote: ↑Mon Dec 13, 2021 10:03 am

cag wrote: ↑Mon Dec 13, 2021 12:07 am

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.

hiran wrote: ↑Mon Dec 13, 2021 10:03 am

... 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.

 LogEvents

hiran wrote: ↑Mon Dec 13, 2021 10:03 am

... 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.

cag wrote: ↑Tue Dec 14, 2021 2:12 am

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

cag wrote: ↑Tue Dec 14, 2021 2:21 am

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 wrote: ↑Tue Dec 14, 2021 6:45 am

... 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?

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

hiran wrote: ↑Tue Dec 14, 2021 7:10 am

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.

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

this.$thing = ...

var thing = ...

 Cargo Spotter

cag wrote: ↑Tue Dec 14, 2021 7:52 pm

hiran wrote: ↑Tue Dec 14, 2021 7:10 am

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

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})

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})

hiran wrote: ↑Thu Dec 23, 2021 11:25 am

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?