No module activation, Double module activation, Network issues

Special modules without a cooldown will sometimes activate twice instantly, enabling then disabling them.

This is detrimental to Guided Torpedoes, which simply blow up in your face, cloak instantly decloaking, etc…

The most likely reason this occurs is due to a network issue:

  • Client activates a module, and sets it to the ‘active’ state.

  • Server receives active state, and activates the module.

  • Server times out waiting for the next packet due to packet loss or congestion.

  • Server assumes the active state to be disabled, even though client still thinks it is enabled.

  • Server disables the module and sends the message to the client

Server should not assume the module is disabled until the client disables it, or the active time expires.

Furthermore, client/server should send duplicate packets to prevent packet loss if possible.

I’ve attempted to re-assign the key and use a different keyboard to no effect, the issue persists.

Other players also have the same bug as I’ve witnessed several Torpedoes exploding in their faces in spectator mode.

  • Multiple instances of ‘no activation’ - modules fail to activate - or activate with no effect, but are on cooldown.

  • Several instances of missiles visually flying directly through Guard hulls; obviously lag. Multiple issues of missiles flying within 50m of a target with no activation. Meanwhile, missiles will activate 100m+ away from me on occasion. Proximity mines not activating, despite proximity, etc…

  • Sometimes, I will fire a missile and its trajectory will be up to 30 degrees off, due to lag and ship rotation.

  • Timing issues, such as recons being able to warp while cloaked, or use active modules after cloaking.

  • The lead indicator (targeting reticule) is not accurate. Even though ping-aware prediction is selected, you often have to lead the marker by a lot, not just a little in order to hit the target. There is something it is still not accounting for.

  • Client prediction (extrapolation) and interpolation are flawed in the same regard. I even sometimes have to lead ships slightly with Laser weapons in order to hit them. That is, if it even does extrapolation.

  • Ping is not accurate, as 130 can feel like 130, or it can feel like 500… Server processing time and response?

  • Average match queue timer is random. Never exceeds 1 minute, despite 20 minute queue times, and just randomly jumps between 16-36 seconds otherwise.

 

Hello) Some special modules can be activated several times and it’s not a bug in this case. When you firing Guided Torpedo, you can push the activation button again to blow it up after launch, at the moment you want. Pushing button twice may result in torpedoes exploding “in pilot’s face” right after the launch.

13 minutes ago, CinnamonFake said:

When you firing Guided Torpedo, you can push the activation button again to blow it up after launch, at the moment you want. Pushing button twice may result in torpedoes exploding “in pilot’s face” right after the launch.

I am not pushing the button twice, and neither are the people I observed in spectator mode. This is simply a network coding issue. I’m also quite familiar with how Guided Torps work, and it is not limited to them alone.

Most likely, the client has to maintain the ‘active’ state as a sort of toggle, and send the state with each packet. If the packet is not received, the server assumes deactivation. Other than that, not sure what the problem could be, but it occurs primarily during laggier sessions, pointing to a network/server issue, and not a client issue.

Can you write step-by-step manual for reproduce issue?

3 minutes ago, Skula1975 said:

Can you write step-by-step manual for reproduce issue?

  1. Play from North America on Euro/Russia server (because there are barely any games on NA server)

  2. Push Special Module button

  3. Watch as it randomly de-activates

It’s intermittent, and not reproducible except via test case.

Although, it would be simpler to check the network code, as I described to eliminate that possibility.

Please, if issue repeat, post game.logs and screenshot for issue

The problem is, I don’t play LRF or Tackler anymore (in T3 I did), where it’s most noticeable. ECM, recon, command and engineer special modules cannot be disabled in such fashion, and recon’s warp can only be disabled after a given duration (although recon should also be affected, I can’t recall ever having experienced the issue. Actually, maybe I did, as I vaguely recall being thrown from warp once without cause).

Actually, I didn’t play much LRF for that exact reason. Every few games I’d end up blowing myself up not once, but sometimes twice.

logs + screenshots needed

also would be well if you check your connection and post results here

 

[@Skula1975](< base_url >/index.php?/profile/239039-skula1975/) [@CinnamonFake](< base_url >/index.php?/profile/257821-cinnamonfake/) Just had a few games like this, so I thought I’d bring it up: Had to lead frigates by 1cm with lazors to get hitreg… ping 130 RU server (feels like 300). So, there’s no extrapolation (prediction) done by the client? That would explain some of the lead marker issues, but not quite all of them. This is quite common however, nothing out of the ordinary here besides the fact that lazors don’t register on target, and other weapons require lead by a mile to hit the target. Logs obviously not required. Client-side prediction is required. For interceptors, the effect is disastrous due to speed. Hits are random at best. Servers are just particularly laggy now, due to high load or congestion on upstream routers, exacerbating the effect, but it is noticeable for any ping above 30, I would imagine.

When your ‘hitscan’ lazors require you to lead the target, something is broken, or lazors need lead indicator…

Tracert (First 5 hops omitted, local network or ISP gateway):

