Oolite Bulletins

Posted: **Sun Dec 19, 2010 3:47 pm**

In the words of Ultravox... "This means nothing to me" - I am presuming a massive hike in version number is a good thing?

Posted: **Sun Dec 19, 2010 3:57 pm**

It means that the MNSR is a lot less M!

Of course, we need to see how well the new js engine stuff compiles in windows & linux first...

Posted: **Sun Dec 19, 2010 4:16 pm**

DaddyHoggy wrote:
In the words of Ultravox... "This means nothing to me" - I am presuming a massive hike in version number is a good thing?

You can read about SpiderMonkey JS here.

Posted: **Sun Dec 19, 2010 4:18 pm**

DaddyHoggy wrote:
In the words of Ultravox... "This means nothing to me" - I am presuming a massive hike in version number is a good thing?

Well, it means:

By using a version of SpiderMonkey that isn’t three years old – Oolite’s been using the same version since JavaScript support first entered trunk – we get a bunch of security fixes and the benefit of the ongoing performance war. (A debug build of the current version is as fast as the release build of the old version.) This covers every core JS change from Firefox 2.0 to Firefox 3.6.
We’ll be able to build with the system version of libjs on some Linux distros, which has been stopping Oolite from being an official RedHat package.
ECMAv5 means compliance to the new JavaScript/ECMAScript standard, which has a “strict mode” that fixes some language flaws.
It also gives us native JSON support for free, which provides a convenient way to put structured data into mission variables.

The reason that we’ve stuck to one version for so long is that building SpiderMonkey, especially wanting the same version on various platforms and a universal version for Mac OS X, is a major pain. This hasn’t changed. At the moment, the new version only works with Mac OS X 64-bit. It’s also unstable (due to changes in the SpiderMonkey programming interface and bugs in old code that just happened to work anyway), but at least there’s finally some progress.

Posted: **Sun Dec 19, 2010 6:33 pm**

Thanks Eric - Thanks Ahruman.

All reads very promisingly!

Posted: **Sun Dec 19, 2010 6:39 pm**

I have to confess that I, too, do not understand half of this stuff, but it does give some insight into the amazing work you people do 'behind the scenes' for us all. Many thanks are due.

Posted: **Sun Dec 19, 2010 8:58 pm**

Windows have caught up with the Mac - one or two bugs still, but I guess we are finally on the right track:
Before:

After:

Posted: **Thu Dec 30, 2010 9:18 am**

It has been pointed out that I should mention that the JavaScript takeSnapShot() method has been restricted to debug and test-release builds.

This is in accordance with a simple and non-negotiable policy: the “stable” end-user release will not allow JavaScript to write to disk or cause things to be written to disk in any way, shape or form other than mission variables.

(As I think I’ve said before, there will probably be an “OXP developer” version which is built as a test release, with various weird and wonderful testing and cheating functions.)

Posted: **Fri Dec 31, 2010 1:08 am**

Starting tonight, Mac and Windows nightlies will use the new JavaScript engine.

If you hit an interesting new bug, we don’t know about it, so tell us. (If you’re running nightlies and not reporting bugs, I officially hate you.)

Posted: **Fri Dec 31, 2010 8:31 am**

Ahruman wrote:
Starting tonight, Mac and Windows nightlies will use the new JavaScript engine.

I think you mean: Starting next year

And for any bugs we find you can blame the millennium+11 bug.

Posted: **Fri Dec 31, 2010 10:15 am**

Eric Walch wrote:
Ahruman wrote:
Starting tonight, Mac and Windows nightlies will use the new JavaScript engine.
I think you mean: Starting next year :lol:

No no, other tonight. They’re up now. :-)

Interesting new bug (I’d seen this before but not done anything about it yet): Most native methods that are supposed to return nothing/undefined now return themselves. If run in the console you get the response “function something() { [ Native code ] }”.

Posted: **Thu Jan 06, 2011 2:39 am**

I know you’ve had to go days and days without being able to see if there’s a Progress update, so here is one.

JavaScript

