Progress

JensAyton · Post by **JensAyton** » Sat Jul 21, 2007 11:02 am

Started work on shipdata.plist verifier.
Started removing redundant and unused data from built-in shipdata.plist, reported by verifier.
Fixed bug where Thargoids no longer have extreme weapon range, detected using shipdata.plist verifier. :-)

JensAyton · Post by **JensAyton** » Mon Jul 30, 2007 11:59 pm

I’ve written up how the GLSL binding stuff works. It won’t make any sense unless you’re somewhat familiar with both Objective-C and OpenGL, but I thought I should mention it anyway.

JensAyton · Post by **JensAyton** » Thu Aug 02, 2007 12:36 am

Work on JavaScript object model. JavaScript prototype relationships now reflect the Oolite object model; specifically, player is a Player, which is a Ship, which is an Entity. This means that a JS script can request, say, the mass of player (which is an Entity property).

JensAyton · Post by **JensAyton** » Thu Aug 02, 2007 4:52 pm

More work on making the object model object modelly. It is now possible to do things like:

Code: Select all

player.dockedStation.switchAI("pirateAI.plist");

Advisable? No. Possible? Yes.

Oh, yes: the call() function has been moved from Player to Entity. It can now also return a value. This means that all old-style player scripting methods and ship AI methods (and others) can now be usefully used from JavaScript. Example:

Code: Select all

var credits1 = player.credits;
var credits2 = player.call("credits_number");
// credits1 and credits2 are equal

player.dockedStation.call("addFuel:", credits1 / 100); // No, I have no idea why you’d want to do this.

JensAyton · Post by **JensAyton** » Thu Aug 02, 2007 8:38 pm

Preliminary class documentation (more properties and methods are likely to be added):

Star Gazer · Post by **Star Gazer** » Fri Aug 03, 2007 10:14 am

How can there be two identical, but different(!!), 'score' items in the 'player' entity class...?

JensAyton · Post by **JensAyton** » Fri Aug 03, 2007 11:36 am

There can’t. Nothing to see here. Move along.

Er, that is… it was a trick to see if anyone actually reads those things. Yes.

JensAyton · Post by **JensAyton** » Fri Aug 03, 2007 4:38 pm

New easy-introspection properties for Entity: isValid, isShip, isStation, isPlayer and isPlanet. Deprecated Entity.valid() in favour of isValid. Added Ship.subEntities. Bug fixes in JavaScript support.

Here’s a dump from my current testing script. Nothing hugely fascinating, I suppose. It does demonstrate that JavaScript allows for much more informative error messages, though. :-)

Code: Select all

** Testing player: <PlayerEntity Cobra Mark III 100>.
** Testing Entity properties:
                     ID [expect: 100]: 100
                             position: (-49515.3, 60769.4, 427622)
                          orientation: (1 + 0i + 0j + 0k)
                              heading: (0, 0, 1)
   status [expect: STATUS_START_GAME]: STATUS_START_GAME
     scanClass [expect: CLASS_PLAYER]: CLASS_PLAYER
                                 mass: 208572.65625
                 owner [expect: null]: null
                               energy: 256
        maxEnergy [expect: == energy]: 256
               isValid [expect: true]: true
                isShip [expect: true]: true
            isStation [expect: false]: false
              isPlayer [expect: true]: true
             isPlanet [expect: false]: false
 ** Testing Ship properties:
                      shipDescription: Cobra Mark III
                                roles: player
                                   AI: dockingAI.plist
                              AIState: AWAIT_COORDS
                                 fuel: 7
                               bounty: 0
                          subEntities: null
** Testing Player properties:
                                 name: Jameson
                                score: 0
                              credits: 100
                         fuelLeakRate: 0
                       alertCondition: 1
                               docked: false
                     alertTemperature: false
                      alertMassLocked: false
                        alertAltitude: false
                          alertEnergy: false
                        alertHostiles: false
         dockedStation [expect: null]: null
** Testing deprecated properties and methods (should produce warnings):
----- JavaScript warning: Player.legalStatus is deprecated, use Player.bounty instead.
      /Users/jayton/Library/Application Support/Oolite/AddOns/JavaScript test.oxp/Scripts/ahruman-player-test.js, line 59.
       legalStatus [expect: = bounty]: 0
----- JavaScript warning: Player.dockedStationName is deprecated, use Player.dockedStation.shipDescription instead.
      /Users/jayton/Library/Application Support/Oolite/AddOns/JavaScript test.oxp/Scripts/ahruman-player-test.js, line 61.
dockedStationName [expect: undefined]: undefined
----- JavaScript warning: Player.dockedAtMainStation is deprecated, use Player.dockedStation.isMainStation instead.
      /Users/jayton/Library/Application Support/Oolite/AddOns/JavaScript test.oxp/Scripts/ahruman-player-test.js, line 63.
  dockedAtMainStation [expect: false]: false
