Turrets: Vastly Improved, but Still Need Work

EDIT: YAY HOORAY! It seems as though this has been fixed. And there was much rejoicing. Thanks, Mark Allen + co.! Never mind. The problem is still there. :/

TL; DR: Make turrets behave as if they are physical things physically attached to your ship, and scrap the whole turret confusion system.

I like turrets. I really do. They're cool, and can potentially add some interesting gameplay. Turrets getting reworked was was of the main things I was excited about, in regards to 1.3. They went from being unusable / a complete joke, to fairly capable weapons.

That said, they could still use some refining. While their overall accuracy feels fairly balanced now, the times when they hit or miss are not terribly intuitive, and look downright stupid sometimes. It can be very frustrating when you're holding a ship constantly centered under your crosshair, yet can see your turrets periodically drifting wildly off target. Thankfully they snap back into position fairly quickly now (instead of permanently aiming behind the target, like they used to), but it's very jarring and silly looking. It's as if the turrets suffer from some sort of attention deficit disorder and just zone out every now and again, only to remember what they are supposed to be doing and snap back to it.

The "snapping back on target" thing feels like a band-aid fix to the old "turret gets permanently confused" bug that was quite strong around when 1.3 launched. It's as if instead of fixing the cause of the turret misbehavior, the devs simply added a periodic reset. While this does work, it's hardly elegant. Honestly, the entire "turret confusion" mechanic feels very arbitrary, and unnecessarily complicated. Additionally, it leaves the player feeling like they have little ability to influence the efficacy of their turrets.

I propose the following alternate solution:

1) To start, scrap the whole concept of confusion.
-Turrets don't need to arbitrary wiggle / drifting added in. In addition to not making a lot of sense, the whole mechanic just feels very much out of the hands of the player.

2) Next up, make turrets actually behave as if they're attached to the ship. (Angle is stored relative to the ship, not the world)
-Currently, turrets act as if their position is tied to a fixed point on the ship, but not their orientation. If a turret is slightly off target, nudging your nose in the right direction does nothing- the turret just instantly "compensates" to continue aiming at its previous, incorrect, place. This feels bizarre- as if the turrets are just free-floating next to your ship, instead of actually being attached. It is also frustrating, since outside of making sure the enemy is inside the firing arc, the player has no ability to help or harm the turret's efficacy. A turret's current angle should be one relative to the ship, instead of an absolute one relative to the world. That is, if the turret is at "5 degrees", it should be at "5 degrees from the angle of the ship".

3) Separate the point the turret is aiming at from the actually target ship.
- The turret should not care about how fast the target ships is moving, how it’s spinning, what direction it’s moving, etc. The turret should care about 1 thing: where it is supposed to shoot. Let the ship’s computer (or however it’s represented) decide where that point is, just like it does for fixed and gimbaled weapons. For laser weapons, that point is directly on top of whatever ship / subsystem you’re targeting. For projectile weapons, it would be the little lead indicator. In any case, that point is all the turret should see. Doesn’t matter how fast you or your target is moving- if that point is stationary, then as far as the turret is concerned, it doesn’t need to change its aim.

4) The next step is to assign turrets either a maximum tracking speed, or even better, a maximum acceleration.
-Obviously we can't have turrets just nailing the target, dead on, all the time. Even with their low damage, that would be brutal. As such, they need limitations. Instead of the arbitrary confusion, they should just be limited on how quickly they can track targets. The easy way is to just give them a fixed maximum rate that they can change their angle relative to the host ship. That’s lazy though, and leads to dumb situations where the opponent can be moving extremely predictable (in a circle at a constant speed), but be completely untouchable. By giving them a maximum acceleration (but uncapped speed), you allow the turrets to deal with that kind of flying, but still be dodged be erratic evasive maneuvers / frequent changes in velocity. The bigger the turret, the lower its acceleration. This would mean bigger turrets can be more easily evaded, but will still get on target if your opponent gets too relaxed, or if you as a pilot manage to keep their relative position to you fairly constant via your own piloting skill, they could still eat up small ships.

