Input consistency & heavy car bug - Rocket Science #19 — Transcript

Full transcript

1. 0:00Hey guys, HalfwayDead here with another episode of Rocket Science.
2. 0:04In this one, we're going to explain input consistency, run experiments, discuss how
3. 0:09to optimize it, and show how the experiments could be used to test heavy car bug.
4. 0:23Let's get this topic started.
5. 0:25Why would you or anyone care about the topic of input consistency?
6. 0:29Let me illustrate this with this simple example: My car is positioned a short distance away
7. 0:35from the ball, standing still.
8. 0:38I want to get a powerful shot, so I will accelerate with boost, jump, tilt back, and dodge forward.
9. 0:46There is an optimal timing of all the steps in this routine which will maximize the power
10. 0:51of the shot.
11. 0:53Finding the correct approach shall be a topic of a future video.
12. 0:56However, what I want to discuss here are the things, that can get in the way of executing
13. 1:01this shot perfectly, even if you know how to do it.
14. 1:05The most obvious and, one would hope, the biggest influencer of the execution is the
15. 1:10human.
16. 1:12Even when knowing how to hit a powerful shot, any human can easily mess up the corrects
17. 1:16timings by a couple 1/100ths of a second.
18. 1:19But it isn't the only culprit in this equation.
19. 1:22The input device can also make a difference.
20. 1:24I've already mentioned this in my controller input lag test and I'll further elaborate
21. 1:29on the testing scenarios later but a device with only 100Hz polling can cause a deviation
22. 1:35of up to 10 ms.
23. 1:37And regarding wireless controllers, I have previously measured up to 20 ms deviations
24. 1:43due to wireless interference or weak signal strength.
25. 1:45And lastly, we also have the game.
26. 1:49Now to set the record straight, Rocket League physics are deterministic.
27. 1:53That means, if the same inputs get used in the same physics step, the outcome will be
28. 1:58identical every time you repeat the same inputs.
29. 2:02There are still reasons for why that timing could get messed up though, even if the human
30. 2:07and input device have done their job perfectly.
31. 2:10The game only checks the state of the inputs every frame, but the physics run at an independent
32. 2:16rate, which can create alignment inconsistencies.
33. 2:18The same kind of alignment can also happen if the framerate is not in sync with the polling
34. 2:19rate of the input device.
35. 2:20I'll explain that later.
36. 2:22Let's get back to the human aspect.
37. 2:24As always, I didn't want to just state the obvious, that humans are not perfect.
38. 2:29I wanted data.
39. 2:31I wasn't able to find quite what I wanted online so I set up my own experiment.
40. 2:36I opened up and wired up my mouse to connect it to my Arduino.
41. 2:40A necessary step, to make sure the machine error of the measurement is basically 0.
42. 2:46What I did then, was to turn a metronome to 120 BPM and tapped along with the beat, measuring
43. 2:52the times between each button press.
44. 2:55The expected time is 500 ms and that was pretty much exactly my average.
45. 3:02The interesting part, however, is obviously the consistency.
46. 3:05In this case, the standard deviation.
47. 3:08It was just below 15 ms in my case.
48. 3:11A short note here: While I have played the piano since I was 5, and would expect myself
49. 3:16to be above average at this kind of exercise, I didn't feel like I was able to replicate
50. 3:21the same consistency that I can when playing a piece of music.
51. 3:25Therefore, I think that this is not the human limit of timing accuracy, but it is a data
52. 3:30point to start with, and I was also interested in confirming whether the average timing fits
53. 3:36a normal distribution, and it does.
54. 3:39But how does the polling rate tie into this?
55. 3:42To figure that out, I can take the measurements and treat them as if they were made at a lower
56. 3:47polling rate.
57. 3:48The result seems rather uninteresting at first sight.
58. 3:52Even with a polling rate of 100 Hz, which is the lowest of any common controller that
59. 3:57I'm aware off, the inconsistency only increases by 0.3 ms or 1.8% compared to 1000 Hz.
60. 4:06That is a good sign and makes sense if you consider that some professionals are using
61. 4:11the DS3 at the highest level of play, but I also said that 100 Hz polling could screw
62. 4:17you over by almost 10 ms and that is still true.
63. 4:22Let's say you pressed the button 501 ms after the previous press and you barely missed the
64. 4:28polling window of the controller.
65. 4:30As a result, your input will be sent after 510 ms, making it 9 ms worse than it was.
66. 4:38But, and that's a big but, the exact same thing can also make your input 9 ms better
67. 4:44if you pressed the button too early after 491 ms.
68. 4:50In the end, this effect will save you as much as it will screw you over, but the average
69. 4:55inconsistency only goes up slightly because the options are more extreme.
70. 5:01It should be noted that if you go as low as 50 Hz or even lower, the inconsistencies will
71. 5:06start to get significant quite quickly.
72. 5:09In the same sense, someone with better timing accuracy than me might be limited by 100 Hz
73. 5:16polling already.
74. 5:17Earlier, I said that there are other technical reasons for why inputs might be inconsistent.
75. 5:23Those are best shown by going over the entire input process from the button press to physics.
76. 5:29In this example, we're going to assume that we wanted and managed to press down a button
77. 5:34for exactly 50 ms.
78. 5:37Our controller shall have a polling rate of 250 Hz, so it polls every 4 ms. 50 ms / 4
79. 5:46ms = 12.5, it doesn't divide.
80. 5:49We can only have a 48 ms or 52 ms button press.
81. 5:55Which scenario happens, is decided by the timing of the button press within the 4 ms
82. 6:01window.
83. 6:02We can assume those micro timing alignments to be random.
84. 6:06In this case a 50/50 chance for either scenario.
85. 6:10Then we have the game, running at a stable 144 FPS.
86. 6:15The game checks the inputs every frame, so it's going to check every 6.94 ms. 48 ms / 6.94
87. 6:24ms = 6.91.
88. 6:26Which gives 91% chance for the input to last 7 frames and a 9% chance to last 6 frames.
89. 6:34In the 52 ms input case, it could last either 7 or 8 frames.
90. 6:39The physics in Rocket League, however, get calculated independently of the framerate
91. 6:44with 120 ticks a second.
92. 6:45Apply the same kind of math we did it in the last step and you get the end result.
93. 6:51There are 3 scenarios.
94. 6:55Either the game calculates the physics as if you pressed the button for 5 ticks, approximately
95. 7:0042 ms, 6 ticks, 50 ms, or 7 ticks, 58 ms.
96. 7:08The odds of registering the intended 50 ms are only 67% and the other two scenarios are
97. 7:1516% each.
98. 7:17Had we capped the framerate at 120 FPS instead, having it at exactly the same rate as the
99. 7:23physics, we would have a 76% chance for exactly 50 ms.
100. 7:29Any multiple of the physics tick rate will outperform any other framerate in terms of
101. 7:34consistency.
102. 7:35This may sound more dramatic than it is until you calculate that with my inconsistency data
103. 7:41earlier, I would only be able to hit the perfect tick 22% of the time.
104. 7:47The example was also assuming perfectly stable framerate which is unlikely.
105. 7:54So far, we have seen why achieving 100% consistent inputs is basically impossible.
106. 8:00But can we actually measure these effects in a test and see how it affects gameplay.
107. 8:04A theory means nothing unless it holds up in an experiment.
108. 8:10This is the part which took me the longest to make.
109. 8:12You might think it's easy, just create a macro with any gaming software and run it over and
110. 8:17over again.
111. 8:18Sadly, it's not.
112. 8:20The accuracy of these ranges from completely inconsistent to usable in some tests.
113. 8:26Unfortunately, when the whole purpose of the experiment is to measure consistency, then
114. 8:31slight inconsistencies are already unacceptable.
115. 8:35So I went back to my trusted Arduino.
116. 8:38It has a microcontroller that allows me to connect it to the PC just like any real gamepad.
117. 8:44The only difference is, that I am free to program it exactly how I want.
118. 8:49So I got to work and wrote some code that allows me to not only to run macros on the
119. 8:54Arduino but also simulate polling rates and other inaccuracies.
120. 8:58Then, I set up the shot from the initial example I gave at the beginning of the video.
121. 9:05To ensure maximum baseline consistency; I took a couple of steps.
122. 9:10Rocket Labs map, lowest graphics settings, closed down every program I didn't need, and
123. 9:17maximum performance mode in Windows, so the processor doesn't use it's power saving features.
124. 9:23I also locked the framerate to 240, a multiple of the physics tickrate, that I was able to
125. 9:28reach in a very stable manner.
126. 9:31Then I let the experiment run for as much time as was feasible.
127. 9:34For the baseline experiment that was almost 6000 shots which takes over 4 hours.
128. 9:41The results are better than I expected to be quite honest.
129. 9:44The default shot I set up was 3041.75 uu/s and it happened 91% of the time.
130. 9:54Within the entire test, not a single shot was below 3008 uu/s and not a single one above
131. 10:013062 uu/s.
132. 10:04That's a difference of less than 2 km/h or barely over 1 mph.
133. 10:09Still rather uninteresting on its own so let's go on to the comparisons.
134. 10:13First, I varied the polling rate default 1000 Hz, 250 Hz, 125 Hz, and 100 Hz.
135. 10:23The percentage of perfectly consistent macros is 91%, 67%, 47%, and 26% respectively.
136. 10:34In the macro, there are obviously multiple actions that have to be done at exactly the
137. 10:38correct timing relative to each other.
138. 10:41So those 26 % are most definitely better than the 22% human quota I said earlier.
139. 10:48The worst case shot strength for all polling rates below 1000 Hz was also an additional
140. 10:53km/h lower.
141. 10:56In my controller input lag test, I measured that, despite the lower average input lag
142. 11:01of the DS4 in wireless mode, the input consistency was a little worse.
143. 11:07Other wireless controllers tended to have a slightly lower consistency too.
144. 11:12With the latency distribution data I collected back then, I can now simulate what using a
145. 11:17wireless DS4 would be like with my Arduino.
146. 11:21The result is kinda interesting, but it makes sense.
147. 11:25The amount of times the perfect frame timing is hit is 78%, as opposed to the 67% in the
148. 11:32250 Hz wired case.
149. 11:34However, that is not the full story, which I think is best shown in visual.
150. 11:43Most of the time, the higher polling rate saves the controller and makes it more consistent,
151. 11:48but wireless is never 100% stable and you can get these spikes which have bigger impacts
152. 11:54on actual gameplay than the polling rate will ever have.
153. 11:58I'd personally rather have small inconsistencies often, than bigger inconsistencies rarely,
154. 12:04but you can make an argument to justify either cable or wireless.
155. 12:09What else can we test?
156. 12:11Well obviously framerate.
157. 12:13I've made a big deal out of matching the framerate with physics, so I have to back that claim
158. 12:18up.
159. 12:19I tested a couple of framerates but for the main comparison I went with 144 since it's
160. 12:25bigger than 120 and one that people commonly use.
161. 12:29To make sure this doesn't just come down to a bit of randomness, the experiment was also
162. 12:34run for over 4000 shots.
163. 12:37The amount of perfectly consistent shots went down to 68% instead of 91%.
164. 12:42But, I hear you say, isn't that just the lower framerate in general?
165. 12:48It is not.
166. 12:49With 120 FPS the result was the same again as 240.
167. 12:53In fact, a tiny bit better but that is likely just down to randomness because I didn't test
168. 12:59it as long.
169. 13:00I also unlocked the framerate completely, causing the framerates to go up to around
170. 13:06600-800.
171. 13:08As framerates approach infinity, the theory predicts that the syncing starts getting irrelevant,
172. 13:13but I was still able to measure a 5% drop in consistency here.
173. 13:19More concerning are the results that happen below 120 FPS.
174. 13:24At 60 FPS the intended shot happened exactly 0 times, and there is a good explanation for
175. 13:28that.
176. 13:29If I wanted to start boosting, and then stop boosting 9 physics ticks later, that is literally
177. 13:30impossible.
178. 13:31Since the game only checks the inputs every frame, all actions will last an even amount
179. 13:35of physics ticks.
180. 13:37That means the intended macro cannot be executed perfectly.
181. 13:42In a sense, the 60 FPS case was still consistent, because there were basically only 2 different
182. 13:47results that happened a combined 95% of the time.
183. 13:51Those 2 results have a speed difference of 4 km/h though, which makes that gap bigger
184. 13:57than any of the worst results that happened at higher framerates.
185. 14:02Because of that, you'll always want as high of a framerate as you can get if you can't
186. 14:07get at least 120.
187. 14:09These results are interesting but in real situations, you're probably not going to get
188. 14:15that stable of a framerate.
189. 14:17The reason I did most of the tests this way is that introducing inconsistencies will also
190. 14:22make the experiment results more random.
191. 14:25Regardless, I did want to check whether any of this is relevant when the framerate isn't
192. 14:30as stable.
193. 14:31So I did test exactly that, by putting a Twitch livestream and a youtube video on my second
194. 14:37monitor, left all my usual apps like Spotify and Discord open, and put the graphics settings
195. 14:43to the maximum.
196. 14:44The frame graph looked like this.
197. 14:46So, very inconsistent but it does still hit the capped framerate quite a bit.
198. 14:52Obviously, if you never reach the capped framerate then the cap is irrelevant.
199. 14:57So I did this with 240 and 144 FPS, and the results are quite clear.
200. 15:04The perfect shot with 240 unstable FPS happened slightly more often than with stable 144 FPS.
201. 15:13Unstable 144 FPS was 30% worse.
202. 15:18Stable 144 FPS is of course still better than unstable 240 FPS, because getting a big stutter
203. 15:25will really screw you over.
204. 15:27That wasn't the point of this experiment though.
205. 15:30So all I had left to do, is try it myself.
206. 15:34I got the intended shot, you guessed it, 0 times in 500 tries.
207. 15:39Obviously, I can't imitate a macro, but we can once again look at the visuals to see
208. 15:44something interesting.
209. 15:46First, let's go with the best case scenario I had.
210. 15:50This shows, that if RL is running as well as it can, you should never blame the game
211. 15:56for missing.
212. 15:57The 144 FPS unstable experiment had some major stutters from time to time, and those can
213. 16:04be just as bad as your own whiffs.
214. 16:06Personally, I thought the 60 FPS stable experiment was most interesting though.
215. 16:12If you line up my good shots with those results, you'll see that if you just take my good shots,
216. 16:18they vary no more, if not less.
217. 16:21That would explain why no one who has played 120+FPS likes going back down.
218. 16:27There are just these shots, where you felt like you did well, but it doesn't go exactly
219. 16:32as expected.
220. 16:33But I'm probably starting to interpret a bit too much here to call it science.
221. 16:38Feel free to draw your own conclusions.
222. 16:41TL;DW.
223. 16:43What can you do to get the maximum consistency?
224. 16:47First: Get the best PC you can, so you have enough horsepower to run the game at a stable
225. 16:53high framerate.
226. 16:54Second: Get an input device with the highest possible polling rate that is wired, if feasible.
227. 17:01Third: Cap your framerate at 120 or 240 FPS.
228. 17:06The latter will have a little lower input lag, but it's basically irrelevant for consistency.
229. 17:12Fourth: Optimize graphics settings and power options to tweak performance.
230. 17:17Is your framerate stable?
231. 17:19Congratulations, you have done all you could and now you don't have any excuses left when
232. 17:25you miss the ball, Whoops.
233. 17:28This leaves another question open though.
234. 17:31Is there anything Psyonix could do?
235. 17:33Since the physics aren't tied to framerate, there are indeed options.
236. 17:38I got Bakkes to write me a piece of code that would read the inputs directly to the physics
237. 17:43ticks, skipping visual frames.
238. 17:45My all so smart idea turned out really stupid when I found out that the physics ticks, are
239. 17:51always queued relative to visual frames and therefore calculated at irregular intervals,
240. 17:57even though they act as if they are calculated at regular intervals.
241. 18:00Ergo, the result is identical.
242. 18:02There is a still a possibility to get more consistency through an input buffer.
243. 18:08I'm not gonna explain in detail what it is, but it would increase input lag in order to
244. 18:13improve consistency.
245. 18:15I might try that out in a future video if people are interested and ask players to test
246. 18:21it in freeplay to see if they like it.
247. 18:24Psyonix tends not to experiment and give us too many options, so I don't have the highest
248. 18:29hopes of ever seeing it in the game.
249. 18:33If you're only here because of heavy car bug and you still watched all the way, then I
250. 18:37applaud you for trying to understand everything I talked about so far.
251. 18:41I shall make a short explanation of what I understand as heavy car bug and how this video
252. 18:47relates to it.
253. 18:49Quite a long time ago, some players started to complain about Rocket League on Reddit
254. 18:53and the official forums, stating that the control of their car felt inconsistent, shots
255. 18:59felt weak, and or their cars were outright turning or moving slower.
256. 19:05Moreover, a distinction that I like to make, although I think some people are split on
257. 19:10this, is that the bug only happens sometimes or it only happens on a specific account.
258. 19:16If you don't have anything to compare to, after all, there is no way for you to know
259. 19:21if the inconsistencies you're feeling are out of the ordinary or even your own fault.
260. 19:26So with that out of the way, here is the problem.
261. 19:30No one has been able to reliably reproduce this change in game behaviour and it's supposedly
262. 19:36independent of such proven inconsistency factors as unstable framerates.
263. 19:41There have been a large number of suggestions on possible causes of the symptoms as well
264. 19:46as fixes in the past, but for some, it never seems to go away.
265. 19:50First, I want to get into some of the causes.
266. 19:54Very often, I have heard that the physics actually change when hcb happens.
267. 19:59That is essentially impossible in online games.
268. 20:03The server and your computer calculate the physics independently and if your cars turning
269. 20:09radius on your computer was wrong then the server would send a different location and
270. 20:14you'd get moved to the correct location.
271. 20:17I could also talk about how I test the physics every patch to make sure they stay the same,
272. 20:23but that is obviously only proof that it is that way for me.
273. 20:27But there is a heavy car bug Discord where many affected people have been doing a lot
274. 20:31of tests with the help of some Psyonix developers, and as far as I've understood it, they have
275. 20:36ruled out actual physics changes.
276. 20:40Another suggestion is input lag.
277. 20:43Delayed inputs can feel horrible and I myself would never like running on a TV with high
278. 20:49input lag.
279. 20:50The problem with this suggestion is, that you can obviously have high input lag, but
280. 20:55that it isn't necessarily Rocket Leagues fault.
281. 20:58I have already made lots of videos, explaining and measuring different causes of input lag.
282. 21:04Once again the people in the testing Discord have already been trying to measure the input
283. 21:08lag Rocket League causes through code.
284. 21:11If you're still suspicious, my external testing setup could be reproduced with about $40-$50
285. 21:18which would allow testing your input lag and confirming that it stays constant.
286. 21:23So if it's neither the physics nor the input lag, then it must be that inputs are not reaching
287. 21:29the correct physics ticks.
288. 21:31For which I suggest using a setup such as the one I had in this video.
289. 21:36If the macros can get consistent inputs but you can't, it must be your fault.
290. 21:42If the data shows anything suspicious, then you have something to work with that might
291. 21:46help fix the issue.
292. 21:48So my suggestion is, that you can contact me and I will help you order and setup these
293. 21:53tests on your own computer if you want to.
294. 21:55I do hope, that if there are a lot of people, I can refer you to those that have already
295. 22:00done it, so you can help each other.
296. 22:04Before you go and contact me, I want you to seriously consider that, because it will be
297. 22:09some work and the setup isn't completely free.
298. 22:12I personally do think it's either a visual bug or a placebo.
299. 22:17I'm not just gonna state that though.
300. 22:18I'm going to give you 2 completely free experiments to do right now, that might convince you.
301. 22:25First one is just an anecdote to counter some of the heavy car bug related statements I've
302. 22:30heard.
303. 22:31In the workshop map called "The Wall" there is a tight turn at the very beginning of level
304. 22:364.
305. 22:37It is possible to get through that turn without powerslide while boosting from the start.
306. 22:43Though, if you try for the first time you'll likely fail.
307. 22:47The only way to do it is to pre-steer before you can see where you're going.
308. 22:53Why am I showing you this?
309. 22:54I think I've heard the statement "See how quick squishys car moves?
310. 22:58My car is always slower."
311. 23:00one too many times.
312. 23:02The top players are able to make turns and twists just in time because they have already
313. 23:07given the input way before you think about it.
314. 23:11When a player lands perfectly on the wall after they've flipped into the ball, it is
315. 23:15because they have done the right inputs before their flip was even over.
316. 23:20Enough about that, the more interesting experiment is the second one.
317. 23:25It's pretty simple, just go into an exhibition match with the slow-mo mutator and play that
318. 23:29for 30 minutes straight.
319. 23:32Alternatively, you can use BakkesMod to create slow-mo in freeplay.
320. 23:36When you go back to normal speed after playing slow-mo for that long, you're gonna feel like
321. 23:42it's way too fast.
322. 23:44It's a great example of a placebo fooling your brain into thinking something is too
323. 23:48fast or too slow.
324. 23:51And you're not immune to this because you have x thousand hours.
325. 23:55I hope no one who thinks the bug is real takes this personally.
326. 23:58I don't have proof that it isn't, but I could never prove that unless I tested all the computers
327. 24:04all the time.
328. 24:05Please, do not take this as an insult.
329. 24:08It doesn't matter who you are, our minds can be fooled.
330. 24:11Science has never accepted a feeling as proof and I will not believe that this is a real
331. 24:16bug until I have seen evidence that shows it.
332. 24:20Before I inevitably cause too many dislikes, I shall end it.
333. 24:25Shoutout to my patrons who continue to support me financially.
334. 24:29Without them, videos like this one would be impossible.
335. 24:32If you want to join the supporters for as little as $1 you get a vote on topic priority
336. 24:37and a guaranteed reply to your questions.
337. 24:39If you want to stay up-to-date about RL changes and the channel, follow me on twitter, or
338. 24:44join my discord, and I'll see you soon for the next video.