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