What’s up guys, Rogue-9 here and a little while ago the Godly Noob shared a few off
looking clips on Twitter where he and other players were losing gunfights in Rainbow Six
Siege after jumping down from height.
Here’s his original clip of a jump out from the second floor of Themepark.
It looks like a lot of his shots on the way down should have hit but the Buck was barely injured.
Something doesn’t feel quite right here.
This follow up re-tweet is even better!
Achieved (Rainbow Six pro player and the current team captain for TSM) shared this rather amusing clip.
Not one but TWO shotgun blasts, at very close range and not a scratch on Ash; nothing, not
a single hair out of place!
Two cases, with similar problems, one after the other… this cannot be a coincidence, right?
Is there something fundamentally broken with vaulting or falling in Rainbow Six Siege?
Time to investigate!
Now as you may have seen from the timestamps on the tweets, it has taken me a little while
to dig through this matter.
I basically approached this topic in three stages:
Firstly, I tested if vaulting and falling somehow affects a character’s hitbox at all.
Could the hitbox be detaching from the character model in some way that could influence gunfights?
Is it possible that the hitbox lands on the ground earlier or even immediately after vaulting
and starts tanking shots while you are still mid-air?
Next, I tested if the first person view and third person character model of a player can
somehow become desynced while vaulting at height.
And finally, I ran some tests to see if there are any issues with a players shots being
able to register while they are vaulting or falling because both of the examples from
Twitter seem to indicate that there could also be an issue with hit registration of
the shots fired by the vaulting player.
So, let’s go through the results of these tests one by one and as always, timestamps
to the different sections of the video are available in the description and a pinned
comment below!
This video is brought to you by NordVPN, the world’s number 1 rated virtual private network
provider, which you can find at nordvpn.com/rogue9!
Do you like playing video games or watching streamed video?
Of course you do!
But maybe you’re not getting the most out of these activities because you are not using a VPN!
Even in these modern times we live in, some games have region based censorship or region
locked online matchmaking and pretty much every streaming service (like Netflix, Hulu,
Disney Plus or Amazon Prime) will have regional content restrictions, potentially denying
you access to some great shows.
If you feel oppressed by these first world problems, then a VPN is exactly what you need!
And if you’re going to get a VPN, then why not go directly to NordVPN, the best choice
there is as rated by VPNMentor and PCMag?
If you use my link in the description below or use the code “rogue9” at checkout,
you can get up to 70% off, plus one month free access and you can even trial the service
for absolutely free with a 30 day money back guarantee.
Who could say no to a free trial?
No one can, so click the link below to support the channel and to get more info about NordVPN!
Testing the hitboxes is something I became quite familiar with in the preparation for
my recent video about the elite skins in Rainbow Six, where I spent a truly unhealthy amount
of time inspecting and touching the in-game character models to make sure that elite outfits
do not affect the hitboxes…
mhhhhhhh….
The best way to visually check hitboxes is to use either Monty or Clash with extended
shield and check when the hip fire dot turns green.
I ran several tests of operators jumping out of windows both testing whether the hitbox
and character model arrive at the bottom at the same time, as well as tracking them on
the way down and with both tests, the results came up negative for issues.
The hitbox and character model stay perfectly in sync.
But those tests were run on local matches, so just to be extra sure, I also ran some
tests in online custom games with pings of either around 75ms or just over 100ms and
I also changed the test up a bit to use live fire instead of the hip fire indicator.
I let the vaulting player drop into a stream of bullets and checked when you can see those
shots register and again in every test the hits registered correctly with no issues.
Let me show you the Valkyrie example frame by frame.
Every bullet mark on the wall shows up exactly when the bullet counter goes down because
those decals are rendered locally.
This is when the first shot on Valk hits and this is when the second shot lands.
But because both players are on a moderately high ping of just over 100ms, the blood splatters
that prove, that these shots registered as hits on the server, are 7 frames (or 116ms) delayed.
The third and final hit lands here… and the confirmation of the kill is received 8
frames later in this case; good night Valkyrie, rest well now my sweet, beefy armed, princess.
But there it is.
Some people will sometimes watch back frame by frame recordings of a kill and forget to
account for the ping.
Even though the crosshairs are far away from Valk when the kill is finally registered on
the shooter’s screen and that might look fishy at first glance, the ping of over 100ms
for each player perfectly explains the delay in the server side validation of the hit and
the fact is that everything is perfectly above board with this test and all of the others I ran.
Conclusion number one is that there are no issues with the hitboxes of vaulting players.
All of my tests returned results that show that from the shooter’s perspective, the
hitbox and character model of the vaulter remain in sync.
Next we need to answer the question of whether or not the first and third person fall speed are the same.
Is it possible that the vaulting player could somehow be arriving at the bottom quicker
(or slower) on their own screen than they are on other players’ screens?
To test this, I simply jumped out of windows again and again while recording the first
person and third person view and
oh my god what was that?!...
go back a bit… isolate the third person view and now zoom in & ENHANCE!
Play that back for me!
Urgh….
Why?
Why is that a thing?
How can I unsee that?
Urgh, let’s just move on!
I ran the first few tests on a local server, to eliminate ping as a variable, and check
this out ! The two clips are synchronised by the match timer.
At 8:30 remaining time, Alibi vaults and one frame later Capitao can see the vault begin on his screen.
This minimal delay occurred quite frequently in my tests and makes sense to me, even for
a local match with almost no ping, because of course the movement info still needs to
be sent from one PC to the other, then processed and then replicated.
And in addition to this, both recordings are working at 60 fps which can cause actions
in the game to fall on different frames for each recording and this can also result in minor differences.
In cases like this, to account for the one frame delay, we will start the left hand timer
one frame later.
Now as we step through the two clips though, you can see that the first person view lands
at 1.616s and at this point the third person view is still more than a meter off the ground.
From here it takes another five frames for Alibi’s character model to finally hit the
floor and even if we deduct that 1 frame of initial delay, it still means that we end
up with a desync of 4 frames and that is in a local match with both players on an indicated
ping of 1ms!
Ha!
So there is definitely a problem in terms of keeping jump outs synchronised for all players!
But now I have more questions!
Is this effect consistent?
As in: Will the first person view always fall faster than the character model and is the
amount of desync always the same?
Could operator armour type and speed have an effect on falling speed and desync?
What about ping; could it makes things even worse?
Is it just windows that cause this issue or vaulting in general?
And could running into the vault result in a different effect compared to vaulting from stationary?
In order to answer all of these questions, I ran this type of test again and again and
again and then a few more times and the results were in equal measures confusing and worrying!
Here is an online test with a latency of around 70ms each and using a rather more hefty operator
for the jump out.
The 3rd person vault animation starts 6 frames after the 1st person (due to the ping) but
the landing is a full 13 frames later and look at this, the desync caused by the vault
appears to cause lingering issues for about a second after landing because Gridlock’s
turn to the right remains a bit delayed until here, where the 3rd person model suddenly
snaps into place and re-synchronises with the first person view and the natural delay
caused by the moderate pings.
In this test with Alibi, the two clips are synchronised by the in-game timer and that
means that the third person view of the vault is delayed by 8 frames due to the ping.
What I am expecting to see here nonetheless is that the first person view touches down
after a shorter flight time, than the third person view but lo and behold, it’s the
other way around!
Here are the same clips but synchronised so that the vault animation starts at the same
time (so basically taking the ping delay out) and you can clearly see the third person view
touching down 3 frames earlier.
This effect can be even more extreme!
Here is another set of clips from a local test and this time it’s Ash jumping out.
After 1.666s
her character model touches down and two frames later the first person view
receives damage but at this stage the player is still mid-air on his screen and it takes
another 7 frames before finally touching down at 1.833s!
This kind thing could perfectly explain the frustrating Twitter clips we saw right at
the beginning: if it can take up to 167ms (or maybe even more in some cases) for the
first person view to reach the bottom after the character model is already down for other
players on the server, then the vaulting player would be a really easy target during this time.
Ok, so sometimes the 1st person view falls faster and sometimes it’s the 3rd person
that gets down sooner and the fun part about this is that it seems to be completely at random.
These tests here were all conducted during the same match.
First Gridlock jumps off the balcony three times and during all three jumps, the synchronisation
is pretty much perfect.
But when it’s Ash’s turn to jump, her first jump results in the 3rd person view
getting down sooner,
the second jump is well synchronised
and then the third time, it’s
the 1st person view that hits the ground first.
As we’ve already established, the desync can happen with low or high ping, so it does
not seem to be a causal factor but, it is worth noting that the latency you experience
in game can interact with the effect.
Here is an example of Mira vaulting with moderate ping and even though the first person view
‘only’ falls 83ms faster than the 3rd person view, the ping means that the first
person view has a 150ms head start and so the first person view touches down almost
a quarter of a second earlier, when both clips are synchronised with the in-game clock.
Only one trial later, the tables are turned and the 3rd person fall time is shorter, which
then ends up counteracting the latency related delay.
So sometimes the combination of ping and desync will make things worse and sometimes they
will partially cancel each other out.
So: there appears to be no rhyme or reason to this phenomenon!
Sometimes one view is quicker, sometimes the other, sometimes they’re synchronised!
Armour types play no role; ping can add to or subtract from the effect but otherwise
does not seem to be connected; the effect is not exclusive to windows (any vault, on
any map will do) and it can occur whether you are running into the vault or vaulting from stationary.
But how does this happen?
What could be causing the fall speeds to be so random?
Let’s compare two different vaults from same perspective!
I have picked two separate jumps where the first & third person perspective actually
matched up and here is the first person perspective of Gridlock jumping out of the same window
on two different occasions.
As you can see, up until here everything looks pretty much synced up but then the left hand
side seems to accelerate much more quickly and the player hits the ground at 1.666s
while the right hand side doesn’t land until 1.833s Now comparing from the third person view (I
have mirrored the clips to be (hopefully) less confusing) and you can see that up to
1.033s both animations are pretty much in sync.
After this point, both animations show the character straighte ning out but while the
right one straightens out while falling immediately, the left hand one stays floating in front
of the window for another 150 odd ms, which is only one frame less than the total difference of 167ms.
So what we can say for sure is that differences in the time at which the body starts to drop
is causing inconsistency in the overall fall time and that could be the reason for why
we see desynchronization between first and third person fall times.
Interestingly, this even goes as far as to affect the detection timer for defenders when
jumping out of a window.
Check out these clips from different jump outs that are synchronised so that the vault
starts at exactly the same time.
For Rook jumping out on the right, the detection countdown starts as soon as his big toe crosses
the window sill, while he is still up in the air and at the same time, Alibi over on the
left doesn’t get a countdown until she is almost on the ground already!
If we let both clips move on from here, you can see that Rook (for whatever reason) ends
up getting detected almost a full second earlier than Alibi for jumping out of a window of
exactly the same height, on the same map.
All I can say to that is: “What the fuck is thaaat!”
For a timer that only lasts 2 seconds, having almost a full second bonus randomly added
on has the potential of significantly affecting the outcome of a jump out!
Last but not least, before we move on to investigating hit registration during vaults, I want to
also show off a three way comparison I ran.
In this set of clips, you can see how the vaulter and two different opponents all see
significantly different landing times for the same jump.
What this clearly demonstrates is that each and every player in a match, can potentially
have a different experience of the same jump in terms of when the vaulting player lands.
Not really surprising but definitely good to know.
And now over to our final set of tests: is it possible that hit registration is somehow
affected for the vaulting player because both of the twitter clips kind of suggest that
enough shots should have landed to win the fight for the ambushing player.
This was a bit challenging to test, because the only thing I could think of to try this
out was to jump out and shoot at another player, while they try to shoot back and then check
the footage frame by frame for hits and misses.
It’s a bit crude as scientific methods go but if you run enough trials then hopefully
you’ll get something useful out of it.
Here’s the side by side view of a decent clip where the lower player wins with a lucky snap
and here is more of a case of the vaulter just getting spotted early and being taken
out in the air.
Sometimes the vaulter won, sometimes he lost; sometimes the desync worked in one way and
sometimes in another but one thing that was consistent in every clip I checked, was that
all shots from both players registered absolutely correctly.
If the reticle was over the enemy player at the time of the bullet counter going down,
the shot always counted as landed so the conclusion is that through all of my trials, I was NOT
able to confirm any issues with bullets landing during the vault.
The only possibility I see to explain the Twitter videos from earlier on is that the
very real desync in first person and third person position could make the vaulter easier
to spot and shoot and that as some of his or her shots are still being fired for a few frames,
the server has actually already validated their death and these additional hits are subsequently discarded.
So there it is!
The hitbox of both players seems to remain completely intact while vaulting but there
is a definite issue with random amounts of desync that can occur when jumping from height
and that can either give the vaulting player a bit of an advantage or disadvantage in terms
of being able to win a gunfight.
In addition to that, the detection timer can also be massively affected by the vault animation
and can in some cases start up to a full second late, which again can potentially affect the
outcome of a subsequent engagement.
The desync I was able to record was usually around 3 to 5 frames at 60 FPS (but sometimes
going up as high as 10 frames).
It’s essentially the blink of an eye and almost all of the time, you would never even
notice if it happened to you in a match.
But, I do also believe that this potential desync is large enough to have an effect on
split second gunfights and it could explain the clips that people have been sharing on Twitter.
Have you had any issues with jump outs or vaults in Rainbow Six Siege?
Share your stories in the comments section below and with that, as always; many thanks
for watching, I hope you enjoyed the video and I will see you in the next episode!