Page 9 of 138
Posted: Sat Jul 21, 2007 11:02 am
by JensAyton
- 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. :-)
Posted: Mon Jul 30, 2007 11:59 pm
by JensAyton
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.
Posted: Thu Aug 02, 2007 12:36 am
by JensAyton
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).
Posted: Thu Aug 02, 2007 4:52 pm
by JensAyton
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.
Posted: Thu Aug 02, 2007 8:38 pm
by JensAyton
Preliminary class documentation (more properties and methods are likely to be added):
Posted: Fri Aug 03, 2007 10:14 am
by Star Gazer
How can there be two identical, but different(!!), 'score' items in the 'player' entity class...?
Posted: Fri Aug 03, 2007 11:36 am
by JensAyton
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.
Posted: Fri Aug 03, 2007 4:38 pm
by JensAyton
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.
Posted: Fri Aug 03, 2007 11:43 pm
by JensAyton
Posted: Sat Aug 04, 2007 8:36 am
by Commander McLane
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.
Posted: Sat Aug 04, 2007 10:43 am
by dajt
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.
Posted: Sat Aug 04, 2007 10:58 am
by JensAyton
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.
Posted: Sat Aug 04, 2007 12:50 pm
by JensAyton
Moved several bugs from
Ta-da list to
BerliOS bug tracker. Wrote new platform-agnosticish
Problem reporting guidelines.
Munge
Posted: Sat Aug 04, 2007 9:36 pm
by *cat
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."
Posted: Sun Aug 05, 2007 12:17 am
by JensAyton
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.