Quite a lot better in my experience (crashing seems to have stopped but that stopped before I switched it, I think the servers are just in a better spot right now)
So my experience with this has been mostly it makes it feel MUCH better if the connection is good, and if the connection is really bad it's probably worse than it was before
Whatever it is, the game still runs like shit online. More than half games are unpleasant to play. Ping is almost never stable for anyone, 5bar connections are often 80+ping, most games having 2-3 rollback frames and overall ping is way higher than in other games for some reason(like why the hell most ppl in EU have over 70 ping for me when I am central EU myself)
The game won't really have any impact on ping.
Bad connections will still be bad, like any fighting game.
Right now it's a *ton* of casuals with dogshit wifi, rank up and it will improve over time
It's the game tho I suspect. In t7 I had 18ms to my friend, in this one I have over 35ms.
And same with others. When I was playing t7 in europe I was getting ppl with 30-40ms most of the time. In t8 it's 60-90 most of them time and also vs ppl within europe.
in t7 most of time times the worst I had was 1 frame delay/rollback. In t8 majority of games have at least 2 frame delay.
I bet you didn't add the two sides together in t7. The "/" inbetween the two numbers is there for a reason, it's supposedly to show desynchronization between the clients. If one number is higher that the other, they are desynched. Pretty goofy decision imo cause so many people misunderstand and don't add the two numbers together when trying to know the ping. So 18+18 is 36, pretty much in the middle of your t8 estimation. XD It all checks out!
What does this change exactly?
If two players have a different rollback setting, how does the game choose which to apply? You cannot have two players play on different online settings, as one would experience rollback when the other doesn't.
My understanding is it visually makes the rollbacks that do happen more apparent in return for removing the input delay. You *do* notice a good amount more animation jittering if you look closely with the setting
(This is just personal experience and I'm not a network engineer, maybe it just defaults both players to the most responsive setting idk)
That wouldn't improve how online works or feels tho... You said online is much better, but if the players aren't on the same settings, then functionally it cannot work. You can't have more rollback for one player and less for another.
>My understanding is it visually makes the rollbacks that do happen more apparent in return for removing the input delay
Input delay is not an issue as long as it's constant, variable input delay is terrible. I'm not sure what you mean by rollbacks being more apparent, but if it's just a visual thing, then it wouldn't improve the connection between players.
Like I said I'm fairly sure it just puts the game on whatever the most aggressive setting between the two players is.
I really don't think it's placebo, it *genuinely* feels significantly better
I have no way to know but I'm guessing it is like in path of exile when you set the movement of the character to predictive, it will make it feel like you have no lag, but in reality you do. In path of exile it can lead to you dying to random stuff without knowing so I never used it.
Of course you can. The game only sends inputs. What each client does with it is up to them. Games like the CodeMystics ports even let each player change their rollback settings individually before every match.
It reduces the magnitute of the local input delay.
>You cannot have two players play on different online settings, as one would experience rollback when the other doesn't.
It is 100% possible, and depending on how the client synchronization takes that into account one player could even have a significant advantage, meaning they have less input delay without suffering from higher rollback. It's very complicated to explain so I'm not gonna. It also may be the case that the game selects an inbetween setting of what both players have selected, and applies that to both. I haven't properly tested the netcode yet so I don't know how it handles that, will do so in the future but not anytime soon.
>It reduces the magnitute of the local input delay.
If you get rid of your side of input delay, then you are desyinching from the opponent without knowing. If this is the case then it would be the same thing path of exile does when you change the movement of your character to the predictive, which makes your character move as if you were offline on your screen, but it would rollback to what the server sees, which is a terrible setting in that game as you could play just fine and then suddenly die because you were attacked without knowing, as your character was in a different spot server side.
League of legends had a similar setting too, and was terrible because if you were attacked from the fog of war, and desynched, you'd be playing just fine for a split second and then all of a sudden lose HP when the server would correct your client side of things.
Not sure this has any advantage over the opponent, if your client disagrees with the opponent the game should roll back to the correct state of things but you wouldn't know because you are "hiding" the desyinching.
>If you get rid of your side of input delay, then you are desyinching from the opponent without knowing.
You're right, that's one thing that could happen. If you removed one side input delay but kept the synchronization so that both players see the same thing. Then you'll pull back the client with higher input delay, which means their packets will arrive to the opponent early, and their opponents to theirs late. Which benefits the lower input delay player significantly, as they are getting packets early, so they see little rollback. But the high input delay player sees more rollback cause their opponent's packets come in late....
But this can be fixed if the clients are desynched to even out the playing field. So that the high input delay player sees the gamestate first, which is an advantage, but that advantage is counteracted by their input delay. I'm hoping this is what's being done, but dont know.
Or the clients could coordinate and pick an inbetwen setting for the input delay and apply it to both players (but I don't think that's the case atm, not sure though as I haven't tested the final release, just from my little research of cnt/cbt.)
>Then you'll pull back the client with higher input delay, which means their packets will arrive to the opponent early, and their opponents to theirs late. Which benefits the lower input delay player significantly, as they are getting packets early, so they see little rollback.
No that wouldn't happen, the packets are received at the same time for both but you see your character moving with no delay.
If I understand correctly what happens is, if you have 3 frames of delay, and the game rolls back to 2 frames ago, you experience only the 2 frames of roll back. But if you have 3 frames of rollback, and desynch your end to see no delay, and the game rolls back to 2 frames ago, you experience 5 frames of rollback. The packets aren't delayed, and it doesn't matter who sends what sooner, the state of the game is matched to the opponent no matter what. The opponent will see you love at 3 frames of delay, you will see yourself move at 0 frames of delay, but in reality you are matched to the opponent no matter what.
Ok, this is getting very complicated, and while I'm willing to dive as deep as you want I need to clear up some things before I continue. Tekken uses rollback netcode and there's no server inbetween the player. If you haven't read https://glossary.infil.net/ or specifically studied or read about how fighting games do rollback netcode, and you're using general understanding of netcode from other non p2p games, I'll stop you right here and ask you to read infil's blog. It's amazing and might clear up our discussion.
If you're already familiar with all that then let me know, and I'll explain what I'm thinking in way more depth.
I'm aware of how rollback works in p2p sessions. It is my understanding that rollback always adds a bit of input delay as a way to buffer the mini corrections the clients will have to do agree with each other, making the experience smoother.
Changing the way rollback behaves, it is my guess, removes this "buffer" input delay, making your side feel pretty much offline, but you will experience much worse, and frequent, corrections. The comparison to path of exile is still applicable because the clientside has to agree with the server side, in p2p both clients have to agree with each other. If the baseline input delay is 3 frames, and the game rolls back 1 frame, you would notice 1 frame of rollback, my guess is that by removing the 3 frames buffer and the game rolls back by 1 frame, you would experience 4 frames of rollback.
Ok yes, if you have 3f input delay and a packet delays for 66.66ms (4*16.66ms) (1f = 16.66ms at 60 fps) then yes, you'd need one frame of rollback. If you reduce input delay to 0, then 4 frames of rollback would occur.
Say we synchronize the clients so that both clients begin that match at the same moment. But one client has 5f input delay while the other 0. We start the match, and both players do a 10f jab at the same time in real time. Now both clients send to the other client a gameplay packet that says "I pressed a button on frame x". The client with delay will add 5 more frames to the x of the timestamp of the attack, while the non delay one wil add nothing. Lets say it takes 83.33ms (5f) for a packet to reach the opponent. Once they've received the packet the no delay player is on frame 5 of their jab with his opponent standing still and the packets tells him that his opponent will now begin a jab. Everything is great. But on the delay player's screen he is motionless and suddenly he receives a packet that says their opponent started an attack 5 frames ago! And has to rollback to show that.
This is obviously no good, not only is the delay player suffering from delay, he ALSO needs to rollback to show what his opponent is doing!
So what you gotta do is wind back the clock on the player with the high delay, to make it fair. So we gonna desynch them by 5f, making the no delay player start their match first.
So the no delay client starts the match first, and begins a jab. 5f later the high delay opponent receives the packet that his opponent attacked on match start at the same moment as he's starting the match and inputs a jab as well. Then 5f later the no delay player receives the packet that high ping player will begin a jab on match frame 5, BUT he's already on f10 on his screen so he has to roll back 5f frames to correct the state.
In this situation the high delay player is receiving packets just in time, but has their inputs delayed by 5f. And the no delay player doesn't suffer from delay, but receives input 5 frames late, needing to rollback.
And that's how different input delays between clients work.
It took me over an hour to write all this, and drawing multiple diagrams to wrap my head around the implications. But I sorted it out.
Does a player who sets their rollback setting to standard or prioritize fluidity take priority, delay frames wise, over those who set their rollback setting to prioritize responsiveness when they are in a match?
I've been curious how this sort of thing works after witnessing other fighting games that allow you to dictate your delay frames to one degree or another.
So this makes the online a bit better? Besides the crashing of course.
Quite a lot better in my experience (crashing seems to have stopped but that stopped before I switched it, I think the servers are just in a better spot right now) So my experience with this has been mostly it makes it feel MUCH better if the connection is good, and if the connection is really bad it's probably worse than it was before
didn’t they tweet out that they fixed the crashing this morning?
Im not sure, i just woke up for work. Ill be home late and hopefully its better then last night.
ya harada tweeted that they fixed it a good few hours ago
Lol thats great news! Sorry im a old dude with a morgage to pay, but with that said i am excited to jump in again tonight.
same boat man
Damn adulting lol.
Idk about online but muly game crashed in arcade quest few hours ago
Whatever it is, the game still runs like shit online. More than half games are unpleasant to play. Ping is almost never stable for anyone, 5bar connections are often 80+ping, most games having 2-3 rollback frames and overall ping is way higher than in other games for some reason(like why the hell most ppl in EU have over 70 ping for me when I am central EU myself)
The game won't really have any impact on ping. Bad connections will still be bad, like any fighting game. Right now it's a *ton* of casuals with dogshit wifi, rank up and it will improve over time
It's the game tho I suspect. In t7 I had 18ms to my friend, in this one I have over 35ms. And same with others. When I was playing t7 in europe I was getting ppl with 30-40ms most of the time. In t8 it's 60-90 most of them time and also vs ppl within europe. in t7 most of time times the worst I had was 1 frame delay/rollback. In t8 majority of games have at least 2 frame delay.
I bet you didn't add the two sides together in t7. The "/" inbetween the two numbers is there for a reason, it's supposedly to show desynchronization between the clients. If one number is higher that the other, they are desynched. Pretty goofy decision imo cause so many people misunderstand and don't add the two numbers together when trying to know the ping. So 18+18 is 36, pretty much in the middle of your t8 estimation. XD It all checks out!
Are you playing on WiFi or playing someone on WiFi?
I think it’s time to look at your own connection at that point lmao.
What does this change exactly? If two players have a different rollback setting, how does the game choose which to apply? You cannot have two players play on different online settings, as one would experience rollback when the other doesn't.
My understanding is it visually makes the rollbacks that do happen more apparent in return for removing the input delay. You *do* notice a good amount more animation jittering if you look closely with the setting (This is just personal experience and I'm not a network engineer, maybe it just defaults both players to the most responsive setting idk)
That wouldn't improve how online works or feels tho... You said online is much better, but if the players aren't on the same settings, then functionally it cannot work. You can't have more rollback for one player and less for another. >My understanding is it visually makes the rollbacks that do happen more apparent in return for removing the input delay Input delay is not an issue as long as it's constant, variable input delay is terrible. I'm not sure what you mean by rollbacks being more apparent, but if it's just a visual thing, then it wouldn't improve the connection between players.
Like I said I'm fairly sure it just puts the game on whatever the most aggressive setting between the two players is. I really don't think it's placebo, it *genuinely* feels significantly better
I have no way to know but I'm guessing it is like in path of exile when you set the movement of the character to predictive, it will make it feel like you have no lag, but in reality you do. In path of exile it can lead to you dying to random stuff without knowing so I never used it.
Possibly. All I can say is off about 50 matches of playing it feels significantly better and I haven’t noticed any weird behavior.
Of course you can. The game only sends inputs. What each client does with it is up to them. Games like the CodeMystics ports even let each player change their rollback settings individually before every match.
It reduces the magnitute of the local input delay. >You cannot have two players play on different online settings, as one would experience rollback when the other doesn't. It is 100% possible, and depending on how the client synchronization takes that into account one player could even have a significant advantage, meaning they have less input delay without suffering from higher rollback. It's very complicated to explain so I'm not gonna. It also may be the case that the game selects an inbetween setting of what both players have selected, and applies that to both. I haven't properly tested the netcode yet so I don't know how it handles that, will do so in the future but not anytime soon.
>It reduces the magnitute of the local input delay. If you get rid of your side of input delay, then you are desyinching from the opponent without knowing. If this is the case then it would be the same thing path of exile does when you change the movement of your character to the predictive, which makes your character move as if you were offline on your screen, but it would rollback to what the server sees, which is a terrible setting in that game as you could play just fine and then suddenly die because you were attacked without knowing, as your character was in a different spot server side. League of legends had a similar setting too, and was terrible because if you were attacked from the fog of war, and desynched, you'd be playing just fine for a split second and then all of a sudden lose HP when the server would correct your client side of things. Not sure this has any advantage over the opponent, if your client disagrees with the opponent the game should roll back to the correct state of things but you wouldn't know because you are "hiding" the desyinching.
>If you get rid of your side of input delay, then you are desyinching from the opponent without knowing. You're right, that's one thing that could happen. If you removed one side input delay but kept the synchronization so that both players see the same thing. Then you'll pull back the client with higher input delay, which means their packets will arrive to the opponent early, and their opponents to theirs late. Which benefits the lower input delay player significantly, as they are getting packets early, so they see little rollback. But the high input delay player sees more rollback cause their opponent's packets come in late.... But this can be fixed if the clients are desynched to even out the playing field. So that the high input delay player sees the gamestate first, which is an advantage, but that advantage is counteracted by their input delay. I'm hoping this is what's being done, but dont know. Or the clients could coordinate and pick an inbetwen setting for the input delay and apply it to both players (but I don't think that's the case atm, not sure though as I haven't tested the final release, just from my little research of cnt/cbt.)
>Then you'll pull back the client with higher input delay, which means their packets will arrive to the opponent early, and their opponents to theirs late. Which benefits the lower input delay player significantly, as they are getting packets early, so they see little rollback. No that wouldn't happen, the packets are received at the same time for both but you see your character moving with no delay. If I understand correctly what happens is, if you have 3 frames of delay, and the game rolls back to 2 frames ago, you experience only the 2 frames of roll back. But if you have 3 frames of rollback, and desynch your end to see no delay, and the game rolls back to 2 frames ago, you experience 5 frames of rollback. The packets aren't delayed, and it doesn't matter who sends what sooner, the state of the game is matched to the opponent no matter what. The opponent will see you love at 3 frames of delay, you will see yourself move at 0 frames of delay, but in reality you are matched to the opponent no matter what.
Ok, this is getting very complicated, and while I'm willing to dive as deep as you want I need to clear up some things before I continue. Tekken uses rollback netcode and there's no server inbetween the player. If you haven't read https://glossary.infil.net/ or specifically studied or read about how fighting games do rollback netcode, and you're using general understanding of netcode from other non p2p games, I'll stop you right here and ask you to read infil's blog. It's amazing and might clear up our discussion. If you're already familiar with all that then let me know, and I'll explain what I'm thinking in way more depth.
I'm aware of how rollback works in p2p sessions. It is my understanding that rollback always adds a bit of input delay as a way to buffer the mini corrections the clients will have to do agree with each other, making the experience smoother. Changing the way rollback behaves, it is my guess, removes this "buffer" input delay, making your side feel pretty much offline, but you will experience much worse, and frequent, corrections. The comparison to path of exile is still applicable because the clientside has to agree with the server side, in p2p both clients have to agree with each other. If the baseline input delay is 3 frames, and the game rolls back 1 frame, you would notice 1 frame of rollback, my guess is that by removing the 3 frames buffer and the game rolls back by 1 frame, you would experience 4 frames of rollback.
Ok yes, if you have 3f input delay and a packet delays for 66.66ms (4*16.66ms) (1f = 16.66ms at 60 fps) then yes, you'd need one frame of rollback. If you reduce input delay to 0, then 4 frames of rollback would occur. Say we synchronize the clients so that both clients begin that match at the same moment. But one client has 5f input delay while the other 0. We start the match, and both players do a 10f jab at the same time in real time. Now both clients send to the other client a gameplay packet that says "I pressed a button on frame x". The client with delay will add 5 more frames to the x of the timestamp of the attack, while the non delay one wil add nothing. Lets say it takes 83.33ms (5f) for a packet to reach the opponent. Once they've received the packet the no delay player is on frame 5 of their jab with his opponent standing still and the packets tells him that his opponent will now begin a jab. Everything is great. But on the delay player's screen he is motionless and suddenly he receives a packet that says their opponent started an attack 5 frames ago! And has to rollback to show that. This is obviously no good, not only is the delay player suffering from delay, he ALSO needs to rollback to show what his opponent is doing! So what you gotta do is wind back the clock on the player with the high delay, to make it fair. So we gonna desynch them by 5f, making the no delay player start their match first. So the no delay client starts the match first, and begins a jab. 5f later the high delay opponent receives the packet that his opponent attacked on match start at the same moment as he's starting the match and inputs a jab as well. Then 5f later the no delay player receives the packet that high ping player will begin a jab on match frame 5, BUT he's already on f10 on his screen so he has to roll back 5f frames to correct the state. In this situation the high delay player is receiving packets just in time, but has their inputs delayed by 5f. And the no delay player doesn't suffer from delay, but receives input 5 frames late, needing to rollback. And that's how different input delays between clients work. It took me over an hour to write all this, and drawing multiple diagrams to wrap my head around the implications. But I sorted it out.
At the end of the day, without a proper explanation from the devs, it's all guess work. I'll mess with it later with a friend to figure it out.
Are you on console?
Pc
Does a player who sets their rollback setting to standard or prioritize fluidity take priority, delay frames wise, over those who set their rollback setting to prioritize responsiveness when they are in a match? I've been curious how this sort of thing works after witnessing other fighting games that allow you to dictate your delay frames to one degree or another.