[General Battuta]

Specifically, I'm interested in the randomness used.

Let's say I have ten missiles chasing a single ship. The ship fires a countermeasure.

The CM has strength 1, and the missiles have seeker strength 2. So there's a 50% chance the missiles will chase the CM.

What I want to know is: if all ten missiles see the countermeasure in the same frame, will they each roll a separate 50%, or do they all use the same roll?

[The E]

Every missile gets its own dice roll.

[General Battuta]

That's not the behavior I'm observing, but I suspect it has something else to do with the way CMs and missiles interact. I'll poke at it further.

[The E]

In pseudocode, what happens is this:

For all homing weapons
    For all countermeasures
              if countermeasure team != weapon team OR weapon owner is traitor
                    if weapon is within countermeasure effect radius
                            compute intercept chance
                            if frand() >= chance
                                  ignore this countermeasure
                            if countermeasure not ignored and within weapon's FOV
                                  change weapon target to countermeasure

[General Battuta]

frand() gets rerolled for each missile, I assume, it's not some kind of seed that gets updated once a frame or something?

Let's talk about this last bit, this seems funny and possibly explanatory to me:

if countermeasure not ignored and within weapon's FOV
                 change weapon target to countermeasure

So it performs the FOV check after the decoy roll? If a weapon gets pulled, but then isn't looking at the CM, it won't chase the CM?

Maybe more importantly, a missile checks for decoy not when it's [in range and looking], but when it's [in range], right? If it later 'sees' the CM for the first time, it's already decided (not) to chase it?

What happens if a CM dies while the missile is attacking it? Can it retarget back to the original?

[The E]

So it performs the FOV check after the decoy roll? If a weapon gets pulled, but then isn't looking at the CM, it won't chase the CM?

Correct.

Maybe more importantly, a missile checks for decoy not when it's [in range and looking], but when it's [in range], right? If it later 'sees' the CM for the first time, it's already decided (not) to chase it?

This is trickier. First, missiles have limited memory of countermeasures they ignore; if a missile ignores a cm, it stores the cm's object id until it ignores a different one. As a result, a countermeasure has a number of chances to pull a given missile (1 chance for every frame in which the missile sees the cm and is inside the cm's effect range). Incidentally, this means that cms become more effective the higher the framerate.

What happens if a CM dies while the missile is attacking it? Can it retarget back to the original?

No. Once a weapon is locked onto a cm, the original targeting information is lost and cannot be retrieved any longer; if the weapon is tabled as an untargeted heat seeker, it may find a new victim.

[General Battuta]

Ugh this **** is a nightmare!

So Angel Flare spreads have more effectiveness than we thought, because each flare in the spread is a chance to reset the missile's memory, right? If you're looking at two flares, you go into an infinite loop of 'I ignore flare A, now I need to roll B, and if I ignore it, return to A...'

I think I've seen Apocs re targeting to a warship after the flare spread dies. But maybe I'm nuts.

[General Battuta]

Does range provide any kind of coefficient to CM effectiveness?

[The E]

To be fair, I am not entirely certain about how target reacquisition may or may not work. It's certainly possible that there's some code somewhere that would allow missiles to reacquire their original targets.

So Angel Flare spreads have more effectiveness than we thought, because each flare in the spread is a chance to reset the missile's memory, right? If you're looking at two flares, you go into an infinite loop of 'I ignore flare A, now I need to roll B, and if I ignore it, return to A...'

Well, not an infinite loop precisely as the missile will eventually leave the cm's sphere of influence. But yeah, pretty much exactly that is what is happening.

Does range provide any kind of coefficient to CM effectiveness?

Nope.

[General Battuta]

Ugh. Maybe we should move spreads to a 'one real decoy, cosmetic companions' model...

[The E]

Maybe. Or we could think about how we can refactor this system a bit.

[Dragon]

How are the swarm/corkscrew missiles treated in this context? From what I've seen, the entire salvo will always either be spoofed or not. It's impossible to, say, lose half of the salvo with a single CM, it's always all or nothing. It might be useful to be able to change this behavior (on a per-mod basis, of course).

Ugh. Maybe we should move spreads to a 'one real decoy, cosmetic companions' model...