When you combine all these together, you end up with a turret that can be evaded by skillful jinking from your opponent, but at the same time, can be aided by skillful piloting / aiming on the turret-user’s side. When using turrets, the name of the game would be to try and keep your opponent’s angle relative to you fairly constant, and make any changes happen as smoothly as possible. Jerky evasive maneuvering on the turret-user’s side could screw up the turret’s aim just as much as the opponents’ maneuvers could. Both using turrets effectively and dodging them would be affected by pilot skill, and the turrets would behave in a more intuitive / less frustrating manner. Turrets being dodged effectivly would hit less than in the current system, and turrets not being dodged effectively would hit more.

Here's a little mock-up I put together of the proposed turret algorithm. Feel free to tweak the values, and see how the turret reacts. Note that it only will work right in firefox and chrome:
http://visikcorp.com/TurretHTML5/TurretDemonstration.html
 
Last edited:
I am not sure what kind of tracking algorithm they are using are since I have did some computer graphics programing as a hobby and developed my own ship tracking algorithm using the ships up and right vector and creating a direction vector from my center to the targets center and take the dot product of the direction vector and right vector for yaw and dot product of direction vector and up vector for your pitch trying to remember that off the top of my head. If the tracking rotation of the turrets are slow the turrets will get confused with the targets darting about trying to catch up to them if the tracking rotation rate is high they will have no problem tracking the targets that turrets aircraft using a different type of rotation and turrets and gimbals use another rotation value like 0 to 360 as opposed to concatenated types.
 
I am not sure what kind of tracking algorithm they are using are since I have did some computer graphics programing as a hobby and developed my own ship tracking algorithm using the ships up and right vector and creating a direction vector from my center to the targets center and take the dot product of the direction vector and right vector for yaw and dot product of direction vector and up vector for your pitch trying to remember that off the top of my head. If the tracking rotation of the turrets are slow the turrets will get confused with the targets darting about trying to catch up to them if the tracking rotation rate is high they will have no problem tracking the targets that turrets aircraft using a different type of rotation and turrets and gimbals use another rotation value like 0 to 360 as opposed to concatenated types.

The turrets just need to draw a line between them, and the point they're supposed to be shooting at, then attempt to make the angle between that line and the direction they're currently aiming as close to 0 as possible, as quickly as possible.

If the turrets had a max acceleration (and an uncapped speed), then they'd need to slow down as they approached their desired angle, or overshoot and swing back. Either option would less to a small amount of drift, not unlike how the current turrets behave when they're actually on target.
 
Last edited:
The extremely low damage of turrets (compared to their gimballed and fixed counterparts) in addition to their inability to stay on target and their, just new, confusion with chaff (which was essentially one of the only reason to ever use them on anything else than a Type 9/Anaconda) makes the turret, most expensive weapons in the game, bloody close to useless...
 
Last edited:
+1 to the OP

what this needs is Sensor augmentation so we actually have a reason to upgrade sensors rather than just install D for mass saving.

Better sensors == less drift/wobble and more on target to actually hit the ship.

And +1 to this!!

My Anaconda is outfitted with 2 x large pulse gimbals (top), and 2 x med pulse turrets (side). Fixed cannons and plasma below. The turret issue has definitely improved, but I totally agree with the OP. That kind of balance might realły be the sweet spot and make pilot skill a priority on both sides of the weapon (aka me vs the enemy). Add some increased accuracy and possibly less chaff confusion - by outfitting more expensive sensors, and we'd have a much more complete package.

Don't get me wrong, I have loved this game (with all he good and bad) since Alpha... but a wish list isn't a bad thing! :D
 
Last edited:

Mark Allen

Programmer- Elite: Dangerous
I can chime in here :) (Much of the turret/weapon functionality ends up being my playground).
I'll answer a few points inline, then I've explained how confusion currently works at the end, along with a problem I'd like to explain.

They went from being unusable / a complete joke, to fairly capable weapons.
Well, it's a start!

<snip>
1) To start, scrap the whole concept of confusion.
-Turrets don't need to arbitrary wiggle / drifting added in. In addition to not making a lot of sense, the whole mechanic just feels very much out of the hands of the player.

