These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
 

Module activation delay. (Videos inside)

First post
Author
Previous Topic Next Topic
Har Harrison
Garoun Investment Bank
Gallente Federation
#61 - 2012-07-02 02:33:05 UTC
This is a MAJOR issue for people in Australia.
It has gotten to the point where a number of corp/fellow FW militia pilots from Australia and other such locations do not fly tackle, even if they are better skilled - they go DPS etc... and let people closer to the server (i.e. people who live in the UK) do the tackle.
Doing a roam the other night we had a Navy Omen guy from the UK getting point before guys from Australia in frigates could. This was even with the module pre-locked.
I also have the issue where the pre-locked module unlocks when spamming the lock button due to a targets invul blocking the lock...
Bubanni
Corus Aerospace
#62 - 2012-07-02 02:41:06 UTC  |  Edited by: Bubanni
Har Harrison wrote:
This is a MAJOR issue for people in Australia.
It has gotten to the point where a number of corp/fellow FW militia pilots from Australia and other such locations do not fly tackle, even if they are better skilled - they go DPS etc... and let people closer to the server (i.e. people who live in the UK) do the tackle.
Doing a roam the other night we had a Navy Omen guy from the UK getting point before guys from Australia in frigates could. This was even with the module pre-locked.
I also have the issue where the pre-locked module unlocks when spamming the lock button due to a targets invul blocking the lock...



That's a different issue, but an issue non the less, I live very close to the servers and have a decent ping

Hmm or rather... its a lag issue + this issue a have been talking about for you guys... fixing my issue will improve your issue and thus reduce your problem with lag in tackling

Supercap nerf - change ewar immunity https://forums.eveonline.com/default.aspx?g=posts&t=194759 Module activation delay! https://forums.eveonline.com/default.aspx?g=posts&m=1180934
Ager Agemo
Rainbow Ponies Incorporated
#63 - 2012-07-02 02:59:43 UTC
not so related but now that people mentions it.... the invul timer for when warping away and in, should be reduced or removed, either way at the speed ships move on those phases is unlikely u can do much against them.
Mors Sanctitatis
Death of Virtue
#64 - 2012-07-02 04:39:26 UTC
CCP Veritas wrote:
Yeah, the stuff in my keynote presentation isn't really related to the OP.

I haven't specifically looked at how pre-firing modules works, but I'm pretty sure it's all client-side processing today. I'm a fan of moving them server-side as y'all are talking about - not exactly a small change though. I'll talk to some folks and see where it might land on the List o' Stuff To Do.


A while back (it's been so long ago, I can't remember when exactly), you could actually "pre-fire" modules, priming them, and then locking a target and it would activate the modules properly when lock was achieved and all was well. Then, for some reason, it broke and no longer worked. Afterwards, players had to begin the lock process and THEN prime the module in order for it to work.

If it is going to be extremely difficult to increase the server tick rate resolution and/or move everything server side and fix the problem, allow me to make another suggestion: increase the time to warp of every ship in the game so that the absolute best time to warp for any ship in the game is at a minimum of 50% greater than the existing resolution.

If the existing tick rate is 1 second, then the minimum time to warp should be 1.5 seconds. Scale all other time to warp for all other ships accordingly so that all warp speeds remain relative. Additionally, all scan resolutions and modules applying scan resolution bonuses will have to be adjusted as well.

While this may be a crude and 'brute force' way of doing things, I think that it provides the most durable solution in that it can take into account the most real world deviation and builds in an additional factor of safety.

Intelligence shouldn't be free.   Mining, reloaded.   ADDICTED.

Nikodiemus
Etsala Empire
Etsala Legion
#65 - 2012-07-02 05:34:43 UTC
Mark Androcius wrote:
The problem obviously is in the programming.

The way it works now:

you target someone - server gets your request - other persons client reacts.
target locked - now scram is activated - server gets your request - other persons client reacts.


The way it could/should work:

you click the scram and then the target - server get your request and calculates how long this would take you before activating - other persons client gets this info and determines if it can outrun it or not.
If not, scram works as intended, if he can he warps away.



