Oolite Bulletins

cim wrote:

New AI events: CASCADE_WEAPON_DETECTED

What should we add to our OXP weapons to trigger this AI event? I'd want the ai ships to flee away from a "Big Boom!" detonating mine even if it doesn't have a cascade effect like Q-mines. And maybe a spoof mine that causes an AI to flee in panic but either doesn't explode or does so in a trivial way...

...like it ECMs till it runs itself out of energy and dies.

Switeck wrote:

cim wrote:

New AI events: CASCADE_WEAPON_DETECTED

What should we add to our OXP weapons to trigger this AI event? I'd want the ai ships to flee away from a "Big Boom!" detonating mine even if it doesn't have a cascade effect like Q-mines. And maybe a spoof mine that causes an AI to flee in panic but either doesn't explode or does so in a trivial way...

...like it ECMs till it runs itself out of energy and dies.

Ah - missed one important new AI command out of the list: broadcastEnergyBlastImminent

cim wrote:

Ah - missed one important new AI command out of the list: broadcastEnergyBlastImminent

Won't that spoil the surprise?

Smivs wrote:

cim wrote:

Ah - missed one important new AI command out of the list: broadcastEnergyBlastImminent

Won't that spoil the surprise?

You could make an OXP that:
- gives Q-mines a custom AI that no longer broadcasts
- changes their scanner colours to white/white so the player doesn't get advance warning either

The fuse on a standard Q-mine is short enough that with the exception of ships with injectors, they're not going to notice quickly enough to get away anyway. (It actually makes it a more effective defensive weapon, since things stop shooting at you immediately rather than when the expanding blue sphere eventually intersects them)

Hmm, forget to say earlier. There are two new AIs for use with the Q-mine - fleeQMineAI.plist and respondQMineAI.plist. The flee AI just runs away from the mine's location as fast as possible, using injectors if available.

The respond AI is used by Thargoids, who lacking fear will not flee from Q-mines. Instead, they try to shoot it down, and then calmly (but quickly!) leave the area if it actually goes off. It's a small target, so they rarely actually succeed in shooting it down.

...

In other AI news, side lasers are now available in shipdata and for JS. Ships with side lasers fitted will automatically use them in combat as a variation on their normal attacks. The AI command "performBroadside" can be used to force the next attack run (only) to be made with side lasers.

cim wrote:

In other AI news, side lasers are now available in shipdata and for JS. Ships with side lasers fitted will automatically use them in combat as a variation on their normal attacks. The AI command "performBroadside" can be used to force the next attack run (only) to be made with side lasers.

This will mean the standard AI.plist files are too coarse to properly give justice to the capabilities npc ships have.
A npc ship could snipe till front laser is overheated, then move in to "performBroadside", then use rear laser on outward pass...overheating all lasers. If it was an elite pilot that's very accurate, almost no player ship could survive it. Maybe too tough for run-of-the-mill pirates, but suitable for harder missions/campaigns.

Switeck wrote:

A npc ship could snipe till front laser is overheated, then move in to "performBroadside", then use rear laser on outward pass...overheating all lasers. If it was an elite pilot that's very accurate, almost no player ship could survive it. Maybe too tough for run-of-the-mill pirates, but suitable for harder missions/campaigns.

Hmm, sounds interesting... I'd have to start using my own side lasers.
I like the performBroadside bit - 'Wait for it, lads! Fire on the uproll!'

El Viejo wrote:

Hmm, sounds interesting... I'd have to start using my own side lasers.
I like the performBroadside bit - 'Wait for it, lads! Fire on the uproll!'

<Wonders if you can make a fighter wing do that in formation.>
<Makes a note on the HIMSN AI page>

Switeck wrote:

This will mean the standard AI.plist files are too coarse to properly give justice to the capabilities npc ships have.
A npc ship could snipe till front laser is overheated, then move in to "performBroadside", then use rear laser on outward pass...overheating all lasers.

At the moment - it is on the list to be changed - NPC laser overheating is somewhat abstract. Once they have player-like laser overheating, then choosing the coolest weapon to make their next attack with makes sense, and the "choose attack method" routine that "performAttack" runs will need a bit of rewriting.

An AI for forward-laser sniping is on my list; I will have to make sure it doesn't make Constrictor Hunt too tough, though... (A side laser attack, incidentally, tends to retain about the same distance from the target, so if they start at long range it will effectively be sniping, though without any imperative to increase range again if the player gets too close)

Switeck wrote:

If it was an elite pilot that's very accurate, almost no player ship could survive it. Maybe too tough for run-of-the-mill pirates, but suitable for harder missions/campaigns.

Well, a full blast from just one military laser will almost destroy a fully-equipped Cobra III, so four would certainly give anything reasonable serious trouble.

Side laser usage does tend to make the NPCs slightly tougher, as they can shoot at the player and move out of the line of fire at the same time. A skilled pilot should still be able to track them, but it does improve their survivability. Admittedly, I was testing with Cobra IIIs, whose side cross-section is smaller than their front cross-section: you might be glad to have an FDL or a freighter try to use its side lasers on you.

Gimi wrote:

<Wonders if you can make a fighter wing do that in formation.>

If they start out in formation, then they would probably continue to attack in formation for at least the early part of the attack run (after that, maintaining a target lock would take priority, of course). Actually, probably the group would split in half - one half using its port lasers, one half using its starboard lasers.

cim wrote:

Gimi wrote:

<Wonders if you can make a fighter wing do that in formation.>

If they start out in formation, then they would probably continue to attack in formation for at least the early part of the attack run (after that, maintaining a target lock would take priority, of course). Actually, probably the group would split in half - one half using its port lasers, one half using its starboard lasers.

