Oolite Bulletins

Screen backgrounds/overlays can now be scaled, allowing for more than 480 pixels vertically. Welcome to the 1990s!

This works by providing a dictionary/JS object instead of a string. The dictionary must have a “name” property, and may also have “width” and/or “height”; if only one dimension is specified, the texture is scaled proportionately. If neither is specified, they will default to the pixel dimensions of the image, which matches the old behaviour (unless your texture has a non-power-of-two size, in which case the behaviour now makes more sense).

The scaling works as follows: the Oolite display space is always 480 units high, while the width varies with the window’s aspect ratio. If the window is at a 4:3 aspect ratio, the width will be 640 units. If a background/overlay has dimensions specified as 640 by 480, it will fill up the screen.

The most common cases are likely to be:

• A higher-resolution version of your current background/overlay, with the same margins: use the dimensions of the old versions. For a full-screen backdrop, this will generally be width = 1024, height = 512 (or just height = 512).
• A proportionately scaled-up version of your current background/overlay with the margins trimmed: height = 480.
• An image scaled disproportionately to fit into a power-of-two aspect ratio (this is fiddly, but makes the best use of memory): the ideal dimensions of the image, scaled to a height of 480. For instance, for a 4:3 image, you’d use width = 640, height = 480. In this case, both dimensions must be specified.

I believe I’ve covered all the situations in which overlays can be specified, namely:

• screenbackgrounds.plist
• [url=http://wiki.alioth.net/index.php/Oolite_JavaScript_Reference:_Mission#runScreen]mission.runScreen()[/url]
• setScreenBackground() and setScreenOverlay().

In the JavaScript cases, passing null or "" will remove any existing overlay/background, overriding screenbackgrounds.plist.

New JavaScript function defaultFont.measureString(<string>) returns the width of a string, in ems, assuming no line breaks. (An em is the intrinsic unit size of a font; for a font at 12 points, 1 em = 12 pt. The mission screen text area is about 32 em wide. For reference, the sizes used in oolite-font.plist are in eigths of an em.)

The measurement takes the substitutions defined in oolite-font.plist into account.

The existence of the defaultFont object does not signify any plan to add multiple font support, it’s just there for future-proofing.

Hey cool! Muchas gracias .-)

This gave me always some headaches (e.g. when thinking about localization/fonts and .charCodeAt()'s Unicode usage). Rock'n'Roll! Will update Cabal_Common.

Since yesterday, coordinatesForEscortPosition() is now passed a second parameter, which is the number of escort slots the ship has. I say “slots”, because the escort index and count passed don’t necessarily correspond to live ships; in particular, coordinatesForEscortPosition() is called before each escort is added, and destroying an escort leaves a hole in the escort array (which can potentially be filled by acquiring a new escort that’s fishing for work).

Also, escort positions are now cached, so updateEscortFormation() is required if you want to change the formation (or create animated formations; it is valid to call updateEscortFormation() from within coordinatesForEscortPosition() to cause an update in the next frame).

sounds interesting, but how would you animate the formations? is there an indicator that shows the first formation has been achieved, thereby letting the 2nd formation begin?

Nope. Since the ships are always chasing a moving target, the true formation can never really be achieved. However, purely time-based animation works, and the ships will continuously try to get where they should be if they aren’t distracted by fighting, collision avoidance etc.

In fact, I have here in my pocket a modified example where the escorts switch between a spinning circle in front of the mother and a static circle behind the mother.

The ships have already been done, but I think the OXP is hidden in the crumbled remains of one of the OoSats.

Compass beacon icons are now drawn in the same way as missile icons. As with missile icons, this will break some existing beacon icons (but their behaviour was previously formally undefined). The polygon-sprite-dump-svg hidden setting now works for beacon icons too.

Since this will break compatibility anyway, I’m considering changing to looking up designs by “beacon” string instead of primary role. Thoughts?

Ahruman wrote:

Compass beacon icons are now drawn in the same way as missile icons. As with missile icons, this will break some existing beacon icons (but their behaviour was previously formally undefined). The polygon-sprite-dump-svg hidden setting now works for beacon icons too.

Since this will break compatibility anyway, I’m considering changing to looking up designs by “beacon” string instead of primary role. Thoughts?

This is a work in progress, so backwards compatibility is never assured. I vote for whatever makes the end product better.
Then again, I don't have to update any OXP's, so I'm being rather selfish here.

Ahruman wrote:

Since this will break compatibility anyway, I’m considering changing to looking up designs by “beacon” string instead of primary role. Thoughts?

Seems to make sense. Given that in case there is no design for a given beacon string, the first letter of that string will continue to be used.

I think I have never used more than one letter in my beacon keys. Perhaps one-letter-strings could automatically result in this letter being used, making them unusable as a name for a custom beacon definition?

Commander McLane wrote:

I think I have never used more than one letter in my beacon keys. Perhaps one-letter-strings could automatically result in this letter being used, making them unusable as a name for a custom beacon definition?

Now that’s downright sensible.

Ahruman wrote:

Commander McLane wrote:

I think I have never used more than one letter in my beacon keys. Perhaps one-letter-strings could automatically result in this letter being used, making them unusable as a name for a custom beacon definition?

Now that’s downright sensible.

Yeah, sometimes I seem to have a sensible moment.

Right, let’s see. *shuffles notes*

• Cube-mapped planets now have their poles in the right place. (I set out to fix this and found that it already worked. Don’t know when that happened.) Latlong textures are now wrong in a slightly different way than before, but I’m not very interested in fixing them; between the distortion, the misalignment, and the pinching, latlong textures have never looked very good. Use cube maps. (Bug #17243)
• Fixed the Mac sound bug where it would occasionally stick a knife into your ear and wiggle it around until your brain started running out of your nose. (Bug #17214)
• New ship script event shipTakingDamage(amount, fromEntity, damageType). Amount will be zero if damage is absorbed by shields. DamageType is the same as for shipDied(). The event is triggered after the damage is subtracted from the ship’s energy but before checking if it’s a kill, so energy may be <= 0 (and you can resurrect a ship by giving it energy in this situation). It should be called for any damage type except “removed”. (Feature request #5077)
• As far as scripts are concerned, the player can now only die once. (Previously, shipDied() would be called twice, once without parameters and once with.)
• When the player is killed by a q-bomb, the damageType parameter to shipDied() is now “cascade weapon” (not “energy damage”) and the player triggers a new cascade.
• Sounds that are listed in customsounds.plist are now preloaded to avoid loading delays. (The code was there before, but was never invoked.) Sounds that are played through JavaScript by specifying a file name cannot be preloaded; if you’re doing this, and your sound isn’t particularly rare, I suggest going through a customsounds.plist entry.
• New Entity method dumpState(). Same type of dump as pressing 0 while paused, or the super-secret shift-H key (I’d completely forgotten about that one).
• The JavaScript global and console objects are now replaced when resetting the game, and can no longer be used to smuggle information across sessions.
• Reduced memory usage of various special effects and JavaScript objects.
• Windows builds now support the JavaScript trace and profile commands (see upthread; only native functions at this time), and also the ability to turn Objective-C exceptions into JavaScript exceptions instead of crashing horribly.
• Updated to FireFox 4b10 version of SpiderMonkey, and dropped support for SpiderMonkey 1.7. Boring for you, fiddly for me, but I got to check in -121970 lines of code in one go. Nice big drop in the LoC graph.
• Bugs #17202, #17214,#17215, #17243, #17391,#17454, #17819, #17888, feature requests #5058,#5077,#5095 and task #3373 closed. Feature request #5031 deferred until after MNSR.