More experimental missile behaviour

[cim]

Missile behaviour in 1.76 has a few annoying features.
- the explosive power of a missile has a significant dependency on frame rate. Frame rates that are too low (or too high!) don't give the correct missile behaviour. Too low, and missiles can do several times the intended damage. Too high, and the increased damage when hitting a missile head-on doesn't actually happen.
- calculating the weapon_energy required in shipdata to get the right sort of explosion is not obvious. The relationship between the weapon_energy number and the actual damage dealt to objects within the explosion is unclear.

So, experimentally in trunk is a new way of calculating missile damage, which has been applied to the standard missile and hardhead. The old AI command dealEnergyDamageWithinDesiredRange is still present and functions exactly as before, so OXP munitions should be unaffected.

Could those of you using the nightly releases please keep an eye on the missiles (both as a target and a user) and give feedback on how they work for you, please?


Technical details for OXPers and the curious follow:

- there's now a new JS function, subject to change, ship.dealEnergyDamage(baseDamage, intendedRange, velocityBias). velocityBias is optional and defaults to 0 if omitted.
- the ship script and AI for missiles has been changed to use this function.

The old dealEnergyDamageWithinDesiredRange works by setting a base damage calculated by multiplying weapon_energy (shipdata) by desired_range (AI parameter), and dividing this by 6.76. This is the damage dealt to ships 1m from the exploding entity (measured from the ship's collision radius to the entity's centre). For a stock missile, this is 166,420 points of damage (over six times the hull strength of a Coriolis station!)
Damage then reduces on an inverse square basis out to the desired_range, giving around 260 points of damage dealt at the intended 25m detonation distance (just enough to destroy an unshielded Cobra III). Beyond the desired_range, no damage is dealt.

At low frame rates, as demonstrated by Eric, this gives highly unpredictable missile damage, as exactly how close the missile gets to the target is increasingly approximated.

ship.dealEnergyDamage has a different damage curve.
- At the intendedRange or less, baseDamage is dealt. There is no increase within intendedRange (if you want there to be, then increase baseDamage, and decrease intendedRange!)
- Beyond intendedRange, damage again falls off on an inverse-square basis.
- The maximum explosive range is calculated as that range where baseDamage/distance-modifier = 1. For the standard missiles, this is a little larger than before, but this is barely noticeable. (objects between 250 and 400m get 1 or 2 points of damage, whereas they would have got 0 before)

If velocityBias is non-zero, then damage will be added (or subtracted, though this only tends to happen to other objects caught in the blast) depending on the combined velocities of the missile and the object caught in the blast. If you're hit from behind while fleeing and dodging, then the net "collision" velocity will be small, and damage will be smaller. If you run head-on into a missile, the damage will be much higher. Collision speeds tend to be in the range 200-1200, so velocityBias itself should be fairly small (somewhat less than 1.0) in most cases.

As a side effect, missiles will probably be slightly more powerful than they used to be against stationary targets and against things that are too macho to dodge... The latter may need a slight AI tweak; we'll see it how it goes.

[Eric Walch]

At low frame rates, as demonstrated by Eric, this gives highly unpredictable missile damage, as exactly how close the missile gets to the target is increasingly approximated.

To be more precisely, standard missiles are programmed to explode at 25 meter from the target. When they really would do that, all missile damage would always be the same. The damage at 25 meters is a fixed amount. So any effect off fleeing, turning or other flightbehaviour that effects the amount of the impact is a result of frame-rate. And, although that feels okay on high end computers, the effect becomes larger on low end computers, when more entities are in the system, or there are entities with more detail near the ship that have to be rendered.

Generally the old situation feels wrong, so I hope this change will lead to similar missile impact behaviour as before, that becomes independent of fps. It will be a challenge for cim to get a predictable variation in the damage so that players still keep the feeling that their actions against missiles do matter.

[Switeck]

Some damage variation is ok. Even doubling or tripling the damage for head-on impacts is ok.
But it was harsh to have a single head-on missile hit-and-kill my basically full-health ship that had way over 1000 combined shield + energy points.
Or for a tail-chasing missile to deal very low damage from a rear (near miss?) impact.

[cim]

Some damage variation is ok. Even doubling or tripling the damage for head-on impacts is ok.
But it was harsh to have a single head-on missile hit-and-kill my basically full-health ship that had way over 1000 combined shield + energy points.
Or for a tail-chasing missile to deal very low damage from a rear (near miss?) impact.

Now you know how I feel all the time in 1.76... Since it's that behaviour I'm trying to stop, it shouldn't still be doing it, no - thank you for testing it. Double damage for head-on compared with fleeing is about the level I'm going for, with fleeing damage being close to the 260 old missiles were supposed to do since that's the aspect which most missiles hit at.

1000 damage should require a combined collision velocity of around 3.0LM with the current calculations, unless there's a bug in them. Did you run into it on injectors, or something? (Oh, or did a FDL or Asp on injectors drop it on you at point-blank range?) Looks like I may need to put a cap on the calculation at about 1.0LM, either way.

I'll recheck the fleeing damage, too; there may be a case where it's too generous to the target there.

[cim]

I've adjusted the calculation slightly in r4884 to reduce (and cap in extreme cases) the effect of collision angle. When I test it missiles generally do damage in the 200-350 range depending on angle and the target's speed, and seem to do a sensible amount of damage to shields/energy when they hit me.

[Eric Walch]

I've adjusted the calculation slightly in r4884 to reduce (and cap in extreme cases) the effect of collision angle. When I test it missiles generally do damage in the 200-350 range depending on angle and the target's speed, and seem to do a sensible amount of damage to shields/energy when they hit me.

