Alternatively, the net phases through player 2 until the client confirms that they’ve been netted.
Sure, but this just flips the issue. Now you can see people not get netted and then netted after a wait.
That’s fine if we’re talking 100 ms, maybe 120 ms, but 500 ms or 2000 ms is just jarring for everyone else.
i think you missed some of my last post
this is what i was saying in my last post yeah, low ping players would see net phase through until hit confirmation.
yes but it flips the issue towards “the best possible outcome” at worse, it takes slightly longer before the low ping player realizes that the high ping player gets netted, this is ONLY to the detriment of the high ping player, however. the high ping player is no longer dealing with trash net code while trying to dodge the trapper. so the likely hood they get netted in the first place goes down.
in most cases the low ping player probably wont even “notice” the fact that the net phased through the high ping player because they are “dealing with there own hoard”
you seem to be looking for “a perfect solutoin” or just, pushing back against ideas for the sake of it, without coming up with any new ideas that help, in reality, a perfect solutoin would require 0ms ping worldwide which, according to our current known laws of physics, is not possible
so lets take a small step back and just, try to find the “best” possible solutoin please? one that resolves as many problems as possible?
some sort of a compromise would be nice? that makes the game “playable” for both high and low ping players. and IMO low ping players seeing a high ping player get tapped by a net late is better then high ping players getting trapped by a net in the first place purely due to unfair net code.
Not at all. There are no perfect solutions to this. It’s a balance between how much you want to try and help high ping players at the expense of low ping players. There has to be a sane cutoff somewhere though. Trying to make the game feel good for someone with 500 ms, or 2000 ms of latency at the expense of everyone else is a bad idea. Not pushing back just to push back, trying to compensate for 500 ms+ pings is not practical. There’s a reason why game devs don’t try to accommodate 500 ms+ latency, there’s no practical way to do it.
It’d be cool if there was.
i was never suggesting that to begin with, the dev’s can block anyone with more then 500ms ping from joining a server for all in care or just cap all latency compensation at a max of 500ms ping, i was just using a 2000ms example as a “worse case scenario” thinking about the problem from the worst possible angles to gain clarity about what the best approach would be.
i stated that, for trapper and player interaction, the server would simply need to wait before confirming the catch/ low latency clients would need to wait before confirming that the high latency player got caught. the fact that that system could scale into high latency territory, with having little to no negative effects on low latency players means “it is probably a good idea” latency = visual delay before high latency player is shown to be trapped on 300ms sure you may be able to notice it, but does that matter compared to the alternative of, high ping players get rekt for no reason?
the fact that, the pox buster interaction would be, absolutely horrible at 2000ms ping tells me that, more thinking may be needed when it comes to pox bursters. or any kind of AOE enemy. since your 300ms visual delay now means your low latency player needs to wait 300ms before confirming that they got flung away, this to me is “a bad thing”
in fact while thinking about it more i may have just come up with the perfect solutoin for pox busters
high latency clients will know there latency to the server
pox busters only target one player at a time for there path finding
path finding should be relatively deterministic. normally i would not suggest enemy location prediction, but i think the fact that “your client knows ahead of time where the pox buster WOULD be based on the pox busters current target, and the path that is it taking, you could actually quite accurately predict where the pox buster is server side, this could defiantly work for mutants, as they, kind of just run at you.
dogs and crushers, not so much, since, you cant predict “when they will decide to jump/ start an attack”
i know a bit of modding, i might even be able to make that predictive position mod for pox busters and other enemies, provided that the client already has the required information, and i can access it in some way, if client has no idea about what team mate the pox walker is targeting/ it’s path finding i might not be able to make something that i am happy with, something basic such as “showing the pox walker x distance in front of itself based on it’s movement speed and your latency” could work? but it wouldn’t be as good as just simply, figuring out where the pox walker is going, of corse.
Sounds like a good project to learn about how difficult it really is.
Keep in mind latency is not fixed and it varies packet to packet. The median for a player may be 200 ms, but individually you may have some packets ranging from 150 to 500 ms.
You should try drawing this out in 2D before you start too. What happens when it is moving in an arc if you’re projecting it [latency] x [velocity] ahead of the enemy? What happens if the predicted location coincides with an existing enemy, or a wall?
Best of luck.
yeah no i understand the challenges. actually my challenge right now is completely unrelated to all that. it is simple the question of. can i do it in the first place while connected to the server.
i have all the data i need working in the simulacrum, i can detect pox busters spawning through, many various methods, grab there velocity, which player they are targeting, their path finding nodes, the last thing to do would be, see if i can move the pox buster forwards visually. i get that ping fluctuates but, i am not here to fix ping fluctuation i am here to sync up “where the pox buster is most likely to be, by the time your input reaches the server”
it is a simple case of, asking, how far will the pox buster move down it’s path finding node withing x ms based on it’s velocity, if they are moving at 5 meters per seconds (which as i can tell that is there normal speed) then for a player with 250ms of ping, i need to move them 1.25 meters down there path finding node.
walls wont be a problem because there path finding is not going into or through a wall.
running into enemies will not be a problem, if they “are not moving for some reason” that means there velocity will be 0 and my lag compensation will not be trying to move them “forwards in time”
besides, when have you seen a pox buster “not” jump through the entire hoard, they phase through freaking everything, 20 crushers in your face? have a pox buster phase through all of them. yeah. i don’t think the rest of the hoard will be an issue
the only actual visual issue you may see is when the path finding nodes update IE a pox buster changes direction, which happens constantly while players are moving around, so that will likely be my largest issue, more then likely, an early version of my mod will have the pox buster visually teleport when it changes direction, and of corse will be most noticeable on super high ping 2000+ when i am shifting the buster 10 meters forwards in time (yeah this game is probably unplayable at that point anyway) also if the game already had poorly made lag compensation in some way. i will need to figure out if i need to adjust my code to account for that, my code may over correct to begin with, depending on how they implemented lag compensation.
so far it is going well, i have all the data working in the simulacrum, but only some of the data working while connected to the server, i may need to change my approach for grabbing this data but i might have a working prototype in 12 hours or so if all goes well.
1 Like
Best of luck.
mod is up on nexus, called Latency Compensation
it is still a work in progress, but i am quite happy with what it is capable of all ready.
1 Like
A link to your mod would help 
https://www.nexusmods.com/warhammer40kdarktide/mods/702?tab=description
What you are doing with the net is not what you described above, but it’s actually a good solution FS should look into building on and implementing. You are clearly not predicting where the net will be based off of where the net is reported… The ‘real’ net isn’t even there when you start predicting the path of the ‘lag compensated’ net. However basing it off of the animation does let you compensate for the duration of the animation (net fire minus wind up animation start) which is a big help for someone around 250 ms of latency.
You really should do a proper write up for FS about having the server send the intent to fire a net (sniper too should work) and have the projectile started earlier based on latency. There are still issues with what happens if they are killed or disturbed within the latency window… However since the visuals would be purely client side, the net just disappearing or going through you harmlessly because they got shot isn’t a big deal.
3 Likes
yeah the direction of the net is predicted based on the trappers current target, not the original net’s data (cus as you said it dosn’t exist at the time haha)
i find the trappers current target which is a combination of, closest player + angle to the player (players in front of the trapper are more likely to be the target. i might simplify this and only use angle in the future tbh)
i then take the targets position and the trappers position to find the direction that the net will travel. this means even if the trapper is above you aiming down, i will predict the net will go down, if the trapper is below you i will predict the net going up, ect
i am doing both net angle prediction and timing prediction for trapper nets to give me the predicted location.
now yes you mentioned what happens if the trapper dies or gets staggers, my code accounts for that as much as possible. obviously there is a 833ms aiming duration before the net fires. and just because the trapper is aiming, does not mean the trapper will shoot.
trappers aiming animation is 57, trappers shooting animation is 53.
i see animation 57, i start a timer to get the correct timing, IF i see the trappers animation go from 57 to anything OTHER then 53, i cancel everything as soon as possible, no more timer, delete any current drawn net. reset the code. seeing any other animation state means the trapper did not shoot (got staggered, died etc)
this means that i “can” predict a net that never gets fired, and this rate of error will increase as your ping increases. but in my opinion, accidentally dodging a net that never got fired, is better then not knowing when to dodge the net at all XD
trappers net animation prediction is basically a separate thing all together compared to position prediction.
as for if i think fat shark should implement my code? well. personally, i think server side role back would just be a better solution.
server side role back means, you simply dodge the current animations on your screen, and then the server checks a previous point in time to see if you dodged the animation or not. (server side enemy history buffer)
yeah i KNOW this means that people on low ping might see something like “that crusher looked like it hit you” as in “i saw the hammer go through your body” they wont see you take damage but it will visibly look like it hit you. but the server says, no actually based on there ping, they dodged it.
server side role back would also apply globally for every enemy in the game. and cause no extra network congestion, but it would increase server load. this gives you “server authority” that feels and acts like “client authority”
now if fat shark was to implement client side animation/ position prediction, then yeah i believe they could do a much better job them me, i know my code could be near perfect if i just had more server data, if fat shark was managing client side prediction it, they could adjust how the animaotin system works and simply, put the enemy into the correct position.
but it would require some fundamental changes to the animation system both server and client side, where the server queues up all animations/ movement, enemy decisions 500ms ahead of time, send that data to the client, and then the client could do “perfect” client side prediction based on that data. you would then have a client side network buffer for all data received, the client can then decide at what point during the buffer to act apon.
i know i am making it sound simple and don’t get me wrong, it is not simple to set this up, the code would require server side code reworks, possibly animation reworks, it would also mean that, enemies are working with data from 500ms in the past in a way rather then current up to data data, so not “the enemies have server lag” but in all honesty. that is probably better then clients having server lag.
lets be real, enemies can be reworked as much as they need to work with the new system. for this reason the game would feel a bit different to play and those effects are unknown.
players on 0 ping listen to the start of the buffer, the animation that was queued then plays 500ms later, players on high ping lets say 250ms, listen to the 250ms mark of the buffer, so animations play 250ms after. this means the same animations play on both high ping and low ping clients at “the same time” in regards to “when there inputs reach the server while reacting to the same animation”
player hit/ input registration would stay relatively the same server side, this system would in theory also work for aiming as well, since you are shooting at “where the enemies will be in the future” by the time the server gets your input the enemy will be where you shot it. yeah no yeah i can see this system working pretty much just as good as server side rollback if done correctly.
at this point the main concern with the system would be how enemies server side are working with data from 500ms in the past.
server side rollback still needs development, but you don’t need to remake a bunch of code, only server side hit registration, and developing the server side history buffer, IMO it should be less of a hassle compared to client side latency compensation. but honestly both concepts kind of have there up’s and downsides
1 Like
Get the solo play mod and start a 0 ping game and see what happens with snipers and dogs. You can verify this one very easily by yourself.
and how do i determine if that is an issue with the solo play mod, or an issue with low ping?
honestly, i could do the same thing with creature spawner in the psykanium.
yeah i don’t see an issue with dodging snipers or dogs in the psykanium at all. i see and hear the dodge indicators, i dodge, i don’t get hit shrugs
1 Like
The game does actually have lag compensation for most melee and ranged combat, and for a certain other unique attacks, but it’s very specific, and some things lack it entirely.
As an example:
Hounds, on colliding with a player, will actually freeze up to 0.2 seconds on the server, based on ping, and an extra 0.1 seconds if the player is blocking. For local players (think of when testing in the Meat Grinder with mods), the timer defaults to 0 so it only lasts a frame. Keep in mind that Hounds can actually land on players who aren’t their current target, though they usually push them out of the way (their push always ignores their main target, but everyone else is susceptible).
Once they’re unfrozen, they check if the player is right in front and within a certain distance (3 units, vs the initial server collision which is 0.65 if the player is dodging or 0.8 if not dodging), if so, the player is considered pounced.
If not, the player is let go, and if they were dodging and weren’t in front of the hound, the hound becomes incapable of landing on anyone at all during that leap attack.
Something to keep in mind is that, while leaping, hounds check if their main target is within 25 units (way, way more than their collision, that’s more than 25x the range of their collision to land on a player) and pushing, regardless of where they’re looking. This applies even while the hound is frozen in midair due to lag compensation.
This makes hounds one of the most fair enemies in the game in regards to latency. Not only the hound will freeze up and wait a bit before checking again if you should be caught, if the player pushes in any direction before or during this period, the hound will be forcibly staggered.
That said, there is one improvement that could be made to this, something that Mutants do. There’s no additional dodge check for when the lag compensation timer is over, and the radius is now always 3 units instead of allowing it to be 0.65 if the player is dodging (which you know, could happen at this point instead of earlier due to latency). This is why dogs seem to magnetize to you if you dodge to the side after they freeze up.
Mutants do check for dodge again for when their timer is up, essentially giving players with latency a second chance to dodge and have the Mutant use their smaller dodge radius (though Mutants themselves have had a huge oversight this entire time, making them extremely forgiving, dodging right into them on the server makes you immune to their grab levels of forgiving, see here).
Speaking of Mutants, ignoring that bug I just mentioned, they’re also very similar to hounds in how they’re intended to check for collision on the server, then set a lag compensation timer if they hit someone, then check again (but better than how hounds do it due to checking for dodge again, so if you dodge in time and away from the Mutant, you should get away with it).
Though right now as I said earlier, due to an oversight, dodging straight into them to collide into them on the server, makes you completely immune to getting grabbed by that Mutant until he starts a new charge action. Don’t assume this will stay, dodging in place to not get grabbed is way too silly to keep it in the game..
Also one last note in case you might think this is lag. If you’re at a different height compared to the Mutant, and the Mutant is slowed down (like by charging around something you vaulted on), and you’re close enough, you will get grabbed, that’s not lag but an intended mechanic to not make chargers useless by just jumping on a crate or so.
Next, yeah, for some reason, despite Trappers being the most unfair enemy in the game with how they can:
- Shoot nets through enemies. They basically just ignore enemies entirely.
- Nets are only stopped by geometry through a raycast from the center of the net, but the collision against players is a sphere around it (always move away from corners if they’re shooting around a corner).
- When they incapacitate a player, assistance through an interaction is always required, so you can’t save yourself through grenades, certain talents, and allies can’t just kill the Trapper from a range to save you, etc. Compared to Hounds and Mutants who allow those things, and Mutants also straight up just don’t damage the player if grabbed against a wall.
Trappers lack lag compensation entirely. Which is extremely weird given that the net isn’t a physics projectile, but rather a fake projectile moved in a straight line through the same updating code that checks for collisions against geometry and players.
Why is it extremely weird? It’d be pretty simple to freeze the net in place when colliding with a player, and have a lag compensation timer just like with hounds. Would it look weird? Yes, but hounds already freeze up in mid air and they’re okay with that, so that can’t be a valid argument against this.
When I say simple there, I do mean it, the code that updates the net is also what manually moves it before checking for collisions against players. I really don’t understand how they settled on keeping the most punishing enemy in the game with no lag compensation whatsoever, when they could be very similar to pox hounds to give high ping players a better chance.
Moving on again, almost all melee attacks have insane lag compensation compared to the cases above.
I say almost because there’s some caveats.
- If the melee attack is an aoe attack, only the main target of the attack gets lag compensation, everyone else gets nothing. This is why Crusher overheads targeting other players are so unforgiving against you, don’t go anywhere near them if you want to be sure while playing at high ping, unless you have a guaranteed stagger or can block unblockable attacks (with a shield or so).
- At the time the attack lands on the server, you must either have been considered as dodging against melee at some point during the attack prior to the hit, or you’re currently considered dodging as such, or you’re NOT blocking and you’d be capable of blocking the attack.
-
- Regarding that last one, unblockable attacks (overheads from Maulers, Crushers, and specific unblockable attacks from monstrosities and captains) will straight up ignore it, as you’d have to not be actively blocking, but that means the game will consider you unable to block them because it’s the block stance that grants the property to block unblockables on shields, as an example. Only exception is having some specific buff that grants you the ability to block unblockables regardless of weapon, but it’s better to dodge at least once against these attacks, and try to time another dodge for when they’re about to land.
If conditions apply properly, when hit on the server, the attack is delayed instead and a lag compensation timer starts. The timer is based on ping as usual.
During this time, the game will retry 10 times across this timer to see if the player can be hit (but blocked) or if they dodged, but the conditions mentioned above can apply again and negate the hit again and again. If the hit never lands through these 10 tries and the timer runs out, it goes off one more time without being able to be delayed further.
Of course, the attack can still be dodged or blocked (if blocking is possible) at this point, and there’s also a unique lag compensation check done here, where if the player is considered dodging against it and has moved far away enough from the enemy, they can also ignore the hit.
Lastly, ranged attacks. Rather than doing this stuff that melee attacks do where the hit is delayed, they instead tend to increase the timer for their “dodge window” (and thus when they fire) based on ping.
Snipers specifically will have to keep their aim on target for longer before preparing to fire and giving a warning, based on ping.
Then, once they give off their warning, the time before firing is that of the scope’s reflection timing + extra timing based on ping (this is why they fire extremely quickly in the Meat Grinder if you use mods to test that stuff, because a local player has 0 extra timing). Plasma Gunners do only this bit, they don’t have a “keep aim on target for X seconds before preparing to fire”.
Being considered as dodging against ranged on the server at any point during this dodge window, will cause their aim to stay at that point where you were considered as dodging (you can still be hit if you’re not considered as dodging against ranged attacks and you’re physically in the way, so obviously, strafe dodge them if possible).
Against other enemies that shoot, it’s a bit different. First, if you’re considered as dodging ranged attacks too early (dodging on the server by the time they play their scope reflection), dodging afterwards is ignored for tracking purposes (you can still dodge to avoid taking damage, it’s more that they’ll continue to track you instead of shooting at your position when you were considered dodging).
Gunners and Reapers always keep track of you though so this is irrelevant to them, and you must be considered as dodging against ranged to not take damage from them (or for them to miss due to spread, which, yeah don’t count on it).
With other shooters, if you weren’t considered as dodging too early, and then you’re considered as dodging shortly before they open fire or afterwards, they will fire their entire burst at your dodge position. This includes extremely long bursts that enemies get from havoc and/or with yellow stimms, just don’t physically walk back into the volley..
The dodge windows are usually 0.5 seconds. Snipers have 0.45, Plasma Gunners have 0.6 (I think). Scab Shocktroopers (that’s an internal name, I forget which ones these are..), Captains with a shotgun and the Ranged Twin with One Handed Plasma gun have 0.75. Extra timing based on ping is added with all of these.
Anyhow.. this is long enough as is. As you can see, there are some cases that could use some improvements, like the slight improvement to pox hounds once they unfreeze (to check if the player is dodging at that point like how mutants do), or how unblockable attacks can ignore lag compensation if you don’t dodge at some point while they wind up the attack (it should probably activate regardless of blocking, dodging, or being able to block an attack or not..), etc.
And other cases where there’s none and could really, really use having something like this, like Trapper nets. The grab action for Chaos Spawns, where they start munching on you, also lacks lag compensation entirely and it’s why it feels like it can get you from very far sometimes.
But that said, there’s also a lot of it that, if it wasn’t there, the game would be unplayable, way more than it is. If you want an example of that, Left 4 Dead 2 is right there (I know it’s an old game, but it’s still a good example!).
Actually, one last thing, seeing as it gets brought up here, the game does make use of rollback, kinda, have you noticed that if you shoot a moving enemy with a hitscan weapon, you land your shots reliably most of the time? Without needing to shoot in front of the enemy trying to predict where they are on the server? Yeah, I wonder why that is huh?
This is also used for melee and pushing as well, and it’s why it works as well as it does. There’s some occasional ghost hits, but most of the time it works out greatly even it high ping (I always play with 200-250ms, I know how it is).
That said, projectiles do kinda suck for this stuff because you do have to shoot ahead with higher ping, more than you’d do for the travel time of the projectile, but that’s can of worms on its own to make it less of a problem..
But anyhow, again for real, to wrap this up. Let me know if there’s something that isn’t clear or that needs more elaboration, I’ll try to answer when I have the time.
I do think than rather than suggesting a lot of things that are already somewhat there, or for client authority which they clearly didn’t want to implement, and it might never get added (I’d love that to be the case, especially if we finally get to host local games, don’t get me wrong!). I think it might be better for now to push for these things instead:
- To add lag compensation for Trappers as there’s no excuse if hounds have that, and they’re fine with freezing them up in mid air.
- For improvements for thrown projectiles with higher ping, as unlike hitscan weapons, they suffer if the target isn’t standing still or moving in a straight line. Forcing you to try to predict based on ping like in many other games.
- For making Pox Bursters and Pox Hounds check for push from all players in range, and not just their main target (or at least for Bursters, it feels really bad when they ignore players at point-blank range). It’s not lag for Pox Bursters most of the time, it’s how specific the forced stagger check is where only the main target can do it.
- For making unblockable attacks still allow lag compensation to trigger even if the player can’t block them, without needing for them to dodge. The player could still end up blocking during the lag compensation timing with a perfect block, which could end up allowing an unblockable attack to be blocked more reliably if they have a talent for that! or with a shield or so, and that would be valid, yet it’s not accounted for!