Oolite Bulletins

SandJ wrote:

If you want to know about your ship, just enter [size=120]player.ship[/size]

If you want to know a great deal more about it, try :d player.ship. This works for just about everything; for example, try :d worldScripts["oolite-nova"] or :d global. On my machine, that last one exposes a number of bugs in a certain OXP. :-)

Whenever you use a macro, it first writes out the macro expansion, i.e. the code that’s actually run. For example, for :d player.ship it prints > dumpObject(eval("player.ship")). You can then examine this further by typing dumpObject, which will print the source code for dumpObject() (a function defined in oolite-debug-console.js inside the debug OXP).

Capt. Murphy wrote:

Code: Select all

 Object.keys(worldScripts)

will give you a handy list of all the worldScripts names in an array.

Or [url=http://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_Global#worldScriptNames]worldScriptNames[/url], which of course has been documented forever cough, hack.

Capt. Murphy wrote:

Code: Select all

Object.keys(missionVariables)

This one can be handy as-well to save you poking about in your save game.

Or :d missionVariables. :d is basically the superpower macro. :-)

Ahruman wrote:

:d is basically the superpower macro.

Thanks Ahruman, most enlightening . The global Object is surprisingly crowded on my system as-well. Several OXPs.

I should have spotted worldScriptNames - one of the things I did with Object.keys() was try and look around a bit for undocumented properties. Out of interest I just used :time worldScriptNames and :time Object.keys(worldScripts), and the latter is a fair bit faster.

Edit to add.... :d worldScripts["xxx"] is brilliant!

I also have a couple of OXPs installed that create properties of the global object (none of my own, as far as I can see; the "offenders" are shield cycler, CCL, and Runner-G5).

Asking as a non-coder who's trying to understand more: Is this a bad thing, and why?

I guess we need to think about this on a case by case base.

A few things can be easily moved into scripts namespaces, I'd think. In JS APIs are often placed globally to have a easy access point for others (e.g. to create a new instance), but we need to be very careful with the naming.

The other option for APIs to expand functionality by appending own methods and properties to existing objects was not my cup of tea (like the often done .unique() or .diff() for arrays), because I've expected that we would get more APIs and then clashes would happen with spectacular unpredictable results.

For CCL I could move the APIs Cabal_Common_ScreenFCB and Cabal_Common_OXPStrengthAPI into the scripts namespace. And Cabal_Common_2DCollision and Cabal_Common_BinSearch could be merged with Cabal_Common.

But these changes would affect other OXPs which are using CCL, so I'll need some feedback at this point.

Commander McLane wrote:

Asking as a non-coder who's trying to understand more: Is this a bad thing, and why?

It’s mostly about name conflicts. For instance, at least one script leaks a global variable called i, which isn’t very descriptive. It’s probably a loop iterator, but if more than one script was using it for something persistent there would be Hilarity.

Globals are also slower (the runtime needs to look in more places to find them), and they might refer to objects which are no longer needed but remain “rooted” so their memory can’t be reused. (This is called a “live leak”.)

It’s also a general problem of traditional JavaScript that this can happen by mistake, because it hides errors. For example, consider: If you’re using strict mode, which you should, you get an error instead. (To use strict mode, put the string "use strict";, with quotes, at the top of your JS file or the beginning of each function.)

Thargoid wrote:

Isn't it "use strict"; rather than "using"? Or are they interchangable?

Stop reading my posts so fast. :-)

Svengali wrote:

A few things can be easily moved into scripts namespaces, I'd think. In JS APIs are often placed globally to have a easy access point for others (e.g. to create a new instance), but we need to be very careful with the naming.

My recommendation has been consistent: export APIs as world scripts, or properties of them with specified names. Clients can then import them as properties or local variables:

So time for a cut then. CCL will be changed and the old version will stay online until the next Oolite release comes.
I'll do some more testing the next days before pushing it out.

Despite starting this thread I must admit most of this is beyond my current level of knowledge (Hopefully in the long run though I will get my self up to speed)

Anyway I'm glad it appears to be a useful thread and one that I will look to study once I have learnt some of the other skills I am working on for oxp writing.

It's surprisingly difficult to find precisely the right knowledge to get a debug console setup working for a complete newbie (new to oolite development, not to software development). I spent over an hour googling and reading bulletin boards and wikis, everything I could find assumed some already existing knowledge of some aspect of what is required.

Here's the result of the fastest & easiest path I've found to get to the debug console. Perhaps this could be put in a more visible "HERE'S HOW TO GET STARTED" sticky somewhere:

1) Download and install the release version of the game from http://www.oolite.org/download/
2) Make a full copy of your release folder hierarchy and name it to indicate it's a developer release
3) Download the Developer Release converter matching your install from http://www.oolite.org/download/
4) run the Developer Release converter, pointing it to the dev folder you made in step 2
5) Download and unpack the debug console from https://github.com/OoliteProject/oolite ... ole1.5.zip (link also on http://www.oolite.org/download/)
6) run OoDebugConsole.exe unpacked in step 5
7) start oolite from the dev folder converted in step 4

The console should show "Opened connection with Oolite version 1.82" (version depends of course on what version of the game you're running)

Hope this helps other fledgling oxp developers out and saves them some time getting started.

Is there a way to spawn a cargo pod with specified contents? Or to modify the contents of an existing container? I'm trying to explore/tweak the VacuumPump OXP and I need to create only gold/gems/platinum cargo containers, spawning random ones and hunting around for the right type is inefficient.