Spoiler

  1     1 ms     1 ms     1 ms  omitted
  2    <1 ms    <1 ms    <1 ms  omitted
  3     6 ms     5 ms     8 ms  omitted
  4     6 ms     5 ms     5 ms  omitted
  5     6 ms     6 ms     6 ms  omitted
  6     8 ms     7 ms     7 ms  tcore4-toronto12_2-4-0-0_.net.bell.ca [64.230.10
4.164]
  7     7 ms     6 ms     7 ms  tcore4-torontoxn_hundredgige0-5-0-0.net.bell.ca
[64.230.50.13]
  8     6 ms     5 ms     6 ms  bx1-torontoxn_et4-0-0.net.bell.ca [64.230.97.159
]
  9     6 ms     6 ms     6 ms  level3_bx1-torontoxn.net.bell.ca [67.69.246.158]

 10     *        *        *     Request timed out.
 11   116 ms   115 ms   116 ms  br2.amsterdam1.surf.net [213.244.164.2]
 12   147 ms   147 ms   147 ms  ae6-6.rt.sl.spb.ru.retn.net [87.245.232.141]
 13   130 ms   130 ms   130 ms  gw-selectel.retn.net [87.245.228.222]
 14   132 ms   132 ms   132 ms  05.spb.net.selectel.ru [188.93.17.9]
 15   131 ms   130 ms   131 ms  node05st-ru.star-conflict.com [5.178.86.28]

The only router that ever dropped a packet was hop #11: br2.amsterdam1.surf.net [213.244.164.2]

I cannot get any metrics from hop #10, since it does not return any ICMP packets.

Here is hop #11 br2.amsterdam1.surf.net [213.244.164.2], while pinging the game server (5.178.86.28) with TTL=11:

Spoiler

Date/Time: 4/22/2017 10:21:51 AM Eastern Standard Time
Pinging 5.178.86.28 with 512 bytes and TTL 11:

Reply from 213.244.164.2: bytes=512 time=129ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=115ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=118ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=117ms TTL=11
Reply from 213.244.164.2: bytes=512 time=130ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=115ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=118ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=115ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=118ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=115ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=130ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=124ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=116ms TTL=11
Reply from 213.244.164.2: bytes=512 time=120ms TTL=11
Reply from 213.244.164.2: bytes=512 time=115ms TTL=11

TTLP statistics for 213.244.164.2:
    Packets: Sent = 50, Received = 50, >1000ms = 0 (0%), Lost = 0 (0%),
Approximate round trip times in milli-seconds:
    Minimum = 115ms, Maximum = 130ms, Difference = 15ms, Average = 117ms

Variance of 15ms, no dropped packets (there was only 1 earlier). I also ICMPd the RU servers, and there was no packet loss there, difference of about 15ms as well. Did a few more on hop #11, dropped 1 more packet, and a difference of 41ms, but that was only 1 out of a series of them.

Actually, that is just the Amsterdam server dropping its own ICMP responses.

Here is the summary for the game server (5.178.86.28) - 0% packet loss, 0.1% congestion >161ms:

Spoiler

TTLP statistics for 5.178.86.28:
    Packets: Sent = 1000, Received = 1000, >161ms = 1 (0%), Lost = 0 (0%),
Approximate round trip times in milli-seconds:
    Minimum = 130ms, Maximum = 166ms, Difference = 36ms, Average = 131ms

This doesn’t appear to be any different from any other time of day, so why is there massive lag and packet loss? Server load?

You know, I just realized where the server capacity went! If not for PvE, OS and Co-op modes, there would be more capacity to dedicate to PvP. ;o

edit: Also, module de-activation does not apply to Recon. You must strafe or roll apparently to exit the warp. Pushing the module button again does not cancel it. So, I have no way of testing that unless I decide to play Tackler/LRF in T5.

I just had another instance of a stationary Empire LRF, and a missile going directly through the hull, from rear to front, straight through the entire ship. I watched it happen as I passed him on the left after firing the missile from the rear.

I get the issue with Inhibitor crystal too.

Many times, I activate the modules during a packet loss. And when the connection comes back, the projectile exploded as intended ; but the client displays indefinitely that the module is “active”. And it stays “active” until I use it once again, even if I don’t use it for 5 minutes.

It may happen from time to time, when playing from NA. Some battles can be played on Ru or Eu servers, and that can lead to extended ping and packet losses.

[@CinnamonFake](< base_url >/index.php?/profile/257821-cinnamonfake/) If you take a look at my ICMP requests, there is zero packet loss, and zero congestion. The ping is stable at 130, as it always is (for RU, EU is 110, US is 45). However, during periods of heavy server load, it feels like 500 ping with 5% packet loss, but the ping is still 130 and 0% packet loss. Every indication points towards a server load issue and not a network load issue.

I just remembered the double-activation bug also applies to Guard Phase Shield. Sometimes it cycles twice, instead of once, wasting a LOT of energy and forcing a recycle. Thus, it affects at least 3 ship classes. I’ll probably quit before I test this though. P2W balance is just broken. You can only take so much abuse by imba ships before it gets tedious.