There is a reason for that behaviour (though I agree it can feel strange) - as you mention later, without some kind of confusion mechanic the turrets are utterly lethal, which is no fun for the defender at all. We discussed (and tried) several options and the best answer so far has been to make it act like the weapon had intermittent signal disruptions - We're still looking at other ways to make them miss "better" but they do need to miss - Suggestions are welcome :). Getting stuck in perma delay was indeed a bit... smelly.

Incidentally, the station's laser weapons have all the fudging mechanisms turned off. Try and dodge 'em ;).

It's actually a surprisingly common and consistently hard problem in developing games - making a mechanical thing/turret/Aiming AI/etc "perfect" is relatively easy, making it bad in plausible ways is harder, and extremely subjective!

2) Next up, make turrets actually behave as if they're attached to the ship. (Angle is stored relative to the ship, not the world)
-Currently, turrets act as if their position is tied to a fixed point on the ship, but not their orientation. If a turret is slightly off target, nudging your nose in the right direction does nothing- the turret just instantly "compensates" to continue aiming at its previous, incorrect, place. This feels bizarre- as if the turrets are just free-floating next to your ship, instead of actually being attached. It is also frustrating, since outside of making sure the enemy is inside the firing arc, the player has no ability to help or harm the turret's efficacy. A turret's current angle should be one relative to the ship, instead of an absolute one relative to the world. That is, if the turret is at "5 degrees", it should be at "5 degrees from the angle of the ship".

3) Separate the point the turret is aiming at from the actually target ship.
- The turret should not care about how fast the target ships is moving, how it’s spinning, what direction it’s moving, etc. The turret should care about 1 thing: where it is supposed to shoot. Let the ship’s computer (or however it’s represented) decide where that point is, just like it does for fixed and gimbaled weapons. For laser weapons, that point is directly on top of whatever ship / subsystem you’re targeting. For projectile weapons, it would be the little lead indicator. In any case, that point is all the turret should see. Doesn’t matter how fast you or your target is moving- if that point is stationary, then as far as the turret is concerned, it doesn’t need to change its aim.

Turrets don't store their direction in worldspace at all - they're just able to correct for your ships rotation faster than the ship can turn, and are being told to aim at an intentionally inaccurate position. The root error here that is frustrating people I think is how confusion is calculated, which I'll discuss at the end.

The code driving turrets and gimbals is identical other than the choice of what to target and which "error" mechanisms to add. In both cases the code is given is a start transform (the position/orientation of the firing weapon mount), a target point to aim at, plus in the case of travel-time weapons the velocity of the target and projectile. Then it's a case of working out the local rotation to either point at the target or figure out the optimal intersection point between bullet & target. Then convert that direction to an orientation relative to the parent ship and onto step 4...

4) The next step is to assign turrets either a maximum tracking speed, or even better, a maximum acceleration.
-Obviously we can't have turrets just nailing the target, dead on, all the time. <snip>

Already done, in most cases weapons currently have very fast acceleration (and instant deceleration to avoid some horrible feedback loops), but all gimbal/turret weapons do have limited tracking speed (except PD turrets). The issue with doing this is that purely using track speeds is extremely hard to balance when you bring into account the range different combat ranges & manouverability - it's difficult to explain in words tbh. This is where we started from and it frankly just wasn't all that fun to play as everything ended up being a knife edge of either the turret can never hit a skilled pilot, or can never be dodged - which is a nightmare for any attempts to balance it.


