Oolite Bulletins

One thing that might be worth considering re the route planning functions: currently the choices (in 1.80) are "best time" or "lowest number of jumps," but sometimes the best time routes only shave off a small amount of time for a large number of jumps, and make extra fuel stops essential. I think there needs to be some sort of optimisation which takes the extra fuel stops into account, a "best of both worlds" route which falls somewhere between the extremes.

Note that as a consequence the player.ship.targetSystem property may be pointing to an out-of-range system during witchspace entry and countdown events, which it previously couldn't. This may require minor adjustments to a few OXPs

If player.ship.targetSystem now points to an out of range system, what property returns the next jump?

Also, would it make more sense to retain the original purpose of player.ship.targetSystem, and add a new property like player.ship.longRangeTargetSystem, so existing OXP's don't get broken, or are there behind the scenes reasons for the change?

phkb wrote:

Note that as a consequence the player.ship.targetSystem property may be pointing to an out-of-range system during witchspace entry and countdown events, which it previously couldn't. This may require minor adjustments to a few OXPs

If player.ship.targetSystem now points to an out of range system, what property returns the next jump?

Try player.ship.destinationSystem I dunno whether destinationSystem works for the player ship (it should), and if so, when. It might work always, in playerStartedJumpCountdown, only in shipWillEnterWitchspace or never.

For my purposes, player.ship.destinationSystem is not set when I need it to be, which is as soon as the player chooses a destination system on the F6 screen.

destinationSystem (and its counterpart homeSystem) only really make sense for NPCs who aren't going to change their mind on this.

phkb wrote:

If player.ship.targetSystem now points to an out of range system, what property returns the next jump?

No property at the moment, but as mentioned recently, in 1.81 there's a second parameter given to shipWillEnterWitchspace specifying where the jump is going. I'll add a property for it as well.

phkb wrote:

Also, would it make more sense to retain the original purpose of player.ship.targetSystem

One purpose - that there is code both OXP and core already using - is to determine which system the player has selected on F6. That purpose is being retained under the original name. It's going to cause problems in some cases either way.

cim wrote:

destinationSystem (and its counterpart homeSystem) only really make sense for NPCs who aren't going to change their mind on this.

That's a bit vague, cim. I know it was only intended for NPCs but you haven't unequivocally said whether it is actually set on the player ship or is always null? It also presupposes no-one writes an AI for NPCs that has them changing their "minds".

In my tests it doesn't get set for the player ship. But I haven't tested all scenarios, just up to the point where the player has selected a destination on the F6 screen. It might get set when the player enters a wormhole, but even if it did it's tool late for my purposes.

Wildeblood wrote:

That's a bit vague, cim. I know it was only intended for NPCs but you haven't unequivocally said whether it is actually set on the player ship or is always null?

Nothing in the core game sets it on the player ship. The JS property isn't marked player-read-only, so you could set it from an OXP - maybe some sort of "file your flight plan in advance" scenario?

Wildeblood wrote:

It also presupposes no-one writes an AI for NPCs that has them changing their "minds".

That's a controlled case, though.

You should now get a warning on your console if you try to dock with a station without clearance and clearance is needed - hopefully soon enough that you can do something about it.

Let me know if you notice anything not quite right with it, or with other parts of the docking process.

New HUD dial to go with the other four data_source dials from earlier - drawCustomImage:. It basically works like an image legend, except it's drawn during the dial rendering stage and you can change the image it points to with the data_source property.

cim wrote:

New HUD dial to go with the other four data_source dials from earlier - drawCustomImage:. It basically works like an image legend, except it's drawn during the dial rendering stage and you can change the image it points to with the data_source property.

Good on you, sir.

Something I've been meaning to raise: when I tried out the custom text dials, once I had defined a data source I couldn't remove it again by setting it to null as I expected to be able to. So an unwanted text had to be set to "". If HUDs are being switched, and each sets its own custom dials & data sources, but those data sources cannot be removed again when the HUD switches, the player ship could build up a very long list of them.

HUD message_gui can now have permanent = yes; set. You'll probably need a HUD setup quite a way from the default one for this to be a good idea, though.

With regard to playerCompletedContract, what situations create the different result types?

For cargo in particular, success is, obviously, when you complete the contract in time. short is when you arrive in time but with less than the agreed amount of cargo. But what is the difference between late and failed? I can trigger the late type by turning up after the agreed time, but I'm not sure how to trigger the failed event.

Ah, got it. late is when you dock in the target system after the deadline, failed is you dock in a non-target system after the deadline.

Some additions to the OXP Verifier:
- Javascript syntax of Scripts/*.js files will be checked
- Syntax of all (fixed-name) plist files will be checked

It's now a lot more worthwhile to run it before bothering to load Oolite in full.