This is a sub-topic of this topic. Please keep this topic clean and only talk about this one specific issue. In this case, the balance will be changed slightly.

This specific topic is about tactical missiles

The problem

Missiles used to track their target in Supreme Commander (not Forged Alliance). As a result, the turn rate was adjusted as the missile got closer. At some point this would happen every 1 - 3 ticks, depending on the missile. A single cruiser firing missiles can therefore easily cause a dozen of these calls happening each tic. Think about those moments when you have an armada of cruisers firing in your Seton bay firing at the middle position because the rock player lost from the beach player.

In Forged Alliance the tracking of a target was removed because it appeared to be overpowered. The problem is that all the tracking logic is still applied - they did not refactor the code responsible for that. Instead, they just switched a toggle somewhere.

As soon as the tactical missile is in a straight line all future turn rate changes are a waste of execution time.

For those interested, this is an example of the code that is being executed:

local TMissileCruiseProjectile = import('/lua/terranprojectiles.lua').TMissileCruiseProjectile02
local Explosion = import('/lua/defaultexplosions.lua')
local EffectTemplate = import('/lua/EffectTemplates.lua')

TIFMissileCruise01 = Class(TMissileCruiseProjectile) {

	FxAirUnitHitScale = 1.65,
    FxLandHitScale = 1.65,
    FxNoneHitScale = 1.65,
    FxPropHitScale = 1.65,
    FxProjectileHitScale = 1.65,
    FxProjectileUnderWaterHitScale = 1.65,
    FxShieldHitScale = 1.65,
    FxUnderWaterHitScale = 1.65,
    FxUnitHitScale = 1.65,
    FxWaterHitScale = 1.65,
    FxOnKilledScale = 1.65,

    FxTrails = EffectTemplate.TMissileExhaust01,
    
    OnCreate = function(self)
        TMissileCruiseProjectile.OnCreate(self)
        self:SetCollisionShape('Sphere', 0, 0, 0, 2.0)
        self.MovementTurnLevel = 1
        self:ForkThread( self.MovementThread )
    end,
    
    MovementThread = function(self)        
        self.WaitTime = 0.1
        self:SetTurnRate(8)
        WaitSeconds(0.3)        
        while not self:BeenDestroyed() do
            self:SetTurnRateByDist()
            WaitSeconds(self.WaitTime)
        end
    end,

    SetTurnRateByDist = function(self)
        local dist = self:GetDistanceToTarget()
        -- Get the nuke as close to 90 deg as possible
        if dist > 50 then        
            -- Freeze the turn rate as to prevent steep angles at long distance targets
            WaitSeconds(2)
            self:SetTurnRate(20)
        elseif dist > 128 and dist <= 213 then
            -- Increase check intervals
            self:SetTurnRate(30)
            WaitSeconds(1.5)
            self:SetTurnRate(30)
        elseif dist > 43 and dist <= 107 then
            -- Further increase check intervals
            WaitSeconds(0.3)
            self:SetTurnRate(50)
        elseif dist > 0 and dist <= 43 then
            -- Further increase check intervals            
            self:SetTurnRate(100)   
            KillThread(self.MoveThread)         
        end
    end,        

    GetDistanceToTarget = function(self)
        local tpos = self:GetCurrentTargetPosition()
        local mpos = self:GetPosition()
        local dist = VDist2(mpos[1], mpos[3], tpos[1], tpos[3])
        return dist
    end,
}
TypeClass = TIFMissileCruise01

Note that at some point the missile is checked every 4 ticks.

A solution

My propose to the solution is to set the turn rate once depending on distance. This prevents the entire thread being made all together. It also prevents a lot of engine calls and distance computations. But, the missile arc will be slightly different. This is where the balance is impacted.

We'd also need to re-evaluate how Aeon T2 TMD interacts with missiles. The final behavior should be similar to the original behavior.

My question is: is it worth changing the arc slightly in order to have a simplified, more performant implementation?

I have not worked out how much this would save in terms of sim time- I'd like to hear people's opinion about it first. Just remember that any code that does nothing costs cycles that we should spent on code that actually matters - like pinging your ally on Rock that he should've made more frigates early on.

I have seen discussion on making some missiles homing again a few times.

Would it still be possible after this change to make select tactical missiles homing, also for mods with homing tactical missiles?

Lastly Aeon missiles don't fly in a straight line. What about that?

@valki said in Questions about performance: tactical missiles:

Would it still be possible after this change to make select tactical missiles homing, also for mods with homing tactical missiles?

Yes - people can add their own scripts to the missiles that make them follow the targets again.

Lastly Aeon missiles don't fly in a straight line. What about that?

The zig-zagging is applied in the engine, see also this blueprint value:

    Physics = {
        Acceleration = 3,
        DestroyOnWater = false,
        InitialSpeed = 3,
        LifeTime = 30,
        MaxSpeed = 12,
        MaxZigZag = 5,
        RotationalVelocity = 0,
        RotationalVelocityRange = 0,
        TrackTarget = true,
        TrackTargetGround = true,
        TurnRate = 0,
        UseGravity = false,
        VelocityAlign = true,
        ZigZagFrequency = 0.5, -- <- this value
    },

