Progress

[JensAyton]

I’ve been working on updating PlanetEntity to support procedural textures in a non-crashing way that fits the current material model. In doing so, I found myself splitting of suns into a separate class, since they share almost nothing with planets in the implementation. As a side effect of this, I started on new, saner lighting management, which would lead to the demo light and shadowing working for ships with shaders. This set of changes turned out to be complex and probably won’t be ready for the next release.

However, in anticipation of the division of planets and suns, suns are now represented as a separate class in JavaScript. The nova-related methods should probably be moved from System to Sun, too.

[JensAyton]

JavaScript vectorExpressions and quaternionExpressions can now be arrays with the appropriate number of Numbers. Additionally, both Vector and Quaternion now have toArray() methods. This is basically to simplify integration with property lists, as in:

Code: Select all

this.magicVector = new Vector(ship.scriptInfo["ahruman-magic-vector"]); // shipdata.plist entry contains script_info = { ahruman-magic-vector = ( 1, 0, 0 ); }

[Griff]

that new light thing sounds interesting, does this mean two light sources in game? the sun and another 'ambient' one placed somewhere else to light up the shadowed areas on ships?

[JensAyton]

It’s primarily a fix for the fact that the demo/shipyard light doesn’t work for ships with shaders. However, I may reuse light 0 for reflected glow from the nearest planet. I also intend to provide a new framework or template for shaders that will allow the game to expand with more light sources in future, but I haven’t worked the details out yet.

[JensAyton]

• Made Ship.shipDescription read-write (except for the player).
• Added global function ExpandDescription(string : String), to perform substitutions like %H, [commander_name] and so forth.
• Added global function RandomName(), intended to be like %R substitution. In so doing, I discovered that %R is broken, but left it as-is so it will generate the same name for existing descriptions. Added %X to do the same thing, but without the bugs. RandomName() is different from either in that it doesn’t use the “predictable” PRNG, so it will provide a new name each time. To use the “predictable” variant in JavaScript, use ExpandDescription("%X").
• Ships that hyperspace out are no longer replenished in interstellar space.

Edit: on further investigation, %R (and thus %X) is only predictable some of the time. Fun, eh?

[JensAyton]

• Got Game Options submenu working under OS X.
• Implemented variable shader complexity support.
• Added default shader, used for all otherwise-unshaded ships with full shaders on, and for smooth ships or ships with effect maps specified in material dictionary with simple shaders.
• All ships now drawn with slight specular highlight by default (shininess = 10, intensity = 0.2) except in reduced detail mode.
• Reduced detail mode setting (as well as wireframe and shader level settings) now saved in preferences.

Effect maps? What are those? Well, there are now four additional keys in material attributes dictionaries: specular_map, emission_map, illumination_map and emission_and_illumination_map. Currently, these are only supported when shaders are enabled, although at least emission_map and illumination_map should be possible to implement for non-shader mode (but not before 1.70).

specular_map specifies a texture whose alpha channel is a specular exponent map (values ranging from 1 to shininess), and whose r, g and b channels specify the specular reflection colour. (If you’re going for realism, this should be white or grey, except for coloured metals like gold.)
emission_map specifies a texture whose values are added directly to the calculated colour for each pixel – in other words, it’s for glowing lights. This is not scaled by emission; the two can be used together, although I don’t see why you’d want to.
illumination_map specifies a texture whose values are added to the diffuse light. This can be used to implement hull spotlights, for instance.
emission_and_illumination_map is like emission_map, except that the alpha channel specifies a colourless illumination level.

Here is a demonstration of emission vs. illumination. The top row is illumination, the bottom is emission.

[JensAyton]

Added code to detect AIs which call reactToMessage: recursively (that is, have a "reactToMessage: FOO" command in state FOO), leading to infinite recursion and a crash. Future versions of Oolite will log an error message and abort AI state evaluation in this situation.

[Eric Walch]

Added code to detect AIs which call reactToMessage: recursively (that is, have a "reactToMessage: FOO" command in state FOO), leading to infinite recursion and a crash. Future versions of Oolite will log an error message and abort AI state evaluation in this situation.

I already was wondering what would happen with AI lines like:

"HAZARD_CAN_BE_DESTROYED" = (checkCourseToDestination);
"GROUP_ATTACK_TARGET" = ( groupAttackTarget)

It looked like getting in a loop to me. It was even on my todo list for testing if this line really (or similar) could crash oolite. But the fix you wrote tells me, it would have. In the Wiki I introduced the name priority message for the messages created with reactToMessage:. I thought that this would be the most explaining name when you don't know of the code.

[JensAyton]

All ships now have a JavaScript script attached. This is good because JavaScript scripts can be modified at runtime; now any script can “patch” the script of any ship to add actions to it.

For ships with script_actions, setup_actions, launch_actions and death_actions, these are now dispatched through the default JavaScript script. Getting this working has been a significant mental block for me this last, er, month or so.

As a result of this change, it is now possible to embed legacy script actions in JavaScript. However, the mechanism for doing this is undocumented and subject to change. So don’t.

If you’ve written an OXP which uses any of these, please make a note to test them with 1.70 when it’s available.

Also made various small changes for Mac OS X 10.5. None of these are in any way critical.

[JensAyton]

