Please fix Client to Client Accuracy aswell as Deathcam!

(Litego) #61

No I said 5 microseconds to the kilometer. Then I multiplied it by 1,000 because 1,000 kilometers is more world wide scale.[/quote]
Yeah ok I see what you did now. Did the math myself and it is indeed 75ms one way, or 150ms ping. That’s a confusing way of setting up a calculation, but alright.

(Ghosthree3) #62

Ugh I forgot about it needing to come back as well. What a disaster.

Scrap it all.

(B_Montiel) #63

[quote=“Amerika;46737”]B.Montiel,

Exactly how much better do you think your 40ping vs. 40ping games will be if antilag was tightened? Do you believe, and please cite your logic and the technology behind it, that things will get better in those situations for your games? If so, how?

Or are we talking about people wanting to guarantee that 150ping players don’t show on servers because it would be impossible for them to play?[/quote]

  1. Wide anti-lag generate overall inconsistency in client positioning. I can’t really know the numbers but, in my mind, an anti-lag set from n to m values generates a x% inaccuracy in client positionning. And this x% inaccuracy will remain the same no matter what your ping is. The firing client computer, following the GI.Am analogy, has a x% liberty to say “ok, this guy is here”. Halving the n to m values also halves the x% inaccuracy.

  2. Wide anti-lag slightly worsen tickrate. I’m still waiting an answer about this, but, as far as I feel the game, tickrate is set to 66 on all servers, like it is usually on all UE3 binaries. I’d better trade some anti-lag generosity (which generate server work, don’t forget about it) for some tickrate improvements. This has an impressive impact on the game feel. If you ever tried both 66 and 100 tickrate servers on a same UE3 game, you may know what I mean. Your hits feel way more consistent, as well as being hit. Generally, people with high ping generates delays in the communication flow. Tickrate use to worsen for a good bit if there’s too many users connected with high pings.

  3. Tightening Anti-Lag would allow devs to forget some associated developments. Kill trading interval would be logically reduced (From two 60 ms ping clients, the actual gap is way to high right now by the way, you still kill after being clearly dead), the new “gib after revive” would have been meaningless. Some hit issues, especially with sparks (revivr) would resolve by themselves.

(Amerika) #64

[quote=“B. Montiel;46914”][quote=“Amerika;46737”]B.Montiel,

Exactly how much better do you think your 40ping vs. 40ping games will be if antilag was tightened? Do you believe, and please cite your logic and the technology behind it, that things will get better in those situations for your games? If so, how?

Or are we talking about people wanting to guarantee that 150ping players don’t show on servers because it would be impossible for them to play?[/quote]

  1. Wide anti-lag generate overall inconsistency in client positioning. I can’t really know the numbers but, in my mind, an anti-lag set from n to m values generates a x% inaccuracy in client positionning. And this x% inaccuracy will remain the same no matter what your ping is. The firing client computer, following the GI.Am analogy, has a x% liberty to say “ok, this guy is here”. Halving the n to m values also halves the x% inaccuracy.

  2. Wide anti-lag slightly worsen tickrate. I’m still waiting an answer about this, but, as far as I feel the game, tickrate is set to 66 on all servers, like it is usually on all UE3 binaries. I’d better trade some anti-lag generosity (which generate server work, don’t forget about it) for some tickrate improvements. This has an impressive impact on the game feel. If you ever tried both 66 and 100 tickrate servers on a same UE3 game, you may know what I mean. Your hits feel way more consistent, as well as being hit. Generally, people with high ping generates delays in the communication flow. Tickrate use to worsen for a good bit if there’s too many users connected with high pings.

  3. Tightening Anti-Lag would allow devs to forget some associated developments. Kill trading interval would be logically reduced (From two 60 ms ping clients, the actual gap is way to high right now by the way, you still kill after being clearly dead), the new “gib after revive” would have been meaningless. Some hit issues, especially with sparks (revivr) would resolve by themselves.[/quote]

Where did you get your information that reducing anti-lag would make an improvement in gameplay? UE3, from what I’ve found, has a lot of different implementations of netcode with the anti-lag being interchangeable with other solutions. Also, client-side hit detection doesn’t factor in very much when talking about server tick rates from what I can find.

I don’t know a ton about the UE3 engine as most of my expertise lies in GoldSrc, Source, and the Q3 engine. So could you cite tech articles that detail what you’re talking about please?

(Amerika) #65

Today the perfect example of what some people find “wrong” with the current implementation of antilag happened to me today. Where they claim they were shot through a wall.

As you’ll see I long jumped away from the person shooting me in the back. I landed on my screen with more than zero HP but then proceeded to die anyway despite the person obviously not having line of sight on me. Also, the death cam shows where I “died” according to the server. This happened on an NA server with everyone pinging around 60 or less including myself and the guy who killed me.

You might look at this video and go, “see, this is exactly what is wrong”. However, I would disagree. If the antilag was removed/tightened I simply would have died before I rounded the corner. Errors/corrections of this magnitude do happen but they are pretty rare…especially one as bad as the video I just showed (easily the worst one I’ve experienced in 350 hours of play…and this was on an NA server with low pings).

Basically, people feel it’s unfair because they see on their screen that they made it around the corner but if the antilag was toned down they probably still would have died but it would have been closer to where the deathcam showed…and it would be way more awful for people with higher pings to play.

(Ghosthree3) #66

How do you capture random events like this. Do you use Shadowplay’s shadow mode or just record everything? Shadow mode is sadly a poor choice for me right now.

(RuleofBooKz) #67

i still say tone it down. tone it down a lot.

i would rather see what is actually happening than have to guess “am i making it round this corner this time or not”?

It happens to me all the time but i play a light character with super high sens and am sprinting all over the place. at such high sense as a twitch gamer even half seconds are important to how u play - decisions u make. I have to see the game as it is not as it will be in half a second or more

You are very lucky it doesnt happen to you. It happens like a few times ever few maps to me. Me with a low 20-40 ping on a all low ping server (save the occasional match maker explorer from the other side of the world)

(Litego) #68

You do see what actually happened. In the video the opponent shot Amerika where you see the blue hologram thingy. That’s what he saw on his screen. Then you got to counter in interpolation delay, latency between him and the server, server calculations, then latency between the server and you. By the time the packet reaches you, you’ve obviously moved on from where you were.

If you however don’t want to die behind corners at all, then you also want to start leading. You basically can’t have good hit detection without dying behind corners.

What they could do is tone down the interpolation so you die closer to the corner, but you’d still die behind it, and a possible side effect to that could be rubberbanding enemies, which is far worse.

(B_Montiel) #69

[quote=“Amerika;48691”]Today the perfect example of what some people find “wrong” with the current implementation of antilag happened to me today. Where they claim they were shot through a wall.

As you’ll see I long jumped away from the person shooting me in the back. I landed on my screen with more than zero HP but then proceeded to die anyway despite the person obviously not having line of sight on me. Also, the death cam shows where I “died” according to the server. This happened on an NA server with everyone pinging around 60 or less including myself and the guy who killed me.

You might look at this video and go, “see, this is exactly what is wrong”. However, I would disagree. If the antilag was removed/tightened I simply would have died before I rounded the corner. Errors/corrections of this magnitude do happen but they are pretty rare…especially one as bad as the video I just showed (easily the worst one I’ve experienced in 350 hours of play…and this was on an NA server with low pings).

Basically, people feel it’s unfair because they see on their screen that they made it around the corner but if the antilag was toned down they probably still would have died but it would have been closer to where the deathcam showed…and it would be way more awful for people with higher pings to play.[/quote]

Your example is self-explanatory. My opinion is that they are not rare at all. Like @RuleofBooKz, I regularly play mercs with less than 100 hp and you can encounter those situations quite often. But anyway, with the current game settings it is somehow normal. With closer anti-lag, especially with light-class mercs, you’d be alerted way sooner that you’re taking strong damage and therefore you’d back off sooner as well. What I hate is that you get delayed punishment. You can’t calculate every move while also thinking “If I go there I may get shot 2 tens of a second after finding a cover”. [That’s probably a reason why light classes are unreliable. 2 smg body shot are roughly a third of your health pool, and that’s totally possible for an enemy to land those in the anti-lag gap.]

Another issue with wide anti-lag are delayed animations. I noticed very recently that your own client view from another client switching weapons is sometimes completely off-timing. Resulting in m4’s headshots from somebody who still has ammo crates in their hands from your point of view. I won’t be aggressive in the same way between enemies with ammo crates in their hands or enemies already switching weapons.

@Amerika, my knowledge on UE3 is totally empirical. With my chivalry team, we administrated one server for scrims/tourneys and occasional pub games for 2 years. We had the opportunity to tweak the server quite deeply (ty simrai), and all the EU teams interested in server tweaking ended into the same conclusions, with some even renting the said 100 tickrate servers. This game had the same client side detection system and 100 tickrate made an incredible difference, and I’m not over-rating it. Hit windows (Melee draggable attacks) were fitting the models and anims in a way closer fashion.

(Ghosthree3) #70

What is the tickrate of the servers in this game by the way.

(B_Montiel) #71

Roughly, the frequency (Hz) at which the server refreshes the game state then sends info packets to clients.

In other very gross terms, if you consider any game as a turn-based game, the 1/tickrate period (fraction of seconds) would be the turn duration for the server. That’s actually not very accurate, but this kinda gives an overall idea.

(Litego) #72

What is the anti-lag gap? Sounds like the enemy is getting extra time to shoot you because of lag, well that’s not how it works. If you die in the “anti-lag gap” you would have died regardless.

(Ghosthree3) #73

Are you serious.

I know what tickrate is, I’m asking what it is in this game.

(Kroad) #74

[quote=“Amerika;48691”]