Thanks cim.
<Now wonders about the feasibility of a lock_formation AI command.>

Formations and groups tend to fall apart after first contact with the enemy.
The leading edge may spot and attack, breaking off from the rest...before the rest of the group is even in scanner range of the enemy.
The end result of that can mean no others from the group attack the enemy.

cim wrote:

New ship methods: ship.dealEnergyDamage(amount,range,shaping), ship.setBounty(amount,reason), ship.clearDefenseTargets, ship.addDefenseTarget(ship)

As the wiki is lagging a little with all these new goodies, can you explain a little what shaping means in ship.dealEnergyDamage?

I presume the function works the same way generally as it's AI command equivalent, and the other two parameters are obvious. But shaping seems a little obscure to my confuddled brain. I guess it will relate to how the amount decreases as a function of range, but in what way?

Switeck wrote:

Formations and groups tend to fall apart after first contact with the enemy.
The leading edge may spot and attack, breaking off from the rest...before the rest of the group is even in scanner range of the enemy.
The end result of that can mean no others from the group attack the enemy.

I understand this, I think I even understand why it would happen. So my thought was some sort of lock_formation command, something that effectively will make a flight of ships act as one unit.
So the flight forms up in formation, locks in formation, performs attack run, when 2 km past target breaks formation, joins formation at 10km, repeat.
A flight of four "HIMSN Asps would then have 4 military lasers and missiles when attacking the bigger units. You can of course add multiple conditions here. If attacked by plasma cannons, break and form up again with increased stand off distance. If attacked by missiles, open formation to 1km between ships, and so on.
Just an idea that I would very much like to see for use in the MRX* HIMSN.oxp.

(* mystical rumored expansion)

Thargoid wrote:

cim wrote:

New ship methods: ship.dealEnergyDamage(amount,range,shaping)

As the wiki is lagging a little with all these new goodies, can you explain a little what shaping means in ship.dealEnergyDamage?

It works a bit differently to the old AI command. With the AI command, you set a range and the weapon_energy property sets an amount of damage. The explosion then deals range * weapon_energy / 6.76 points of damage at 1m range (for a standard missile, 166420 points of damage). This falls off on an inverse square basis (and rises, within 1m range) until the set range, where it is truncated to zero.

The problem with this is that the damage dealt by a missile is highly dependent on the range it detonates at, which is dependent on the frame rate (the higher the frame rate, the closer to the programmed range the missile will explode). As a result, a single missile impact can destroy just about anything at low frame rates - and a frame rate of 30, which is perfectly adequate for normal play, still sees normal missiles able to destroy a fully military shielded Cobra III in a single hit with a head-on collision ... whereas at a frame rate of 100, this will never happen.
(A second problem: that damage formula is really not intuitive for working out how much damage the missile actually deals at its programmed range)

So, ship.dealEnergyDamage(amount,range) works a bit differently. Rather than setting the maximum range for the explosion, you set the ideal range. 'amount' damage is dealt at this range and at closer ranges. The maximum range is then automatically calculated based on an inverse square falloff of damage outside the ideal range (with a truncation to zero for efficiency at max scanner range)

...but. The old behaviour meant that missiles did more damage if you hit them head-on, and less if you got them to explode while fleeing. This is an interesting dynamic that we wanted to keep (or introduce, at frame rates closer to 100...) - but with just those two parameters every missile does exactly the same damage regardless (around 270 points for a standard missile).

So, the third parameter "shaping" (it is internally called "velocityBias" and I may go back to that name for the docs) for ship.dealEnergyDamage looks at the relative positions and velocities of the two objects, and adds on "shaping" points of damage for every 0.001LM of relative closing speed (capped at 1.0LM). This means that a collision where the missile is just scraping the edge of its detonation distance, at quite an angle (if you almost but not quite evade it, for instance) will do significantly reduced damage, while a head-on collision will do significantly increased damage.

For the standard missile, I calibrated it assuming the "standard collision" which should do 266 damage was for a ship doing about 0.3-0.35LM fleeing from a missile doing 0.75LM, for a relative closing speed of around 0.4LM. The standard missile is therefore set to this.ship.dealEnergyDamage(170, 32.5, 0.25);
and it detonates at about 25m, which is within the 32.5m ideal damage radius even with some framerate oddities.
- at 0.4LM against a fleeing target it does 170+(400*0.25) = 270 damage: near enough the intended damage, but it can be lower if the target managed to curve out of the blast. Still enough to destroy an unshielded Cobra III most of the time, as intended.
- at 0.75LM against a stationary target it does 170+(750*0.25) = 357.5 damage. Enough to seriously damage but not destroy a shielded Cobra III
- at 1.0LM+, when a pirate FDL drops a missile on you head-on at point-blank range, it does 170+(1000*0.25) = 420 damage. Enough to destroy a shielded Cobra III, or significantly damage one with full military shields.
(relative closing speed can be negative, though generally only if the missile was aimed at someone else)

Thanks for reminding me I'd missed the documentation for that one.

Gimi wrote:

I understand this, I think I even understand why it would happen. So my thought was some sort of lock_formation command, something that effectively will make a flight of ships act as one unit.
So the flight forms up in formation, locks in formation, performs attack run, when 2 km past target breaks formation, joins formation at 10km, repeat.

The problem is that for any target much smaller than "really quite enormous" and/or much faster than "stationary", the objectives of "remain in formation with flight leader" and "hit the same target as the flight leader" are contradictory. At a distance of around 10km, you need to be accurate to less than a degree to hit a fairly large ship (like a Cobra III or Python). At a flight separation of about 1km (a fairly tight formation, given the size of these ships) you need to fly on a trajectory over 5 degrees different to hit the same target at 10km.