Oolite Bulletins

Does this interfere with track_contacts in shipdata?

Tricky wrote:

Does this interfere with track_contacts in shipdata?

It won't track contacts with exceptions, but others will continue to be tracked.

cim wrote:

exclude ships from collision tests against each other

Cim, you are a mind-reader. I just made a workaround in Escort Deck to avoid the non-stop collisions if there isn't about 30m between the main ship and escorts, which looks too much in closeups. So I place escorts near and move further back after landing in 1m steps at each collision which result a bit smaller but still too big gaps (at least no more escorts killed by the owner accidentally ).
Then in parallel you make a real solution without I ask, brilliant!

Working well in my tests, just I put a logcontrol.plist into my package with collision.except=no; else I got about 1MB log in every minutes and CTDs after 1-5 minutes, but no problem without log.

Norby wrote:

collision.except=no;

The debug log lines will be gone in tonight's build.

Following some recent discussions regarding ambient level lighting, the JS read/write property system.ambientLevel has now been implemented (commit 2962ab9) and will be available for testing in the next nightly.

The property is set on a per-system basis and the default is still whatever is present in the planetinfo.plist ambient_level property, or 1.0 in case of absent value. The light level is now capped at 10.0, which is more than enough to light up the existing universe plus a few more parallel ones.

Since ambientLevel is a per-system property, it will be reset to the new system level whenever you hyperspace or enter witchspace. If you are planning to use it for setting light levels universe-wide, you must be aware of that.

Quite a few bugfixes in tonight's build. A couple of substantive changes, too.

Scenario restrictions can now be more complex. You can combine different restriction types, and you can also tell Oolite not to process a core game plist while in a specific scenario. (For example, if you have a scenario where you don't want the player to be able to buy a Cobra III, you could exclude the core shipyard.plist so they can't). [wiki]scenarios.plist[/wiki] has more details. Scenario authors can get themselves into a larger than normal mess with this feature, as some entries in some of the plist files are required (e.g. if you override descriptions.plist - not recommended! - you must respecify all the entries used by core Oolite, or if you override trade-goods.plist you must redefine goods keyed "slaves", "alloys" and "minerals") - but it means that people developing scenarios that aren't just an addition on top of the core Oolite will have a much easier job of clearing out Oolite's defaults.

The corona_flare property has also been updated a bit, so that its appearance doesn't depend so much on the star's radius (for a given corona_flare value, the actual radius of the corona was proportional to the square of the radius of the star). Appearance within the star radii and corona_flares in the core game should be mostly unchanged, but if you were using larger values for either you might notice a difference.

I'm editing the noshaders oxp/oxz to make them v1.81 compliant. I was able to mend most warnings so far.

Don't know if it's the right place to ask, but I have got following my problem. Refering to the wiki I was able to setup up conditions via conditions key in shipdata.plist:
But It seems this isn't support in current development release anymore. After digging through the files I saw the _number was removed from the keys. Yet it still nags about the deprecated conditions key. I suppose the conditions was part of the old script engine, so maybe some is out there who's able to point me in the right direction (Wiki/Posting).


thanks in advance.

Use a conditions script, similar to equipment items.

http://wiki.alioth.net/index.php/Oolite ... wSpawnShip

thanks wildeblood. allowSpawnShip and allowOfferShip seem to be the ones I have to use then... too bad the simple conditions is gone now, usage was straight forward, but I think the script is probl. more versatile in the longrun.

Anything else I have to have an eye on?

[wiki]OXP_standards[/wiki] is probably the document you're looking for (including other things which are part of the legacy scripting system). Not yet updated for 1.81/1.82, but other than commodities/markets there's not going to be much change there.

thanks cim for the reply and the hint with the oxp standards. Does allowspawnship work for (system)stations too? It does mention only ships as entities to be spawned in the wiki.

Amah wrote:

Does allowspawnship work for (system)stations too?

Yes. A station is just a special type of ship with some extra capabilities.

Note that if you use conditions to make it impossible to spawn a ship with the main station role designated in planetinfo.plist for that system, the game will fall back to a coriolis as backup [1], and complain in the log file. If you want particular main system stations it's usually easier to set their role in planetinfo.plist than to use conditions.

[1] If that doesn't work either, it'll use any station it can find and complain even louder.

ah ok. I see how far my efforts will bring me now, and if it's ok will get back if I fail.

I understood planetinfo.plist is more a hardfixed approach (put station xy in System z). I'm working on the small Dertien Z_GrOovy stations and they are originally spawned based on systemproductivity plus its roles weighting.

A big set of changes in this morning's build, relating to equipment. A few of these have been in the nightlies for a while, but I don't think I mentioned them before, and they're all part of the same piece of work.

Basically the overall purpose of these changes is to make it much easier to make OXP equipment similar to the core equipment items and/or change the functionality of (some) core equipment.

So:

• Considerably more ship properties are writable by JS - maxRoll, maxPitch, maxYaw, maxThrust, maxEnergy, energyRechargeRate, cargoSpaceCapacity - and on the player ship also maxForwardShield, maxAftShield, forwardShieldRechargeRate, aftShieldRechargeRate. Yes, you can adjust forward and aft shields independently.
• heatInsulation is also writable for the player ship (it's been writable for NPCs for a long time)
• There are equipmentAdded and equipmentRemoved events. These don't supersede the existing worldscript events, but may often be easier to use. They are also shipscript events, unlike the others, so can be used on NPCs.
• There are some new ship properties for injector control - injectorBurnRate, injectorSpeedFactor - and for modifying the Scanner Targeting Enhancement text - scanDescription.
• Condition scripts get an updateEquipmentPrice method which can be used to provide variable price equipment (like fuel and renovation are in the core) in an OXP.
• Various core equipment items have been modified internally to make them fit with the above capabilities. The actual effect should be unchanged, but if you currently have an equipment.plist which overrides the core one, you will need to merge in the changes.
• There's now a concept of "provides" in equipment, to allow OXP equipment to provide core functionality (e.g. a navigation computer which provides docking computer, ASC, and advanced nav array as a single item). There's potential here for breaking down some of the more multi-functional items of equipment into a few pieces, too - the only one in the core game at the moment is that fuel and cargo scooping are now provided as separate functionality blocks (though the core game "Fuel Scoops" item of course continues to provide both of these features at once). See [wiki]equipment.plist[/wiki] for more information on what functionality blocks are available. There's a ship.hasEquipmentProviding(key) method which does what it says.

Wiki documentation is updated with all the new properties, methods, etc.

There have been some quite big changes to how many pieces of core equipment - energy units, shield boosters, heat insulation and large cargo bay especially - work internally. Careful observation that these items are all still functioning as they did in 1.80 will be required.

Very nice improvements, for example the writable maxshields are better than shield capacitors and the new injector properties made easier the making of my Small Fuel Injector idea. This game still growing faster than my ability to make my upcoming ideas.