Progress

zevans · Post by **zevans** » Thu Sep 17, 2009 2:08 am

I KNEW it was the flashers. Good work!

This goes to show that misdirection is the <key>. #derrenbrown

JensAyton · Post by **JensAyton** » Sat Sep 19, 2009 10:13 pm

Cache flushing is now asynchronous.

Or, to be a bit more concrete, startup times (especially on a “warm” cache) and delays in docking are shorter, potentially by several seconds.

JensAyton · Post by **JensAyton** » Sun Sep 20, 2009 1:22 pm

Wrongness redacted.

Post by **Eric Walch** » Sat Sep 26, 2009 10:41 am

Added the AI command: setCoordinatesFromPosition.
Coordinates is a vector variable that is only used by AI scripting. With this command one can store the current position in Coordinates and later in the script return to that position with the already existing command setDestinationFromCoordinates.

Added the JS property coordinates as a read/write value to ship. That way you can set it to any calculated value and than instruct the ship with the AI command setDestinationFromCoordinates to set this value as destination. Before we had only the AI command setCoordinates: x y z. And that command could only be used with fixed values.

Wiki pages · Post by **Thargoid** » Sat Sep 26, 2009 10:44 am

Just for clarity, will coordinates be in abs values? Thinking back to the fun and games in the past of abs values that weren't.

Post by **Eric Walch** » Sat Sep 26, 2009 11:30 am

Thargoid wrote:
Just for clarity, will coordinates be in abs values? Thinking back to the fun and games in the past of abs values that weren't.

I had updated the wiki page for clarification but it is a vector parameter, like position: this.ship.coordinates = ([x, y, z]). Only setting coordinates does nothing itself, like the other AI commands that change coordinates. It will be the setDestinationFromCoordinates that sets the real destination to that value. This is in line with all other AI commands that use that approach.
This will make thinks like flying into the external docks of the buoy repair station much easier to script.

JensAyton · Post by **JensAyton** » Sat Sep 26, 2009 12:07 pm

I don’t like the name, it sounds like it’ll change the position of the ship or something. How about targetCoordinates or savedCoordinates?

Post by **Eric Walch** » Sat Sep 26, 2009 12:21 pm

Ahruman wrote:
I don’t like the name, it sounds like it’ll change the position of the ship or something. How about targetCoordinates or savedCoordinates?

I was also not thrilled of the name setCoordinatesFromPosition but it was consistent with the existing: setDestinationFromCoordinates. And both are mend to be used in conjunction with each other. The first storing the coordinates and the second, later in the code, using the coordinates again.

..... Wait, you mean the coordinate property. You are right. savedCoordinates will be a more descriptive name and give less association with the ships actual position. (targetCoordinates will give an association with destination).

Post by **Kaks** » Sat Sep 26, 2009 1:11 pm

Thargoid wrote:
Just for clarity, will coordinates be in abs values? Thinking back to the fun and games in the past of abs values that weren't.

They're in internal coordinate system, which means abs..

The abs were, it's the planets & suns that kept moving about. Almost like in RL!

Post by **Kaks** » Sat Sep 26, 2009 5:48 pm

Two more scripting changes today:
planet.setTexture('foo') is going to be deprecated in 1.74 - it's being replaced by the read / write planet.texture property. You can now check which texture was applied to a specific planet.
Planet.texture returns null if no texture was applied.

And there's a new collection of read only properties attached to the Oolite object now: Oolite.gameSettings.foo allows OXPs to find out which game features are enabled.

In no particular order, the settings that can be queried are:
Oolite.gameSettings.autosave, wireframeGraphics, procedurallyTexturedPlanets, speechOn, reducedDetailGraphics, shaderEffectsLevel, musicMode. While most of the settings are just on/off switches which make the gameSettings properties return either true or false, the last two gameSettings properties return strings describing the specific settings their corresponding options have been set to. The wiki will be updated with the new info in a little while...

Svengali · Post by **Svengali** » Sat Sep 26, 2009 7:24 pm

Kaks wrote:
And there's a new collection of read only properties attached to the Oolite object now: Oolite.gameSettings.foo allows OXPs to find out which game features are enabled.

Yes! Thanks a lot :-)

Post by **Kaks** » Sat Oct 10, 2009 4:09 pm

Ok, quite a few things have happened on the javascript side of things inside trunk:

