Hi, it is me, Nimos, you may remember me from my previous hit reddit post about how you could see cloaked ships initiate warp on grid in Eve's log viewer.
This post is also about a game mechanic that almost nobody knows about but is actually really simple once you know what to look for. On and first of all, I do not live in London or even the UK, that's a shitty myth that needs to be dispelled. I live in Germany and my ping to Tranquility is around 13ms-16ms on most days.
I'll teach you how I killed hundreds of goon travel ceptors in just a few weeks of camping. I'm going to narrate my thought process a little bit, you can skip to the last section if you don't care about that.
Early in December my sig deployed to a pipe system in goon space and we started gatecamping whenever we had nothing else going on. The system is on the road to Aridia and it had a lot of Goons coming through on their way to Amarr.
Of course most of those people were using travel interceptors. We could go for hours and ONLY see interceptors that happily warped past our camp.
For years I thought locking travel ceptors was just a myth. I had never been caught in a sub 2 align ship and somehow assumed that sub 2 align ship kills on zkill must be bad skills, people not hitting jump, disconnects, etc. Until some day about 1-2 years ago when I was gatecamping in Vale and actually got to lock any sub 2 ceptor that came through.
I was never really big into gatecamping, but with all the traffic coming through our system it got me thinking. Why could I lock "instawarp" ceptors then, but not always?
I'm sure anyone with more than one account has seen this. When you have multiple clients open they receive updates from the server at different times.
Here's an example. Two clients on the same computer, side by side. When I launch drones from my Gnosis, they appear on my Daredevil's overview 620ms earlier than on my alt's overview.
I remembered that back in Vale when I was able to lock interceptors, I saw that effect a lot, my main had been significantly ahead of my alt.
So why does one client get updated before the other? Is maybe related to the character ID? No, sometimes one of my characters got updated earlier other times my other character got updated earler. Is it maybe related to the ship ID? No, trading ships between characters did not yield any consistent result and with the same ships the order could be different.
I have found four things that could affect the update order.
- Jumping through a stargate
- Large amounts of ships entering or leaving grid.
- Sometimes randomly for no reason
At first I thought maybe there was a queue of some sort and every client was updated sequentially. My theory was that you got put into a random spot in that queue when you entered a system by either undocking and docking. The way I thought about #3 was that when other people got assigned a spot in the queue they could be placed ahead of you and you'd lose your early spot.
However, the queue theory had some flaws. The most glaring one is that the delay between clients was just too big. The most extreme one I experienced was about 900ms between both of my clients. Even if the server somehow did other calculations between client updates, which is very implausible by itself, 900ms would mean that the server was at the edge of hitting Tidi. While there was nothing major going on on that node. It also didn't explain why sometimes I'd get "kicked out of my spot" for no reason at all.
Eventually I noticed that #3 and #4 would only put me "backwards" in time and whenever they happened my client experienced "rubberbanding" as people call it. That's when something happens on your screen, then everything moves back by a split second and the same things happen again.
That observation was what lead me to my current theory that I think is pretty valid:
When your client first requests an update from the server, by either undocking or entering a system, it gets put on a one-second interval that is independent of the server tick. Observing the network traffic by two Eve clients kind of confirmed this. They get updated precisely once per second, but at different millisecond timestamps.
Depending on when during the server tick your client requested its first update, you either get new info early or late. This means that there can be a delay of up to one second between the server calculating a "tick" and your client actually receiving an update about what just happened.
When you see "rubberbanding", it's likely that your update was scheduled before the server was done calculating the next "tick".
Now, to understand this you have to know that the server only sends updates when things actually change on grid. And by that I don't mean just ship's positions. If, for example, a ship is orbiting another ship that is aligning in a straight line and neither of them does anything to change their speed, your client will just calculate their continued positions on its own and the server will not send an update until one of them actually changes something about that state. (I also confirmed this on Sisi by looking at network traffic with a bunch of characters).
Not receiving an update is something that's entirely expected by the client. To the client it just means "keep showing the state of the grid we last send you, all the ships keep moving on the paths they were moving on".
So what happens when the client's update is scheduled before server is done with the tick?
The client will expect an update. Not getting one at the expected time during a second, it thinks that nothing changed and will continue showing the grid. Then, a couple of milliseconds into that, the server belatedly sends its update, which basically is "here's what actually happened". So the client resets everything to the state in the update, which is a split second in the past from the last thing it was showing, so it looks like everything jumps back and plays again for the player.
Now, how does this tangent relate to the tick position? Well, the late update during rubberbanding resets your update interval, so all following updates will be in 1s intervals after that one. Which means you're now later on the tick than you were before.
That explains #3 and #4 in the list, each are caused by server load putting you back on the tick.
Lock, Point and Warp Interactions
By now you're probably thinking "why are you talking about server ticks so much, I thought this was about instalocking". Well I told you to skip ahead if you don't care about in-depth technicalities and I'm going to keep going like that, so there's still a chance to skip ahead! This one will be shorter though.
In this section I'm going to talk about warp mechanics. Every time I talk about warping in this context, we'll assume it has an align time greater than 1 second and less than or equal to 2 seconds
The basic process of just warping without considering any lockers looks like the following:
1) The player initiates warp to a destination
2) The server receives the intent to warp
3) On the next tick, the server starts aligning the ship, starting from 0 velocity. We'll call this one tick 0. 4) On the next tick, the ship will still be aligning. We'll call this one tick 1.
5) On the final tick, the ship will be at >=75% of its max speed and enter warp. This is tick 2.
Now, two things that most people know but some people are still confused about:
It doesn't matter how fast your ship goes "between ticks". You either warp on tick 1 or tick 2. You don't warp at tick 1.5. This means it doesn't matter if your Ares aligns in 1.4 seconds or 1.99. It should be obvious just from the theory, but I did a bunch of sisi testing with a nomad set, and found absolutely no difference between 1.1s align and 1.99s align.
It doesn't matter what the warping person's latency is. The client only sends one command to the server that queues the warp. Everything after that is done entirely by the server.
How do these steps play out when someone is trying to lock you?
Let's assume Alice has just jumped her travel Ares into Bob's gatecamp.
1) Alice initiates warp to her next gate.
2) The server receives her intent to warp
3) Tick 0, the server starts aligning Alice's ship
4) The server sends an update to Bob, that Alice's ship has decloaked and is now aligning (still Tick 0) 5) Bob sends his intent to lock the Ares to the server (still Tick 0)
At this point, the paragraph about the update order comes into play.
As you remember, the time between #3 and #4 can be anywhere from (let's estimate conservatively) 50ms-1000ms. As you can imagine that's a huge range.
Another thing worth mentioning is that initiating locks is handled between ticks, while finishing locks happens on full ticks.
Let's first assume Bob is late on his update interval, getting them 500ms after the tick and has a ping of 16ms and is spam clicking his overview 50 times a second which is unreasonably fast but a nice round number.
Lastly, locking a ceptor from a max sebo ship takes about 600ms. T0, T1, T2 refer to the ticks mentioned earlier.
3) T0+0ms, the server starts aligning Alice's ship
4) T0+500ms, The server sends an update to Bob, that Alice's ship has decloaked and is now aligning
5) T0+520ms, Bob sends his intent to lock the Ares to the server
6) T0+528ms, the server receives the intent to lock the Ares and schedules the lock to finish in 600ms
7) T1+0ms, the server calculates tick 1, nothing really happened yet
8) T1+128ms, this is the time that Bob's lock request is scheduled to finish
9) T2+0ms, the server calculates tick 2, finishes Bob's lock and Alice enters warp.
Note how Bob's lock request and Alice's warp finish on the same tick. When this happens, from Bob's view you'd see a successful lock, but get the message "target is invulnerable" when trying to use a module on it.
If Bob is early on the update interval however, getting his updates only 200ms after the server tick, this plays out differently:
3) T0+0ms, the server starts aligning Alice's ship
4) T0+200ms, The server sends an update to Bob, that Alice's ship has decloaked and is now aligning
5) T0+220ms, Bob sends his intent to lock the Ares to the server
6) T0+228ms, the server receives the intent to lock the Ares and schedules the lock to finish in 600ms
8) T0+828ms, this is the time that Bob's lock request is scheduled to finish
7) T1+0ms, the server calculates tick 1, finishes Bob's lock
8) T1+200ms, Bob receives the update that he has a lock and activates his warp disruptor
9) T2+0ms, the server calculates tick 2, Bob's warp disruptor activates, Alice cannot enter warp
Important thing to notice here is that we still have a lot of room for more latency, but not infinitely much. You don't need to live in London, but being in Europe will help a lot.
The Guide / TLDR
So how did I use this information to get two Daredevils to over 100 killmarks?
First of all, I used an alt with 4 remote sebos to get it up to 3500ms scan res. Any ship with 4 mid slots can do this.
Then the goal is to get your updates early enough to be able to finish the lock on tick 1. As you remember, 3 things can change your update time and one of those only goes the wrong direction.
Well, the actual technique to use this is really dumb. What I did is, I jumped in and out of system. Over and over, until I got the updates early enough.
Jump into system, activate sebos. Jump in an alt in a sub 2 align ship. Activate autopilot on the alt to another gate, quickly switch over to main and start spam clicking the overview with point active. If I got lock and point on the alt, I'd be set to catch any other sub 2 align ship that jumped into system until server load pushed me back. If I didn't get lock and instead got the "target is invulnerable" message, I'd jump out and back in again. Repeat until it works.
That's all there is to it.
EDIT: Oh finally, shoutouts!
Predditors, the TEST sig, my primary community in this game. If you're in Legacy/TEST and like cloaky content or smaller-scale fleet as well as an always active standing fleet and a great community, consider joining!
Lorenaii and Syrinea of B0RT for listening when I kept rambling about instalock on Dreddit discord, talking to someone about my thoughts really helped me figure things out. One extra shoutout to Syrinea because he was actually really knowledgeable about instalocking and helped me confirm or disprove a lot of stuff with his input.
Aid London and his friends in goons who had a consistent instalock camp up before I did it and made me realize it's possible to do.
Aiden Malcolm of Initiative Associates, who killed my 170km Daredevil when I was drunk on new years eve and thought I should engage an arty Thrasher at range.
- Finally found out why the game is so unresponsive and full of desync
- [TECHNICAL] A case for an alternative server design for EVE (EVE 2.0 when?)
- Could the Dark Avengers update potentially be split in two?
More about EVE OnlinePost: "How I got 170 killmarks on my Daredevil – An in-depth look into “ultralock” mechanics" specifically for the game EVE Online. Other useful information about this game:
Top 7 NEW Games of February 2021
Looking for something new to play on PC, PS5, PS4, Xbox, or Nintendo Switch in February 2021? Here are the notable video game releases.
Top 20 NEW Open World Games of 2021
2021 will bring us tons of open world games for PC, PS5, Xbox Series X, PS4, Switch, and beyond. Here's what we're looking forward to.