Interdiction Nullification
Interdiction Nullifier use
The new Interdiction Nullifier module allows you to bypass bubbles. These were added to the game in May 2021. They are a high slot, that when activated, will adjust the math of where you land to ignore mobile disruption bubbles. They have limits on what ships they fit on. https://wiki.eveuniversity.org/Interdiction_Nullifier has more information on them.
All Math on where you will land is done when you START warp. Any math is redone if you are bubbled and reinitate warp. It's not when you go into warp but when you start.
So if you warp to a gate, and there's a bubble already up, you land on bubble edge. If you warp to a gate and bubble goes up mid warp, you land on gate.
A Nullifier says 'fuck all that, I'm going to do what I wanna do!' and you warp to the gate in both locations, as long as you use the module BEFORE initiate warp. You can use the module while cloaked.
After you warp, you have a cooldown time, which is about the same length of cloak timer, so sometimes the T1 is better than the T2.
Greetings Newbeans, your tip of the day.
Did you know that they changed interdiction nullification? Here's your simple version.
Moving a pod? Shuttle makes it easy, costs almost nothing, warps slowly but cannot be caught other than by a smart bomber. So if you're smart, cannot be caught! 😄
Want to move something with a minor amount of space? First, can you ship it with a JF? do that then. But an interceptor works great. The T1 is sometimes better than the T2. You can cycle the T1 every 50 seconds, while the T2 only every 60 seconds. Warping gate to gate can be dangerous though, so again, minor pauses help. Small bubbles in key places can totally fuck you up but at least you have a MWD to get you out of those jams. I like the malediction for the insta lock camps. Must start the nullifier before warping, so it's easy to fuck up the timing of this, practice a bit!
Want to move something more substantial? The industrials can now fit them. they use a high slot, so a cloak and a nullifier at least gives you SOME kind of out if there's something bad going on . 😄 Also, the blockade runner and Deep Space transport can fit them, sometimes with a MJD as well, making you hard to catch, but a scout helps a lot.
Covert ops also make great nullified entries, as long as you have a low align time. You can still get decloaked by smart pilots. Pre-planning helps a lot, but flying around in a covert ops ship like a cheetah makes me feel invicible. 😄
Instalocker
Want to give thanks to /u/KiuNakamura on reddit for this instalocker diagram. It's never perfect, but this seems to be the way Dogma/Destiny works on the eve cluster.
The Server Tick (or, “WTF, Why Didn’t My Point Turn On?!”)
Thanks to ullrerm on this blog: https://web.archive.org/web/20201111164354/https://namamai.wordpress.com/2014/06/25/the-server-tick-or-wtf-why-didnt-my-point-turn-on/
June 25, 2014 by ullerrm 2 Comments
It’s a scenario we’ve all experienced: You’ve got a fleet on a gate (or a station undock), and a hostile’s just appeared. Everyone drops drones and assigns them to the fastest locker in the gang, waiting for “point!” to be called on voice comms. The hostile de-cloaks, and it’s a fast ship. Everyone starts locking, and a few of you even appear get a lock on him… but before your point activates, the hostile warps away.
Congratulations: You’re yet another victim of the 1Hz Destiny Server Tick, the processing loop that forms Tranquility’s beating heart.
What IS the Destiny Server Tick?
There’s a few different parts of the Eve Server. [1] But, when it comes to shooting things in space, the most important part of them is Destiny. This is the part of the Eve server/engine that simulates grids — it handles advancing the physics simulation of Eve (ships and drones and missiles flying around), and communicating things to the client (physics updates, module activations, target locking, health/status, and other visual elements).
Each solar system, on the server, has a Destiny processing loop associated with it. At all times, this loop is running, and the code inside this loop looks something like this:
Pre-Tick Work:
Move people between grids, as they warp in/out or cross grid lines
Manage client actions (“I want to warp to gate X”, “I want to orbit object Y at 2km”, “I want drone X to return to my bay”)
Manage server actions (“Drone X just exploded”, “Object Y just spawned a missile”, etc.)
Send packets to clients containing everything they need to know to render the game for the next second
Physics (aka “Evolve”):
Simulate ships/drones/missiles moving around on grid. Handle bumps/bounces.
Post-Tick Work:
Clean up, and go to sleep until the next tick.
The goal of the server is for a server tick to run exactly once per second (or, 1 Hz). If it takes less than a second to do a tick’s work, then everything’s great, and we go to sleep for the rest of the second. (Or do a tick for another system on the same node.) But, when it takes longer than that, we have a hard choice to make: either put off some work until the next tick, or come up with more time to process the tick. And that’s where Time Dilation comes in — it stretches player activity out so that we have several seconds to do one tick’s worth of work.
Does This Mean Eve Is Actually Turn-Based?
Nope! Quite the opposite, in fact.
Destiny does a lot of work on the tick, but it can do a lot of work outside the tick as well. When client messages (including “start locking a target” or “turn on a module”) are received by Tranquility, it typically processes them immediately, and will even tell your client the result if it can. For example:
If you’re trying to jump through gate, it will mark you as “jumping through the gate” the instant that it receives the message, and will send back an acknowledgement right away that you’re jumping. However, everyone else on the grid won’t know that you’ve started jumping until the next server tick.
If you activate a turret module, it’ll immediately calculate the damage, and immediately apply it to the target. It’ll send back a packet right away, telling you, “I activated this module for you.” However, you won’t receive information about how much damage was dealt until the next tick! And neither will the target! Yes, this means you can be dead for up to a second (or up to 10 seconds, in the case of severe TiDi) and not know it yet!
Also, some tasks are completely divorced from the tick and can happen at any time, subject only to the latency between you and TQ. (For example, starting a scan with probes.)
The most important place where this affects you is a pair of closely related actions: aligning/warping, and locking a target. In both cases, they get “rounded up” to the next nearest server tick!
Rounding Up: Warping and Locking
The biggest example of rounding happens in align times. When you click “Warp to X” in the UI, your client immediately sends TQ a message: “Align me to celestial X, and warp me as soon as possible.” TQ immediately acknowledges this request, and queues up a work item for the next server tick. At the next server tick, it switches your state from Impulse Mode (normal grid flight) to Pre-Warp Mode. Then, immediately after that, and for each server tick afterward, it’s going to do this check: “Are you above 75% of max velocity, and in the proper direction? If so, immediately switch you to In-Warp Mode. Otherwise, continue to move on grid as needed to align.”
Because the check for 75% is done on the tick, your align time gets effectively ’rounded up’ to the nearest tick — if EFT lists your ship’s align time as 4.5 seconds, the actual time needed to enter warp will vary between 5 and 6 seconds. If this sounds bad, don’t worry; it’s even worse for a would-be tackler.
Imagine that you’re sitting on a gate, with a warp disruptor “primed” (i.e. pre-activated, before you have a lock). Something jumps through the gate, and you want to lock it and turn on your point. You have a 3.5 second lock time, and you have a 75 millisecond latency (aka a 150 ms “ping” time, since pings measure round-trip) between you and Tranquility. [2] What needs to happen? In order:
TQ processes the tick in which the target decloaks and starts aligning. It sends a network packet to your client that tells you, “ship X just appeared on grid, and it’s aligning towards Y.”
75 ms later, the “target is decloaked” packet successfully crosses the Internet, and your PC receives the packet, processes it, and the target appears on overview.
Your eyes and brain see the ship appear on the overview, and get your finger to click. Let’s say this takes 150-200 ms to do. [3]
Your PC sends a network packet to TQ, saying “please start locking target X.” Another 75 ms to cross the Internet!
TQ receives your “lock it” packet. It immediately starts counting off lock time, queuing a “finish locking” work item to trigger in exactly 3.5 seconds. It also immediately sends a packet back, acknowledging that you’re starting to lock.
…
3.5 seconds later, outside of the tick loop, the work item fires. TQ says, “Okay, mark down that they’ve marked ship X (for preventing cloak). At the next tick, tell the client that they’ve successfully locked.”
At the next server tick — which could happen instantly after, or could happen up to a second later — TQ sends a packet to your client, saying, “You locked ship X; it has this much HP on shields, armor, and hull. By the way, it’s still aligning towards Y.” That packet takes another 75 ms to cross the Internet! (At the same time, it’s sending a packet to the pilot of X, notifying them of a yellowbox.)
Your PC receives the “lock finished” packet. It sends TQ a packet saying, “OK, activate my warp disruptor module on X.” Yet another 75 ms to cross the Internet!
TQ receives your “tackle it” packet. It immediately activates the packet, and queues the “You warp scrambled X” message to be delivered at the next tick.
That’s a huge list! Most importantly, it requires four trips across the Internet between your PC and the server. At a minimum, it rounds up to the next server tick — and it can be worse if you’re on a high-latency connection. From your 75 ms perspective, it took you four seconds to lock; adding an additional 100 ms of latency would add a full second to your final point activation time, making it a five-second lock!
Practical Application: Instalocking Gatecamps
These rounding effects are particularly painful when it comes to very quick-locking ships, and very quickly-aligning ships. The 1Hz tick of the server produces some nasty thresholds when it comes to gatecamps. Given the above information, it’s pretty easy to write a tool that plays with delays in server tick and effects of latency to TQ, and simulates ships trying to lock other ships.
Imagine that we have a Keres with two sensor boosters on it, both scripted for scan resolution. This gives the Keres an advertised lock time for of 1.2 seconds for most interceptors. For comparison, the official align time for most interceptors is between 1.9 and 3.0 seconds, depending on fit and player SP. In theory, the Keres should be able to catch all interceptors with plenty of time to spare. Does it?
In practice, due to latency and server tick rounding, it doesn’t! The threshold is two seconds; any interceptor with an align time of less than two seconds will get away from the Keres. (At best, the Keres will appear to lock them, but the point won’t activate before the interceptor can start warp.)
So, let’s look at nano-fit interceptors. What lock time do we need for the Keres to catch a ship that aligns in 1.9 seconds? This answer depends a lot on your latency to TQ:
With a 100 ms latency to TQ, the Keres needs to be officially able to lock them in less than 0.725 seconds — achievable with three sensor boosters. And, again, this is highly thresholded; anything below 0.725 seconds will catch everything, and anything equal to or above 0.725 seconds will miss everything (due to the point not activating in time).
With a 150 ms latency to TQ, the Keres needs to be able to have an official lock time of under 0.625 seconds to lock and point a 1.9 sec-align interceptor.
And so on. In general, each 50 ms increase in latency to TQ requires a 100 ms (0.1 sec) reduction in lock time to compensate for it.
To put it bluntly, if you want to catch instawarping interceptors, the most important part is living in London! That, or have a lot of remote sensor boosters — which, unfortunately, are subject to stacking penalties.
Can We Fix This?
Ironically, we can, and not by nerfing interceptor mobility. Increasing the server tick rate to run twice per second, instead of once per second, completely eliminates most of these distortions — and, far more importantly, it makes playing Eve a much better experience for people on high-ping connections such as Australians / New Zealanders.
The server tick time in TQ is actually a compile time switch; flipping it is as easy as recompiling the server and deploying it. (And, in fact, this has happened in isolated parts of TQ, during the “inverse TiDi” mechanic of Alliance Tournament.) However, don’t expect it to happen any time soon. Doubling the server tick rate means roughly doubling the CPU load for each node. In a world where Jita regularly has TiDi kicking in just from normal player activity, bumping up the server tick rate is probably a non-starter.
Alternatives include sending “prime my module” packets to the server (to eliminate one of the roundtrips), or varying server tick frequency with load (i.e. Jita/Amarr/Rens is probably just fine with 1Hz ticks, or even 0.5Hz).
—
1: Can any CCP employees, past or present, ping me and explain how Michelle and Macho got their names?
2: For where I live (northwestern United States), a 150-160 ms ping to TQ is typical. Australian players can have 300 ms or more.
3: Reaction times (for a simple ‘I saw something, immediately flex a muscle’ response) will vary between 150ms and 200ms, depending on age and mental agility. If you have to select between two targets and pick one to tackle, your brain’s pattern recognition systems have to kick in, taking 400ms or more.