Join us at the Oolite Anniversary Party -- London, 7th July 2024, 1pm
More details in this thread.

Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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: In the JavaScript cases, passing null or "" will remove any existing overlay/background, overriding screenbackgrounds.plist.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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.
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Re: Progress

Post by Svengali »

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.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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).
User avatar
Killer Wolf
---- E L I T E ----
---- E L I T E ----
Posts: 2268
Joined: Tue Jan 02, 2007 12:38 pm

Re: Progress

Post by Killer Wolf »

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?
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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.
User avatar
Thargoid
Thargoid
Thargoid
Posts: 5527
Joined: Thu Jun 12, 2008 6:55 pm

Re: Progress

Post by Thargoid »

You really are in danger of someone writing Space Invooders OXP, you realise this? :twisted:
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

The ships have already been done, but I think the OXP is hidden in the crumbled remains of one of the OoSats.
User avatar
Thargoid
Thargoid
Thargoid
Posts: 5527
Joined: Thu Jun 12, 2008 6:55 pm

Re: Progress

Post by Thargoid »

The ships I know (I've seen them) - they can now march en-mass from the witchpoint to the station via a rather serpentine sideways route... :mrgreen:
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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?
User avatar
Gimi
---- E L I T E ----
---- E L I T E ----
Posts: 2073
Joined: Tue Aug 29, 2006 5:02 pm
Location: Norway

Re: Progress

Post by Gimi »

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. :oops:
"A brilliant game of blasting and trading... Truly a mega-game... The game of a lifetime."
(Gold Medal Award, Zzap!64 May 1985).
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Progress

Post by Commander McLane »

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?
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Progress

Post by Commander McLane »

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. :wink:
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Progress

Post by JensAyton »

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.
Post Reply