ship.forwardWeapon, ship.aftWeapon, ship.portWeapon, ship.starboardWeapon

these read-only properties return the Equipment Type for the weapon installed, or null if no weapon is installed at the specified facing.
On a fresh Jameson, player.ship.forwardWeapon.equipmentKey will return
'EQ_WEAPON_PULSE_LASER'
As NPC ships can only mount forward and aft weapons, the port and starboard properties will always return null.

ship.missileCapacity - read-only property, the maximum amount of missiles that the ship can carry. For NPCs, that's always equal to the number of missiles on board.

ship.missiles[] - array, read-only: all equipped missiles, external tanks, etc... are contained within as Equipment Types.
On a fresh Jameson player.ship.missiles[0].description would produce
'Faulcon de Lacy HM3 homing missile, fast and accurate when used in conjunction with standard targeting scanners.'

ship.equipment[] - array, read-only: all equipemnt listed on the f5 screen, excluding the main weapons. Equipment Types, of course. On a fresh Jameson, ship.equipment.length would be 0. Each equipment type property accessed via ship.equipment[n].property

-------

ship.passengers[] - array, read-only: all passengers are contained within as passenger objects, with the following structure:{name:string, start:systemID, destination:systemID,eta:clockSeconds, premium:credits, fee:credits, startName:systemName, destinationName:systemName, etaDescription:string}

ship.contracts[] - array, read-only: all cargo contracts are contained within as cargo objects, with the following structure:{quantity:int, commodity:string, start:systemID, destination:systemID,eta:clockSeconds, premium:credits, fee:credits, startName:systemName, destinationName:systemName, etaDescription:string}

Two new function have also been added:
ship.addPassenger(name, start, destination, eta, fee), and
ship.awardContract(quantity, commodity, start, destination, eta, fee)

example of usage: player.ship.addPassenger('Foo',0,7,clock.seconds+7*24*3600,1500)

If in galaxy 1, adds Foo as a passenger going to lave, who espects to be there 7 days from now, and will pay around 1500 credits on arrival (Oolite rewards early arrivals, penalises late ones).

-------

And finally, a long overdue change to the way js interacts with the player's cargo. There's now a new Manifest object, that can either be accessed using player.ship.manifest, or by simply typing Manifest.

Manifest['foo']: read/write property.
Replace 'foo' with any of the standard commodity identifiers, which are the lower case versions of the standard commodity names - as seen on the F8 screen. For 'Food' use Manifest['food'], for 'Alien Items' Manifest['alien items'], 'Liquor/Wines' Manifest['liquor/wines'], etc...

there's also
Manifest.list[] - array, read-only, lists all cargo types present in the hold with their quantities: {commodity:stringIdentifier, quantity:int, unit:string, commodityName:string}

As a direct result of working in this area, there are a few deprecations:

ship.availableCargoSpace & ship.cargoCapacity are now deprecated, the properties to use are now

ship.cargoSpaceAvailable, ship.cargoSpaceCapacity & ship.cargoSpaceUsed (unchanged from before)

Also deprecated are

canAwardCargo & awardCargo.

To add 5 tons of food, you can now type Manifest['food'] += 5; once the cargo bay is full, no extra cargo will be added onboard. And here's how you remove 2 kg of gold: Manifest['gold'] -= 2;

I think this covers the lot. Hopefully I didn't miss anything!

pagroove · Post by **pagroove** » Sat Oct 10, 2009 4:54 pm

Wow Kaks. You Dev's really have a heart for this game

I'm no real scripter but it looks like a lot of added possibilities.

pmw57 · Post by **pmw57** » Sat Oct 10, 2009 11:38 pm

Kaks wrote:
ship.missileCapacity - read-only property, the maximum amount of missiles that the ship can carry. For NPCs, that's always equal to the number of missiles on board.

ship.missiles[] - array, read-only: all equipped missiles, external tanks, etc... are contained within as Equipment Types.
On a fresh Jameson player.ship.missiles[0].description would produce
'Faulcon de Lacy HM3 homing missile, fast and accurate when used in conjunction with standard targeting scanners.'

I am wondering why missileCapacity is inconsistant across different ships, when missiles seems to be the more appropriate method to use for both player ships and NPC ships as well.

Lestradae · Post by **Lestradae** » Sun Oct 11, 2009 12:58 am

With the new cargo options, the last showstopper for owning multiple ships has disappeared.

Very good