테스트에있을때 니모스라는애가 알려줫는데, 얘가 얼마전에 레딧에도 썼던 내용임

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.

대략 1.1초 얼라인과 1.99초 얼라인과 다를게 없다는 이야기

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.

워프하는 사람의 핑은 관계가 없음. 클라이언트가 서버에 워프한다고 보내놓으면 계산은 서버에서 하기 때문임. 이해 잘 안되면 밑에까지 읽어보셈.

그러니까 무새고가 뒤진건 김치핑때문이 아님

얘가 뒤진게 디클락당해서 뒤진게 아니라 그냥 워프하기전에 클락안하고 뒤진거랬으니까 지가 클락버튼을 늦게 눌렀던지 아니면 니네집 인터넷이 애자라 워프누르고 클락누르는 사이에 인터넷이 나갓다 들어왓다던지, 아니면 걍 ㄹㅇ수만분에 1 확률로 배나 드론 2000m 옆에 스폰됐던지 하면 클락 못할수도있음

아무튼 핑때문은 아님
클락 늦게누른 님 손가락 또는 인터넷 또는 님 운빨을 탓하셈


그럼 선생님 1.9초 셉터는 어떻게 잡나요????


먼저 업데이트 오더라는걸 알아야댐

이 업데이트 오더의 초기화는 다음과 같은 경우 일어날 수 있음

1. Docking/Undocking

2. Jumping through a stargate

3. Large amounts of ships entering or leaving grid.

4. Sometimes randomly for no reason

도킹, 언도킹, 게이트 넘을때, 다수의 함선이 그리드로 들어오거나 그리드에서 나갈때 또는 지 꼴릴때

그럼 이 업데이트 오더를 왜 알아야 하느냐?

https://m.imgur.com/ymS8CA9
위 짤처럼 같은 그리드에 있어도 가끔 한쪽 툰이 업데이트가 더 빠를 때가 있음

짤의 경우 왼쪽이 업데이트 오더가 더 빠른거임

그림으로 최대한 설명해보겟음

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.

니가 처음 성계를 들어오거나 언독을 해서 서버에다가 업데이트를 요청하면 이게 서버틱이랑은 별개인 1초 인터벌의 요청 큐에 올라감. 얘가 이브 클라 두개의 네트워크 트래픽을 관찰해서 알아냇다함. 얘네는 위 그림처럼 1초 "간격" 을 가지는건 맞지만 툰별로 별개라 각각 다른 미리초 타임스탬프마다 1초가 찍힘.

앨리스는 타마에서 케다마를 가고싶어하는 1.9초 아레스고

밥은 타마에서 놀부카이켄 게이트를 캠핑하는 정신병자 인스타로커임

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.

그럼 밥이 500ms의 딜레이를 가졌다고 가정하고, 16ms의 핑을 가지고있고, 실제로는 엄청 빠르지만 계산하기 좋은 숫자인 초당50번 오버뷰를 클릭하고있다고 쳐보자. 마지막으로 인터셉터를 맥스 센부배로 락인할때 걸리는 시간을 600ms라고 가정했을때 아래와 같은 일이 일어난다.

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.

틱0 + 0ms , 서버가 앨리스의 1.9초 셉터를 얼라인시키기 시작함.

틱0 + 500ms , 서버가 밥에게 앨리스가 디클락하고 얼라인한다고 알려줌. (밥의 오버뷰에 인터셉터가 생김)

틱0 + 520ms , 밥이 아레스를 락인한다는 시도를 서버에 보냄 (초당50번클릭 = 1000ms / 50 = 20ms)

틱0 + 528ms , 서버가 밥이 아레스를 락인시도한다는 정보를 받고 아레스는 600ms 후에 락인된다고 계산해놓음 (핑 16ms가 왕복시간이므로 16ms/2=8ms)

틱1 + 0ms , 서버가 틱1을 계산함, 별일없음

틱1 + 128ms, 서버가 밥의 락인이 끝났다고 계산함

틱2 + 0ms, 서버가 틱2를 계산한 뒤 밥에게 락인이 완료됐다고 알리고, 앨리스는 케다마로 워프함.

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:

밥의 락이랑 앨리스의 워프가 같은 틱에 일어남. 밥의 화면에는 락인이 완료됐지만 "target is invulnerable" 메시지가 뜨면서 모듈이 안올라감.

그러나 만약 밥이 업데이트 인터벌의 딜레이가 200ms밖에 안된다면 아래와 같은 일이 일어남.

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

틱0 + 220ms, 밥이 아레스를 락인한다는 시도를 서버에 보냄

틱0 + 228ms , 서버가 밥이 아레스를 락인시도한다는 정보를 받고 아레스는 600ms 후에 락인된다고 계산해놓음

틱0 + 828ms , 서버가 밥이 아레스의 락인이 끝났다고 계산함

틱1 + 0ms , 서버가 틱1개의 계산을 완료한 후 아레스를 락인시켜준다고 보냄

틱1 + 200ms , 밥의 오버뷰에서 락인이 완료된걸로 보이고 밥은 아레스에다 디스럽을 걸음 (역, 돌아올때 핑 계산이 안된거같음 근데 큰상관은없음)

틱2 + 0ms , 서버가 틱2개의 계산을 완료한 후, 워프 디스럽터가 가동되고 앨리스는 뒤짐

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.

위와 동일한 기준에서는

(1초)-(딜레이)-(락인시간)=(인스타락가능한핑)x2

(1000)-(200)-(600)=200x2=400ms

이므로

이론적으로 위같은 조건에선 400ms로도 인스타락이 가능함. 그래서 유럽에 사는게 도움이 많이 됨.

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.

그래서 결론적으로 리모트시보를 존나달아서 스캔레졸을 ㅈㄴ 올린다음

위에 올린거처럼 틱1에 락인을 끝낼 수 있을 때까지 님의 업데이트 오더를 새로고침해야됨.

그냥 특별한 방법이 있는게 아니고, 위에 설명했던거처럼 도킹,언도킹을 반복하거나, 성계를 들락날락을 존나해서 틱1에 락인을 끝낼 수 있을 때까지 계속 와리가리 쳐야됨.

새벽5시에 잠안자고 써서 가독성 씹창났는데 읽느라 고생했음

그럼자러감ㅂ2

3줄요약

1. 무새고가 뒤진건 김치핑때문은 아님 (워프하는놈의 핑은 상관없음)

2. 태클하는놈의 핑은 상관있음

2. 1.9초 셉터를 락인하고싶으면 게이트를 계속 넘어서 딜레이가 충분히 낮을 때까지 새로고침해야됨