So, how does the confusion actually work right now?
(Apologies for the awkward explanation, I'd love to be able to sketch diagrams effectively in forums sometimes!)

It's all based on the acceleration of the target in the plane perpendicular to the vector from the weapon to that target - each weapon has thresholds that it can cope with (smaller weapons work better against faster targets where large weapons have problems), above one threshold confusion increases, below a different one confusion decreases (it takes about 5-10 seconds to reach maximum and half that to drain again). This acceleration is also scaled with distance - close up the acceleration will confuse the turret faster than when further away as it's a greater angular acceleration from the weapon's point of view.

There's then a semi-random harmonic oscillator (summation of a handful of sine waves with different frequencies/amplitudes) that's multiplied by the current level of confusion to work out how much to delay the tracking by (whenever the oscillator outputs low numbers the weapon catches back up to its target - this is one of the changes that came in 1.3). There's a second 2-dimensional oscillator that applies the minor continuous wobble that gimbals share. Once this direction is figure out we go into the shared AimAtTarget code to do its thing.

Note that velocity has no effect whatsoever, just acceleration of the target over the last quarter-second.

Here's the rub...

The acceleration used in this process is the minimum of either the target's worldspace acceleration, or its acceleration relative to your ship. Crucially (and this is where many of the current problems I think stem from) it does *not* account for your ships rotation when checking the target's relative acceleration. What does this mean in practice? if you're following someone in a turn battle and perfectly controlling your rotation to keep the target stationary in your view you'd expect the relative acceleration to be extremely low, and the weapon on target - but it's not so the weapon gets more and more confused in a situation where they ideally shouldn't, which detracts from the skill aspect in using turrets. This was on my list to fix for 1.3 but frankly with all the other tasks it got delayed, and I've not had time to go back and sort out the maths/rebalance all the factors... yet.

I'm currently tied up with Mfpghssgl.... Gnpppfh... (sorry, not allowed to discuss that... brain filter refuses) - But I hope to get another pass at turrets soon :).

-Mark


P.S. Hopefully that made sense! My Wall-of-Text posts can get a bit garbled at times....
 
Last edited:
Hi Mark, thank you very much for the detailed info!

I know I'm not alone with saying this is exactly the kind of communication I always like to see. I know it takes time to write a post like this, and it is much appreciated!

I've always loved the idea of turrets, and excited to see what you will make of them in the next pass. Good luck with Mfpghssgl in the meantime :D
 
They seem to be working pretty well now, I'd like for them to not randomly shut off though. It's not a big deal to reset their mode, but having them suddenly not work when you start a fight is a little "not fun".
 
Thanks Mark!

This is exactly why I hope you guys could have time (be allowed) to write official blogposts about specific dev areas! This text with some diagrams and pictures would easily have been material to put up on the new community website! :)
 
  • Like (+1)
Reactions: Poy
a whole bunch of detailed info that is very appreciated

Rauminen is right, this is the stuff we want to see from you guys; thanks.

This level of detail and exposition kills off a bunch of guesswork and mystification about gameplay aspects; so even if something IS being weird, like the turrets, we now have a better understanding of their current status and also what you guys are planning for/thinking about them as well (priority, complexity, "we like this, it's a feature now", that kind of thing).
 

Hi Mark,
very interesting post (thanks for the details) and best of luck in the future with the 2nd pass. Interesting to know that my flying is partly to blame when my turrets miss :)
Whilst I admit I didn't understand everything from the bits I did understand it sounds like the process utilised was to get a perfect turret tracking algorithm based on accelerations and then add noise to the tracking to confuse. If im honest I was expecting a modified Kalman filter or something of that sort but In hindsight the method you describe seems a lot easier to adjust on the fly by merely tweaking the noise and the weapon size-target size modifiers.


Also I've tried making anagrams of "Mfpghssgl.... Gnpppfh..." but didn't manage anything, you can't blame me for trying right? :)
 
........Wall-of-Text posts can get a bit garbled at times....

Wow. All that for turrets? I'm certainly no programmer and not particularly intelligent but, can't it be made a lot easier just having the turret always track the target and then having a % chance of hitting based on the type and class of the turret? I know I'm over simplifying the issue and have no idea what I'm talking about but, it my head it makes sense :D It all seems way over complicated to me, which probably explains a lot :D

Anyway, always track and then roll the D20! (+3 Vorpal)

Also, awesome to see a post like this.
 
Last edited:
First off, thank you very much for not only taking the time to read my post and write out a thorough and detailed response, but also for your work on trying to make turrets fun and fair. I really appreciate it.

Well, it's a start!
Indeed it is! The progress so far is very exciting!

