Page 16 of 139

Posted: Fri Jul 11, 2008 9:41 pm
by Cmdr. Maegil
Ahruman wrote:
Cmdr. Maegil wrote:
Does this mean I can make the missile variants OXP work?
Dunno. What does it do? :-)

This. :?
(Oh, and by “now works” I meant “should now work”, I haven’t tested it yet.)
Oh!...

Posted: Sat Jul 12, 2008 12:07 am
by JensAyton
As far as I can see, that has no connection to shipyards whatsoever…

Posted: Sat Jul 12, 2008 9:36 am
by another_commander
And as far as I can tell, it works already in 1.71.2 ;-)

Posted: Sat Jul 12, 2008 9:59 am
by Commander McLane
Ahruman wrote:
Note to localizers: "equipment-not-available" = " (N/A)" has been replaced with "equipment-@-not-available" = "%@ (N/A)".
Noted (and implemented).

Posted: Mon Jul 28, 2008 3:24 pm
by JensAyton
Working on splitting Split player JS object into two, player and player.ship. Tthe following properties and methods are still in player:
  • name
  • score
  • credits
  • alertCondition
  • alertTemperature
  • alertMassLocked
  • alertAltitude
  • alertEnergy
  • alertHostiles
  • trumbleCount
  • specialCargo
  • contractReputation
  • passengerReputation
  • increaseContractReputation()
  • decreaseContractReputation()
  • increasePassengerReputation()
  • decreasePassengerReputation()
  • commsMessage()
  • consoleMessage()
The following properties and methods have been moved to player.ship, along with everything inherited from Ship and Entity:
  • fuelLeakRate
  • alertCondition
  • docked
  • dockedStation
  • specialCargo
  • galacticHyperspaceBehaviour
  • galacticHyperspaceFixedCoords
  • awardEquipment()
  • removeEquipment()
  • hasEquipment()
  • equipmentStatus()
  • setEquipmentStatus()
  • launch()
  • awardCargo()
  • canAwardCargo()
  • removeAllCargo()
  • useSpecialCargo()
  • setGalacticHyperspaceBehaviour()
  • setGalacticHyperspaceFixedCoords()
The equipment-related ones will probably be moving up to Ship at some point.

This is the last major scripting-related change I expect to do before MNSR. I want to go over all the property and method names for consistency, though.

Edit: hmm, that was surprisingly easy. I wonder what I’m missing.

Posted: Mon Jul 28, 2008 4:32 pm
by Eric Walch
Ahruman wrote:
hmm, that was surprisingly easy. I wonder what I’m missing.
specialCargo. Probably a missing deletion in player.

Posted: Mon Jul 28, 2008 5:14 pm
by JensAyton
Eric Walch wrote:
specialCargo. Probably a missing deletion in player.
Indeed. (Also, I’m working on compatibility forwarders. There are a lot…)

Posted: Thu Aug 07, 2008 6:51 am
by JensAyton
Because JavaScript 2.0/ECMAScript 4th Edition will have a built-in class named Vector, I am renaming Oolite’s JS Vector type to Vector3D. Vector will continue to work in 1.72 and probably 1.73, but will later be removed. Unlike other compatibility aliases, there will be no warning messages if you continue to use Vector; your code will just stop working in 1.74.

Posted: Thu Aug 07, 2008 7:41 am
by JensAyton
Added bounty back to player as well as player.ship, since it’s conceptually a character trait rather than a ship trait.

...

Posted: Thu Aug 07, 2008 1:10 pm
by Lestradae
Do I understand correctly that the division into player and player.ship is the basis for owning more than one ship becoming possible, Ahruman? :shock:

Re: ...

Posted: Thu Aug 07, 2008 3:40 pm
by JensAyton
Lestradae wrote:
Do I understand correctly that the division into player and player.ship is the basis for owning more than one ship becoming possible, Ahruman? :shock:
No. The distinction doesn’t exist in the game code itself, only the scripting interface.

Posted: Thu Aug 07, 2008 3:49 pm
by JensAyton
Ahruman wrote:
Because JavaScript 2.0/ECMAScript 4th Edition will have a built-in class named Vector, I am renaming Oolite’s JS Vector type to Vector3D. Vector will continue to work in 1.72 and probably 1.73, but will later be removed. Unlike other compatibility aliases, there will be no warning messages if you continue to use Vector; your code will just stop working in 1.74.
Additionally, I’m phasing out the ability to use lists of numbers instead of vectors or quaternions except in constructors, for forwards compatibility with the type system in JavaScript 2.0. (Anyone seeing a pattern here?) Hwever, you will still be able to use an array. Example:

Code: Select all

var v = new Vector3D(1, 2, 3);  // will continue to work
var u = v.add(4, 5, 6);         // will generate a warning and later an error
var w = v.add([7, 8, 9]);       // will continue to work
Thus, in future a vector expression will be any of:
  • A Vector3D
  • An Entity
  • An array of three numbers.
Similarly, a quaternion expression will be one of:Or, in JavaScript 2.0 terms:

Code: Select all

type VectorExpression = (Vector3D! | Array! | Entity!);
type QuaternionExpression = (Quaternion! | Array!);

Posted: Sun Aug 24, 2008 10:17 pm
by JensAyton
Re-implemented SDL sound code to be more like Mac sound code, with code sharing advantages and bla bla. More importantly, the same sound can now be played on more than one channel at once on non-Mac systems. As a result, we no longer use two identical afterburner sounds.

Posted: Sat Aug 30, 2008 2:07 am
by JensAyton
Noticed that system.entitiesWithScanClass(), system.filteredEntities(), system.shipsWithPrimaryRole() and system.shipsWithRole() were all broken, and fixed them. Also added some nice JS console macros:
  • :nearest role – sets result to the closest ship with the specified role.
  • :tnearest role – sets the player’s target to the closest ship with the specified role. Example. :tnearest coriolis
  • :find expression – sets result to an array of entities matching expression, which is a predicate using the variable entity. For example, to find all planets, use: :find entity.isPlanet
  • :findS expression – similar to :find, but only looks for ships. Example: :findS ship.scanClass == "CLASS_BUOY"
  • :target expression – like :findS, but sets the player’s target to the closest found object.
These macros can be added to the console in 1.71.x with the following commands:

Code: Select all

:setM nearest this.result = system.shipsWithRole(PARAM, player)[0]
:setM tnearest player.target = system.shipsWithRole(PARAM, player)[0]
:setM find this.result = system.filteredEntities(player, function(entity) { return eval(PARAM); })
:setM findS this.result = system.filteredEntities(player, function(ship) { return ship.isShip && eval(PARAM); })
:setM target player.target = system.filteredEntities(player, function(ship) { return ship.isShip && eval(PARAM); }, player)[0]

Posted: Sat Aug 30, 2008 12:37 pm
by DaddyHoggy
Your continued tickling in the background is, as it always is, much appreciated, even by those of us who do not (yet) need to worry about such things!!