extreme lag considerations [O]

Bug Report Section Launcher, game client and connection issues
1

i’ve now been locked onto twice while using adaptive camo, once by a lrf, who tracked me behind a rock and then fired a shot. not sure if hack or 5 second lag? :\ no micro/drones.

 

i’ve also used flares on countless occassions only to have the missile hit me anyways, or the R8 armadillo movement immunity not kick in… 3-5 seconds after using them… again… not sure if lag or…

 

edit: oh, i’ve also seen LRFs moving around with scattering field still active… at full speed… (i’m guessing a packet was dropped or something? but this proves one thing: locking is indeed client-sided, and therefore hackable)

 

but it seriously needs a fix.

 

also, using the special module and it deactivates a split second later even though the button was pressed only once. especially effective with jericho torps - in your face :\

 

new server stats: 118 US (23.1%), 112 EU (22%), 280 RU (54.9%). 510 total… and RU/EU are climbing… still rare that i get US games…

 

almost no instances of 1v1 with bots though… not sure if coincidence… or fixed…

 

also, when using pulse lasers (or any lasers for that matter) i actually have to aim in front of the target (lead it)… hence my assumption that the lead marker does not correct for lag/latency. well, in the case of lasers, it can’t…

 

but it also doesn’t with other weapons. ie: with gauss on US server i can aim at the lead marker and hit, on RU/EU i have to aim in front of the lead marker. with a fast inty they become impossible to hit on EU/RU.

2

[This is a very important and vital information, that you should familiarize yourself with prior to posting bugs, please do read it.](< base_url >/index.php?/topic/15572-how-to-report-client-related-bugs/)

3
  1. Describe the bug in a few words/sentences.
  2. Why do you think this is a bug.
  3. How often does this bug occur.
  4. What was your last action/How to reproduce the bug.
  5. Detailed explanation of the bug.(Only if you need to add more information to 1.)
  6. Your system specs + Operating system as DX Diag.
  7. Videos + Screenshots (Only if needed, but in most cases they are helpful)
  8. ( Please only add the Logs and Exceptions of the game session where the bug occured, not all! )

 

  1. done

  2. obvious, it has to do with netcode/lag. some actions are not sent to client it appears, or vice versa.

  3. more often when there is lag

  4. i don’t see how to reproduce it… it happens randomly, more often when there is lag…

  5. not applicable

  6. my system specs are irrelevant, this is network behaviour, experienced by everyone.

  7. not required, explanations are obvious.

  8. there is nothing of interest in the log files.

 

thanks. finished. although i fail to see how this helped.

 

imo, the OP explains quite precisely what is going on:

 

A. put on EU/RU servers 75% of the time… US server only 25% of the time. that’s most of your lag there - MM related.

 

B. lead marker does not take ping/latency into account, must aim in from of the lead marker on EU/RU server. (not to mention all shots fire 0.5 secs later, meaning there is a processing time on server that is not reported in the ping).

 

C. some actions appear not to be sent to client/server… possible dropped packets, why survival modules dont work sometimes, or why you see lrfs moving with scattering field, or why people can target you in cloak… it’s client-sided… so you see something on your screen, but the server never receives it, doesn’t acknowledge, but client doesn’t need an ack for these client-side actions… which could also lead to the special module activating and deactivating again as well… not sure how that’s handled on the server.

4

if you want my theory on why the funny stuff with out-of-sync modules is happening, follow the thought in C. above.

 

modules are reported as actions to the client/server. when one is activated/deactivated, the client pushes a notice to the server which pushes it to other clients.

 

if the packet is never sent (as this is UDP) and i’m not sure whether you’re duping packets. technically you should send 2 of each packet (duplicate) in conditions like these where the server is overseas. it adds +100% overhead, but is the only reliable way to solve that problem.

 

the only fix i see (besides mitigating it slightly by sorting players to the appropriate regional servers, and duplicating packets):

 

is to report the state of each module along with the state/position of the ship when they are reported. an extra 5 bits 1,1,1,1,1 all on, or 0 for off. (technically, dont need 5 bits, can be done with 4).

 

for modules that don’t require a target, the server would pick that up as the trigger,

 