The new JavaScript engine (now the same version used in Firefox 4.0b8; the old one corresponded to Firefox 2.0) is now required in Mac builds, the default for Windows and being used for 32-bit Linux nightlies. This means faster scripts and new language features; I’ve started a thread about those here. Getting this working involved a lot of changes, some of which fixed obscure pre-existing bugs, including ways to crash the game using scripts.
The console now makes an effort to describe results more helpfully. In particular, there is no more “[object Object]”; instead, you get a pretty-printed dump of the objects property keys and values. If the object’s toString() method returns something other than “[object Object]”, that will be used, but this can be bypassed using the improved :d macro. For instance, player.ship will still give you “[PlayerShip "Cobra Mark III" position: (-49515.3, 60769.4, 427622) scanClass: CLASS_PLAYER status: STATUS_DOCKED]”, but :d player.ship will dump all enumerable properties of the player’s ship instead.
Some time this autumn, Kaks made a change where player ship properties became undefined after ejecting. This has now been unified with the general concept of entity validity, and it also happens when the player dies.
Fixed a bug in the expandDescription function: if a value in the override dictionary was a number (e.g., in expandDescription("[test]", { test: 5 }) it would be ignored. This bug was introduced somewhere between 1.74 and 1.74.2, causing buggy messages in the material test suite under 1.74.2. In 1.75, all values in the override dictionary will be converted to strings by calling their toString() method. In 1.74.x, passing an array would select a value from it at random, but this was not documented. These changes also affect expandMissionText().
The performance of the string expander used for expandDescription() and various other situations has been improved substantially.
Using a customSounds.plist key as a sound name now works as expected.
“Strict mode” warnings have been renamed “pedantic mode” to avoid confusion with ECMAScript 5 strict mode. Pedantic mode can now be turned off temporarily using the debugConsole.pedanticMode property (if the debug console is loaded).
Because of a bug in SpiderMonkey, warnings about “useless values” have been disabled. To support this, disabling a warning in logcontrol.plist now stops the warning from appearing in the debug console as well as the log.

Other

Implemented support for hat switches and analogue game pads’ D-pads under Mac OS X. Also enabled mapping of hat switches and buttons above #15 on all platforms (broken when integrating Mac joystick support).
On the Mac, the loading progress messages are now mostly true.
Faster planet set-up, meaning slightly faster loading and witchspace jumping.
Patrol ships no longer block the docking queue.
New station key: has_patrol_ships (fuzzy boolean).
Kaks “made fuel price slightly more variable”, I’m not sure what that’s about.
New, snazzier Xcode build setup for dependencies under Mac OS X. I’m sure you’re thrilled.

Posted: **Thu Jan 06, 2011 2:45 am**

Here, incidentally, is the output of :d player.ship in trunk:

Code: Select all

{
    manifest: [object Manifest],
    aftShield: 128,
    aftShieldRechargeRate: 2,
    compassMode: "COMPASS_MODE_BASIC",
    compassTarget: undefined,
    cursorCoordinates: (20, 173, 0),
    docked: true,
    dockedStation: [Station "Coriolis Station" "Coriolis Station" position: (-49515.3, 60769.4, 427622) scanClass: CLASS_STATION status: STATUS_ACTIVE],
    forwardShield: 128,
    forwardShieldRechargeRate: 2,
    fuelLeakRate: 0,
    galacticHyperspaceBehaviour: "BEHAVIOUR_STANDARD",
    galacticHyperspaceFixedCoords: (96, 96, 0),
    galaxyCoordinates: (20, 173, 0),
    hud: "hud.plist",
    hudHidden: false,
    maxAftShield: 128,
    maxForwardShield: 128,
    reticleTargetSensitive: false,
    scoopOverride: false,
    scriptedMisjump: false,
    specialCargo: undefined,
    targetSystem: 7,
    viewDirection: "VIEW_GUI_DISPLAY",
    weaponsOnline: true,
    aftWeapon: null,
    AI: "oolite-player-AI.plist",
    AIState: "GLOBAL",
    beaconCode: null,
    bounty: 0,
    cargoSpaceUsed: 0,
    cargoSpaceCapacity: 20,
    cargoSpaceAvailable: 20,
    contracts: [],
    cruiseSpeed: 280,
    desiredSpeed: 0,
    displayName: "Cobra Mark III",
    entityPersonality: 27313,
    equipment: [],
    escorts: null,
    escortGroup: [OOShipGroup "escort group", 1 ships, leader: <PlayerEntity 0x102091200>{"Cobra Mark III"}],
    forwardWeapon: [EquipmentInfo EQ_WEAPON_PULSE_LASER "Pulse Laser"],
    fuel: 7,
    fuelChargeRate: 1,
    group: null,
    hasHostileTarget: false,
    hasHyperspaceMotor: true,
    hasSuspendedAI: false,
    heatInsulation: 1,
    heading: (0, 0, 1),
    isBeacon: false,
    isCloaked: false,
    isCargo: false,
    isDerelict: false,
    isFrangible: true,
    isJamming: false,
    isMine: false,
    isMissile: false,
    isPiloted: true,
    isPirate: false,
    isPirateVictim: true,
    isPlayer: true,
    isPolice: false,
    isRock: false,
    isBoulder: false,
    isThargoid: false,
    isTrader: true,
    isWeapon: false,
    lightsActive: true,
    maxSpeed: 350,
    maxThrust: 32,
    missileCapacity: 4,
    missileLoadTime: 0,
    missiles: [[EquipmentInfo EQ_MISSILE "Missile"], [EquipmentInfo EQ_MISSILE "Missile"], [EquipmentInfo EQ_MISSILE "Missile"]],
    name: "Cobra Mark III",
    passengerCount: 0,
    passengerCapacity: 0,
    passengers: [],
    portWeapon: null,
    potentialCollider: null,
    primaryRole: "player",
    reportAIMessages: false,
    roleProbabilities: {
        player: 1
    },
    roles: ["player"],
    savedCoordinates: (0, 0, 0),
    scannerDisplayColor1: null,
    scannerDisplayColor2: null,
    scannerRange: 25600,
    script: [Script "oolite-default-player-script" version 1.75],
    scriptInfo: {},
    speed: 0,
    starboardWeapon: null,
    subEntities: [],
    subEntityCapacity: 0,
    target: null,
    temperature: 0.234375,
    thrust: 32,
    thrustVector: (0, 0, 0),
    trackCloseContacts: false,
    vectorForward: (0, 0, 1),
    vectorRight: (1, 0, 0),
    vectorUp: (0, 1, 0),
    velocity: (0, 0, 0),
    weaponRange: 12500,
    withinStationAegis: false,
    collisionRadius: 72.7341079711914,
    distanceTravelled: 0,
    energy: 256,
    mass: 185580.015625,
    maxEnergy: 256,
    orientation: (-1 + 0i + 0j + 0k),
    owner: null,
    position: (-49515.3, 60769.4, 427622),
    scanClass: "CLASS_PLAYER",
    spawnTime: 0,
    status: "STATUS_DOCKED",
    isPlanet: false,
    isShip: true,
    isStation: false,
    isSubEntity: false,
    isSun: false,
    isValid: true,
    inspect: function inspect() {
        debugConsole.inspectEntity(this);
    }
}

Posted: **Thu Jan 06, 2011 7:23 pm**

(This post will only make sense to people with a relatively deep understanding of the JavaScript language.)

Ever since we started on JavaScript support in Oolite, our prototype chains have been rather wonky. The root reason for this was that most of our host classes didn’t have construct callbacks, so their representation inside JS wasn’t really a constructor. The wonkiness meant that you couldn’t, for instance, add a method to Ship.prototype and call it on ship instances; instead, you had to define it on Ship.__proto__ (or Object.getPrototypeOf(Ship) in ES5).

The practical result of this has been that utility and backwards-compatibility methods defined in the global prefix script haven’t behaved quite right.

This is fixed, bringing an end to the terrible plague of wonkiness.

(Of course, you shouldn’t be adding methods to host object prototypes anyway, unless you’re an Oolite developer working on oolite-global-prefix.js, i.e. me. But it’s a Good Thing that stuff is now non-wonky.)

Oolite Bulletins

Progress

Re: Progress

Re: Progress

Re: Progress