generally i would say this game’s netcode is fine even at 100-120 ping, there are just some exceptional moments

I am happy that the hitreg isn’t like it was in Loadout where it was 100% clientside, you could use lagswitch to pull off stuff like this https://www.youtube.com/watch?v=JNcNunFU3qg and so playing vs 300-400 ping players (which happened quite often as the game was playable at that ping) was extremely infuriating as you would be killed behind walls, killed by nades/rockets that seemed to be really far away from you, etc.

Getting shot behind walls in this game happens, but it is barely a problem, you’ll get shot right when you go behind cover, it’s not very noticeable really.

As for fixing spectator, I haven’t quite read every post in this thread, but if it’s at the cost of being able to play at 100-120 ping then I would rather keep bad spectator.

(B_Montiel) #75

Sorry, I missread your question :p…

The default tickrate on UE3 games is usually between 40 and 66 Hz, and the game feels like it is set in this bracket.

What is the anti-lag gap? Sounds like the enemy is getting extra time to shoot you because of lag, well that’s not how it works. If you die in the “anti-lag gap” you would have died regardless.[/quote]

No, I know, but it virtually makes this “third of your health pool” impossible to use. Take this scenario : at 30 hp, you run away. With close anti-lag, once you went into cover, you’re safe. With wide anti-lag, you still have this death lottery upon your head for almost 0.2s… If you want to compensate and make sure you won’t die, you have to run away way earlier (like 50 or 60 hp), and chances would be high that you are 30 hp at the end. (Sorry, it’s quite hard to put in words)

(Gi.Am) #76

I did a quick search. Didn’t find a way to sniff the tickrate from an actual server but. The default setting for UE3 is 30 for net and 35 for lan. However the respective line in the shooterengine.ini is set to 60 for net and 35 for lan. So assuming that the servers run the same shooterengine.ini I would argue they run at a tickrate of 60.
Ofcourse thats nothing more than a guess and they could very well tweak that on the server versions.

(Amerika) #77

[quote=“B. Montiel;48763”]
@Amerika, my knowledge on UE3 is totally empirical. With my chivalry team, we administrated one server for scrims/tourneys and occasional pub games for 2 years. We had the opportunity to tweak the server quite deeply (ty simrai), and all the EU teams interested in server tweaking ended into the same conclusions, with some even renting the said 100 tickrate servers. This game had the same client side detection system and 100 tickrate made an incredible difference, and I’m not over-rating it. Hit windows (Melee draggable attacks) were fitting the models and anims in a way closer fashion. [/quote]

But the antilag in DB is a layer. There is the network connection layer and then there is the predictive layer. Not every game has the latter or uses the same technology. It didn’t come necessarily with UE3 according to what I found. There were multiple solutions that could be employed and are employed against a broad range of games. FPS games, fighting games and even platformers all can use something different. Just because you played Chivalry doesn’t mean it’s the same thing that DB uses. That’s why I was asking you to cite what you know to be a fact about Dirty Bomb.

Also, I could see melee playing out a lot different. With no/little anti-lag you’d need to predict where people were going to be even at decent pings. So animations wouldn’t match. With the antilag, since you’re so close and you’d constantly be predicting where people are and how they are swinging, if there was any error correction you’d know it. Where in an FPS when you’re being shot you’d only maybe notice it when going around a corner. If you died in the open you’d be totally fine with it.

So I could see antilag being annoying in a melee game at times…but is it worse than having to predict where people are at if it’s toned down a lot or removed? Even after basically showing proof of what happens in DB when the antilag goes wrong, which doesn’t appear at first glance to do any favors for DB, I still don’t see the issue. Because I either would have died anyway or the game would have been laggy enough that I would have lived…and then we all are playing a laggy game.

(Gi.Am) #78

Wait a minute I just looked at Kroads video (The DB one) and that fragger got killed by a knife. Presumable by the medic that can be climpsed at in the beginning sitting at the other side of the wall. That guy actually kills someone with a crotzni, when the fragger turns the corner.
How is that even possible? I mean based on the positions I would have suspected a bug where the fragger hitbox or knife goes slightly through the wall, instead of delayed damage notification due to lag.

(RuleofBooKz) #79

what @B. Montiel is putting into words about when to run and when to gun and how this game seems sluggish and a little sloppy is my experience also

(Amerika) #80

@Ghosthree3 I have Shadowplay set to always record the last 20 minutes I played. If something good happens during that time I hit alt + f10 and it dumps my gameplay to a video file. Since my card is built for it (any card that is a gtx650 and up I believe is) there is no additional stress put on it while playing a game and since I have the temp file being stored to a non-OS drive and along with being dumped to that drive there is zero impact on gameplay even when I hit alt F10.

Setting it to 5 minutes would make it a lot easier to get clips for highlights but I like sometimes having whole rounds captured as I am more a fan of raw gameplay footage as opposed to highlight reels.

Also, I somehow missed what @Kroad said and I agree with him entirely. Including the part about Loadout. Ugh, Loadout.