Oolite Bulletins

Thargoid wrote:

However I think the example parcel script itself needs a little tweaking, unless you've got a TARDIS...

Thanks. Fixed in r5329, along with a crash bug in the interface code.

cim wrote:

The interfaces are categorised and sorted by category. For easier translation and consistency, I'd like to add a few common categories to the core descriptions.plist: suggestions for what they should be are welcome.

What categories have you got to start with?

As we have discussed elsewhere I believe that one of the categories should be "Station Places" (or equivalent wording) for mission screens that "take" you to locations within the station such as bars, local police stations, planetary embassies, etc.

Thinking about the sorts of OXPs we already have, I'm thinking:
- Bounties
- Deliveries (which the parcels one would move to)
- Employment (sort of a miscellaneous category for missions that don't fit elsewhere)
- Help
- Logs
- News
- Ship Systems
- Station Places
Obviously OXPers could choose their own as well, but I'd like to try to cover most of the common categories.

I would have thought "Organizations" for things like the Explorers' Club config page, Bounty Hunters' message board at seedy space bars, and UPS, Oo-Haul, RRS & ITHA (Escort Contracts OXP) missions. More-or-less for any OXP that will repeatedly offer missions, that you can accept or decline, and puts a "Your reputation with..." string on the manifest page, as distinct from you-beaut Mission OXPs where declining any stage basically defeats the purpose of having the OXP.

As per this thread, boring and complicated things have happened to text handling (r5394). If you maintain an OXP which does complicated things with strings, it would be a good idea to test it.

The tickle() event handler, which has been deprecated more or less since the dawn of time, is no longer supported. Attempting to set the tickle property of a script now generates a warning.

The legacy script trace facility, which printed extremely detailed analysis of what legacy scripts were doing, is no longer supported. If you want to debug a legacy script, you should probably get it done in 1.76. (Actually, there’s been talk on the dev mailing list of removing legacy script support altogether; since we’re no longer planning a 2.0, we’re not committed to maintaining it in 1.x forever.)

The confusingly-named script.trace.javaScript and script.trace.legacy log messages – which are unrelated to the above trace facility and the JavaScript equivalent console.trace() – have been renamed to script.javaScript.call and script.legacy.run respectively. (script.javaScript.call is logged every time a method on a script is called directly by Oolite. script.legacy.run is logged each time a legacy script is run. These messages are disabled by default in logcontrol.plist.)

Since I’m busy throwing things out: the AI method scriptActionOnTarget: has printed a big, scary deprecation notice for some time now. Is anything notable still using it?

----- WARNING in AI fooAI.plist: the AI method scriptActionOnTarget: is deprecated and should not be used. It is slow and has unpredictable side effects. The recommended alternative is to use sendScriptMessage: to call a function in a ship's JavaScript ship script instead. scriptActionOnTarget: should not be used at all from scripts. An alternative is safeScriptActionOnTarget:, which is similar to scriptActionOnTarget: but has less side effects.

Ahruman wrote:

Since I’m busy throwing things out: the AI method scriptActionOnTarget: has printed a big, scary deprecation notice for some time now. Is anything notable still using it?

Checking through the big pile of OXPs:
- two in Assassins, both: "scriptActionOnTarget: becomeUncontrolledThargon"
- two in Galactic Navy, both: "scriptActionOnTarget: becomeExplosion"
(All used for destroying Q-mines)

It seems to me that those cases would work unchanged if scriptActionOnTarget: was aliased to safeScriptActionOnTarget:. (The difference is that scriptActionOnTarget: causes an immediate legacy script update/tickle event.) While Assassins uses a legacy script, it appears none of its handlers do anything when status=STATUS_IN_FLIGHT, except for a few that update planet descriptions on the idle tick. As such, the difference shouldn’t matter. And in practical terms, I tend to think of legacy script support as “Assassins compatibility mode”.

As discussed here, scripts are now loaded using the standard loading order, meaning that built-in scripts can be overridden by OXPs.

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.

The rapid fire rate they're now using also means they overheat their laser far quicker and then switch to the other laser and overheat it quickly too. Perhaps they should fire about half as fast till they score a hit or get hit?

The average NPC intentionally has an AI roughly equivalent to a Harmless human pilot. Wasting laser shots all over the place, failing to hit the broad side of a Boa, and fighting at inappropriate range suggests that it's working properly. Regularly remembering they have an aft laser is not so realistic, though - I shall tune their behaviour so that non-forward weapons only get considered within their "accurate" range, and that should fix this problem.

Switeck wrote:

Perhaps they should fire about half as fast till they score a hit or get hit?

The smarter half of the NPCs will adjust their targeting circle narrower if they keep missing, which automatically limits their rate of fire a bit (as well as making it less likely that they'll get into this sort of situation). The less smart half will just hold the trigger down in the vague direction of the target.

It's not actually too bad a tactic when used at appropriate range: they have a laser cool enough to fire for a bit most of the time, and the constant looping around to switch lasers makes it harder for the enemy to get a solid lock on them. (And if they had shields, it would balance the load on them)

Cool, just as long as this isn't the overwhelmingly common npc behavior.

Incidentally, I'm seeing missiles fly off in every direction except the ship I targeted.
Are missiles also using random-but-low accuracy values?

Switeck wrote:

Cool, just as long as this isn't the overwhelmingly common npc behavior.

Well, anything without an aft laser will be fine, so how common it is depends on your ship mix.

Switeck wrote:

Incidentally, I'm seeing missiles fly off in every direction except the ship I targeted.
Are missiles also using random-but-low accuracy values?

Missile accuracy is randomised, but works in a completely different way and doesn't make a lot of difference to their flight path (and also should be virtually identical to 1.76 behaviour). I haven't noticed any odd missile behaviour myself, but then I don't use them much, so I'll keep an eye open.

cim wrote:

Switeck wrote:

Cool, just as long as this isn't the overwhelmingly common npc behavior.

Well, anything without an aft laser will be fine, so how common it is depends on your ship mix.

Switeck wrote:

Incidentally, I'm seeing missiles fly off in every direction except the ship I targeted.
Are missiles also using random-but-low accuracy values?

Missile accuracy is randomised, but works in a completely different way and doesn't make a lot of difference to their flight path (and also should be virtually identical to 1.76 behaviour). I haven't noticed any odd missile behaviour myself, but then I don't use them much, so I'll keep an eye open.

It's funny that you should mention a potential problem with missile behaviour Switek. Maybe related, I'm not sure yet, but 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. I've just discovered this last night and today will try some frame callback delay between the missile firing and adding the new target lock for the player and see if that fixes it for what I'm trying to do.
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.