Oolite Bulletins

spara wrote:

How does the market save work now that there is the option to save at a non-main station? Does the game save the main station market and the particular non-main station's market?

That's correct.

As you may have guessed from the slowing of pace in the Progress thread and other comments we've made, we're getting closer to making an official release. This will be a stable release, numbered 1.80. As with the 1.76 stable release, we will be freezing the source to everything except documentation and serious bug fixes a couple of weeks before the release. We don't know yet exactly when that will be - it all depends when we think it's ready to go.

So, what does this mean:

• features are basically done for the release, so don't expect anything major to change in the nightlies in that respect from now on. There's still room to fit in minor stuff - JS properties, for instance - though.
• wide testing of the new features is crucial, especially the new OXP features. If you're an OXP author with a bit of time to spare, please try either writing a new OXP or converting an existing one to use the new features, and let us know how it goes. I've found various bugs and/or missing useful functions while doing this ... someone who does things I wouldn't think of is likely to find much more. Things like the new populator, new ship roles, new HUD dials, are all a bit under-tested at the moment.
• there has been incredible progress by the community in converting OXPs to the new OXZ format so that when a new user downloads 1.80 they'll have around 150 expansion packs - and rising - instantly available. I wasn't expecting us to have more than 100 by the time we launched, so this is great!
• please check over OXPs for bugs that weren't there in 1.77.1: we may have broken something along the way and not noticed.

Once we're reasonably confident that everything is working okay, we'll start the freeze.

A few recent bug fixes, all of which show we've got a bit of testing to do yet:

• collisions with stations should now be extremely rare
• save game filenames are back to the 1.77.1 behaviour of having "1" as a valid character
• external views work properly again
• typos in main shipdata roles fixed

We've also updated some of the documentation to 1.79 standards - new pictures for the Advice for New Commanders document, and an updated Reference Sheet can be previewed on Github. As part of getting the reference sheet updates together I have screenshots taken of all the new core ship models against a white background - if anyone else has a use for those, here's a zip file

cim wrote:

I have screenshots taken of all the new core ship models against a white background...

The Viper and Interceptor images now match - but the stated dimensions of the Interceptor are now incorrect, of course.

