It is currently Sat Jun 06, 2020 2:02 pm

All times are UTC-04:00




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Fri May 08, 2020 1:29 pm 
Offline
User avatar

Joined: Wed May 01, 2019 10:39 am
Posts: 29
It seems the answer is lag compensation.

Before lag compensation was invented if you had a low ping you would destroy anyone with a high ping. Due to those high ping players leaving the game and developers seeing those high ping users stopping purchasing their games as they cant compete developers came up with lag compensation in a bid to even the playing field and get game sales back up.

And while the high pingers can now play without getting destroyed and developers see an increase in sales and will tell you it all works great,
In reality all they done is turned the tables on low ping players and gave the high ping user the advantage due to the stupidly high algorithm that allows users with 2/300 ping to run around and dominate in their safe little lag comp bubble while those with low ping get artificially gimped resulting in a bad game experience.

Its all about allowing as many users with whatever kind of stupidly high ping they have to buy the game and play without getting destroyed by users with better connections thus the high pinger will be more likely to continue playing.


Top
   
PostPosted: Fri May 08, 2020 1:44 pm 
Offline

Joined: Wed Jan 11, 2017 2:41 pm
Posts: 198
Image

Well that low ping/high kill rate theory seems to be working well for you...

_________________
iMac 27"
3.4GHz Intel Core 7
16GB DDR3
Nvidia GeForce GTX 680MX 29048MB
OSX 10.13.6


Top
   
PostPosted: Fri May 08, 2020 1:56 pm 
Offline
User avatar

Joined: Wed May 01, 2019 10:39 am
Posts: 29
Solutions to lag and lag compensation methods

There are various methods for reducing or disguising delays, though many of these have their drawbacks and may not be applicable in all cases. If synchronization is not possible by the game itself, the clients may be able to choose to play on servers in geographical proximity to themselves in order to reduce latencies, or the servers may simply opt to drop clients with high latencies in order to avoid having to deal with the resulting problems. However, these are hardly optimal solutions. Instead, games will often be designed with lag compensation in mind.[6]

Many problems can be solved simply by allowing the clients to keep track of their own state and send absolute states to the server or directly to other clients.[7] For example, the client can state exactly at what position a player's character is or who the character shot. This solution works and will all but eliminate most problems related to lag. Unfortunately, it also relies on the assumption that the client is honest. There is nothing that prevents a player from modifying the data they send, directly at the client or indirectly via a proxy, in order to ensure they will always hit their targets. In online games, the risk of cheating may make this solution unfeasible, and clients will be limited to sending relative states (i.e. which vector it moved on or shot in).
Client-side

As clients are normally not allowed to define the main game state, but rather receive it from the server, the main task of the client-side compensation is to render the virtual world as accurately as possible. As updates come with a delay and may even be dropped, it is sometimes necessary for the client to predict the flow of the game. Since the state is updated in discrete steps, the client must be able to estimate a movement based on available samples. Two basic methods can be used to accomplish this; extrapolation and interpolation.[7]

Extrapolation is an attempt to estimate a future game state. As soon as a packet from the server is received, the position of an object is updated to the new position. Awaiting the next update, the next position is extrapolated based on the current position and the movement at the time of the update. Essentially, the client will assume that a moving object will continue in the same direction. When a new packet is received, the position may be corrected slightly.

Interpolation works by essentially buffering a game state and rendering the game state to the player with a slight, constant delay. When a packet from the server arrives, instead of updating the position of an object immediately, the client will start to interpolate the position, starting from the last known position. Over an interpolation interval, the object will be rendered moving smoothly between the two positions. Ideally, this interval should exactly match the delay between packets, but due to loss and variable delay, this is rarely the case.

Both methods have advantages and drawbacks.

Interpolation ensures that objects will move between valid positions only and will produce good results with constant delay and no loss. Should dropped or out-of-order packets overflow the interpolation buffer the client will have to either freeze the object in position until a new packet arrives, or fall back on extrapolation instead. The downside of interpolation is that it causes the world to be rendered with additional latency, increasing the need for some form of lag compensation to be implemented.
The problem with extrapolating positions is fairly obvious: it is impossible to accurately predict the future. It will render movement correctly only if the movement is constant, but this will not always be the case. Players may change both speed and direction at random. This may result in a small amount of "warping" as new updates arrive and the estimated positions are corrected, and also cause problems for hit detection as players may be rendered in positions they are not actually in.

Often, in order to allow smooth gameplay, the client is allowed to do soft changes to the game state. While the server may ultimately keep track of ammunition, health, position, etc., the client may be allowed to predict the new server-side game state based on the player's actions, such as allowing a player to start moving before the server has responded to the command. These changes will generally be accepted under normal conditions and make delay mostly transparent. Problems will arise only in the case of high delays or losses, when the client's predictions are very noticeably undone by the server. Sometimes, in the case of minor differences, the server may even allow "incorrect" changes to the state based on updates from the client.
Server-side

Unlike clients, the server knows the exact current game state, and as such prediction is unnecessary. The main purpose of server-side lag compensation is instead to provide accurate effects of client actions. This is important because by the time a player's command has arrived time will have moved on, and the world will no longer be in the state that the player saw when issuing their command. A very explicit example of this is hit detection for weapons fired in first-person shooters, where margins are small and can potentially cause significant problems if not properly handled.
Rewind time

Another way to address the issue is to store past game states for a certain length of time, then rewind player locations when processing a command.[7] The server uses the latency of the player (including any inherent delay due to interpolation; see above) to rewind time by an appropriate amount in order to determine what the shooting client saw at the time the shot was fired. This will usually result in the server seeing the client firing at the target's old position and thus hitting. In the worst case, a player will be so far behind that the server runs out of historical data and they have to start leading their targets.

