HK_BLAU
New member
There are instances in-game where using Assassinate on a quickly moving target (e.g. mid-dash) goes right through them. This made me curious if Assassinate is hitscan or not, and I found some puzzling results. Essentially, Assassinate seems to be hitscan, but there is a semi-random delay between the visual of shooting, and the enemy receiving damage, leading to some situations where clear hits at close range end up being misses. These results were obtained in testing with 0 ping. Attached are the brief tests I did, but should illustrate the problem clearly. in the first clip (volvo.mp4), the shot to damage delays are as follows:
long range:
1st shot: 30 frames (0.1 timescale)
2nd shot: 8 frames
3rd shot: 8 frames
4th shot: 3 frames (note how the delay in this shot is audibly/visibly shorter in the clip, than the two previous shots)
5th shot: 26 frames (0.1 timescale)
mid-short range:
1st shot: 34 frames (0.1 timescale)
2nd shot: 8 frames
3rd shot: 9 frames
in the second clip (plsfix.mp4), the delays are as follows:
1st shot: 9 frames
2nd shot: clearly missed
3rd shot: 3 frames
4th shot: 4 frames
5th shot: 5 frames (mid-short range)
6th shot: 25 frames (0.1 timescale) (mid-short range)
7th shot: 78 frames (0.1 timescale) (!)
What i gather from this and additional testing: it looks like on timescale 1, the delay can be either 3-4 frames, or 8-9 frames. using timescale 0.1, it greatly increases the chances of the shot being 3-4 frames (so about 30 frames), but it can still be the 8-9 frame delay (the last shot in the second clip) rarely. This discrepancy is what i believe to be the cause for some clear hits on moving targets missing (see third attachment, skissue.mp4), because you happened to roll the 8-9 frame delay, which is enough time for the fast moving enemy to get out of the way. When the delay is 3-4 frames, the shot feels instant and this doesn't really happen.
Obviously, if the shot is intended to be hitscan, there should either be no delay, or the delay should be small and NOT visibly random. Alternatively, the shot should not be hitscan, but have a very high bullet velocity such that in ranges like the third clip, the travel time would be tiny enough for the shot to effectively be hitscan.
long range:
1st shot: 30 frames (0.1 timescale)
2nd shot: 8 frames
3rd shot: 8 frames
4th shot: 3 frames (note how the delay in this shot is audibly/visibly shorter in the clip, than the two previous shots)
5th shot: 26 frames (0.1 timescale)
mid-short range:
1st shot: 34 frames (0.1 timescale)
2nd shot: 8 frames
3rd shot: 9 frames
in the second clip (plsfix.mp4), the delays are as follows:
1st shot: 9 frames
2nd shot: clearly missed
3rd shot: 3 frames
4th shot: 4 frames
5th shot: 5 frames (mid-short range)
6th shot: 25 frames (0.1 timescale) (mid-short range)
7th shot: 78 frames (0.1 timescale) (!)
What i gather from this and additional testing: it looks like on timescale 1, the delay can be either 3-4 frames, or 8-9 frames. using timescale 0.1, it greatly increases the chances of the shot being 3-4 frames (so about 30 frames), but it can still be the 8-9 frame delay (the last shot in the second clip) rarely. This discrepancy is what i believe to be the cause for some clear hits on moving targets missing (see third attachment, skissue.mp4), because you happened to roll the 8-9 frame delay, which is enough time for the fast moving enemy to get out of the way. When the delay is 3-4 frames, the shot feels instant and this doesn't really happen.
Obviously, if the shot is intended to be hitscan, there should either be no delay, or the delay should be small and NOT visibly random. Alternatively, the shot should not be hitscan, but have a very high bullet velocity such that in ranges like the third clip, the travel time would be tiny enough for the shot to effectively be hitscan.