but for modules that require a target, the target would have to be a member of the actual module itself, which the server would have to query the client in the event that an ‘on’ state is detected.

 

anyways, it would require a complete rework of the code, as well as a bunch of other stuff i haven’t even bothered to mention.

 

but, even if you were to include all target info with the state/position of the ship, it would amount to only an extra 24-30 bits.

 

this guarantees that the correct on/off state is always available to the client/server even if a packet is dropped. and the server can always query the client for the info if it detects an on/off state change in a later packet, but no notice of the event prior.

5

As far as the LRF and scattering field are concerned, it only deactivates IF you input a directional command after its activated, so you could go full speed, activate the field, and drift in relative safety to your desired destination while you torp from a distance. For flares, if the flared missile still connects for whatever reason, it will still detonate. That can be due partially to lag, but also based on the missile’s flight path both before and after flares were activated. I am curious to know if unguided missiles are affected by flares, since flares are meant to deter guidance systems.

 

I am curious as to whether the Armadillo implant applies to all or only specific types of movement inhibition (slows from Tacklers, engine shutdowns, or disabled afterburners). Perhaps someone could go into detail?

 

Question about your situation with LRF and lock-on under camo: did you have an indicator denoting you were locked on, or is there a chance that the LRF simply followed your trail and correctly guessed your location?

6

Question about your situation with LRF and lock-on under camo: did you have an indicator denoting you were locked on, or is there a chance that the LRF simply followed your trail and correctly guessed your location?

This is usually the case. I’ve been playing a lot with Jericho LRF and it’s quite easy to predict playermovement, especially other LRF frigates. I usually get called cheater and such, but reality is, that some players rely too much on their modules to “hide” them. When I see an annoying LRF, I don’t stop until it’s dead, following it and predicting it’s every move. Even flares are only slightly annoying, they don’t really matter much when you’re dealing with an experienced player.

7

This is usually the case. I’ve been playing a lot with Jericho LRF and it’s quite easy to predict playermovement, especially other LRF frigates. I usually get called cheater and such, but reality is, that some players rely too much on their modules to “hide” them. When I see an annoying LRF, I don’t stop until it’s dead, following it and predicting it’s every move. Even flares are only slightly annoying, they don’t really matter much when you’re dealing with an experienced player.

I don’t think players realize that their afterburners give themselves away when fleeing or coming in for a sneak attack as well…

8

I don’t think players realize that their afterburners give themselves away when fleeing or coming in for a sneak attack as well…

Shhh! :stuck_out_tongue:

9

Shhh! :stuck_out_tongue:

Uhh I mean, I never can see an interceptor until its too late! Interceptors OP!

10

almost no instances of 1v1 with bots though… not sure if coincidence… or fixed…

Coincidence, I had one a few days ago.  I had an R7, two R8’s, and one R9 loaded.  The other guy took a T4 guard.

 

Shhh! :stuck_out_tongue:

I’ve tried it, but been unsure how well it works.  But I flown a cloaking ship in a while.

11

I’ve tried it, but been unsure how well it works.  But I flown a cloaking ship in a while.

Depends on the ship. Tackler + recon got true stealth, i.e. go completely invis. But a covops lights up like a beacon when afterburning while cloaked.

12

As far as the LRF and scattering field are concerned, it only deactivates IF you input a directional command after its activated, so you could go full speed, activate the field, and drift in relative safety to your desired destination while you torp from a distance. For flares, if the flared missile still connects for whatever reason, it will still detonate. That can be due partially to lag, but also based on the missile’s flight path both before and after flares were activated. I am curious to know if unguided missiles are affected by flares, since flares are meant to deter guidance systems.

 

I am curious as to whether the Armadillo implant applies to all or only specific types of movement inhibition (slows from Tacklers, engine shutdowns, or disabled afterburners). Perhaps someone could go into detail?

 

Question about your situation with LRF and lock-on under camo: did you have an indicator denoting you were locked on, or is there a chance that the LRF simply followed your trail and correctly guessed your location?

 

hmm, you’re right about the LRF scat field. although that’s not indicated in the description.

 