No no no and no. Your example of how it "should" work leaves out so many steps in its implementation that it boggles my mind to even try and point out all the flaws. Citing this lame pseudo code jargon only hurts the point the OP is trying to make.

Module delay is a very important factor in the overall Gameplay/lag-component of Eve Online. This is why time dilation is actually a big step forward and a great help for large fleet fights

That being said, singular events that prevent small scale module activation within a second of the confirmation are so low on the "need fixing scale" I am amazed you are even bothering here.

This is a TINY problem if there even is one, and from watching your vids and having the experience I have, I still believe it is an item that should be low on CCP's list of "**** to fix".
Molinator Agnon
Oruze Cruise
#66 - 2012-07-02 08:52:12 UTC
I gave feedback about this issue in the last EVE survey I responded to - it annoys the hell out of me as well.

Lag frustrates me, but it gets exponentially frustrating when you're doing something that requires quick reactions - be that pointing a fast frigate, attempting to deactivate modules for ammo switches or the like.

This is my #1 gripe with EVE Online at the moment, and I think it would make EVE a lot more "playable" and appealing if server response times were reduced.
VanDam
Caldari Provisions
Caldari State
#67 - 2012-07-02 08:53:59 UTC
That is why I drag my disruptor to a high slot and press F2 as soon as I have target lock. Quicker than a pre-activation.
Molinator Agnon
Oruze Cruise
#68 - 2012-07-02 09:05:04 UTC
DelBoy Trades wrote:
This is the reason people call "point" and then the prey warps off half a second later.

And also the reason why this issue should be one of the biggest priorities for the Devs - decrease the server "tic" and increase the level of competition in this game.

When server tics are much longer than human reaction time (~200ms), the playing field gives huge handicaps to players that might be able to react more quickly and combat becomes much less exciting.
Pipa Porto
#69 - 2012-07-02 09:11:18 UTC  |  Edited by: Pipa Porto
Molinator Agnon wrote:
DelBoy Trades wrote:
This is the reason people call "point" and then the prey warps off half a second later.

And also the reason why this issue should be one of the biggest priorities for the Devs - decrease the server "tic" and increase the level of competition in this game.

When server tics are much longer than human reaction time (~200ms), the playing field gives huge handicaps to players that might be able to react more quickly and combat becomes much less exciting.


I'm Ok with (in fact, I prefer) EvE not being a twitch fighter game. Your reflexes and the length of your OODA loop still have an enormous effect on your combat abilities. Especially in smaller hulls.

EvE: Everyone vs Everyone

-RubyPorto
Molinator Agnon
Oruze Cruise
#70 - 2012-07-02 10:33:33 UTC
Pipa Porto wrote:
Molinator Agnon wrote:
DelBoy Trades wrote:
This is the reason people call "point" and then the prey warps off half a second later.

And also the reason why this issue should be one of the biggest priorities for the Devs - decrease the server "tic" and increase the level of competition in this game.

When server tics are much longer than human reaction time (~200ms), the playing field gives huge handicaps to players that might be able to react more quickly and combat becomes much less exciting.


I'm Ok with (in fact, I prefer) EvE not being a twitch fighter game. Your reflexes and the length of your OODA loop still have an enormous effect on your combat abilities. Especially in smaller hulls.

Quicker reactions should always be a valid way to defeat an enemy in a game that supposes to be played in real time - but as it stands currently, EVE is not real time but more of a second by second turn-based game.

I don't think EVE will ever be a twitch fighter where reaction time is the biggest factor in victory - but I think it's wrong to handicap players who are entirely capable of reacting more quickly the ability to do so because of the server tick.

Combat in general would be vastly improved if server performance improved to the same level as a MOBA (or FPS) match, and I would hope that this would be a goal of CCP's. I know this is made difficult or nearly impossible by the fact that it is a single shard, but I can honestly say (without a shred malice - this universe is amazing) that I will lose interest in EVE if server performance is not addressed in the future. So it's reassuring to already see two CCP posts here.

