EVE General Discussion

Hi CCP, and everybody else....

Can you please work on improveing module activation delay... or more specificly, the time it takes for a warp disruptor to activate right after you locked a target (fx a fast frigate)

As I see it now, there is a delay that allows you to lock the target right before it enters warp, while trying to point it with a warp disruptor or such, but because of that delay it will warp away before the module activates...

I recall a time when the delay was much smaller, but it's very visible now....

So whats the problem...? I often hear people call "point" when in fact they only just locked the target... only to see the target warp away a half second later... most often it's light ships that warp fast anyway like frigates...
other times it's after a tackle has burned at a target that was aligning out...

The problem is not actually that people call point before the target is pointed, but that they were used to the fact that the target was pointed when the target was locked...

I am aware that this game is "tick" based, and that's the main reason for this problem, but what if you made "prefired points" server sided? so they actually activated the same "tick" as you locked the target.

http://www.youtube.com/watch?v=KRQ7yF4a4dg <-- just uploaded this video clearly showing the problem

(I have confirmed myself while I made that video it takes exactly 1sec after you locked the target, until the module activates)

" http://www.youtube.com/watch?v=9VtsnhAomJs first example, I found that it happened often when I had about 1200-1400 scan res vs a rifter with 2x tech 1 nanofibers... back then

http://www.youtube.com/watch?v=XPrAk0hXpgI in this second video I am using an 1800+ Scan res cynabal... I started locking the frigate half a second after it became visable, managed to get a lock on it, and it then warped away... Note that I did not activate the warp disruptor until after I started locking it...and it is clearly flashing grey..."

So, I was thinking, could more poeple confirm they experienced this annoying delay? and how many would agree they want it optimized to "happen less" ?

Both in attempts where it was "heated" before locking, and after locking, but even then... if that was the problem, they should optimize the "heated" modules

You dont need to 'heat' the module before locking.

just click the module to activate it, then start locking - or start locknig and activate the module before the lock finishes.

In either case, so long as the odule is queued up to activate before the lock finishes it should activate on the target as soon as the lock ends.

I've never had any problems with it taking a second longer after the lock is gained.

Look at my videos, they will confirm the problems, and by "heat" it means prefired, activated before the locking finishes or before you even begin locking ;)

also, as I said, it's not a problem when the target isn't warping fast enough + you still have high enough scan res...

But even in examples of bigger ships trying to tackle bigger ships, this can happen.

I am about to upload a video that shows the problem... give me a few min, it's not that the client tells you that you have warp disrupted the target... it's that it takes so long before it does... :) anyway, look back in about 15 mins+

Everyone knows this man, my post was in half-jest. It's the same as when I warped off a gate with no hostiles on it, then (while in warp) I got teleported back to the gate I came from, killed and podded. My client told me I warped off the gate 30 seconds before I was teleported back. Logs (obv clientside) shows me I initiated warp 30sec+ before I even got damage notifications. We were less than 50 people in local, they were ~20-25 landing on the gate and we were 4-5 leaving it. No visible lag, no module delays, etc.

The non-jest part in my post is this; your client tells you ALOT of stuff, and sometimes impossible/should-not-happen stuff happens. Like me being teleported back, half a minute after my sub 4 sec align time ship had told me it was warping. Like when your modules tell you they are activated, you even see them run a full cycle or start a second, at times, and yet they seem to have no effect. But in the end, what matters, is what the server says. CCP cannot check what our clients tells us, it's unreasonable and the workload for GM's would be immense, and so much potential for players to try cheat themselves into reimbursements. So when the server tells CCP that our modules did not activate, or that targets was out of range, even tho we saw something different..

TL;DR we have to suck it up.
Players don't want this to happen, CCP don't want this to happen, but you won't be able to "fix" this, and this is one of the rare cases I actually trust CCP will try to make this as good as possible.

Easy fix, click the scrambler before targeting and then click the intended target, this makes it work the instant you have lock, no lag at all.

Ouch, my bad, didn't see that one indeed.

I never have that problem though, possibly an isp issue?

Bubanni already explained the component that is most likely responsible for the observed behavior: the server-side simulation runs on 1 Hz.

So it can take for up to a second for any action you take to be processed.
For a demonstration of this effect let a large fleet jump through a gate: It's reasonable to assume that the timing at which people click the gate is pretty random, yet you'll see them flash in waves (with one second between them) as they jump.

The server updates the state of the solar system once every second, so how EVE works is

TICK status of the world is initialized
players click things, odd timers run out, ...
TICK server processes everything that has happened since the last tick and updates the status of the world

The simulation runs at 1Hz for both you and the player you are trying to tackle. What happens is probably something like this

Player A is sitting at one side of the gate, Player B at the other

Player B hits jump
TICK - Player B jumps into the system and loads grid
Player B hits warp
TICK Player B is now uncloaked and aligning towards his warp destination
Player A hits Lock and activates his warp disruptor
TICK Player A has started locking, Player B is still aligning
Player A's locking timer runs out
Player B has reached the velocity to start warp
TICK now the server has to decide in which order to process these two actions.

What Bubanni insinuates is that the order of precedence in which things that happened since the last TICK are processed may have changed - with (possibly unintended) side effects on gameplay.

There are many plausible ways to establish an order of execution, e.g.
* "tag everything that happens between ticks with a timestamp and execute actions in the same order they would have happened in continuous time"
* "let all competing actions roll dice against each other and perform the winner first"
* "process commands in some fixed, arbitrary order, e.g. always process warp and movement commands before module activations because 'w' for warp comes after 'a' for activation in the alphabet"
* "process commands in some fixed order that is based on performance criteria and designed with an eye towards graceful degradation" (maybe it is more important to process warps before module activations to keep a 1000vs1000 lagfest playable and somewhat synced?)
* "adjust the order of execution based on node load to ensure optimal performance and graceful degradation"
...

If all the Ifs and assumptions in this post are near the mark I would look for the culprit somewhere in the many performance optimizations during the last 1-2 years.