This is a WYSIWYG solution that allows players to aim directly at what they are seeing. But the price is an aggravation of the effects of latency when a player is under fire: not only does their own latency play a part, but their attacker's too. In many situations, this is not noticeable, but players who have just taken cover will notice that they carry on receiving damage/death messages from the server for longer than their own latency can justify. This can lead more often to the (false) impression that they were shot through cover and the (not entirely inaccurate) impression of "laggy hitboxes".[7]

One design issue that arises from rewinding is whether to stop rewinding a dead player's lagged commands as soon as they die on the server, or to continue running them until they "catch up" to the time of death. Cutting compensation off immediately prevents victims from posthumously attacking their killers, which meets expectations, but preserves the natural advantage of moving players who round a corner, acquire a target and kill them in less time than a round trip to the stationary victim's client.

Rewinding can be criticised for allowing the high latency of one player to negatively affect the experience of low-latency players. Servers with lag compensation will sometimes reduce the length of player history stored, or enforce ping limits, to reduce this problem.
Trust clients

It is possible for clients to tell the server what they are doing and for the server to trust the data it receives. This method is avoided if at all possible due to its susceptibility to cheating: it is a simple matter to route network data through a second computer which inserts fabricated hit messages or modifies existing ones, a technique which cannot be detected by anti-cheat tools.[7]

However, the sheer scale of some games makes computationally expensive solutions like rewinding impossible. In Battlefield 3, for example, a "hybrid hit detection" system is used where clients tell the server that they hit and the server performs only a vague test of plausibility before accepting the claim.[8]

Trusting a client's results otherwise has the same advantages and disadvantages as rewinding.
Make clients extrapolate

A less common lag solution is to do nothing on the server and to have each client extrapolate (see above) to cover its latency.[9] This produces incorrect results unless remote players maintain a constant velocity, granting an advantage to those who dodge back and forth or simply start/stop moving.

Extended extrapolation also results in remote players becoming visible (though not vulnerable) when they should not be: for example if a remote player sprints up to a corner then stops abruptly at the edge, other clients will render them sprinting onward, into the open, for the duration of their own latency. On the other side of this problem, clients have to give remote players who just started moving an extra burst of speed in order to push them into a theoretically-accurate predicted location.
Design

It is possible to reduce the perception of lag through game design. Techniques include playing client-side animations as if the action took place immediately, reducing/removing built-in timers on the host machine, and using camera transitions to hide warping.[10]


Top
   
PostPosted: Fri May 08, 2020 2:16 pm 
Offline
User avatar

Joined: Wed May 01, 2019 10:39 am
Posts: 29
Pakrat,

It should be easy to test by using different servers with different latencies and let us know how it works.

Let;s say playing with 400 ms vs 60 ms latency. Are you in for the test?


Top
   
PostPosted: Fri May 08, 2020 5:19 pm 
Offline
User avatar

Joined: Wed Jan 11, 2017 12:55 pm
Posts: 105
So the guy who is always at the top of the scoreboard is complaining that his score isn’t high enough because of lag. LoL.

What 672 kills or whatever you have aint enough? “ Yeah but but but that one guy that shot me down. He cheated! “

Thanks for that. Made my day.


Top
   
PostPosted: Fri May 08, 2020 6:13 pm 
Offline

Joined: Mon May 07, 2018 1:44 pm
Posts: 49
Location: Kamikaze Empire
I'm sorry my connection has been poor the past couple of months. Usually it improves after a few days/weeks but this time it persists so I'll change ISP and see. I'll have new connection next week.


Top
   
PostPosted: Fri May 08, 2020 6:56 pm 
Offline

Joined: Wed Jan 11, 2017 2:41 pm
Posts: 198
This game was developed with a 28k, 33k, 56 dial up modem connection as the norm. I have played WB on all of those plus DSL, and hi speed cable today yet still suffer from congestion on the net and bad servers between me and IEN. Years ago they used to publish the IEN server addy so you could do a traceroute and see which hops were bottlenecking your conx and then contact that ISP to report a throughput blockage at their hop..Sometimes they actually fixed it too..But you were always at their mercy as gaming conx's werent really on the top of their list of things that they prioritized....No matter which connection method I have used, the lag incurred has always been due to some fucked up servers along the way. You never get the same ones every time.. Some days its clean and some days its dirty. Depends on where you live and how good your providers network is and also if there is any storm activity along the way...Since neither are adjustable on the users end, you gotta run what ya brung so to speak. Everyone would love the fastest best connection possible all the time.. But thats not realistic so we have to use that which we have when we log in for the day.. Its not the players fault so stop trying to tie it to fairness..

_________________
iMac 27"
3.4GHz Intel Core 7
16GB DDR3
Nvidia GeForce GTX 680MX 29048MB
OSX 10.13.6


Top
   
PostPosted: Fri May 08, 2020 8:50 pm 
Offline

Joined: Tue Jan 10, 2017 12:48 pm
Posts: 714
I believe Jitter is the biggest problem with your route to get to iEnt's servers right up there with it. I'm under 60 ms to just about everywhere I go and jitter is mostly at zero with 1 sometimes. BUT the trunk line to iEnt's server goes through DC and well that's where I get pinched I'm quite sure. The problem though isn't in the downstream as that's always seems more stable, but the problems will always show upstream. So your guns seem ineffective, but their guns appear basketball size For whatever reason this seems to be the case, but then I could be full of feces!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC-04:00


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited