Oolite Bulletins

Astrobe wrote:

Next I tried with distant suns OXP, which I thought was the most likely culprit, but it still works with it.

Something I've found in the course of figuring out about half a dozen different clashes between 1.79 and OXPs, is that the most likely culprit usually isn't the one at fault.. in fact, it can be downright surprising when you eventually track down the culprit.


The binary method is often the fastest way to find the offending OXP:

Remove half the OXPs. If problem goes away, change to the other half of the set and try again.

Continue removing half the remaining OXPs each time, eliminating the half that are trouble-free. Repeat until you have identified the culprit.

Even if you have hundreds of OXPs, this method will let you identify the source of the trouble in less than 10 iterations.

Glare should now also be visible on the external views. From tonight's build, it will also affect NPC ships, which might add a bit more consideration as to how one approaches combat.

cim wrote:

From tonight's build, it will also affect NPC ships, which might add a bit more consideration as to how one approaches combat.

I saw that in my emails.. VERY cool!

cim wrote:

Glare should now also be visible on the external views. From tonight's build, it will also affect NPC ships, which might add a bit more consideration as to how one approaches combat.

Very cool indeed! Might this also add a wrinkle to how the AI flees from combat? Or at least, how a skilled NPC might try to flee from combat. Because, if possible, one should try to run away towards the sun, to make oneself harder to hit.

I'd imagine it would also affect how a skilled NPC would attack.. out of the sun.

I say, the Constrictor Thief is a deadlier opponent now. Only problem was the blasted hunter pack at the WP beacon. I don't want any help from them and finally had to fight them off to scoop the you know what. They turned on my like ravenous wolves. Had to leave PDQ.

Ah, yes. It shouldn't be too difficult to reduce the likelihood of that sort of interference.

Tonight's nightly will have planet texture preloading turned off - you'll notice it on the F7 screen that the planet takes a few seconds to appear (depending on your graphics card and CPU). This may fix the problems with white-ball planets and disappearing planets, or it may not. I haven't seen either in an afternoon's play after making the change, but they didn't show up very often for me before, so...

cim wrote:

Tonight's nightly will have planet texture preloading turned off [snip] This may fix the problems with white-ball planets and disappearing planets, or it may not.

So far, so good - no white/disappearing planets, either at Ismaan or elsewhere (and F7 is loading pretty fast on my rig).

A couple of extra things for the JS Ship representation in tomorrow's build: The definition format is basically identical to characters.plist

And a couple more for the player ship The current cost of renovation (shortly after servicing this will be very low and impossible to buy at that price), and the ship-class multiplier for renovation costs (e.g. a prototype ship might cost twice as much to service as normal compared with its price)

A little convenience feature for manifest.plist users - if your manifest.plist defines the version, author and license properties (the first is required, but the other two aren't) these will be added as this.version, this.author and this.license values to all your script files (you can still override them within the script file if you want something else there)

This should make updating your version numbers on new OXP releases much easier (so there's even less excuse not to do it for minor changes...) - it brings the number of copies of the version number needing updates for a new Oolite release down from 53 to 2, for example.

...and in other news, a little bit of a usability tweak to the equipment list.

The list is now sorted by tech level and then by price (on the purchase list, low-tech cheap first; on the F5 screen high-tech expensive first). Items also have a sort_order property in equipment.plist which defaults to 1000 - but we've set Fuel to 1. This overrides the normal sorting so Fuel is always first. Probably in most cases distributed OXPs wouldn't set sort_order on their equipment - but if you want to re-order your own items in a personal settings OXP it might be useful.

cim wrote:

...and in other news, a little bit of a usability tweak to the equipment list. The list is now sorted by tech level and then by price (on the purchase list, low-tech cheap first; on the F5 screen high-tech expensive first).

Excellent - thanks!

Cim, you are a good fellow!

cim wrote:

A couple of extra things for the JS Ship representation in tomorrow's build:

Code: Select all

ship.crew
ship.setCrew(definition)

The definition format is basically identical to characters.plist

I know from other discussions and from the tantalising hints on the documentation for this in the wiki that this will eventually lead to the ability to add more than just a pilot, but for now is this basically a scriptable way of adding a define pilot to a ship? Thank you again for all the new features cim!