Logic that doesn't need to be calculated per frame

[Coronia]

With multiple attempts to optimize performance from different contributors recently, here's a thing I want to discuss: Currently we have several logic that's been calculated per frame, which is one of the main performance sources. Other than optimizing these logic, I'm also thinking about whether all of them need to be executed that frequently. Here're some examples I've founded:

• MindControlRangeLimit: in actual practice, we don't really need to make victim free from mind control at the exact same moment when it's out of range, could have like 1 sec of delay or even more
• Spawner.LimitRange: same as above, not need to be that accurate
• Powered.KillSpawns: think we can live with spawners live 1 or more sec after depowered don't we? Also it's one of the costly functions according to VerySleepy in our test
• Interceptor, KeepTargetOnMove etc: while 1 sec is indeed a too long delay for them, maybe they can use 2 or more frames' interval rather than 1?

Haven't looked into all the cases, and most of them still need to be executed per frame since they have timer or such. For those don't have to be that frequently, we can use proper Unsorted::CurrentFrame % X settings on them

[TaranDahl]

I think that when each unit is initialized, a value between 0 and 14 (let's assume it is y) can be assigned to it, and it will update when Unsorted::CurrentFrame % 15 == y. I think this is better than directly using Unsorted::CurrentFrame % 15 == 0 because it distributes the performance overhead across 15 frames.

[Starkku]

KeepTargetOnMove was in mission handler and thus had inherent delay but it caused issues with the logic so I had to move it to per frame processing. Something to keep in mind.

Given interceptor is effectively autoscanning for targets tying it to the same targeting timer as passive aquisition of targets could be sensible but given that projectiles move so damn fast it is likely way too slow for this purpose.