----- JavaScript warning: Player.valid() is deprecated, use Player.isValid property instead.
      /Users/jayton/Library/Application Support/Oolite/AddOns/JavaScript test.oxp/Scripts/ahruman-player-test.js, line 65.
               valid() [expect: true]: true
** Testing Entity.entityWithID():
             Entity.entityWithID(100): <PlayerEntity Cobra Mark III 100>
             == player [expect: true]: true
** Tests complete.

JensAyton · Post by **JensAyton** » Fri Aug 03, 2007 11:43 pm

Added Entity.distanceTravelled, Entity.spawnTime, Ship.target, Ship.escorts, Ship.temperature, Ship.heatInsulation, Ship.deployEscorts() and Ship.dockEscorts().

Commander McLane · Post by **Commander McLane** » Sat Aug 04, 2007 8:36 am

Ahruman wrote:
Er, that is… it was a trick to see if anyone actually reads those things.

Oh, I do follow each and every of your posts here, believe me. I haven't yet fully overcome my reluctance to get into Javascript, though.

But I promise, as soon as I'm ready with Anarchies.oxp, I'll convert the whole thing into the Javascript-model. I believe then is the time for myself to munge through all your adorable work and learn your wiki documentation by heart. And when I'm done with this, I guess I will have been converted into a Javascript-junkie.

Post by **dajt** » Sat Aug 04, 2007 10:43 am

For the love of all things holy man, get yourself out of that horrific PLIST scripting and into something that makes sense!

It just kills me that OXP authors are putting stuff together with copy/paste from other OXP PLISTs and battling with that insane syntax. I mean of course that's the only reasonable way with the PLIST scripts, but there is a better world out there!

Note this is not meant as a slight against Giles' work, all praise Giles for adding scripting, but PLISTS... eeeuuuww. I stupidly said I would add "or" conditions one day and he said he'd be interested to see how I did it. I didn't - can't do it with the PLIST script structure.

And for all you lua people out there - I didn't use it because Oolite is completely unicode enabled, and lua isn't, so if Oolite ever did get localised then lua isn't suitable.

JensAyton · Post by **JensAyton** » Sat Aug 04, 2007 10:58 am

dajt wrote:
For the love of all things holy man, get yourself out of that horrific PLIST scripting and into something that makes sense!

To be fair, plist scripting has one advantage: it’s in the stable release. JavaScript is the future, but plists are the present.

dajt wrote:
And for all you lua people out there - I didn't use it because Oolite is completely unicode enabled

…apart from the bit that actually displays text. ;-) (Did anyone other than me actually suggest Lua? I suggested Lua and Io because a) I’m a trend whore and b) there was existing work on Objective-C integration. I’m not actually very familiar with the languages.)

Added Ship properties: entityPersonality, isBeacon, beaconCode, isFrangible, isCloaked, isJamming, groupID, potentialCollider, hasHostileTarget, weaponRange, scannerRange, reportAIMessages, withinStationAegis, maxCargo, speed, maxSpeed.

JensAyton · Post by **JensAyton** » Sat Aug 04, 2007 12:50 pm

Moved several bugs from Ta-da list to BerliOS bug tracker. Wrote new platform-agnosticish Problem reporting guidelines.

*cat · Post by *cat » Sat Aug 04, 2007 9:36 pm

I like the idea of Cmdr Mclane "munging" through the JS!
Wow! It really IS a word:
Mung (or munge) is computer jargon for "to make repeated changes which individually may be reversible, yet which ultimately result in an unintentional irreversible destruction of large portions of the original item." It was coined in 1958 at the Tech Model Railroad Club, at the Massachusetts Institute of Technology.

OR

"Dirt and vegetation that fills a crack."

JensAyton · Post by **JensAyton** » Sun Aug 05, 2007 12:17 am

Began work on ship scripts – scripts attached to ships. A ship script is specified as a file name (referring to a JavaScript file in the Scripts directory) with the key script in shipdata.plist. A ship script completely replaces setup_actions, launch_actions, script_actions and death_actions; these keys are ignored if script is present.

Currently, the following event handlers are defined for ship scripts:

didSpawn() (equivalent to launch_actions)
didDie() (equivalent to death_actions)
wasScooped(scoopingShip) (equivalent to script_actions for cargo pods)
playerDidDock() (equivalent to script_actions for stations)
shipDidDock(ship)
didScoop(scoopedObject)

The idea is that all current world script event handlers that make sense for non-player ships will be supported, and all ship script event handlers will also be supported for world scripts, which will act as ship scripts for the player. I’m not certain whether player ships will be able to have ship scripts in addition to the world scripts, but that shouldn’t be too hard.

Oolite Bulletins

Progress

Munge