regarding missiles: nah, they’re guided/cruise missiles and flares just fail to function. unless flares have a maximum range, which isn’t stated in the description?

 

as for stasis generator and the R8 armadillo implant… again, bad description. it doesn’t prevent stasis movement debuff… it must be situations in which i’m using proton wall and the enemy has a mk1 stasis and i happen to be flying straight where maybe i think it works… no other explanation.

 

and the LRF that locked onto me, got a lock tone about 3 secs after using camo, so i looked up to status, only camo active - no micro/drones - was weaving between rocks, not at all visible to him in the first place. go around like the 3rd rock and before i even go around it, a shot was fired at me (and i saw the beam pointing right at my flight path)… didn’t even bother to look at lockon indicator.

 

some actions still seem client-sided. what the trigger condition is, i’m not sure… but they happen more often when lag is involved.

 

i’ve seen engineers warp without using a gate… it wasn’t destroyed… it never appeared in the first place… and dude just warps lol… and all sorts of things like that…

 

long story short (aka tldr) fix the lag.

13

may be of interest
 
 

Q. Why ships cannot fly in a straight line (clientside) when under heavy lag?

A. All flight calculations are handled by the server. At the moment of a lag spike, the client tries to calculate the flight trajectory without the server’s help. When the correct information finally reaches the client, the trajectory is changed to reflect the situation which may result in a sudden “jerk”. This is why the trajectory may become jagged.

 

 

Regular FPS games, everything is done clientside and sent over for server to sort the mess out. hit detection etc. SCon is apparently server dependent and it’s safe to assume EVERYTHING else also works that way including turret facing, active modules and rockets.

 

Which explains almost everything we’re having problems with. Assault rails not shooting where we aimed it at, rockets, coil mortar jamming, wobbles etc. Probably why they decided to take out switchable ammo and missiles too if I’m allowed to guess. Imagine 24 idiots spamming the toggle switch non stop lol.

 

Pros and Cons - we dont suffer teleportation so much (unless difference in latency is huge between you and everyone else ie. your 50ms vs 300ms average)

We also never get WTF-killed by people who popped in and out too fast for our client to see. Or delayed crosskills that is so common in other shooters where you killed the other guy, ran inside a building and died on the way going up the stairs from a headshot by the same guy you killed 3 seconds ago. etc.

 

Cons would be those things you listed in OP ofcourse

 

You activating a module, server says he didn’t get the memo 1 second later.

You launching a torpedo, server says you manually detonated it - right in your own face

That thing with coil mortar - look left, no firing solution to target, look forward directly at target, gun jams coz server says you’re still looking left and no firing solution

 

I have issues with Assault Rails and rockets and dealt with them since before this patch which Zap seems to think is patch specific. I would roll and turn then open fire at a target when lined up but Assault Rails decided to shoot slightly off - exactly where I had the cursor at 0.5 seconds ago etc. Same deal with rockets. (EM Torps seem unaffected tho)

 

My theories anyway. Active modules could work differently than how I assume it does and something else is causing all this junk. But prognosis fits the symptoms.

14

(aka tldr) fix the lag.

or let client handle some of the load

15

Putting everything server side helps minimize the risk of cheaters.  It’s still possible of course, but a little harder.

16

  1. done

  2. obvious, it has to do with netcode/lag. some actions are not sent to client it appears, or vice versa.

  3. more often when there is lag

  4. i don’t see how to reproduce it… it happens randomly, more often when there is lag…

  5. not applicable

  6. my system specs are irrelevant, this is network behaviour, experienced by everyone.

  7. not required, explanations are obvious.

  8. there is nothing of interest in the log files.

 

  1. Ok

  2. Not obvious as its not been checked on our side.

  3. Possibly

  4. Understandable

  5. Agreed.

  6. Negative, this is required for the troubleshooting process.

  7. Agreed, and not mandatory anyhow.

  8. Negative, this is required for the troubleshooting process.

 

You want help with stuff, we need this information to be able to help you, regardless of if you think it helps or not.

 

You can refuse the information we need to help you, but then we wont have the information needed to help you, thus… are not able to help you.

 

Your choice.