So, as many of you are probably aware, Rail Turrets that do not have complete 360-degree freedom of motion cause extreme CPU usage when either the turrets are too big or there are too many of them. Feed has already posted a very reasonable suggestion for how to solve this issue, however I believe that it could be taken one step further and be entirely automated.
Let's start first with a time-cost analysis of rail turrets. When performing rail collision detection, we start with the blocks of the moving entity--the turret, and check against whatever it's docked on. I'm not entirely certain of the specifics, but it appears that Schine has managed to make this run in effectively linear time when there are no collisions, which is awesome. But, when a collision is detected, suddenly we must check every block in the turret against every block in the parent ship, and we jump into N-squared time for just one turret. Add multiple turrets into that and we're in N-cubed, which means larger vessels and turret counts are completely unusable.
Why?
Because a turret doesn't know when to stop trying to move in a certain direction, and so it repeatedly attempts to move to follow a target that it physically cannot, triggering an N^3 algorithm with a very large number of items to process on each frame, causing extreme processor wait times and absolutely butchering framerate. What Feed suggested above would solve this completely: a turret would rarely need to perform a worst-case collision check because of the boundaries set by the player. But I don't think there's a need to have the player do this. The turret could be coded to remember its last attitude and elevation, so when it makes an attempt to move and is blocked, it stores the attitude/elevation it tried to move to as its max for the direction it was moving (as determined by the sign of the change in current attitude/elevation), and will never attempt to move beyond said maximum/minimum until the entity it collided with is modified. This takes an N^3 algorithm and controls it with a condition that will greatly reduce the number of times it is called, vastly improving performance on large ships that use a large number of turrets.
tl;dr version: I suggest that Rail Turrets be changed to record maximum and minimum values for both attitude and elevation and restrict movement in between these values when a collision is detected in order to reduce the number of collision checks that are called by AI-operated Rail Turrets and restore usable performance of battleship-style ships.
Let's start first with a time-cost analysis of rail turrets. When performing rail collision detection, we start with the blocks of the moving entity--the turret, and check against whatever it's docked on. I'm not entirely certain of the specifics, but it appears that Schine has managed to make this run in effectively linear time when there are no collisions, which is awesome. But, when a collision is detected, suddenly we must check every block in the turret against every block in the parent ship, and we jump into N-squared time for just one turret. Add multiple turrets into that and we're in N-cubed, which means larger vessels and turret counts are completely unusable.
Why?
Because a turret doesn't know when to stop trying to move in a certain direction, and so it repeatedly attempts to move to follow a target that it physically cannot, triggering an N^3 algorithm with a very large number of items to process on each frame, causing extreme processor wait times and absolutely butchering framerate. What Feed suggested above would solve this completely: a turret would rarely need to perform a worst-case collision check because of the boundaries set by the player. But I don't think there's a need to have the player do this. The turret could be coded to remember its last attitude and elevation, so when it makes an attempt to move and is blocked, it stores the attitude/elevation it tried to move to as its max for the direction it was moving (as determined by the sign of the change in current attitude/elevation), and will never attempt to move beyond said maximum/minimum until the entity it collided with is modified. This takes an N^3 algorithm and controls it with a condition that will greatly reduce the number of times it is called, vastly improving performance on large ships that use a large number of turrets.
tl;dr version: I suggest that Rail Turrets be changed to record maximum and minimum values for both attitude and elevation and restrict movement in between these values when a collision is detected in order to reduce the number of collision checks that are called by AI-operated Rail Turrets and restore usable performance of battleship-style ships.