Some recent changes:
- one new property: system.allDemoShips (it returns an array, though at the moment it'll have either 0 or 1 items) for getting access to the simulated ships shown on status screens.
- the procedure for allocating "hold" positions for ships in a docking queue has been changed. This should reduce the number of collisions and near-misses while waiting to dock, so please keep an eye out for odd behaviour especially when many ships are waiting.
- ships using the new AI will follow the player out of interstellar space if possible. If you don't want this, set the AI flag "oolite_flag_likesInterstellarSpace" (in core, the thargoid AIs have this)
- MFD switching now works on autopilot, and MFD settings should be preserved a little better across HUD changes
- There's a Ship.shipDataForKey(key) static method to get access to raw shipdata.plist entries.
- the "white planet" bug should now be entirely gone: please let us know if you see any more of them!
- OXZ loading and startup should now be much quicker
- a bug introduced in 1.79 in the save/load screen is now fixed again
- a few minor AI tweaks and fixes

cim wrote:

Some recent changes:... a few minor AI tweaks...

Would those tweaks include the assassins, by any chance?

I don't think anything I changed would have affected them, but I could be wrong - what's different?

Only a vague impression of unexpected behaviour, in that they surprised me - but I've only had a brief excursion with today's nightly so far.

A few more minor adjustments - all feedback welcome:
- bug with manifest screen paging fixed
- new optional "drawWitchspaceDestination:" HUD dial. It's not added to the default HUD (though there's some code to uncomment to overlay it on the fuel gauge if you want, and it's been in nightly builds for a few days just to check it) but is there for OXPers
- new communications role "escapepod" (so that pods don't get shuttle comms despite sharing an AI)
- NPC miners will get a bit closer to asteroids before starting mining, so should be able to scoop up more of the bits.
- the temporary testing comms messages are now removed

cim wrote:

- NPC miners will get a bit closer to asteroids Star Jellies before starting mining, so should be able to scoop blown up into more of the bits.

Just sayin'

There is certainly an assumption in the miner AI that things with "asteroid" in their role list do in some way resemble an asteroid. YAH advertising billboards will be targeted for destruction in the same way. On the other hand, it's a very easy way for OXPers to add things inside asteroid fields.

I've adjusted it so that anything with "no_boulders" set in the shipdata.plist is not a mining target even if its role would normally suggest it. YAH billboards already have that, and it's easy enough to add it to the jellies.

New JS property ship.isMinable added. Thanks.

cim wrote:

I've adjusted it so that anything with "no_boulders" set in the shipdata.plist is not a mining target even if its role would normally suggest it.

New JS property ship.isMinable added. Thanks.

Excellent!
And I will sort out the Jellies, honest.

Question about the new auto_weapons parameter in shipdata.plist. Does it obsolete has_fuel_injection, has_shield_enhancer parameters etc. when used? And if it does, what does it exactly obsolete, e.g. is it futile to set has_fuel_injection or has_scoop on pirates?

spara wrote:

Question about the new auto_weapons parameter in shipdata.plist. Does it obsolete has_fuel_injection, has_shield_enhancer parameters etc. when used? And if it does, what does it exactly obsolete, e.g. is it futile to set has_fuel_injection or has_scoop on pirates?

It doesn't obsolete them, but it does mean you need fewer like_ship entries that only differ in those settings.

has_X properties give the ship a chance on creation of having particular equipment (as does the forward_weapon_type property, for example). auto_weapons gives the populator a chance to modify ship parameters if necessary to better fit the role.

So, for example, a Krait has a (fairly high) chance of having injectors. In most roles, the populator will just go with whatever it gets - but assassins need injectors, so if the Krait is generated without injectors (or for example if a Cobra III assassin is generated which will never have injectors by default) then the populator will add them if auto_weapons allows.

The final changes we made before the freeze - mostly bug fixes, and mostly mentioned briefly in other threads:
* considerably fewer assumptions made about the font texture - still a few left, but better than it was. Thanks to edgepixel for experimenting and finding these problems
* the font texture is now reloaded if strict mode is turned on or off
* a few more startup optimisations - you should get to the spinning cobra even faster now, especially with lots of OXPs
* cargo dumping default key changed from 'd' to 'shift-D'
* momentum from explosions only applied if there was an explosion (noticeable if you remove a large sub-entity)
* fixed some bugs with Managed AddOns folder creation and use
* some updates to the tutorial following testing with a new player
* sun_glare_filter / sunGlareFilter ship properties
* HUD legends can be right-aligned, and the default HUDs now use this. This makes it much easier to get your HUD OXP to cooperate with font OXPs.
* Containers in use for sub-tonne commodities now shown on the manifest screen, which might stop the occasional not-a-bug report.

...and one nasty bug discovered about two hours after the freeze started despite having been in the game for months
* stop strobe-light effect when approaching particular suns from particular distances.

Please keep testing the nightly builds (now is as safe a time as any to join in, if you haven't yet) and reporting bugs as you find them.

cim wrote:

spara wrote:

Question about the new auto_weapons parameter in shipdata.plist. Does it obsolete has_fuel_injection, has_shield_enhancer parameters etc. when used? And if it does, what does it exactly obsolete, e.g. is it futile to set has_fuel_injection or has_scoop on pirates?

It doesn't obsolete them, but it does mean you need fewer like_ship entries that only differ in those settings.

has_X properties give the ship a chance on creation of having particular equipment (as does the forward_weapon_type property, for example). auto_weapons gives the populator a chance to modify ship parameters if necessary to better fit the role.

So, for example, a Krait has a (fairly high) chance of having injectors. In most roles, the populator will just go with whatever it gets - but assassins need injectors, so if the Krait is generated without injectors (or for example if a Cobra III assassin is generated which will never have injectors by default) then the populator will add them if auto_weapons allows.

Two questions.
1. Does this mean that only ships added by the populator (in systemWillPopulate or systemWillRepopulate) will get their equipment revised? So if I add an assassin using addShips outside of the populator and the ship I get is a Cobra III, it will not have injectors?
2. Does this mean that equipment is only added to the ships, not removed? So that if a ship is added as a pirate-light-fighter and it has full missile load configured in the shipdata.plist, those missiles will not be removed from it?