Page 1 of 2

1.77 for OXPers

Posted: Tue Jan 08, 2013 5:29 pm
by cim
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.
  • 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.plist bugs are fixed. Specifically, requires_cargo_space now 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.dealEnergyDamage rather 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] accuracy value 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_ROCK scan 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 to mission.runScreen to 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 guiScreenChanged fires 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_DETECTED AI 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 the broadcastEnergyBlastImminent command 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 isInSpace property of Entity may help here (better than isValid in 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_alpha property. 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.markSystem now 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. [EliteWiki] 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.adjustedSeconds gives 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.plist and missiontext.plist. Translations will need to be updated.
The above is not a complete list of changes, of course. There are a lot of other new features listed in the changelog which are less likely to be relevant to existing OXPs, but are hopefully interesting for new OXPs. Have fun with them.

Re: 1.77 for OXPers

Posted: Tue Jan 08, 2013 5:46 pm
by Diziet Sma
It might pay to make this sticky for a while at least..

Re: 1.77 for OXPers

Posted: Tue Jan 08, 2013 8:24 pm
by another_commander
This one is stickied for now. It contains important information that will be of help to OXP creators, at least during the first few weeks of version 1.77.

Re: 1.77 for OXPers

Posted: Wed Jan 09, 2013 12:53 pm
by Cody
Seems like the ideal place to thank the dev team for their hard work - 1.77 is cool!

Re: 1.77 for OXPers

Posted: Fri Jan 11, 2013 4:19 pm
by pagroove
Agreed. Thanks for all the hard work to make this game better and better. :).

Re: 1.77 for OXPers

Posted: Sat Jan 12, 2013 5:23 am
by GGShinobi
Agreed! Thanks for this great game!! :D

(A "thumbs up"-button would be nice in this forum :mrgreen:)

Re: 1.77 for OXPers

Posted: Sat Jan 12, 2013 6:11 am
by Solonar
1.77 is a vast improvement, in game play, graphic effects and even performance. For some reason I can run full shaders in this version without suffering the same performance loss I experienced in 1.76. This client has not yet even crashed to desktop for me yet, as it would do on occasion for the previous release.

Re: 1.77 for OXPers

Posted: Sat Jan 12, 2013 6:21 am
by GGShinobi
GGShinobi wrote:
(A "thumbs up"-button would be nice in this forum :mrgreen:)
I just noticed that while a thumbs-up-button would be nice, a poll ("do you like the new version?") would do the trick, too!

So, now I've spammed enough! *rushes away* :arrow:

Re: 1.77 for OXPers

Posted: Sat Jan 12, 2013 12:20 pm
by Cody
GGShinobi wrote:
I just noticed that while a thumbs-up-button would be nice, a poll ("do you like the new version?") would do the trick, too!
<chortles> No... spare us the buttons and polls!

Re: 1.77 for OXPers

Posted: Sat Jan 12, 2013 3:05 pm
by cim
I'll keep updating the list as OXP-relevant bugs or changes are discovered.
  • Cargo premium and passenger advance in contracts reported as zero. This is a bug in 1.77 and will be fixed in 1.78. A partial workaround for OXPs using these is possible for passenger contracts (which always have an advance equal to 25% of the final payment, if they are standard Oolite-generated ones), but no neat solution exists for cargo contracts.

Re: 1.77 for OXPers

Posted: Thu Jan 17, 2013 12:22 am
by Styggron
Fantastic updates to 1.77. I really miss the energy bomb, I know it is very controversial I wish it was a toggle rather that forcing it to be strict mode only. People that want the advantage would always find a way anyway. it is all about player choice and customisation I was really surprised it was removed :-(

Hopefully someone will make an energy bomb equivalent OXP but for the present I'll have to stick with 1.76.1 which is a real pity.

Again fantastic work on the project development it has been so many of us Elite fans so happy :-)

Re: 1.77 for OXPers

Posted: Thu Jan 17, 2013 1:38 am
by mandoman
Styggron wrote:
Fantastic updates to 1.77. I really miss the energy bomb, I know it is very controversial I wish it was a toggle rather that forcing it to be strict mode only. People that want the advantage would always find a way anyway. it is all about player choice and customisation I was really surprised it was removed :-(
I kind of feel the same about the Energy Bomb, but I'm having to get creative in the situations I would usually have used it. I don't know, it makes things more exciting, but very dangerous. :)

Re: 1.77 for OXPers

Posted: Thu Jan 17, 2013 2:09 am
by mandoman
Okay, I just had a first. I was flying my Diamond cargo ship, and like I always do with it and others as big, I handed docking with the Oresque Station to the docking computer. After swinging me all over the place, while taking a steady pace toward the docking slit, the computer was about to take my ship into the station, when it suddenly flipped the ship on end, and crashed it. After I pressed Space, I found myself floating in space, just outside of the station, with no HUD, and no controls. The sounds were all working well, though. :)

Re: 1.77 for OXPers

Posted: Thu Jan 17, 2013 5:44 am
by Styggron
Ok disregard my posts re Energy Bomb you CAN put it back if you want.

The link is at the bottom of the Oolite Wiki entry for Energy Bomb :D

Time to update to 1.77 exclusively now.

http://wiki.alioth.net/index.php/Energy_Bomb

Re: 1.77 for OXPers

Posted: Thu Feb 07, 2013 10:57 pm
by Frame
Cool, but starting with splash screen chrashes on AMD ATI when vertical refresh is set to on