Changed names of a bunch of script event handlers. Made some event handlers available to NPC ship scripts which were previously only sent for the player. The name changes are:

• didBecomeDead -> shipDied
• didAbortAutoPilot -> playerCancelledAutoPilot
• didBeginJumpCountDown -> playerStartedJumpCountdown
• didCancelJumpCountDown -> playerCancelledJumpCountdown
• didDie -> shipDied
• didDock -> shipDockedWithStation
• didExitWitchSpace -> shipExitedWitchspace
• didFailToJump -> playerJumpFailed
• didLaunch -> shipLaunchedFromStation
• didLaunchEscapePod -> shipLaunchedEscapePod
• didRecieveDockingRefusal -> playerDockingRefused
• didScoop -> shipScoopedOther
• didSpawn -> shipSpawned
• didStartAutoPilot -> playerStartedAutoPilot
• shipDidDock -> otherShipDocked
• wasScooped -> shipWasScooped
• willDock -> shipWillDockWithStation
• willEnterWitchSpace -> shipWillEnterWitchspace
• willExitWitchSpace -> shipWillExitWitchspace
• willLaunch -> shipWillLaunchFromStation

The general pattern is that messages that are sent to any ship begin with ship, and messages that are only sent to the player begin with player. A special case is otherShipDocked, which is sent to a station’s script when a ship docks with the station.

In 1.70, the old names will be supported but will generate an error. (Specifically, the game will look for the new name, and if no matching method is found, it will look for the old name.) In 1.71, the old names will no longer be supported.

shipWillDockWithStation, shipDockedWithStation and shipWillLaunchFromStation – but not shipLaunchedFromStation – now get the station as an argument. For NPC ships, shipDockedWithStation is sent immediately after shipWillDockWithStation, since the ship doesn’t “exist” inside the station. shipWillLaunchFromStation is sent at the moment of launching, and shipLaunchedFromStation is sent after the 2 seconds of rotation after launching, after switching status from STATUS_LAUNCHING to STATUS_IN_FLIGHT and before the AI message "LAUNCHED OKAY" is sent.

The situation with witchspace messages is messy. Currently shipWillExitWitchspace, shipExitedWitchspace and shipWillEnterWitchspace are only sent for the player, while (only) NPC ships get shipWillEnterWormhole and shipExitedWormhole (corresponding to AI messages "ENTERED_WITCHSPACE" and "EXITED WITCHSPACE") when they enter/leave a wormhole, but not when hyperspacing in normally. (shipExitedWormhole is sent to a ship which has entered a wormhole in another system, been “freeze dried”, then resurrected when the player jumped to the same system). I’m not actually sure in which situations it would be appropriate to send a shipExitedWitchspace message to an NPC ship, and when it wouldn’t.

[JensAyton]

The following official bugs are being deferred to post-1.70:

• 012528 Shuttles are not landing anymore.
• 012458 escort-role is not working.
• 012450 deployEscorts can result in idle escorts after an attack.
• 012373 UseSpecialCargo buggered
• 012363 Aft, port and starboard weapons in shipyard.plist
• 012362 aft_weapon_type in shipyard.plist
• 012344 Ship crashes through collission by scooping cargo.
• 012212 Rising shuttle problems
• 011808 NPC-entities facing problem
• 011694 Zooming ships problem on demo 2 screen
• 011693 NPCs can use escape pods in interstellar space.
• 011692 Witchspace jump in atmosphere causes continued heating
• 011689 Ships launched by stations can’t use primary weapons
• 011688 Some ships do not display on demo 2 screen
• 011686 Crash on respawn, possibly related to player subentities
• 009269 PLAYING.txt is missing
• 005186 Keyboard issues
• 005159 No splash screen showing

The following official bugs are candidates for fixing for 1.70:

• 012240 Ghost Cargo Pods deferred
• 011893 Full-screen mode menu input broken Working around by filtering out stretched display modes; proper solution deferred
• 011691 Cancelling load game dialog handled badly (Mac OS X only) fixed

Unofficial bugs:

• Commander McLane’s showShipModel: bug: I can’t find the whole conversation now, but ISTR it’s fixed.

[another_commander]

Regarding bug 11694 (ships zooming problem on demo 2 screen), the bug has been temporarily hack-fixed (and not perfectly for that matter), but the zoom situation is now much better than before. Still it is good to have it in the list until it gets fixed properly.

[Commander McLane]

Unofficial bugs:

• Commander McLane’s showShipModel: bug: I can’t find the whole conversation now, but ISTR it’s fixed.

I recall that it was fixed.

And again thanks for all our work!

[JensAyton]

All JavaScript class documentation has been moved out of the draft namespace and quickly (hah) consistency-checked. It can be found in Category:Oolite scripting (or Category:Updated JavaScript features in Oolite 1.70, which is basically all of them, but the infrastructure to track changes by version should be useful in future). Still to do: document global objects and script events, and finish overview of JavaScript.

[JensAyton]

Another_commander has identified the short-range chart as the site of much memory leakage. In doing so he pinpointed one particular leak, which is triggered in various other contexts as well, but it’s a small part of the problem. I expect to be able to track this down quite quickly now that we’ve got a particular target, although the whole Christmas thing will get in the way somewhat.

In the mean time, I suggest not hanging around the short range chart screen more than you need to.