EDIT: While my suggestions for helping us fix this issue is maily for Dark-Assassin, this can go for anyone else as well:
I'm going to outline a brief explanation of how both work (of which I'm not implying the people in this thread do not know how it works, but more or less for everyone -- including casuals -- who view this and aren't familiar with the mechanics) and then proceed to conclude what our best options to take are from that. There is some interesting research I stumbled across over the past 2 years, so parts of this post will be interesting to everyone from all areas hopefully.
How unlagged works is it keeps track of the past 35 or 70 (or some number of gametics, it's been probably > 1 year since I looked at the source code... lets assume enough for at least 1000ms of lag compensation), and when your fire command arrives on the server: it rolls everyone back to the recorded position, does the attack, and restores everyone to their position. This all happens instantly and you never see it on your client since it's all serverside.
- Ping: The method of ping based unlagged is to use the time it takes over the net and divide it by the amount of milliseconds per gametic to tell you 'it was this many gametics in the past', of which you then apply the above to get your desired result.
- Gametic: Gametic unlagged is where you know the (maximum) gametic of the last update, and emit that with your attack so the server knows the last frame you saw when firing and will apply the appropriate rollback to get the result.
The key to understanding what goes wrong with both as we deviate from ideal situations (where ping and gametic would be identical in performance):
With ping based unlagged, the server sends out a pulse to the clients every second, of which the client responds with the timestamp back to the server. From this it can tell how long the trip took, and update the player ping accordingly. This means you only have a resolution of one second, and anything that goes abnormally wrong with packet delays in between will result in inconsistent reconciliation. For example, suppose we fired off our packet to the server which arrives and says we have a ping of 30ms. Now suppose 100ms later we click fire and on the path through some nodes on the net, it gets routed wrong or something weird happens, and it arrives at the server 250ms later. Our shot will then be rolled back 30ms (which is 1 or 2 gametics), but this is far from how many gametics it was when we actually saw the player (approximately 8-10 or so). The way the unlagged code worked was grab the most recent ping, and since the time slice is one second, depending on when the routing goes weird (or worse, the situation I dealt with and many others which will be described in a second), it will still use the "30ms" unlagged because it has no idea about the ping fluctuations that occurred until it requests an update approximately 1 second later.
Where this continues to go south is with how routers are notorious for screwing up and holding onto packets when other things occur on the network... in particular wireless. I noticed a significant difference between wifi and wired, my shots felt like they were consistently hitting wrong while on wireless, and switching over to wired not only fixed this problem [almost], but somehow I was out-reacting people who out-reacted me originally. Maybe it was the distance from the router, I'm not sure, but it brought out all the negatives of ping unlagged. Furthermore, a vast amount of the community does not own their own place and has to deal with others using their internet (which further exacerbates these issues), and then we have to throw in the beyond-our-control-handling of our packets from our ISPs, many things can go wrong with a faulty node.
With gametic unlagged, we see are sending the most recent command we've received from the server. This bypasses all of the problems of ping unlagged (except a small amount of cases which I will describe shortly) because you are only sending the latest update that you received. If you happen to have some major spike with your 'fire' packet and it goes around in some horrid 400ms loop, it contains the time-stamp of exactly what gametic you saw when you fired. From this, when the packet arrives at the host, the server knows when you fired and will adjust accordingly. No kind of vicious spike [within reason] will cause your shot to come out weird because you are effectively transmitting the index of the time-slice that you are -- quite literally -- seeing.
There are some areas where gametic can have problems. These are when packet ordering becomes fuzzy and another packet arrives before our 'fire' packet. Servers can't just let clients pick and choose the gametic to apply the shot, or else hacked binaries will just look back in time for the proper place and send those. Only the most recent gametic received from the client is used. This means if you send two packets: F (for fire), then M (for move, where F comes after by 28ms), if packet F gets lost along the way but somehow M does not get routed badly and arrives first with a more recent gametic, then the stale gametic in F will be ignored and the unlagged will process the most recent gametic (which we're assuming M is at least 1 or more gametics ahead of F since it is emitted from the client one full gametic later... assuming a steady stream of packets). Usually its not the case where just that one single packet is toasted, and usually clients tend to send "+fire" in their packet over multiple, so such cases are rare for this to happen -- but there is one interesting result I discovered online:
There was a casual investigation by a network programmer into the effects of ping when crossing the ocean (where ping levels were 200-300 or higher), and he found that with really high ping, even under stable ping conditions, the ordering the packets has a much higher probability of arriving out of order. Why? We don't know, but this was just a result that was discovered. This means you may be suffering
possibly from this issue. However I'm definitely hesitant to say that you are suffering from this and its not some other anomaly, but I'd like to keep this option that your high ping may bring out a fringe corner of gametic unlagged on the table.
So that covers one potential issue, and I'll discuss shortly how we can debug this issue with your help to figure out if this is in fact the issue.
Another problem with Doom is that other games aren't as fast as doom, so such anomalies if being off +/- 1 gametic do not have as critical of change as Doom does. We don't tolerate much error as well as other games since one gametic and a player moving 30 units per second on some axis means being off by a gametic of 1 could be off by the whole size of a doomguy. When we include the railgun and throw out guns like the SSG with really wide spread, it's easy to run into serious issues. Other games do use gametic unlagged and have immense success, and you can see this in games like Half-Life where even at 200ms the game is very playable. Valve has whole articles dedicated to gametic unlagged and it's effectiveness, but Doom definitely blurs the lines due to speed and object size being opposites compared to the mainstream titles.
Now that we know about how unlagged works, how problems occur on the network side, and why accuracy really matters with the railgun and such, is there any other problems that can happen?
The following may also contribute to shots having problems, along with their provided reasons:
- We did in fact miss and it just feels like we should have hit them (which we will rule out shortly).
- Our aim was trained to a specific thing over time and we adjusted to weird compensations that are removed when we use something like gametic unlagged (if we were used to ping unlagged). There was a study showing how if we made a monitor change color when we press a button on a keyboard with a built in delay of some amount of time like 200ms, eventually our brains lock into this 200ms time frame, and when the user tries it after a bunch of tries at 50ms, it feels to the user as if the color is appearing before we even press it. This is some kind of placebo effect to try to watch out for. I'm not saying you are having this, but it's something to keep in mind.
- There is an underlying issue with how things are processed in the engine that causes the anomalies described.
There's only one real way to fix this, and I HIGHLY encourage you to do it because IMO if you are suffering from these problems, they need to be debugged and proven to either be a connection issue, an aim issue, or an engine issue.
1) Record a demo of this effect to confirm this is in fact an issue.
2) Get a custom build where the server prints out the X/Y/Z of you firing, and the X/Y/Z of the enemies and your unlagging amount when it happens... which will require you and a server to have a modified binary, so this is no small feat of work like (1).
3) If there appears to be an underlying issue, then developers will investigate it.
I know this is a bit of a pain in the ass, but its the only way to find out. From (2), we will be able to determine if you are in fact aiming at the right spot and you are getting unlagged improperly, or if there is a packet ordering issue (though ping based unlagged would also give you these issues but it's worth investigating IMO since it then we can decide if we want to add more data to mitigate this problem), or diagnose if there's some kind of error in the engine itself... which could even go as deep as the internals of the engine that almost none of us touch. Who knows.
As a final story, I find anomalies still happen and things aren't perfect. Gametic unlagged has tremendously helped my shots connect better, and while I've heard overwhelmingly positive responses (which Torr has also seen) and no negative responses, with the fast paced online doom gameplay and problems with collisions of hyper-speeding small bodies, netcode will always be an issue unless we migrate to something very hackable (which then precludes itself from getting in for this very reason). If something was broken, a lot more people would likely have complained by now -- especially in the competitive scene -- that their shots we're getting toasted significantly more on gametic than ping unlagged. However, almost no one plays with 200-300ms, and virtually 99% of the competitive scene that cared about this upgrade are all in the range of 10-170ms of lag, so such corner cases with upwards of 300ms of ping likely didn't get tested for such critical aim issues. I did test this at obnoxious levels like 500ms+ and had no issues, but actually having a client connect across an ocean is a different thing that I couldn't directly test. I still think however doing the above suggested methods will help us discover more about any problems about the engine and deliver a better experience. I'd also like to note that videos on their own will only show that you did shoot at someone, their rail went through their body, and nothing happened. This needs to be shown -- or better yet, showing that you can miss and still kill is the interesting part.
While I'm not around much since my internship has me programming from 8 - 5 and I come home usually wanting to do something else other than touch a computer, I might be able to investigate this on weekends and see whats up. I just need the raw data and videos of someone slowing it down so we can see it happening, and go from there. Even if I'm not around, I'm almost positive the other devs would be able to make a much more educated decision with data.
In short, I would consider ping unlagged being better than gametic unlagged to be a bug that needs to be fixed, not a reason to keep ping around. I am all for keeping ping around until gametic is fixed -- assuming there is actually something wrong with it and not some of the other non-bug related issues stated previously -- though we need to collect evidence for this, and likely by collecting evidence we will then be able to fix such issues.