There is a reason for that behaviour (though I agree it can feel strange) - as you mention later, without some kind of confusion mechanic the turrets are utterly lethal, which is no fun for the defender at all. We discussed (and tried) several options and the best answer so far has been to make it act like the weapon had intermittent signal disruptions - We're still looking at other ways to make them miss "better" but they do need to miss - Suggestions are welcome . Getting stuck in perma delay was indeed a bit... smelly.

Incidentally, the station's laser weapons have all the fudging mechanisms turned off. Try and dodge 'em .

It's actually a surprisingly common and consistently hard problem in developing games - making a mechanical thing/turret/Aiming AI/etc "perfect" is relatively easy, making it bad in plausible ways is harder, and extremely subjective!

I suppose a better way to phrase my suggestion is not so much to remove confusion (as I agree that turrets certainly need limitations), but to change where it is coming from. At current, the confusion you're describing is the turret not knowing the correct spot to shoot. This can be very frustrating, because even if the player attempts to compensate for the turret's confusion, it will stubornly do everything in its power to continue aiming at that incorrect point. What I'm suggesting is to make the "confusion" come from a turret's -inability- to target the right point. That way, if a player corrects with their ship, they can "help" the turret along, and improve its aim.


Turrets don't store their direction in worldspace at all - they're just able to correct for your ships rotation faster than the ship can turn, and are being told to aim at an intentionally inaccurate position. The root error here that is frustrating people I think is how confusion is calculated, which I'll discuss at the end.

The code driving turrets and gimbals is identical other than the choice of what to target and which "error" mechanisms to add. In both cases the code is given is a start transform (the position/orientation of the firing weapon mount), a target point to aim at, plus in the case of travel-time weapons the velocity of the target and projectile. Then it's a case of working out the local rotation to either point at the target or figure out the optimal intersection point between bullet & target. Then convert that direction to an orientation relative to the parent ship and onto step 4...

That makes sense, but is very frustrating (in my opinion) from a player point of view. My ship's sensors obviously know exactly where the target ship / subsystem is, and can provide me with a perfectly accurate lead reticule for my fixed / gimbaled weapons. It's very counterintuitive that the ship would not share this information with the turrets. Again, since the error is coming from where the turret thinks it should be aiming, instead of its ability to move into position, it feels very much out of the hands of the player.

Already done, in most cases weapons currently have very fast acceleration (and instant deceleration to avoid some horrible feedback loops), but all gimbal/turret weapons do have limited tracking speed (except PD turrets). The issue with doing this is that purely using track speeds is extremely hard to balance when you bring into account the range different combat ranges & manouverability - it's difficult to explain in words tbh. This is where we started from and it frankly just wasn't all that fun to play as everything ended up being a knife edge of either the turret can never hit a skilled pilot, or can never be dodged - which is a nightmare for any attempts to balance it.
Did you ever try uncapped (or extremely high) max tracking speed, but both limited acceleration AND deceleration? I realize that a simple "keep speeding up in the direction you need to go" would lead to wild overshooting / overcompensating, but with basic PID controller (or something similar), you could keep that in check and actually use it as a replacement for the artifical arbitrary wiggle they've got now. I've got some experience in robotics, and this is how we kept our manipulators from just waving back and fourth, instead of settling on the desired position. Getting a robot arm to move to a desired angle is not dissimilar from trying to aim a turret.

In a nut shell, instead of just constantly accelerating in the direction they need to go, have them look at the -difference- between their current angle and the desired angle, and the rate that difference is changing. If the difference is very high and the rate of closure is very low, accelerate as fast as possible. As the difference gets smaller and rate of closure get gets higher, stop accelerating. When the difference gets sufficiently small, or the rate of closure gets sufficiently high, decellerate.

What this leads to is if the target stays still, or changes its relative angle at a constant rate, the turret will zero in on it with minimal overshoot (depending on how you tune it). If they keep changing their relative angle at inconsistent rates, the turret will tend to lag or overshoot, unless the player helps compensate. Additionally, if you want to keep the little bit of wobble turrets have (like gimbaled weapons), all you need to do is set a -minimum- speed. If the turret can't ever outright hold still, then it will constantly be in a state of slightly overshooting its target, swinging back towards the desired angle, and overshooting again. You can adjust how dramatic the wobble is by adjusting that minumum speed. Want more wobble? Higher minimum speed, thus more overshooting / overcompensating. Want less wobble? Lower minumum speed, thus better ability to actuall "rest" on target.

