Oolite Bulletins

New parameter for mission.runScreen: allowInterrupt. Set it to true (default is false, of course) and the mission screen can be interrupted by the GUI keys (F5, F6, etc.). Probably mainly useful for interfaces. (The parcel contracts screen now uses this)

If the screen is interrupted, the callback function does not run.

CommonSenseOTB wrote:

If on the other hand you have an oxp in place that gives the player a new target lock with a different target right after he loses the lock on the target the missile was targetting

Which event handler are you using for this?
Is this with or without the Multi-Targeting System?

CommonSenseOTB wrote:

normally, when you have a target and fire a missile, it will pursue it's target, while the player loses target lock with that target and all is well. If on the other hand you have an oxp in place that gives the player a new target lock with a different target right after he loses the lock on the target the missile was targetting, it would seem the missile instantly has that new target as its target for some reason.
...
The point I'm trying to make is that this problem perhaps shouldn't be happening and that maybe there are some quirks overall in the missile firing/targetting/accuracy core code that may need to be looked for/at that are causing strange or unexpected behaviour.

I'm pretty sure my problem is not due to losing target lock at the moment of firing a missile. I hate that btw! I might want to keep that targeted or at least switch to a different target, not be targeting nothing just because I fired a missile!

My missiles usually make a nominally correct path towards the enemy, but if they miss on final approach they go into corkscrews and figure 8's with total disregard for the direction or distance of their designated target. If anything, they tend to turn away from the enemy after initial pass -- and not even for the purpose of doing a 270 degree turn so they're approaching for a possible rear or head-on shot.

Switeck wrote:

I'm seeing "jousting" again by the npc ships. They don't close to very short range, instead staying about 12-15 km apart and shooting front and rear lasers at each other in rapid succession. This wouldn't be a problem in and of itself, but they're scoring extremely few hits if any at that range. Over the course of 1 minute, I didn't see any hits between the 2 npcs.

Should be fixed in r5427 - NPCs with aft lasers will now only use them if they're at a range that gives a reasonable chance of hitting with them. If they're too far away, they'll close in first. As with the rest of the combat changes, this needs some more extensive playtesting to pick up on cases I've missed.

cim wrote:

CommonSenseOTB wrote:

If on the other hand you have an oxp in place that gives the player a new target lock with a different target right after he loses the lock on the target the missile was targetting

Which event handler are you using for this?
Is this with or without the Multi-Targeting System?

Please just ignore my brief confusion. It appears that it was my script itself that was causing this and indeed hiding the fact. I'm playing musical chairs while squaredancing whilst in an infinite loop of "which came first, egg or chicken" and while trying to follow the chain of logic became convinced I was actually the chicken. Wait, no...the egg. Is it possibly to be the egg and chicken simultaneously???

Eureka, I've discovered quantum computing but narrowly escaped mental damage. Perhaps not.

Excuse and ignore please...

Station markets are now readable through the station.market property, and writable with station.setPrice() and station.setQuantity(). Full documentation on the wiki.

Forgive me if I missed it, but is there a timescale for the release of v1.77 yet?

Smivs wrote:

Forgive me if I missed it, but is there a timescale for the release of v1.77 yet?

Later than now, earlier than never?

While docked, and within reason, you can specify the exit of a mission screen with the exitScreen parameter. (e.g. exitScreen: GUI_SCREEN_INTERFACES)

A few minor bugs with parcel contracts have been fixed, and they've been made a little less frequently offered.

Cargo contracts and passenger contracts are now offered through the interfaces screen to fulfil a few feature requests for those contract types without having to dive into the GUI code mess (and for consistency with parcels). A few points about this:

• the algorithm for what's on offer isn't quite the same as the previous one, but it's intended to give similar results with one exception: the mass range of cargo contracts has been tweaked to increase the number available to Python/Boa pilots, and reduce the number for which the Anaconda is the only built-in ship with sufficient capacity.
• all available contracts may be considered: no longer limited to viewing 5 at once. This may affect balance slightly by making it easier to find suitable contracts, but probably not by a lot.
• a couple of new customsounds entries specifically for contract accept/reject. Custom overlays and backgrounds may be applied to the contract offer screens.
• each type of contract now has an API to allow OXPs to add a contract directly to the station list. Perhaps a mission starts when the player picks up a seemingly innocent passenger...
• the route map screen for a contract now shows the government and economy of the destination
• time displays are currently in hours. This can be customised by overriding the definition of oolite-contracts-time-format in missiontext.plist for people who prefer day+hour format.
• contracts are generated on arrival in the system, rather than on first view of the contracts list.

Additionally, an "unselectable" option has been added to mission screen choice keys. (You'll see how it works in the cargo and passenger contracts). There are a number of entries beginning "interfaces-category-" added to descriptions.plist as previously mentioned ("Station Places" has been replaced with Wildeblood's more generic "Organisations" suggestion) for ease of translation.

F8 F8 still works for now to allow easy comparison between the old and new contract generation algorithms. It'll disappear before 1.77, though (as far as I know the only OXP which relies on GUI_SCREEN_CONTRACTS existing is New Cargoes, and that should be done as interfaces anyway)

cim wrote:

F8 F8 still works for now to allow easy comparison between the old and new contract generation algorithms. It'll disappear before 1.77, though (as far as I know the only OXP which relies on GUI_SCREEN_CONTRACTS existing is New Cargoes, and that should be done as interfaces anyway)

<makes mental note for Cataclysm, which uses it as well at one point>

BGS is affected as well - it does nothing on missionscreens and there is nothing it can do at the moment. I'm aware of the possibility to set the background image/overlay in the new scripts, but it is still a standard missionscreen and there's no way to identify specific screens. So BGS will stop the music on all these subscreens.

A couple of new shipscript events (+worldscript if it's the player's ship, of course) The first one fires if a cascade explosion occurs within scanner range, or if a nearby ship calls the broadcastEnergyBlastImminent AI command. Equivalent to the CASCADE_WEAPON_DETECTED AI event.

The second one fires if someone shoots at them (with intent to hit) and misses. Equivalent to the ATTACKER_MISSED AI event.

Also, as requested, three new properties for visual effects: scaleX, scaleY, and scaleZ. Ever wondered what a Boa would look like if it were five times the width? Very silly is what it looks, but now you can prove it.

@cim:
Just noticed this in the repositories log on Berlios:

cim wrote:

Enable: 'b' secondary activation key for equipment (timer's patch)

Could you explain in a bit more detail what the "b" key now does?

That's the suggestion from this post. Timer kindly provided a patch for the extra key, and after testing it's now enabled in the default build.

If you press 'b', the currently selected primable equipment will get its "mode()" function called. While the functions are called mode() and activate() they don't have to be used for that. And no, there's no room on the keyboard to have any more keys than that...

For all existing equipment, it of course does nothing.

cim wrote:

That's the suggestion from this post. Timer kindly provided a patch for the extra key, and after testing it's now enabled in the default build.
If you press 'b', the currently selected primable equipment will get its "mode()" function called. While the functions are called mode() and activate() they don't have to be used for that. And no, there's no room on the keyboard to have any more keys than that...
For all existing equipment, it of course does nothing.

If I'm understanding this right, it would be more accurate to call this "Equipment Mode" rather than "Secondary Equipment".
<Goes off to change his key map again>