Seems like a pretty clear cut thing. Wasted engine calls and computations should be removed. Even if it changes the balance a little bit, I'm sure it can be tweaked to be as close to normal as possible and then we can simply get used to the new change. A lot of games, at least with navy like Setons end up with a ton of tac missiles. I wouldn't be surprised if it hits performance quite a bit.

I'll do a proper investigation into the hit on the sim later today.

Could you post a comparison screenshot of the difference in missile arc?

@blackheart I'll make sure to add that in too. The screenshots that I'll provide will be just a draft - it will require some tinkering in the long haul.

Initial investigations with intended changes show a difference of 0.5ms - 1.0ms for 25 UEF cruisers firing. I have a fast processor, so this is easily 1ms - 2ms for a laptop. It is not significant, but a quick water drip reduction in a large bucket called the sim.

Low arc

Low-medium arc

Medium-high arc

high arc

Disclaimers:

• They're both shooting at the same location.
• The UEF cruiser has been adjusted.

As a note a lower arc for missile make them more vulnerable to TMD’s

Yep - that is why this is a balance thing too.

0.5ms - 1.0ms for 25 UEF cruisers

What does that mean though? Is that 1ms over a 30min game or is that 1ms per tick? Per second?

That is per tick - apologies

To clarify further: there is 100 ms / tick to run the game at +0.

It would be pretty cool if cruisers could pick low or high arcs for missiles. Low arc: Missile flies up for a second then turns straight to target. High arc: Missile calculates turn rate on launch needed to follow semicircular trajectory.

That is for the balance team to decide - I'm just here to make things faster .

So if I understood you correctly we gain about a 1% speed improvement (1ms/100ms) in reasonable sized mid to lategame navy fights/sieges.

It's not huuge, but considering those are the situations where speed improvements matter the most it certainly is significant.

I'd say thats very much an improvement worth implementing.

Small balance note: Besides the TMDs there are also some maps that might be effected by different TML arcs. Previous save spots might be become hittable if the arc changes enough.
E.g. many spots on the setons islands are quite sensitive to the exact missile height and flight path

I would disagree. 1% sounds pretty weak to me. Remember this means if you can make the computation completely instantaneous you will gain 1% performance. So in reality you will probably be able to gain somewhere around 0.5%. Surely there are higher priority performance issues?

@Askaholic It is a bucket of water - every drop counts. If we find 10 of these type of performance gains (ambient sound is another) then we have 5ms - 10ms additional time in a tick. I'm probably not going to take on this issue myself as it is not that hard to do. But it would be a nice beginners issue for someone who has not touched the code yet, is not able to analyze the code himself yet but does want to contribute.

@cheeseberry said in Questions about performance: tactical missiles:

So if I understood you correctly we gain about a 1% speed improvement (1ms/100ms) in reasonable sized mid to lategame navy fights/sieges.

It's a 1% speed improvement if your computer is just barely able to process all of the information (it takes 100ms to process the next tick's info)

If your computer is fast enough to process everything in 90ms, it's a 0% improvement

If there's an air fight and it takes 400ms to process all the info, this wouldn't give 1% performance improvement. Saving 1 ms would be 0.25% improvement.

Since it's normal for seton's to slow to -1 or even -2 if weak PCs are involved, even outside of air fights, saving 1ms per tick would end up saving 1 second every 1000 ticks (100 seconds) so ROUGHLY it could save 1 second every 2 minutes. If my math is right, for a 30-minute game, it would save about 15 seconds, or for a 60-minute game it could save less than 1 minute of real time. But that's assuming you constantly have 25 cruisers out. So really it would only save about 30 seconds of real time 1 out of every 10 games.

Not a bad thing, but definitely not worth "breaking" the balance. (Of course it remains to be seen whether such a change would even be a bad thing for the balance.)

Small balance note: Besides the TMDs there are also some maps that might be effected by different TML arcs. Previous save spots might be become hittable if the arc changes enough.
E.g. many spots on the setons islands are quite sensitive to the exact missile height and flight path

Good point. Unironically: we need to make sure this wouldn't break Astro Craters.

It's not MY map, but it's a very important map to the community just based on the amount it gets played.

I think also those people (craters folk) don't keep up with the balance patches so they will be surprised when they make cruisers and it just doesn't work.

@askaholic said in Questions about performance: tactical missiles:

I would disagree. 1% sounds pretty weak to me. Remember this means if you can make the computation completely instantaneous you will gain 1% performance. So in reality you will probably be able to gain somewhere around 0.5%. Surely there are higher priority performance issues?

Certainly cant be picky with performance gains, like @Jip said every bucket of water counts towards better performance, plus like Jip & Sprouto said it's not one big change that fixes performances its hundreds of changes like THIS, that fix the performance.

Yes but hundreds of changes that each break a little part of the game (like the ability of cruisers to shoot over the mountains in Astro Craters) would add up to a lot of damage to the quality of the game.