So, how does the confusion actually work right now?
(Apologies for the awkward explanation, I'd love to be able to sketch diagrams effectively in forums sometimes!)

It's all based on the acceleration of the target in the plane perpendicular to the vector from the weapon to that target - each weapon has thresholds that it can cope with (smaller weapons work better against faster targets where large weapons have problems), above one threshold confusion increases, below a different one confusion decreases (it takes about 5-10 seconds to reach maximum and half that to drain again). This acceleration is also scaled with distance - close up the acceleration will confuse the turret faster than when further away as it's a greater angular acceleration from the weapon's point of view.

There's then a semi-random harmonic oscillator (summation of a handful of sine waves with different frequencies/amplitudes) that's multiplied by the current level of confusion to work out how much to delay the tracking by (whenever the oscillator outputs low numbers the weapon catches back up to its target - this is one of the changes that came in 1.3). There's a second 2-dimensional oscillator that applies the minor continuous wobble that gimbals share. Once this direction is figure out we go into the shared AimAtTarget code to do its thing.

Thanks for clarifying this. that would explain why turrets sometimes seem to start daydreaming, and also the fairly ubrupt "snap back to action".

Note that velocity has no effect whatsoever, just acceleration of the target over the last quarter-second.

Here's the rub...

The acceleration used in this process is the minimum of either the target's worldspace acceleration, or its acceleration relative to your ship. Crucially (and this is where many of the current problems I think stem from) it does *not* account for your ships rotation when checking the target's relative acceleration. What does this mean in practice? if you're following someone in a turn battle and perfectly controlling your rotation to keep the target stationary in your view you'd expect the relative acceleration to be extremely low, and the weapon on target - but it's not so the weapon gets more and more confused in a situation where they ideally shouldn't, which detracts from the skill aspect in using turrets. This was on my list to fix for 1.3 but frankly with all the other tasks it got delayed, and I've not had time to go back and sort out the maths/rebalance all the factors... yet.

I believe a lot of my frustration / confusion is coming from the inclusion of the target ship's worldspace acceleration. I don't see why turrets need to know, or care, about that. This is largely why I was suggesting having the turrets only look at the lead indicator. In the case of fixed weapons, it will always be on top of the target ship / subsystem, and accuratly represent the acceleration of the target relative to the host ship. Since the turrets are attached to the host ship, it is the basis of their frame of reference, and relative acceleration should be all they care about. In the case of projectile weapons, the acceleration of the lead indicator should be all the turret cares about. If the target ship's relative velocity and acceleration are changing maddly, but because of the host ship's absolute velocity the lead indicator is moving very little, then a projectile turret should have no problem aiming. If the target's relative angle is completely stable, but the host ship is wildly changing it's own velocity (moving eratically, while perfectly keeping the target under the crosshair), the lead indicator would be all over the place, and the projectile turret should have a har time keeping up.

I'm currently tied up with Mfpghssgl.... Gnpppfh... (sorry, not allowed to discuss that... brain filter refuses) - But I hope to get another pass at turrets soon .

-Mark


P.S. Hopefully that made sense! My Wall-of-Text posts can get a bit garbled at times....
Oh sweet! I didn't realize Mfpghssgl.... Gnpppfh... was being worked on already! I so excited!

In all seriousness though, thanks again for taking the time to deal with this. It always makes me happy when I see a dev has written up one of the long, involved replies. I look forward to seeing what you have to say about the above points.
 
Any chance of allowing turrets to "lock in" to a fixed position if you choose? Lets say a particular opponent is using a lot of chaff and you just want to manually control the weapon.

Turning off gimbal and turret mode would be very cool. Especially if there would be an increase in output of damage by doing so.
 
I can chime in here :) (Much of the turret/weapon functionality ends up being my playground).
I'll answer a few points inline, then I've explained how confusion currently works at the end, along with a problem I'd like to explain.


Well, it's a start!



