Question about clientside

Discussion in 'PlanetSide 2 Gameplay Discussion' started by Teneth, Aug 22, 2014.

  1. Teneth

    I heard once that the clientside issues were unavoidable because of how many people are involved in large fights. Does anybody know if that's true or if Sony ever talked about it? I guess I was wondering whether it was fixable or something that was too ingrained in the code to fix.

    And by clientside, I mean the lag delay that happens everywhere in the game. The most clear example of it is when you turn a corner and still die because the other player hasn't seen you turn the corner yet. Anyways, just wondering,

    -Teneth
  2. Goretzu

    Well you can't beat Physics, unfortunately.

    So clientside becomes the least worst option in an MMO.

    Having said that it is something that gets much better and worse, currently on the EU servers it is pretty bad in large fights, but then after their inital optimizations passes it seemed to be much better.

    Certainly I think they can make it much better from its current state, although whether that is code, hardware or both I don't know, but hopelly with the PS4 code being combined it will be in their interest to get the PC version running at peak efficency.
    • Up x 1
  3. Alzir

    It's too in grained in the code to change I'd guess, but it doesn't just have the negative side effects for a player as you use in your post (apologies work PC won't allow me to reply directly to OP).

    Play aggressively and clientside works to your advantage....you peek a corner and the passive player on the other side doesn't see you for the split second it takes for the client to update respective positions.
  4. Aaren


    What is it with people and "physics"

    If feels like everytime there is a discussion of networking in relation to games - someone feels the need to say "physics" or "the speed of light" as though that somehow explains everything.

    In regards to improving lag compensation or hit confirmation in order to improve player experience. It's certainly do-able. Many other games have managed to have functioning hit detection, despite large player counts, or client centric lag compensation. Red Orchestra, World of Tanks and ARMA all come to mind. The problem is simply, what sacrifices are made to acheive that goal.


    Actually that delay, has little to noghting to do with "clientside". If this is something you're not particularly knowledgable on, there's a nice succient explanation over here: http://forums.tripwireinteractive.com/showpost.php?p=1046708&postcount=11
    Full thread is here: http://forums.tripwireinteractive.com/showthread.php?t=77077


    That delay, is 300-700ms of additional dsync or latency that PS2 appears to have for.....some....reason. It's not wholly attributable to clients ping, as then it should equally affect both people in an engagement as packets have to travel from the shooter to the victim and back. That aside, multiplayer games have long been designed with lag compensation - specifically to prevent players gaining any sort of advantage or penalty from their ping to the server (within reason).

    PS2's lag compensation is currently having issues, partially broken, or absent completely depending on your experience, and while issues are expectable for a game of this scale - that doesn't excuse systematic dysfunction.
    • Up x 4
  5. Goretzu

    Sorry I hadn't realise you'd solved that problem, congratulations, you'll be looking forward to your nobel prize next year then! :)

    The reality is though that is what it comes down to, even if it were fibre from your CPU to their CPU and everything in between (which it is very much not).

    These problems will improve as technology improves (as they in fact have since modern MMO first appeared in the later 90's), but they'll never entirely go away.




    The idea that you can "somehow" get rid of the issues mentioned in the OP by some magic code or other method is plain unrealistic.

    You may as well be asking for a flying car piloted by a talking pig........ someday, maybe...... not today and not soon though.



    The reality is they can be optimised and improved upon as PS2 did, but which seems to have slipped quite a bit since they concentrated on the PS4.

    WAR was a good (and bad) example of this, it had serious problems on release, by 2 years in it could support 400 vs 400 battles reasonably well (unfortunately it was too late to make the game a success).
  6. Alzir

    I think you may need to explain this a little more for me, as that thread didn't add anything to my understanding, which is as follows:

    I see a target on my screen and any hits are passed on to the server to pass on to the guy I shot, who may on their screen have already rounded a corner....they get hit and die. Passive player sits on a flag covering a door, while aggressive player slow peeks the corner so that they have their sights on the target as the target comes into view - with no latency they'd see each other at the same time, but with latency the passive player doesn't see the aggressive player yet because the aggressive player's actual position has not yet reached passive player's client. In the meantime, the passive player is sat in the same spot, so aggressive player's client has an accurate location for them, and he gets a tiny fraction of a second to fire first.

    Is this not quite right?
  7. Risae

    Just gonna post this here

  8. Aaren

    I continue to fail to see why some people think the speed of light is relevant in the limits of current day computer networking.

    Would having FTL communications reduce the delay inherent in current networks? Of course...but in the case of gaming - few games fully utilize a connection to it's peak. The amount of data that is sent between the client and server - is rarely significant in comparison to say, downloading or uploading files, or streaming video.

    Yes current networks have an inherent delay - but even with a ping of 200ms, a client is 'only' 0.2 of second behind the server. Even if you were to add an additional 50ms for hardware interference (input lag and such) that's still 0.25 of second. The Human Benchmark project has recorded 215ms as the average human reaction time to predicted stimuli. Most people's base reaction time is even longer - around 350ms or so. What this means is that only in the case of two players connecting to an intercontinental server - are likely to run into a net connection delay significant enough to cause issues with simultaneous interactions.

    The reality is - that client's, particularly in games, and servers - are the more common cause of issues with desync or gameplay delays. The time it takes for a machine to interpret the packets it receives - process the data, then render it on screen, process the players input, and return the information to the server - is where the bulk of the delay lies - and that is solely a software optimization issue. If your engine cannot seamlessly simulate your gamestate - and update and receive packets to populate it - you have issues somewhere. In 2014 we have multi-threading, we have on-board NIC's and direct cache addressing. If your gamestate is too complex, simplify it, if your packetflow is too heavy - consider only sending data that is absolutley nessacary. Most dev's are more than capable of understanding this - yet every now and then, someone pulls a Battlefeild 4, and tries to do something silly, like streaming physics between the client and server.

    Most developers use some form of buffering or lag compensation to try and mitigate this. Valve's Source engine, while hardly perfect - uses an interesting hybridisation of lag compensation, input predication and entity interpolation - an upshot of which is that both client and server's simulation is 100ms behind of the "actual state", this facilitates the server's ability to confirm damage as valid from both clients perspectives - before authorizing the kill.


    No system is perfect, faster than light or otherwise. But PS2's current system is increasingly incapable of reliable and consistent preformance. At least in my own personal experience. Enemies routinely ignore damage, exploit their connection to gain an advantage, or exhibit damage compression. The constant problem of damage being delayed or flat out ignored points to a lack of, or significant issue with - any server validation, and the issue of clients falling far enough out of sync - to damage enemies beyond their line of sight - suggests there is little to no interpolation or lag compensation.

    Yes PS2 is a difficult case by it's sheer scale. But that only makes it all the more vital that all that can be done, is done - to minimize the effect of trying to co-ordinate so many. Even if that means certain limitations or sacrifices have to be made. I hope the devs are working on this - I really do. Because I've seen thread after thread on these forums, and all we ever seem to get is a "we're investigating it".

    RadarX over on Reddit stated that:
    And without turning this into a discussion on who said what, when and where - I have to absolutely disagree. The only thing that will keep people interested in your game, when some experience gameplay that is flat out dsyfunctional - is the assurance that it will be fixed ASAP. Unless you explicilty give examples or insight into how you are working on a solution - few are going to see vague 'assurances' every couple of months, as indicative of anything other than damage control.

    Lets agree to hope to see a working solution for PS2's network prefomance as soon as possible then. Before it suffers WAR's fate.
    • Up x 3
  9. Aaren


    I'll do my best. I don't pretend to be an industry expert or anything, but I've been wrestling with this concept for years.

    The reason this happens ^
    Is because of a lack of any form of authoritive lag compensation. In the Source system for example (which I am more familar with) - the server keeps a record of the game state up to 300ms in the past. When your damage packets reaches it - it quickly "windsback" or checks that anywhere in those past 0.3 seconds, you could have seen, and hit your target. If so - it passes the damage information onto your victim.

    But in PS2 - the server appears to do nothing like this. All damage is applied to all players, regardless of their synchronization with each other. This is why it's possible for you to damage someone when on their screen - they've already made it to safety. The issue isn't "client side hit detection" but rather "lack of lag compensation" it's largely just a matter of terminology, and an understandable sacrifice for PS2's scale.


    This is a different scenario all together, and one I'm still struggling to see the 'advantage' in.

    This video deals with Call O Dooty and consoles - but the concepts discussed are identical: https://www.youtube.com/watch?feature=player_detailpage&v=xyCQtUFOJmA#t=857

    Yes - in the case of a player peeking around a corner - with their opponent sitting still - the aggressor has an advantage - moreso the longer the delay between the two enemies. However in other circumstances - the aggressor is at a disadvantage - The longer the sum ping (delay) between two enemies, the more likely you are to be shot after taking cover on your screen.

    Referring to the video however - you'll notice that in a straight, face to face confrontation - the player with the lowest ping, will have an advantage, as their damage will reach the server before their enemies. The problem with PS2 however, is that damage does not appear to be authorized by the server. Your damage packets have to reach the server - then your opponent directly - and if they have high ping, it will take your damage just as long to reach them, as it takes theirs to reach you.



    The problem I personally have with this - is that the majority of the time I'll notice my enemy before they see me - get 4-7 hit markers on them - then die instantly from seemingly a single bullet. Now on their screen, they may have seen and shot me too. But that damage should be delayed by the overall ping between us - not compressed into a single instant for some reason. That indicates that the server (or the clients) in PS2 is attempting some form of lag compensation - which is precisley what it's not supposed to be doing.


    Long and short of it is - I have no clue what on earth is going on with PS2. It seems to have the downsides of both systems, with none of the upsides. Whether lag compensation is done server side, or clientside, players with better connections should have the better overall experience - yet even with only 7ms to the server (28 ingame) the game is mostly unplayable for me.
    • Up x 1
  10. Zotamedu

    How is human reaction time relevant here? That's another delay on top of the transfer delay. It is not as well as server delay.

    So a very basic version would be this. A player peeks around a corner and see another player. 200 ms later he starts shooting. On the other side, 200 ping away, the other player sees the first player at the same time as he starts shooting on his end. Then 200 ms later he can start shoot back. If there were no client side hit detection or lag compensation. The one who peeked around the corner would easily win the fight because he had the difference in ping extra to react. Lag compensation introduces a delay to even that out. Then it's the same 200 ms reaction time for both players so there's no problem. The problem is difference in latency, not the absolute latency. So reaction time is highly irrelevant in this discussion.
  11. Aaren


    It's relevant as you cannot begin shooting at a target until you see them. And if the advantage offered by a poor connection (Roughly 200ms) - is more than the average reaction time, your victim won't have the opportunity to even begin firing back, before they are already dead. That's all.

    Lag compensation dosn't simply introduce a delay, otherwise as you say - it would have little to no impact - simply make things feel even more unresponsive. What it attempts to do is nulify the effects of the total ping between two players. Hence compensation. This can mean anything from ensuring that playermodels and hitboxes are as in sync as is possible - to preventing players from better or poorer connections from suffering advantages or disadvantages - to ensuring that all players can interact with the gameworld seamlessly (not have terminals ignore their input for example). Interpolation (or extrapolation) smoothes entity movement, so your enemies appear to you, roughly where they see themselves on their screen - removing the advantage or disadvantage of a high total latency.

    The problem in PS2 is not difference in latency. It would be - if the server was providing authoritative lag compensation - but it supposedly isn't. If it were, the person who could get their packets to the server first (best connection) would win every time, as any packets arriving afterwards would be discarded - as the server would have already flagged the victim as dead. However as it stands PS2 currently seems to have no damage invalidation and packets have to travel the full length of the total latency between two players. Thus - reaction time is relevant - as commonly, two players on a PS2 server will have a sum latency higher than 400ms - allowing one player to see, react and kill a player before they even round the corner on their victims screen.
  12. Goretzu

    And I fail to see why you think Physics is just about the speed of light. :confused: I guess we both need eyetests.

    Indeed, but as I said even if you had perfect connection from CPU to CPU it wouldn't make the issue go away, and of course we don't have that.

    And of course it's not even about A signals delay, but rather about many signals and their comparrative delays and their interaction with each other (and this is before we every get to server issues directly).





    All of which is still ultimately control by Physics. :confused:
    Or are you saying code (indirectly), servers and the technology there are built on somehow isn't?

    You can add artifical lag to try and synch certainly, but it's a very different ball game when it's a few people in Team Fortress and a few 100 people in PS2.
    To do this in the manner suggested in the OP you'd actually probably need a time-machine for it to be effective (just a small Physics problem to solve in that case).

    I suspect that recent problems have been down to simply not having enough maintance done on PC game.


    They don't seem to have been doing much probably due to the PS4 issue, now they don't (or shouldn't soon) have that issue, and should be able to concentrate on fixing and maintaining performance levels at least at the levels the game has seen before.
  13. Tricycle

    Player A is being shot at by player B. Player A runs into a building through the doorway and turns left immediately after entering it to find cover, but he dies there fraction of a second later. His corpse is behind the cover so he feels the death was unjustified.

    If player A has, say, 5ms latency then it is safe to say that the player B has something like 300ms latency. In other words the player B sees where the player A was 300ms before, not where he currently is. He saw A at the doorway where he killed him, but in reality he was already behind the cover.

    Alright, so how exactly do you guys think you could overcome this problem without creating a time-machine? I see fancy words like lag compensation. What does that do? It predicts? So instead of sending the received location information of A to the B, the server predicts where A will be after 300ms in order to compensate B's lag and it sends that info to B instead. Player B's client will then place A closer to the real location. Since the server knows how A has moved recently it is pretty easy to predict the movement. However, when A enters the building and makes the sharp turn to the left the server could have not predicted it 300ms before it actually happened. This means B will see A entering the building and keeping on moving forward after the doorway while his back is facing the doorway. When the information of the turn arrives the character warps to the left behind the cover in B's screen. Player A would have died to the same place just like before, because the server couldn't have seen in the future to predict the quick left-turn to the cover. So this kind of prediction does not really work, does it?

    It's possible that I'm overlooking something so could you tell me how exactly do you think SOE could ever fix this, because I think this is unfixable without the time-machine of course. :)
  14. Aaren


    You're right it isn't easy, or even vaible - but the method you outline of predicting the players positions is predictive- or extrapolative. It attempts to make guesses as to where A will be in the future. This is generally exeedingly diffucult and rarley accurate.

    Again, as Source is what I mod for - that's what I'm familiar with, and the way Source gets around this - is by using interpolation inststead of extrapolation. Where extrapolation tries to predict where a player is going based off of the most recently aquired packets. Interpolation works in reverse. Source clients default to run 100ms behind realtime but broadcast and receive a new packet every 50ms. This way if there is some packet loss - and one packet is lost - the client can still render smooth movement - as there is always at least two availible packets to figure out a starting and end point.

    So player B will always see player A run into the building and duck out of sight. It may not be the exact path that A took on their screen, but it is functionally sufficient to avoid A receiving damage when they are out of sight.

    Interpolation obviously also has its downsides - everyone is running in the past - so now it's even easier for someone to be shot around or through cover from their perspective. The way source combats this - is by having the server authorize damage. The server keeps a 300ms buffer or history of the gamestate, and whenever someone sends a kill request - the server ''winds back" the position of the two players involved - and verifies that the attacker had a clear shot on the victim. If that is the case - the damage is sent on to the victim. Of course this places a greater load on the server - and in the case of PS2 may simply be impractical - but it's a system that works in nearly every scenario. It is possible to do without a time machine.

    In the case of PS2 I can't rightly say what needs to be done to fix the current problems - it seems if nothing else - that some degree of damage validation is necessary. So that enemies will stop damaging you after you have already killed them from your perspective. If your packets only had to reach the server to earn a kill - and not the round trip of all the way to your victim - you wouldn't get one-shotted by people who suffer from high ping or packet delay. Of course - this would make it harder for people with higher pings to play the game - but honestly, that is how it should be. That is why we pay to support servers in our regions - or shell out money for good ISP's.
  15. Prudentia

    all of you forgot the most important part:
    Planetside 2 scaled down to a 5Hz Tickrate a while ago. while this does reduce the amount of data the Servers have to calculate, it also increases lag by a fair bit. to be precise, every data you send to the Server has a delay between 1 and 200ms.
    and it Looks like not only Clients have FPS Problems, the Server too often struggles to process data within a 200ms timeframe so hit detection and movement prediction are getting worse and worse
  16. Brad2810

    Client-side? oh...you mean landing a scythe on a random piece of floating architecture (500m up) and getting out, and shooting at your team-mate who has done the same thing and appears to be running on thin air?

    I see no problems! :D
  17. Aaren


    Where does everyone keep pulling this stat from?

    Whether we can beleive SOE or not - they have explicitly said:

  18. Tricycle


    Say, player A survived the dash to the cover. Then he peeks through the doorway, shoots B and quickly moves back to the cover. By the time the 300ms lagger aka player B sees the maneuver player A has already returned back to the cover on his screen. While B sees A's movement he manages to deliver a fatal head shot. Now, I suppose you mean the server will then wind back 300ms so that it can verify where A was when B fired the gun. Actually, why is this verification necessary? All it will realize is that A was standing in the doorway 300ms ago and the hit was legit. It's practically the information B's client already knows. It plotted A to the doorway, so where else would it be?

    Or do you mean that the server will check A's position when B fired the gun without compensating the latency? In that case player A is obviously in cover and B's shot was a miss. However, let's think about this for a moment. How can B ever hit A in such situation? It would be impossible for him to do that. He would always miss. Unless ofcourse he can see in the future and he will then fire the gun at the empty doorway exactly 300ms before player A moves there.

    I still don't quite see how you could ever fix this. Could you give me an example of how you think it could be done?
  19. Aaren

    The 300ms, is a serverside mechanic. Not B's ping. And I was wrong, the default and maximum value is 1000ms or one second. Clearly the buffer system only works if a clients ping is less than 1000ms, otherwise there will be no data for the server to verify - it will take too long to reach the server.


    Okay - I think we're going to have to re-establish the scenario we're using, don't worry - I brought some diagrams :)

    Lets say, player B has 200ms to the server, while player A has 5ms. Player A is doing their ducking routine - they have run through a doorway, and ducked behind cover. Meanwhile B is watching that doorway, waiting for them to reappear.


    The server's see's player A as 5ms behind where they see themselves on their screen - while B is 200ms - simply by virtue of their connections. As for seeing other players - both A and B have an additional 100ms added to their representation of their enemies locations - as part of Source's interpolation system.

    [IMG]

    In other words, A's path of movement behind the cover (doorframe) - is not streamed directly to B's client.

    B receives 2-3 packets telling their client "A was at this point, then this one, then this one" and smoothly animates A's motion across those points.

    This prevents errors of perspective - as both players are not seeing the "true" position of their enemy or their movements. They are seeing their "echoes" smoothed along a calculated path. BUT. This is not a network restriction. Once A and B have seen their delayed perspectives of the situation - any actions they take will be broadcast back to the server at their respective pings. In other words - it will take either client (their ping+100ms) to see anything, but only (their ping) to send their reaction to the server. This helps in the case of packet loss - but it also normalizes the difference in A and B's perspectives - by always ensuring they are both behind what the server sees.


    The reason for the server windback - is the inherent difference in perspective between the two players's perspective and the servers. Things are about to get complicated, as we have to simultaneously consider 3 perspectives, but this diagram should help:

    [IMG]

    There's a lot going on here, so lets break it down:

    • The red icons - are the servers perspective. Green is B's, and lavender is what A sees.
    • The arrows indicate B's shot(s) at A.
    • As you can see - from both A and B's perspectives - they are ahead of where the server considers them to be. For A this is a fairly minor difference as A's ping is only 5ms. But for B this discrepancy is larger, as their ping is higher, it takes their packets longer to reach the server.
    • However - it takes the same amount of time for both A and B's packets to reach each other. So B see's A 305ms in the past, and A see's B, 305ms in the past.
    Hopefully now it should begin to be clear what the problem with this scenario is. From B's perspective - A is outside the building and in clear line of fire. However A is closer to the servers perspective at least in terms of their own position - and dosn't see B at all - because on A'sscreen, Bis 305ms back in the past, running up the path or something.
    The server meanwhile - has a somewhat averaged view of things. It only takes 5ms for A's position to reach it - but it takes 200ms for B's positional packets to arrive - so meanwhile, B could have run off somewhere.

    The problem comes in trying to reconcile these three different perspectives. Who Is correct? In Source's system - the server is given that authority. But if the servers perspective was simply treated as the only true one, and left at that - B would be cheated out of any damage, despite having clearly shot A on their screen.
    This is where the "compensation'' part of "lag compensation" comes in. The 1000ms buffer or 'windback', is used to resolve the confliction between these three seperate realities.

    The server - will now move A and B back along their respective paths for 1000ms and see if at any point in time, B could have indeed shot A. In the case of our scenario, there is a window of opportunity when B could have gotten A - about 305ms back, when they both saw the other out in the open. The server will then start to apply B's damage to A - and move time forwards. It is quite likely in our particular example - that over 305ms or so, both A and B will loose sight of one another as they move into the servers's most up to date positions for them.

    Unless B's weapon can kill a player in under ~305ms, assuming all of their shots were on target - A will receive some damage - but most likely escape unharmed. B will see they managed to hit A - but will probably have expected to kill them outright - while from A's perspective they will receive damage delayed after running behind cover.

    The bigger the ping difference between the two players - the less damage B will see and the more A will feel as though they are being shot through cover, or receiving damage after an unreasonable delay. But by using the buffer, the server has prevented even stranger behaviour - such as A suddenly dropping dead behind cover. Or B emptying an entire magazine into A - only to have them walk away unscathed.


    Of course the issue with Source's system - is that, because of the interpolation and windback - the effects of higher ping are almost exponentially worse - and once the mean ping between two enemies is beyond 1000ms - the server will be unable to windback far enough to reconstruct anything. The buffer is also understandably demanding on the server - which has to keep emulation of the game running for all the other players while it resolves one particular skirmish. If there are multiple simultaneous fights - this load only increases exponentially.

    One might wonder why use this system at all? Why not simply let the clients decide who got hit? Well:

    Aside from injecting packets, there's also the concern of ''lag switching" or how the system handles players with poor quality connections. If packets are delayed or lost - does the system still apply the damage they contained to your victim? It has to - there's nothing to invalidate it.


    And that's not the only problem with client-authoritative lag compensation.
    If we again take our same scenario with A and B, and apply it to a purely client determined system:
    [IMG]
    • Now, the server no longer has any job other than simply relaying information between the two clients.
    • B's information will always take longer to arrive than A's due to their ping. This means their damage on A will be delayed - but also their location from A's perspective - will be delayed.
    • On B's screen - A is still standing out in the open - allowing B a clear shot at them. But on A's screen - B is still approaching the building.
    • Because B's packets take longer to reach A - their damage will as well - but B is also able to move and shoot, while those packets are in transit.
    • As A moves onwards to their next destination - 305ms in the past from their perspective - B is pumping rounds into their back. As their delayed image of A runs into the building and they follow.
    • Unless each players client can somehow dynamically ignore damage it receives from players that are too far out of sync - A will die to B's fire. The damage will be delayed - but still spread out over however long it takes B's weapon to kill a target. However because the damage is delayed - there is nothing A can do to avoid it. They are already dead - they just don't know it yet because B's connection is so slow.
    PS2 appears to attempt to compensate for this by delaying damage at the server - and compressing it into bursts or 'chunks' as I detailed in my post over here. Of course that is simply an educated guess, based on my personal experience while playing, so it may be completely off the mark.
    • PS2 may actually do some form of entity interpolation - disrupt your connection briefly and watch as enemies and vehicles zoom about crazily before resuming regular motion - that's evidence of some sort of buffer or smoothing.
    • The damage compression effect could also be caused by some form of basic server-side hit validation - that effectively checks whether or not an enemy can see you from the servers perspective - and then dumps all the damage they claim to have done - on you in one go.
    • Or it could simply be the effect of packet loss. But with 7ms directly to the server, 23-30ms in-game and 0% packet loss, in my case at least - it can only be my enemies connections that are effecting me.
    The problem with that method of course - is that it fails to take into account the pings of both players, and the respective desync between their perspectives. Why is this a bad thing? Because it means that your opponents ping - not your own, determines the outcome of an engagement. Of course this is always the case in any multiplayer game - but with little to no form of lag compensation - the effects are far more catastrophic.

    It is completely understandable, that PS2's sheer scale makes full serverside windback/buffering like this an unviable solution, however - currently PS2's method of lag compensation and/or interpolation is failing completely for some players (myself included.) The elegance of the Source system is that your own connection to the server - is within your control. You can choose a server you have a better connection to - or upgrade your connection. It's harder to ensure that all your opponents have the same ping as you.


    Apologies for the long winded explanation - I've only really started to fully understand these nebulous concepts over the past year or so. If anyone is more knowledgeable on this stuff, please feel free to correct me - it would be great if we could even get some direct response from SOE on how exactly their system works - as at this stage it's mostly a case of examining the symptoms and guessing as to what's either created them - or might be malfunctioning.



    PS: I think I deduced why people always quote ""the speed of light" in these discussions. It's not because "The speed of light is a constant" as many say, but rather because in a real life situation the delay between perspectives is only that of the speed of light, which is incredibly low in comparison (unless you're fighting across lightyears). Thus what people should say is "Computer networks currently can't communicate at the speed of light. When they do, the noticeable lag will be significantly reduced down to less obtrusive levels."
    • Up x 2
  20. Tricycle


    In my example B shot A with a fatal head shot when A peeked through the doorway. So, if we keep that in mind then wouldn't this windback system simply verify the shot and pass the damage to A who from his point of view was dodging the shots in the cover? In other words he would have died in the cover as soon as the info about the head shot arrives, right? I don't see the benefit of this system.

    I reviewed your other post and I think all I see is a typical shootout with few 100ms latency. The server knows how much damage Mr Dragoon can take and when you exceeded that amount the server told you he died. However, his client was still sending damage packets to the server when it happened which were delivered to you right after the death. If we'd look the same situation from Mr Dragoon's point of view I'm 100% sure it looked like he killed you first. Thus the question is, why should have you survived instead of him? I think it's only fair you both died. This is latency. There's no way around it.

    I don't think it's an evidence of buffering or anything. The packets that are transmitted from the client to the server contain location + movement information (heading + speed). The server will then pass them over to the players around you within certain radius. The clients will then place the players according to those locations and move them to the given direction until the next packet arrives with a new set of coordinates and movement information. Since this happens in a 30 packets per second rate it looks smooth. If the data flow is interrupted for a longer time periods then you will see people running/driving in straight lines or jet packing through the sky, etc. They are simply behaving the way described in the latest packet received.