That would make them decoy decoys, wouldn't it?

...I know, I know.

[General Battuta]

That's a really good question. I hadn't thought of that. E, are the Narayana's Apocs currently using swarm or burst?

[DahBlount]

If I remember the tables correctly, Apocs use Swarm with 4 missiles per swarm.

[Cyborg17]

I think I've seen individual missiles be spoofed by countermeasures.  It's worth testing to make sure.

[X3N0-Life-Form]

If I remember the tables correctly, Apocs use Swarm with 4 missiles per swarm.

Looks like it from the release table I have on hand.

Code: [Select]

$Name: Apocalypse#Narayana
$Model File: MissileXL.pof
$POF target LOD: 0
$Mass: 60.0
$Velocity: 200.0
$Fire Wait: 20.0
$Damage: 1000
$Damage Type: HugeWeapon
$Arm radius: 250
$Shockwave Damage Type: Shockwave
$Blast Force: 1000.0
$Inner Radius: 150.0
$Outer Radius: 300.0
$Shockwave Speed: 100
$Shockwave name:                shockwave01
$Dinky shockwave:
+Blast Force: 100
+Inner Radius: 10
+Outer Radius: 20
+Shockwave Speed: 0.0
$Armor Factor: 1.0
$Shield Factor: 0.1
$Subsystem Factor:  0.5
$Lifetime: 72.0
$Energy Consumed: 0.0
$Cargo Size: 2.5
$Homing:  YES
+Type: ASPECT
+Turn Time:  2.0
+View Cone: 360.0
+Min Lock Time: 4.0
+Lock Pixels/Sec: 25
+Catch-up Pixels/Sec: 10
+Catch-up Penalty: 15
$Swarm: 4
+SwarmWait: 2.0
$Free Flight Time: 1.0
$LaunchSnd: 325
$ImpactSnd: 101
$FlyBySnd: -1
$Rearm Rate: 0.02
+Weapon Range: 12000
$Flags: ( "supercap" "Huge" "Big Ship" "No Dumbfire" "particle spew" "bomb" "same turret cooldown" "no lifeleft penalty" "cycle" )
$Trail:
+Start Width: 3.0
+End Width: 0
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 4.0
+Bitmap: missiletrail02
$Impact Explosion: ExpMissileHit1
$Impact Explosion Radius: 104.76
$Dinky impact explosion: ExpMissileHit1
$Dinky impact explosion radius: 104.76
$Piercing Impact Explosion: exp04
$Piercing Impact Radius: 52.38
$Piercing Impact Velocity: 25
$Piercing Impact Splash Velocity: -25
$Piercing Impact Variance: 20000
$Piercing Impact Particles: 10
$Pspew:
+Count: 1
+Time: 1
+Vel: 0.0
+Radius: 1.5
+Life: 0.1
+Scale: 0.0
+Bitmap: missilespew02
$Thruster Flame Effect: missilethruster02
$Thruster Glow Effect: missileglow02

[AdmiralRalwood]

Another possible solution is to make the probability of the missile ignoring the CM drastically higher so that checking each frame has roughly the same probability as a single check with the current strength (of course, a lower framerate will make flares less effective, and a lower framerate is probably more likely in a massive missile swarm).

[jr2]

Mph.  Why do I get the feeling that having gameplay features rely on variables that can change from system to system is a bad idea?  I'm getting that early 90s vibe where if you tried to play an old DOS game on a Pentium you got insta-stomped as everything was playing at ludicrous speed. 

Was retail FPS capped?  If so, can't the missile be changed to check 30x every second or whatever the cap was?

[AdmiralRalwood]

Why do you need to base the behavior on retail when we're dealing with modded weapons and countermeasures in the first place?

A better solution would be to somehow change countermeasures to not use a single cmeasure_ignore_objnum value, but inserting a vector into a countermeasure object sounds like a bad idea... maybe a pointer to a vector/dynamic array? You're adding indirection (and virtually guaranteeing CPU cache misses) for a central type of object which will need to be processed multiple times per frame, though...

[Bobboau]

an optional flag for multiplying distraction chance by frame time? another optional flag for what not remembering anything at all and re-evaluating all countermeasures all the time?