Progress

[Cmd. Cheyd]

I guess in the final stage they won't be treated as ships, though?

I hope not, since I just blew away an entire planet with a single strike from a Mil Laser...

[Griff]

if you manage to pull off this planet code rewrite Ahruman, does it mean shaders for planets? i'm only asking because i think i promised everyone i'd do a backflip if shaderified planets became a reality and i'm starting to worry for my spine and vertebrae!

[Cmd. Cheyd]

I've already specifically asked this, so I'll answer if you don't mind...

(Yoda Voice) Be afraid, Griff... Be very afraid...(/Yoda Voice)

[pagroove]

I'il look at it tonight. Looks promising though.

[Cody]

i promised everyone i'd do a backflip if shaderified planets became a reality and i'm starting to worry for my spine and vertebrae!

I'll settle for the Griff WTF icon doing a back-flip.

[DaddyHoggy]

I've already specifically asked this, so I'll answer if you don't mind...

(Yoda Voice) Be afraid, Griff... Be very afraid...(/Yoda Voice)

No - surely : <Yoda_voice>Afraid be yes? HmHmm, Griff, afraid yes, be</Yoda_Voice>

[Commander McLane]

I’m working on a complete rewrite of planets. There’s lots of boring drudgery to go, but here’s a preview of sorts: a collection of planet meshes with correct texture coordinates.
planet-tester.oxp.zip (750 KiB)

Usage:

• Install OXP
• Name your planet texture of choice “world.png” and stick it in your AddOns folder
• Summon a “planet-tester-l3”.

The L3 is a medium-detail planet with 1280 polygons. There are six levels, from L0 (20 faces – an icosahedron) to L5 (20480 faces, can take half a minute or more to load). The planets have a 500 m radius, about the size of a Coriolis station.

There are some problems. Each model has a few invisible triangles. I believe this is a problem in Oolite’s data loading rather than the planet generator itself. (In wireframe mode, it can be seen that these triangles are actually inside out, but a winding error in the generator would appear as a repeated pattern). There’s a visible edge running up the “back” of the planets due to a limitation in Oolite’s smoothing. Neither of these problems will affect the final version.

There’s no trivial way to smoothly spin a ship around its Y axis, but Commander McLane will be glad to hear that the poles do in fact line up with the Y axis.

Textures are still pinched at the poles. This problem is fundamentally unavoidable with latitude/longitude texture maps, although it could be made arbitrarily small by throwing twenty more triangles at it. I intend to support cube map textures for planets in future, which will make this problem disappear entirely.

By the way:

Code: Select all

  [shipData.merge.failed]: ***** ERROR: one or more shipdata.plist entries have like_ship references that cannot be resolved: planet-tester-l2

This is because planet-tester-l2 is like_shipped to itself, instead of to planet-tester-l0 like all the others.

[JensAyton]

Thanks. I’d fixed that locally, but decided to leave it as an exercise to the reader. :-)

[Commander McLane]

Thanks. I’d fixed that locally, but decided to leave it as an exercise to the reader.

Ah! That explains everything, of course.

(Note to self: Learn this by heart as a handy explanation for my own bugs.)

[JensAyton]

That wasn’t so much an excuse for the bug as an excuse for not posting the fix.

[JensAyton]

Numerous times while using the debug console, I’ve wished I could use the last returned value in an expression without writing the previous line again, or copying and pasting. (Laziness is the core of programming.) Then I remembered that it was my code, so I fixed it: as of r2810, the last (non-null, non-undefined) value is stored in $. Example:


Since the console’s behaviour is implemented in JavaScript, this can easily be backported. Open Debug.oxp/Scripts/oolite-debug-console.js, find the line this.evaluate = function (command, type, PARAM), and change the function definition to:

Code: Select all

this.evaluate = function (command, type, PARAM)
{
    let result = eval(command);
    if (result !== undefined)
    {
        if (result === null)  result = "null";
        else  this.$ = result;
        consoleMessage("command-result", result.toString());
    }
}

this.$ = null; // initial value

[Commander McLane]

Handy.

[drew]

I guess in the final stage they won't be treated as ships, though?

I hope not, since I just blew away an entire planet with a single strike from a Mil Laser...

<evil laugh>Now witness the firepower of this fully armed and operational battle-station!</evil laugh>

I've already specifically asked this, so I'll answer if you don't mind...

(Yoda Voice) Be afraid, Griff... Be very afraid...(/Yoda Voice)

Shouldn't that be:

Griff, very afraid, you must be...

?

Cheers,

Drew.

[Kaks]

Some more javascript stuff:

As reported elsewhere, the compass is now exposed to javascript via two new read-only properties

player.ship.compassTarget and player.ship.compassMode
compassMode can be any one of the following:

Code: Select all

'COMPASS_MODE_BASIC'
'COMPASS_MODE_PLANET'
'COMPASS_MODE_STATION'
'COMPASS_MODE_SUN'
'COMPASS_MODE_TARGET'
'COMPASS_MODE_BEACONS'

Whenever the compass target changes, a new event is generated:
compassTargetChanged (compass target, compass mode)

We also have some changes to NPC missile handling:

the key max_missile inside shipdata.plist now also applies to all ships, not just players. Players are still limited to 16 missiles, while NPCs can have up to 32 missiles on board at any given time.

the new missile_load_time shipdata.plist key can now be used to determine the minimum delay in seconds between launching missiles. This applies to both player and NPC ships. If not specified, the ship's delay between missile launches is 0 seconds.

The following equipment related javascript commands now work with NPC ships too: awardEquipment(), removeEquipment(), equipmentStatus(), setEquipmentStatus() as well as hasEquipment()

NPC missile management is now possible: player.ship.target.awardEquipment('EQ_REMOVE_MISSILES') will remove all missiles from the targeted ship, while player.ship.target.awardEquipment('EQ_HARDENED_MISSILE') will add an ecm resistant missile to that ship, if there's any free pylon.

two new NPC & missile specific javascript commands have been added: ship.fireMissile() and ship.selectNewMissile()

fireMissile() will try and fire the first available missile, will return the missile fired, or null if no missiles can be fired at this time. It can take the optional missile identifier parameter, to allow for a specific missile to be fired. Missiles cannot be fired if the NPC ship hasn't got a valid target, or if the previous missile was launched less than missile_load_time seconds before. If a missile type was specified, and not found on the ship, fireMissile will return null as well.

selectNewMissile() will automatically select a missile for a specific ship. It uses the missile_role shipdata.plist key to find out which missiles to select. As with the system populator, there's a small chance that missiles other than the missile_role specified in shipdata will be selected.

Code: Select all

player.ship.target.awardEquipment(player.ship.target.selectNewMissile()); 

will automatically add the 'right type' of missile to a ship, i.e. one that its captain would normally choose.

Finally, there's a new clock.addSeconds(seconds:number) function. It adds the specified number of seconds to the in-game clock. The time range is between 1 second and 2592000 seconds (30 days) (in the latter case, the on-board clock will be adjusting for a considerable time) - returns true on success.

[Screet]

hasEquipment()

...which reminds me to ask whether there is something like the C++ type map in Objective C. It could enhance the access speed for equipment very well.

Adding these options for equipment is great - just what I would have been looking for in the next days anyway as I would like to make my missile defense system available to NPCs and one possible solution could be that specific ships simply are awarded with a NPC version of it

Screet