I'm very passionate about this issue because I think EVE has vast amounts of potential for improvement of small scale player vs player combat if there was a lot less of "Please wait..." and second-long delays on module activation.
Pipa Porto
#71 - 2012-07-02 10:37:41 UTC  |  Edited by: Pipa Porto
Molinator Agnon wrote:
Pipa Porto wrote:
Molinator Agnon wrote:
DelBoy Trades wrote:
This is the reason people call "point" and then the prey warps off half a second later.

And also the reason why this issue should be one of the biggest priorities for the Devs - decrease the server "tic" and increase the level of competition in this game.

When server tics are much longer than human reaction time (~200ms), the playing field gives huge handicaps to players that might be able to react more quickly and combat becomes much less exciting.


I'm Ok with (in fact, I prefer) EvE not being a twitch fighter game. Your reflexes and the length of your OODA loop still have an enormous effect on your combat abilities. Especially in smaller hulls.

Quicker reactions should always be a valid way to defeat an enemy in a game that supposes to be played in real time - but as it stands currently, EVE is not real time but more of a second by second turn-based game.

I don't think EVE will ever be a twitch fighter where reaction time is the biggest factor in victory - but I think it's wrong to handicap players who are entirely capable of reacting more quickly the ability to do so because of the server tick.

Combat in general would be vastly improved if server performance improved to the same level as a MOBA (or FPS) match, and I would hope that this would be a goal of CCP's. I know this is made difficult or nearly impossible by the fact that it is a single shard, but I can honestly say (without a shred malice - this universe is amazing) that I will lose interest in EVE if server performance is not addressed in the future. So it's reassuring to already see two CCP posts here.

I'm very passionate about this issue because I think EVE has vast amounts of potential for improvement of small scale player vs player combat if there was a lot less of "Please wait..." and second-long delays on module activation.


Right now, in big fleet fights, the server takes 10-20s to complete the calculations it needs to for each tick (this is what TiDi does).
Speeding up the ticks to a FPS-like ~30HZ would mean that, for each second of IF elapsed time, the server would spend 300-600s to complete the calculations.

Increasing the server granularity would TiDi all of the hamsters until they died.

EvE: Everyone vs Everyone

-RubyPorto
Rellik B00n
Lethal Death Squad
#72 - 2012-07-02 10:47:03 UTC
+1 to OP

I often run in a cruiser with over 3500 scan res. I lock everything in a very very short period of time and a large number manage to warp out without my modules activating.
[Of a request for change ask: Who Benefits?](https://forums.eveonline.com/default.aspx?g=posts&find=unread&t=199765)
Hemmo Paskiainen
#73 - 2012-07-02 11:16:13 UTC
It is the same with smartbombs. They have it more worse, my bug petition about it got an answere that i need to figur out why. It is also the same reson why some smartbombs miss their cycle and some cycles do no damage at all..... Logs show nothing though...

If relativity equals time plus momentum, what equals relativity, if the momentum is minus to the time?
Deucaliona
Penumbra Institute
#74 - 2012-07-02 11:53:32 UTC
Pipa Porto wrote:
Bubanni wrote:
Bump


Stop that.



The server has Always operated on 1s Ticks. This isn't new. The only solution to this would be for the server to operate at 2HZ (at which point you'd start complaining about the .5s module delay).

The 1HZ server tick is not likely to change any time soon.



If this is operating at 1 tick a second, why does the lock and module activation not happen in exactly the same tick? Since we are using the module for the lock anyway.
Pipa Porto
#75 - 2012-07-02 11:57:54 UTC
Deucaliona wrote:
Pipa Porto wrote:
Bubanni wrote:
Bump


Stop that.



The server has Always operated on 1s Ticks. This isn't new. The only solution to this would be for the server to operate at 2HZ (at which point you'd start complaining about the .5s module delay).

The 1HZ server tick is not likely to change any time soon.



If this is operating at 1 tick a second, why does the lock and module activation not happen in exactly the same tick? Since we are using the module for the lock anyway.


