Oolite Bulletins

Posted: **Tue Mar 11, 2008 7:56 pm**

All beep, boop and click sounds now go via customsounds.plist, with quite a few different keys, allowing for more varied/specific sounds in OXPs. (The curious can view the current version here.)

Setting the player’s target from JavaScript now locks on ident or a missile, with UI feedback.

another_commander has traced one probable source of memory overconsumption (not an actual leak, just way too many ships being generated).

Posted: **Sun May 04, 2008 3:00 pm**

Oh yes, the ol’ progress thread.

In addition to the boops, beeps and clicks mentioned above, quite a lot of other sounds – most, in fact, now go through customsounds.plist. Someone should check it out. Together with the new JavaScript music stuff in 1.71 (not properly documented yet, but outlined here) it’s a good time to be updating custom sounds OXPs.

Yesterday I checked in a fix for the bug which was messing up sun sizes. However, there’s now a second, not obviously related bug causing coronas not to be drawn.

I’ve revamped the processing of shipdata.plist, shipyard.plist and demoships.plist into a unified model, although it hasn’t been adopted fully (in particular, the shipyard still uses the old code). The effects of the changes are:

Filtering out of broken ships. Ships with a like_ship entry referring to a non-existent ship, or cycles of like_ship references, are removed. So are shipyard entries for ships that don’t exist (which means that Lestradae’s hack will actually work properly). Log messages are generated for ships filtered out in these contexts, but the shipyard one will be hidden by default in 1.72 because of Realistic Shipyards – but see below.
Memory usage and performance are improved. (For the geeks: random ship selection is now O(log n) instead of O(n) (for n = number of ship types with a given role) for the common case, but degenerates to O(n²) when a conditions check fails.)
New plists shipdata-overrides.plist and shipyard-overrides.plist can be used to replace individual properties in shipdata and shipyard, respectively. shipdata-overrides.plist should be useful for localization OXPs to set ship names without overriding other attributes. The most obvious use for shipyard-overrides.plist is a leaner implementation of Realistic Shipyards. Override entries for ships that are not in shipdata/shipyard will be ignored.

Note to Lestradae: version 1.73 and later will log warnings for shipyard.plist entries which don’t have corresponding shipdata.plist entries. The way to avoid this is to switch to shipyard-overrides.plist when 1.72 comes out.

Example of using shipdata-overrides.plist for localization:

Code: Select all

{
    // Localize built-in ships
    "alloy" = { display_name = "Frammento di Metallo"; };
    "asteroid" = { display_name = "Asteroide"; };
    // ...etc...
    
    // Localize OXP ships. Information for ships that are not installed will
    // be discarded by Oolite at startup.
    "python-cruiser" = { display_name = "Python Classe Incrociatore"; };
    // Note: display_name is not inherited through like_ship.
    // (This is not related to shipdata-overrides.plist, but worth noting anyway.)
    "python-cruiser-player" = { display_name = "Python Classe Incrociatore"; };
    // ...etc...
}

It would also be possible to use to, say, retexture ships using shipdata-overrides.plist by adding/changing their materials dictionary. However, it is not possible to override part of the materials dictionary, or any other dictionary or array within a shipdata entry. This is a feature, not a bug; if you could do partial overrides, interactions between different overrides would become to complex.

Posted: **Sun May 04, 2008 3:36 pm**

Hi Ahruman,

good news for me!

Filtering out ... references, are removed ... shipyard entries for ships that don’t exist (which means that Lestradae’s hack will actually work properly).

If I understand that correctly, will that create a new opportunity for a Realistic Shipyards Strict Version (one without ships of its own in, i.e. no shipdata.plist, that only rewrites prices & TLs of whatever ship oxps are installed)?

If this becomes possible without the old problems (many stderr reports, empty shipyards), I`ll add such an alternative strict version again to the download options.

Note to Lestradae: version 1.73 and later will log warnings for shipyard.plist entries which don’t have corresponding shipdata.plist entries. The way to avoid this is to switch to shipyard-overrides.plist when 1.72 comes out.

Does this mean that all ships data from the shipyard.plist that have no correspondence in the shipdata.plist of the Realistic Shipyards V3.01 OXP itself would have to be moved to a new shipyard-overrides.plist, while for a Strict Version (no shipdata.plist at all) the shipyard.plist would simply have to be renamed to shipyard-overrides.plist?

Or is it more complicated than that?

When answering, please take into consideration my limited understanding of scripting

Cheers, all sounding good!

L

Posted: **Tue May 06, 2008 12:33 am**

congrats on some serious improvements! =D

Posted: **Sat May 17, 2008 6:44 pm**

In 1.72, the Entity.call() function will only be available when the debug OXP is installed.

Posted: **Fri May 23, 2008 6:26 am**

System.setSunNova() will be deprecated in favour of Sun.goNova() and related methods and properties.

Posted: **Fri May 23, 2008 7:41 pm**

Rewrote argument validation and error handling in every single JavaScript function to be more consistent and less wrong. This took a while…

Posted: **Wed Jun 04, 2008 7:30 pm**

Fixed a number of bugs in the new ship registry system, in particular stuff related to like_ships handling. PAGroove_Stations 1.2.1 now works with the trunk version, but generates three error messages on first launch or when rebuilding the cache. The new is_template property can be used to indicate that a shipdata.plist entry is intended only to be used as a template for like_ships, which suppresses the error messages. (Such templates are completely removed from the ship registry after like_ship relationships are resolved.)

Also improved robustness and error messages when failing to set up a station properly.

Posted: **Thu Jun 05, 2008 9:15 pm**

@Ahruman

But after the generated error messages it works I assume? Great work btw developing this game

Posted: **Thu Jun 05, 2008 11:42 pm**

pagroove wrote:
But after the generated error messages it works I assume?

Indeed. The “problem” ships are removed from the registry, but after like_ship relationships have been “flattened”, so they’re not needed any more. Exactly the same happens with is_template, only without the error message.

Posted: **Thu Jul 10, 2008 8:47 pm**

Equipment restrictions are now applied when adding/awarding equipment, not just when shopping. Added new restrictions requires_free_passenger_berth, requires_full_fuel and requires_non_full_fuel, which are probably not very useful except that two of them are used for EQ_FUEL and EQ_PASSENGER_BERTH_REMOVAL. Awarding a damaged equipment item now removes any working version of the same equipment, instead of trying to remove EQ_FOO_DAMAGED_DAMAGED.

Posted: **Fri Jul 11, 2008 8:29 pm**

Shipyard now uses the “new” ship registry stuff. Woohoo, etc. Shouldn’t make a noticeable difference, except that shipyard-overrides.plist now works.

Note to localizers: "equipment-not-available" = " (N/A)" has been replaced with "equipment-@-not-available" = "%@ (N/A)".

Posted: **Fri Jul 11, 2008 8:52 pm**

Ahruman wrote:
Shipyard now uses the “new” ship registry stuff. Woohoo, etc. Shouldn’t make a noticeable difference, except that shipyard-overrides.plist now works.

Does this mean I can make the missile variants OXP work?

Posted: **Fri Jul 11, 2008 9:20 pm**

Cmdr. Maegil wrote:
Does this mean I can make the missile variants OXP work?

Dunno. What does it do? :-)

(Oh, and by “now works” I meant “should now work”, I haven’t tested it yet.)

Posted: **Fri Jul 11, 2008 9:38 pm**

Ahruman wrote:
shipyard-overrides.plist now works.

Oolite Bulletins

Progress

..