There is a reason for that behaviour (though I agree it can feel strange) - as you mention later, without some kind of confusion mechanic the turrets are utterly lethal, which is no fun for the defender at all. We discussed (and tried) several options and the best answer so far has been to make it act like the weapon had intermittent signal disruptions - We're still looking at other ways to make them miss "better" but they do need to miss - Suggestions are welcome :). Getting stuck in perma delay was indeed a bit... smelly.

Incidentally, the station's laser weapons have all the fudging mechanisms turned off. Try and dodge 'em ;).

It's actually a surprisingly common and consistently hard problem in developing games - making a mechanical thing/turret/Aiming AI/etc "perfect" is relatively easy, making it bad in plausible ways is harder, and extremely subjective!



Turrets don't store their direction in worldspace at all - they're just able to correct for your ships rotation faster than the ship can turn, and are being told to aim at an intentionally inaccurate position. The root error here that is frustrating people I think is how confusion is calculated, which I'll discuss at the end.

The code driving turrets and gimbals is identical other than the choice of what to target and which "error" mechanisms to add. In both cases the code is given is a start transform (the position/orientation of the firing weapon mount), a target point to aim at, plus in the case of travel-time weapons the velocity of the target and projectile. Then it's a case of working out the local rotation to either point at the target or figure out the optimal intersection point between bullet & target. Then convert that direction to an orientation relative to the parent ship and onto step 4...



Already done, in most cases weapons currently have very fast acceleration (and instant deceleration to avoid some horrible feedback loops), but all gimbal/turret weapons do have limited tracking speed (except PD turrets). The issue with doing this is that purely using track speeds is extremely hard to balance when you bring into account the range different combat ranges & manouverability - it's difficult to explain in words tbh. This is where we started from and it frankly just wasn't all that fun to play as everything ended up being a knife edge of either the turret can never hit a skilled pilot, or can never be dodged - which is a nightmare for any attempts to balance it.


So, how does the confusion actually work right now?
(Apologies for the awkward explanation, I'd love to be able to sketch diagrams effectively in forums sometimes!)

It's all based on the acceleration of the target in the plane perpendicular to the vector from the weapon to that target - each weapon has thresholds that it can cope with (smaller weapons work better against faster targets where large weapons have problems), above one threshold confusion increases, below a different one confusion decreases (it takes about 5-10 seconds to reach maximum and half that to drain again). This acceleration is also scaled with distance - close up the acceleration will confuse the turret faster than when further away as it's a greater angular acceleration from the weapon's point of view.

There's then a semi-random harmonic oscillator (summation of a handful of sine waves with different frequencies/amplitudes) that's multiplied by the current level of confusion to work out how much to delay the tracking by (whenever the oscillator outputs low numbers the weapon catches back up to its target - this is one of the changes that came in 1.3). There's a second 2-dimensional oscillator that applies the minor continuous wobble that gimbals share. Once this direction is figure out we go into the shared AimAtTarget code to do its thing.

Note that velocity has no effect whatsoever, just acceleration of the target over the last quarter-second.

Here's the rub...

The acceleration used in this process is the minimum of either the target's worldspace acceleration, or its acceleration relative to your ship. Crucially (and this is where many of the current problems I think stem from) it does *not* account for your ships rotation when checking the target's relative acceleration. What does this mean in practice? if you're following someone in a turn battle and perfectly controlling your rotation to keep the target stationary in your view you'd expect the relative acceleration to be extremely low, and the weapon on target - but it's not so the weapon gets more and more confused in a situation where they ideally shouldn't, which detracts from the skill aspect in using turrets. This was on my list to fix for 1.3 but frankly with all the other tasks it got delayed, and I've not had time to go back and sort out the maths/rebalance all the factors... yet.

I'm currently tied up with Mfpghssgl.... Gnpppfh... (sorry, not allowed to discuss that... brain filter refuses) - But I hope to get another pass at turrets soon :).

-Mark


P.S. Hopefully that made sense! My Wall-of-Text posts can get a bit garbled at times....

Thank you for such an in-depth explanation! That's really helpful.
 

Deleted member 38366

D
--- Deleted ---
 
Last edited by a moderator:
Back
Top Bottom