So the tick is broken into 2 parts.

Part 1: Server is processing requests and deciding what happens due to those requests.
Part 2: The Server is telling the clients what happened.

Pre-activating a module tells your client that you want it to activate as soon as you're locked on target. So, as soon as the Client hears back from the server that it has a lock, it fires back with the module activation. So the module activates on the tick after the lock.

EvE: Everyone vs Everyone

-RubyPorto
Bubanni
Corus Aerospace
#76 - 2012-07-02 12:09:16 UTC
Pipa Porto wrote:
Deucaliona wrote:
Pipa Porto wrote:
Bubanni wrote:
Bump


Stop that.



The server has Always operated on 1s Ticks. This isn't new. The only solution to this would be for the server to operate at 2HZ (at which point you'd start complaining about the .5s module delay).

The 1HZ server tick is not likely to change any time soon.



If this is operating at 1 tick a second, why does the lock and module activation not happen in exactly the same tick? Since we are using the module for the lock anyway.


So the tick is broken into 2 parts.

Part 1: Server is processing requests and deciding what happens due to those requests.
Part 2: The Server is telling the clients what happened.

Pre-activating a module tells your client that you want it to activate as soon as you're locked on target. So, as soon as the Client hears back from the server that it has a lock, it fires back with the module activation. So the module activates on the tick after the lock.


which takes exactly 1 sec + locking time (so fastest possible will be 2 sec to lock and point a frigate) which is too long to catch many frigates

Supercap nerf - change ewar immunity https://forums.eveonline.com/default.aspx?g=posts&t=194759 Module activation delay! https://forums.eveonline.com/default.aspx?g=posts&m=1180934
Pipa Porto
#77 - 2012-07-02 12:51:05 UTC
Bubanni wrote:
Pipa Porto wrote:
Deucaliona wrote:
Pipa Porto wrote:
Bubanni wrote:
Bump


Stop that.



The server has Always operated on 1s Ticks. This isn't new. The only solution to this would be for the server to operate at 2HZ (at which point you'd start complaining about the .5s module delay).

The 1HZ server tick is not likely to change any time soon.



If this is operating at 1 tick a second, why does the lock and module activation not happen in exactly the same tick? Since we are using the module for the lock anyway.


So the tick is broken into 2 parts.

Part 1: Server is processing requests and deciding what happens due to those requests.
Part 2: The Server is telling the clients what happened.

Pre-activating a module tells your client that you want it to activate as soon as you're locked on target. So, as soon as the Client hears back from the server that it has a lock, it fires back with the module activation. So the module activates on the tick after the lock.


which takes exactly 1 sec + locking time (so fastest possible will be 2 sec to lock and point a frigate) which is too long to catch many frigates


Never said anything different.

Problem is that fixing it either requires trusting the client or adding potentially significant load to the server. Neither option is good.

EvE: Everyone vs Everyone

-RubyPorto
Lin-Young Borovskova
Doomheim
#78 - 2012-07-02 13:14:31 UTC
This small "lag" stuff is happening to me now on many other modules than only scram/TP stuff, missiles used to "shoot" at the beginning of cycle, now it's more about the end of it, same for shield boosters, usually starts rep at the beginning of cycle but now I can clearly see the effect happen only after 50/70% of cycle, armor effect of actual rep cycle apply rep effect at the beginning of next cycle, looks awkward.

brb
CCP Veritas
C C P
C C P Alliance
#79 - 2012-07-02 13:16:08 UTC
You guys are giving me a good idea for a devblog 'cause it's clear the whole 1hz tick thing is confusing to some ;)

CCP Veritas - Technical Director - EVE Online
Pipa Porto
#80 - 2012-07-02 13:26:10 UTC
CCP Veritas wrote:
You guys are giving me a good idea for a devblog 'cause it's clear the whole 1hz tick thing is confusing to some ;)


A Dev blog detailing how it works would be awesome.

(Could you also detail how aligning works, so we can finally put to rest the idea of a passive align, pretty please?)

EvE: Everyone vs Everyone

-RubyPorto