Generally the damages are higher than before and should be lowered. I have a special missile testing ship and usually I got a damage of a bit more than 2/3 of the shields (200 to 250 damage) when getting a frontal hit with no speed myself. This is a high-end machine with fps> 50. With low framerates this might be higher.
With the current setting of the new missile the damage is noticeable higher. Shield indicator turns red after the same hit.

log shows:

Code: Select all

[missile.damage.calc]: Range: 32.500000 | Damage: 145.710000 | MaxRange: 392.308791
[missile.damage.calc]: Base damage: 145.710000
[missile.damage.calc]: Velocity magnitude factor: 629.602234
[missile.damage.calc]: Velocity corrected damage: 325.776239
[missile.damage.calc]: 325.776239 at range 26.907288 (d=0.827917)

For those that also want to log above info, cim added a switch for it in logcontrol.plist, but with the console you also can switch it on with:

Code: Select all

console.setDisplayMessagesInClass("missile.damage.calc", true)

.

I like the high spread, so probably should base damage still be lowered?

[cim]

Generally the damages are higher than before and should be lowered. I have a special missile testing ship and usually I got a damage of a bit more than 2/3 of the shields (200 to 250 damage) when getting a frontal hit with no speed myself. This is a high-end machine with fps> 50. With low framerates this might be higher.
With the current setting of the new missile the damage is noticeable higher. Shield indicator turns red after the same hit.

I've calibrated the missile damage based primarily on a target which is running away from the missile (which most things that you might want to fire a missile at will be). An inevitable side effect is that damage against stationary targets is now higher than before, but players don't usually spend much time shooting missiles at those.

I could reduce the base damage so that it was calibrated for impacts on stationary targets instead, but I think this would make missiles noticeably less effective in real combat than their 1.76 counterparts {1}. Or, I could decrease the effect of relative velocity on damage, and so make the spread smaller.

Thargoids I still need to do something with so that they don't try to deal with missiles by ploughing through them, as that makes them considerably more vulnerable. I think it'll need a few AI tweaks there, which can wait until pilots with fear are working properly.

{1} At 30 FPS missiles are already noticeably less effective in combat than their 1.76 counterparts, in that they can't blow up a toughened ship in a single hit. But I think that's how they're supposed to be...

[Eric Walch]

I've calibrated the missile damage based primarily on a target which is running away from the missile (which most things that you might want to fire a missile at will be). An inevitable side effect is that damage against stationary targets is now higher than before, but players don't usually spend much time shooting missiles at those.

You are right. I did al my tests against missiles in a stationary situation. Easier to do and, because I sometimes tested with different accuracies, stationary testing gave more reproducible test conditions. But, on calibration you correctly take standard behaviour as basis and that is usually not a player waiting for an impact.

[Commander McLane]

But, on calibration you correctly take standard behaviour as basis and that is usually not a player waiting for an impact.

Objection, your honour! This is exactly my standard behaviour towards incoming missiles. If I'm quick enough I press 'E', if not, the missile hits. I ignore it and continue to kill its sender with my lasers.

And I never fire a missile myself.

[Cody]

<chuckles>

[Eric Walch]

But, on calibration you correctly take standard behaviour as basis and that is usually not a player waiting for an impact.

Objection, your honour! This is exactly my standard behaviour towards incoming missiles.

It will not be possible to keep behaviour identical as before. Maybe base damage could be lowered a bit in favor fleeing getting a lower damage than before.
And I also never flee for normal missiles, they get usually ecm-ed. So when I'm hit by them, its by surprise and thus more likely head-on than on my tail. By receiving missile hits, I mainly think at hardheads. Fleeing for them gives me more time to run away. I do a 'ping' every few seconds. Half of the occasions I manage to ecm it, the other half I do get a hit on my tail. At least when full back shields, otherwise I try to buy more time to ecm it by keeping a distance with short bursts of my injector.
(Using cloak feels like cheating and is only used when I really are pressed for time to do other stuff)

[Commander McLane]

(Using cloak feels like cheating and is only used when I really are pressed for time to do other stuff)

Indeed, it does feel a little like cheating. However, NPCs launching fragmentation missiles against me feels a little like cheating, too. So in this case I do use the cloak. However, I don't use it immediately, but wait until the fragmentation missile has made half the distance. The reason is simple: if the fragmentation missile detonates too closely to its owner, the owner is frakked, which depraves me of the kill. It's even worse if I have just frakked the owner and the missile explosion would vaporize his precious cargo (my precious loot, to be precise!). To prevent that I allow the missile to reach a safe distance before I duck and let it blow up.

[Eric Walch]

(Using cloak feels like cheating and is only used when I really are pressed for time to do other stuff)

I just committed a changed missile AI that no longer 'pops' the missiles on cloaking.

Now, when the target cloaks, it remembers the targets identity and heads toward the last known position of the target. Then it exploded there, in the hope the target did not move. Meanwhile, it keeps scanning for the stored identity, and as soon as it re-appears, it resumes its flight to the target.

That means that a cloak no longer disables the missile, but only disables the tracking of the target. To be safe, the target has to stay cloaked until the missile reached its destination. That prevents dealing with missiles by just a short burst of the cloak and forces to stay cloaked for much longer times to sneak away from the last known location.

Play with it for some time and let than know if this is a change that should stay in. The change will not affect novice pilots as they have no cloak but makes the cloak a bit more energy-expensive in its use. I think more realistic.

[Smivs]

Sounds good to me

[Cody]

Good - I'll download trunk tomorrow and coerce Nortons to run it. (That will be in tonight's nightly, yes?)