1.77 for OXPers
Posted: Tue Jan 08, 2013 5:29 pm
Welcome to 1.77! As you can see from the changelog, this version has a lot of new properties, methods, commands and features for scripting.
Some of them have implications for existing OXPs, and for the best way to do things when writing new OXPs. We've tried to keep things as compatible as possible, and almost all OXPs which worked in 1.76 should continue to work in 1.77 - but there were a few unavoidable areas where compatibility was broken, and edge cases which don't quite work the same as before - importantly, there are now also better ways to do certain things, and OXP writers might wish to upgrade their code to use this.
Red is used to indicate changes which may cause bugs in existing OXPs (or in some cases is known to do so), ranging from cosmetic oddities to complete failure.
Blue is used to indicate changes where existing OXPs may wish to make use of a new feature, and new OXPs should avoid using the old method.
While this is a long list, the vast majority of OXPs will continue to work as before without any changes being necessary. Please read through it to make sure that you are aware of potential issues for your OXPs, though.
Some of them have implications for existing OXPs, and for the best way to do things when writing new OXPs. We've tried to keep things as compatible as possible, and almost all OXPs which worked in 1.76 should continue to work in 1.77 - but there were a few unavoidable areas where compatibility was broken, and edge cases which don't quite work the same as before - importantly, there are now also better ways to do certain things, and OXP writers might wish to upgrade their code to use this.
Red is used to indicate changes which may cause bugs in existing OXPs (or in some cases is known to do so), ranging from cosmetic oddities to complete failure.
Blue is used to indicate changes where existing OXPs may wish to make use of a new feature, and new OXPs should avoid using the old method.
While this is a long list, the vast majority of OXPs will continue to work as before without any changes being necessary. Please read through it to make sure that you are aware of potential issues for your OXPs, though.
- Energy bomb is now strict mode only. Awarding this equipment by script will now fail with an exception. Additionally, combats in which use of an energy bomb was an expected combat tactic may now be more challenging than intended.
equipment.plistbugs are fixed. Specifically,requires_cargo_spacenow actually takes up space, and"available_to_all" = no;really does ban equipment from general installation. At least one OXP is affected by the latter. You will also find incompatible equipment disappearing from your ship when you load a save game. OXP equipment providers should check for this and update their OXPs. See also the note below on "condition scripts".- Core missiles have been changed to use a JS-based detonation. While there is some compatibility code in place, OXP missile provision should make use of the JS method
ship.dealEnergyDamagerather than the old AI command, as this allows more precise (and intuitive) control over missile behaviour, and is less dependent on FPS. Missiles which use the standard missile AI but have their own ship script will fail to detonate as a result of this change until rewritten. - There have been significant changes to NPC combat AI. Consider giving mission-important or otherwise toughened ships a custom
![[EliteWiki]](/images/elitewikismall.png)
accuracyvalue as a more interesting substitute for massive energy reserves or ridiculous armaments. - NPC laser specifications have been unified to player spec. This significantly increases the fire rate and heat capacity of NPC beam and military lasers, while slightly weakening the NPC pulse laser. Again, combat balance may be affected: while the intent has been to keep generic spacelane combat balance roughly equivalent to 1.76 - and we'd like to hear your feedback on this - OXPs with heavy use of military laser NPCs will find they are much more dangerous.
- NPCs may now equip and use side lasers. Additionally, an optional "weapon_facings" parameter has been added to shipdata.plist, to define the weapon mounts an NPC ship has (default: all). Ship OXPs should define this parameter for better compatibility with other OXPs; shipset OXPs should note that all core Oolite ships now have weapon_facings defined, and copy these values to their own shipdata.plist
- Rock hermits explicitly have a
CLASS_ROCKscan class rather than relying on the populator. Rock hermit OXPs should copy this bug fix if they don't already have it. - An 'interfaces' screen is provided on F4. This allows player-initiated access to mission screens and extra functionality, scripted through
station.setInterface. The practice of using particular GUI screen change combinations to activate mission screens should generally be avoided in preference to an interface definition, to remove the chance of OXP conflicts, and to give a more consistent user interface to the player. Note that several additions have been made tomission.runScreento assist with this. - The contracts screen F8 F8 has been removed. All functionality is now available on F4. Any OXPs which were relying on F8 F8 existing will need to be altered.
- The screens for which
guiScreenChangedfires have been adjusted. This has already caused problems with some OXPs when tested in trunk. For future proofing, we recommend that you always check the 'to' parameter of this event handler carefully. - A
CASCADE_WEAPON_DETECTEDAI event to allow responses to nearby Q-mines has been added. Custom AIs should be modified to incorporate this event as appropriate. Two new standard AIs (for running away and for attempting to destroy the mine) have been added, and may be convenient. Additionally, OXP weapon systems which create a cascade blast should strongly consider using thebroadcastEnergyBlastImminentcommand a few seconds before detonation. - Point defense AI support has been improved. Capital ships with turrets and/or thargoid lasers may benefit from using the fine control over this functionality available through script and AI commands. The default point defense behaviour may be adequate, however. Ships with large turret capacity are now considerably less vulnerable to 'swarm' tactics, as their defenses will target multiple nearby attackers. Additionally, the turret properties controlling firepower, range, and rate of fire now all work properly.
- Roles beginning with a '[' are now forbidden. This is because the role '[foo]' now refers explicitly to the ship with shipdata.plist key 'foo'. This is more convenient than explicitly specifying a unique role for every ship.
- References to ships in holds are slightly different. The new
isInSpaceproperty of Entity may help here (better thanisValidin many cases) - Exhaust z-size is now used. This is a relative, not absolute, setting, with 1.0 as the default size, and 0.5 to 2.0 being multiples of that. Values outside the 0.5 to 2.0 range will be treated as 1.0. Shipset OXP writers should note that some values for exhaust z-size have changed in the core shipdata.plist as a result, though if you have remodelled the ship you will probably want to set your own anyway. Ship OXPs may also wish to check this value.
- planetinfo.plist
cloud_alphaproperty. A bug preventing proper cloud generation for textured planets is now fixed. As a result, textures which already have clouds added may look wrong. Planet texture OXPs may wish to set cloud_alpha to a value < 1.0 to adjust for this. - Condition scripts have been added to ships, shipyards, and equipment. These supersede and deprecate the legacy scripting approach to conditions, and are considerably more flexible. With this change, all legacy scripting engine usage can be duplicated by JS scripting, and use of legacy scripting in new OXPs is strongly discouraged. You can also use these instead of the TL:99 hack, and this has been done for core equipment items.
mission.markSystemnow has extra parameters. OXPs using this function can now modify their markers so that other OXPs will not remove them. You can also change your marker colour and style to make the distinction between OXPs clearer to the player.- Visual Effects have been added. These allow the addition of non-colliding scriptable entities to the universe. In general, these are to be preferred over the use of fake ship entities with simple models ... and ship entities with non-existent models are still not supported.
- 'Virtual' docks added by the deprecated '
port_dimensions' and 'port_radius' keys now count towards the collision radius of the station. Specifying real dock subentities is recommended. Additionally, code has been added to flexibly disallow docking at stations - useful if you have a station which the player shouldn't be able to dock at, for instance. Multiple docks can also be added, which may be useful for busy stations. - The string expansion system is now more consistent. Certain patterns do expand differently - e.g.
[%H]and will need to be adjusted. Additionally, because of the need for compatibility with older Oolite versions, the handling of %R is a little inefficient - unless you're generating planet descriptions, %N should be used instead. clock.adjustedSecondsgives the current adjusted time. This can be used to set things up on witchspace exit, etc. without having to wait for the player's clock to finish adjusting. Recommended for any deadline calculations which are needed.- Character '31' (hex:1F, octal:037) is now a narrow 'hair-space'. Custom font OXPs should ensure that this character is blank and has the same narrow width as the core font definition, as it is used to allow an equivalent to 'tab stops' in mission text.
- Several additional entries are now present in
descriptions.plistandmissiontext.plist. Translations will need to be updated.
.
)
