If you have been playing eve for some time, then you have certainly heard the notion that drones are weird. They just don’t always do what you expect from them. Suddenly they hit very well, or give up chasing fully. They are so weird in fact, that very few people have actually tried to understand what they are doing. Usually CCP Round or something POScode is all that has to be said about drones. There is some really good comparison of the stats like for example by EVE-Uni. But we don’t really know what that means. Does better tracking make any difference? How about more range? Personally, I would like to know a little better.
First, here is a short summary of my understanding how drones fly:
Drones orbit in the same way as everything else in Eve. They have a fixed orbit radius assigned to them and if you press the drone key they just orbit at that range.
So the question is more how exactly does orbiting work in general? I did a bunch of testing on this and found out that the mechanic is rather simple. At some point you get “advised” an orbit plane (Interestingly stopping and restarting the orbit doesn’t give you another plane, but it stays the same). From now on, your target vector is a tangent to the orbit circle that intersects with your position projected into this orbit plane . Got it? Here is a quick sketch:
If there is no tangent because you are closer than the orbit distance then ships just burn away in a straight line.
Like most things in eve, drones also have mass, and their actual movement is dependent not only on where they want to go, but also where they were going previously. This is exactly the same as with ships etc. In order to give you some Idea of how fast drones move, here is the align times of a few common drones:
|Acolyte II / Hobgoblin II
|Hammerhead II / Valkyrie II / Vespa II / Infiltrator II
|Berserker II / Wasp II / Praetor II / Gecko
They are pretty agile, aren’t they?
Drones have a propulsion module that has a 2.5 second cycle time. Whenever they close in past a certain distance they red-cycle it, when they move outside of another distance (usually greater than the redcycle distance) they reactivate it after 1 second of delay.
Now there is a lot of ways to try and figure out what kind of damage drone actually do, but it is generally agreed upon that it is hard to code, or computationally expensive. The easiest sensible way to do it is this
- If the drone can catch up to the target then it does full damage
- If it can’t catch up to the target, then we set it at the agressors position and use that standard tracking formula
- If there is different kinds of drones decide for each one on it’s own
This is the way pyfa does it (in Auto mode). It usually yields pretty good results, but it can’t really explain some things. Hence the notion that “drones are just weird” that stays around.
I chose to do something a little bit more complicated, which hopefully allows us to figure out how or why that drone weirdness actually works. Here is my plan:
- Figure out how the drone moves over a really long time and depending on other factors like target speed / target turning
- Use the turret tracking formula to find out what DPS the drone does over it’s trajectory
People refrain from this kind of calculation because they generally assume that you get results that are reliant on the starting position of the attackee and the drone, beause of the inital travel time. But that problem can be mitigated pretty easily. We just give the drone enough time to surely reach it’s target, and then start calculating it’s DPS. That way we get a good steady state number that is comparable (And you can make your own calculations about travel time, like for example in Coevolution: Skynet Gila. Make sure to also include lock times and missile travel time if you end up making an argument for or against drones) In order to reach pretty stable data we do this for 10’000 seconds(about 1 hour and 40 minutes) for each drone flying around it’s target, and we have our numbers.
For the very first time, I managed to actually use EOS (from Pyfa) to get all my variables. It looks like the days of hardcoding everything have finally ended! For the google collab version, I decided to lazily hardcode it again tho, so that you can easily change numbers and see what happens. Source
Now this has to be addressed somewhere. This code doesn’t necessarily do the same thing as drones in game. I have obviously tried to understand how exactly the game calculates everything, but some things are just hard to figure out. Specifically the following points might differ from the game:
- When deciding whether to activate the MWD I take the closest point on the trajectory, this might not be to point at which the drone is at a tick, but also on the intersecting line between the ticks. Eve might or might not do this, it is very hard to tell.
- If the drone is within the activation distance, then it starts shooting as per game database. I interpreted in in a way that this is only a thing when it first enters that distance to the target. Should it drift out of the activation distance again, then my drone keeps shooting.
- Sometimes drones seem to orbit below their orbit radius in game, so it is likely possible that there is some intermediate stage between burning away and flying on a tangent in the orbit mechanics. This stage hasn’t been modelled.
I ended up graphing the DPS over the target speed instead of distance as this seems to give a lot more insight. Each graph takes about 25 minutes to simulate (Including poorly optimized multithreading).
Generally drones seem to have 5 different behaviours depending on the speed of the target when it is burning in a straight line. From standstill to outrunning the drone, these seem to always be.
1. Stable Orbit
The drone orbits with nearly it’s orbit velocity (due to mass slightly slower). DPS is mostly dependant on the enemies signature radius.
2. Asymetric Orbit
The enemies speed now is a significant factor in the drones angular velocity. For large parts of the orbit it reduces the angular velocity, and as such the drone usually hits better if it had problems because of the small signature before.
3. Broken Orbit
This is a behavior that I don’t think is actually accurate to the game. What my simulation does is something like this:
The drone flies alongside the target and shoots it. then at one point it gets to close, under the orbit radius. At that point it heads straight away from the target and loops around, the whole thing repeats.
If the game has a more gentle method to stead the drone back to it’s intended orbit, then this would absolutely look different. Here is a quick graph of how this looks like in my simulation. If anyone has a clue how this works, please contact me.
4. Cyclic Pattern
Here the thing is pretty clear again. The drone shoots while falling back, then lights its MWD and catches up again.
5. Getting Outran
And finally we have the bbvious one. It just can’t keep up and does no damage.
Sometimes the advice is given that you should sit still as drones will out-track themselves. While this definitely works in some cases, I generally think that this is bad advice just like that. If this actually significantly reduces DPS in comparison to moving is very much dependent on your own signature. You can see this in the graphs presented above: The bigger the signature, the less the damage lines dip on the left of the graph. It looks like you can reliably do this with a sig of under 50 against heavy drones. For medium drones against a sig of 50 or heavy drones against a sig of approximately 100 there is still some decent DPS reduction to be had, after that it doesn’t really work anymore.
Another interesting phenomenon can be found in some of the graphs, specifically if let the target fly in a circle instead of in a straight line.
As you can see there is this little spike just before the drone gets outran. I haven’t really found the exact combination if drone, signature and orbit velocity where this reaches it’s maximum. But I am pretty sure it is the famous “Ishtar wrecking my Malediction” Effect (The Rattlesnake oneshotting an Imp thing is however different, it has more to do with high damage low RoF weapon systems having really high wrecking shots, similar to Trig Crits).
Feathering is a term coined by Chessur. It describes a flying style where a highly maneuverable ship uses it’s agility to generate extra range over often just slightly slower enemies. This works by spiraling up or down, ships that click-approach end up in a bigger spiral than the ship they are approaching due to their lower agility and end up burning a further circle around the enemy. This creates a lot of stable distance between the two ships that is very stable at the same time.
So if now you use an orbit and have drones chasing you, what ends up happening is that due to the drones really high agility, they describe a smaller circle than your ship. Because of this, they have less distance to cover to catch you. So even drones that are slower than your ship end keeping up with you. Hence I would call this reverse-feathering.
So what do you do if that seems to happen to your Interceptor? Ideally you would speed up or slow down. Or to get out of the situation quickly I suggest just double clicking in space once – you will burn away in a straight line, and hopefully you are soon faster than the Drones chasing you, so that it doesn’t apply DPS anymore.
While drones are still weird, I think I have found some of the reasons to why they work the way they do. Ideally I would fully figure out how that intermediate orbit mechanic works if it exists, and also do a lot more ingame testing to see if my numbers match what actually happens. Nonetheless, I am happy with the progress so far.
For the folks at pyfa, I think your method of estimating drone DPS is pretty good, if you would implement a function that would reduce shown DPS for the “If the Drone can catch up to the target then it does full damage” part, like for example demonstrated in this reddit post from a couple of years ago, it would be even better. Ideally this would be backed up by both tickwise simulation and ingame testing.