(Un)known issues Rocket League

Patch 2.32

Description

Neo Tokyo Hacked seems to have a slightly different physics mesh which means that exact bounces could potentially be different (most noticeable in custom training). Proof in video. The small boost pads only also seem to have slightly smaller hitboxes than on the other maps.

Possible cause

Psyonix used to have slight differences on all standard maps due to making them from scratch. At some point in the past, they decided to ensure that they all use the same mesh and boost pads to make it less confusing and more consistent for the players. Since then, multiple maps have slipped through the cracks of this standardization until the community has made them aware of it.

Possible solution

Fixing it is as easy as applying the correct preset that every map has and releasing a patch. Fixing the reocurrence of this issue would likely need a organizational change.

since release

Description

The current implementation of demos has not in itself shown any signs of being bugged. All calculations seem to run as expected when there is no lag. The exact requirements for a demo are explained in this video from Rocket Sledge. These rules create some situations where most players intuitively assume that a demo should occur but it doesn't and vice versa. Psyonix has even indirectly admitted that the rules are imperfect by attempting to change them multiple times since the release of Rocket League. Unfortunately, other iterations had just as many (or more) weird edge cases. On top of that, the other edge cases were not what people were used to from many hours of playing and were thus perceived as less intuitive. Consequently, Psyonix has settled for the current rules as a good enough choice, but they are aware that it's not perfect system.

Possible cause

The current version of demo rules exist because Rocket League, like any video game, uses approximations in the physics simulation to enable real-time gameplay. With these approximations the simple surface impact angle calculations that the game was using for demos at release were often very inaccurate. The current demo rules forgo the angle of the surface. That allows them to avoid a good deal of the accuracy issues, at the cost of rules that don't exactly follow intuition.

Possible solution

This issue will likely only ever get fixed if Rocket League implements continuous collision detection. With continuous collision detection, surface angles can be calculated with sufficient accuracy.

since release

Description

Some bounces do not reflect at the angle that they should based on the mesh that is visible. The best way to test this is in the custom training editor with the shot prediction. It is possible to find angles on the crossbar where, when you move the trajectory of the ball up a bit, it bounces further down off the crossbar, which is the reverse of what should happen.

Possible cause

Wrong bounces happen due to 2 reasons: Either there is an invisible mesh part that is in a position it shouldn't be, or it happens because of the limited tick rate that Rocket League uses. Physics updates happen 120 times a second. From one tick to another, it is possible that the ball moves into the wall with a small overlap. On a flat part of the wall, this doesn't really matter. On a heavily curved part like the posts, the overlap can cause surface angle calculations that don't match the location where the ball should've touched the post. I have a video on this specific issue here.

Possible solution

This issue will likely only ever get fixed if Rocket League implements continuous collision detection. Continuous collision detection can accurately calculate the exact moment of contact, which allows the proper angle calculation to take place.

since release

Description

When going for a simple shot with a dodge, it is possible to hit the ball twice, generating significantly more power than on a single touch. An example can be found in the final shot of this video. The ball goes from 56 to 94 to 105 kph if you step through it frame by frame. Without the second touch, no shot above 100 kph was possible from that catch. It doesn't seem to be humanly possible to get this consistently, which makes it a bit random.

Possible cause

The way this works is that the first touch is not too strong. From the combination of the speed of the car and the rotation of the car from the dodge and the relative point of impact, the front catches up with the ball for a second touch. With normal physics, this wouldn't be an issue due to the conservation of energy. The car cannot put more energy into the ball than what is in the system. However, Rocket League uses additional forces that generate extra energy on every touch. As a result, every additional touch accelerates the ball by an unnatural amount. The physics are explained here.

Possible solution

There might be no way to fix this without significantly changing the feeling of Rocket League. Possible fixes would require specifically detecting the difference between shots and 50s/pinches/flicks as those are all mechanics that rely on multiple ball touches resolving.

since release

Description

Cars of the same preset, e.g. Octane and Fennec spawn in slightly different positions despite using otherwise identical physics. This affects freeplay spawns, custom training packs, and also kickoffs. Some cars may therefore start a likely negligible bit closer to the ball on kickoff than others. This can also confuse players into thinking there are physical differences between cars of the same preset, even though there are none.

Possible cause

The engine spawns cars with their visual mesh first and then attaches the physics hitbox. The alignment of the physics hitbox to the mesh is different to make the cars' visuals match the hitbox better.

Possible solution

Set the physics position to the same value after the car has fully spawned in. This is already possible with BakkesMod for testing and practice purposes, but would need to be done by Psyonix to work on online servers.

since release

Description

When running the same setup and inputs in Rocket League on the same patch on the same computer, you get a deterministic outcome. That means the same outcome can be repeated every time. That determinism is lost in Rocket League when you compare AMD to Intel Processors. And every new patch, the compiler may do slightly different optimizations and cause miniscule changes to the outcome.

Possible cause

Floating point numbers use all kinds of optimization to allow for fast calculations. There are processor specific functions for fast trigonometry for example. Reordering operations can change the outcome of calculations as well.

Possible solution

Solving this issue requires turning off certain compiler optimizations and avoiding the usage of all internals that use floating point manipulation not adhering to IEEE754 rules.

unknown (likely since release)

Description

It is possible to have occasional desyncs with the server on a perfectly stable connection without any inherently unpredictable actions occuring. The desyncs are usually very small but when using mechanics where the small difference means you do or don't get a flip, you get situations like this and this.

Possible cause

It is impossible to know exactly what causes this issue without having full access to the Rocket League servers. However, it's conceivable that all these desyncs happen due to the physics inconsistencies between processors.

since release

Description

The kickoff start is invisible to the player until they receive the first signal from the server. This is very obvious when playing on servers with > 200 ms ping, but the issue is not exclusive to those.

Possible cause

The kickoff countdown on the player's computer only updates when it receives the signal from the server (with the internet delay) even though it could be synchronized to the real moment where it happens. This also prevents the player from seeing the movement of the car for the first X ms after the timer hits GO, where X is your ping.

Possible solution

The same kind of prediction synchronization that the game uses for normal gameplay just needs to be applied to kickoffs. There is a chance that the current implementation would need a significant rewrite because the kickoff situation is considered a paused game state.

since release

Description

Failed flip resets that almost succeeded may occasionally cause your car to jerk out and be completely unrecoverable in non-local games.

Possible cause

Rocket League's netcode always tries to predict the true state of the server on your computer/console in order to give you online games with no additional input latency. When the prediction is incorrect, it uses the information sent from the server to correct the prediction and show you the true state of what happened. The server does not currently send information about whether you have your flip available. If your computer incorrectly thinks you've gotten a flip reset on the ball due a slight misprediction, it will not be updated until after you attempt to use the flip. This causes those flip resets where the flip just seems to warp the car all over the place, as the prediction of the flip attempts to get reconciled with the server saying that there can't be a flip.

Possible solution

The netcode needs to send extra data from the server to the players about their current flip availability. This would solve all the cases where there is a delay between the player getting the flip and them using it. The cases where players try to flip immediately as they get the flip reset are not 100% solvable, as the server cannot send that information faster than the speed of light. It is likely that they would happen less often if the unnecessary desyncs were solved.

unknown (recent)

Description

When playing over the internet, a perfect connection does not exist. However, there are indicator icons that are supposed to flash when the connection between the player and server becomes too bad, or the server itself fails to run properly. Recently, there have been many cases of such server issues, with all players on the same server experiencing very severe lag. The server health icon does not always flash correctly and the network indicators suggest that it could also not be due to fluctuating ping or packet loss.

since release

Description

The average frame rate drops and becomes highly inconsistent when pressing buttons or moving the analog stick on a controller at the same time as pressing keyboard buttons or using the mouse. The issue may not be noticeable in a GPU bound system, or if a low manual frame rate limit is used. This issue will affect people trying to use hybrid input methods for comfort or accessibility reasons as well as analog keyboards that use controller emulation to send analog signals.

Possible cause

This happens because of the user interface. When you change the input device, the UI updates to show you the correct button prompts for your device, but when you use multiple device types at the same time, it attempts to switch back and forth every frame. This shuffles a lot of resources back and forth in the background for no purpose, and causes the framerate drops.

Workaround

You can use the BakkesMod console command cl_rendering_scaleform_disabled 1 to disable the entire UI at the downside of, well, disabling everything in the UI. It is also possible to use paid third party software like reWASD to combine the input methods into one virtual device.

Possible solution

Providing users with an option to freeze the UI buttons to controller or keyboard bindings would prevent this issue. Alternatively, checking whether the user is actively inputting on two devices at the same time before switching would at least prevent the majority of the switches.

since DX11 version

Description

The boost UI has a significant impact on game performance since the DirectX 11 version of the game has been released. On low end computers or at very high frame rates, it can reduce performance by over 10%. When boost is set to unlimited, the UI doesn't have to update and there is no performance impact. It's confirmed to be UI related, because there is no performance hit in the same situations when the UI is disabled.

Workaround

You can use the BakkesMod console command cl_rendering_scaleform_disabled 1 to disable the entire UI at the downside of, well, disabling everything in the UI.

unknown (likely since free-to-play)

Description

The minimum level required to play ranked in Rocket League can be circumvented simply by queueing in a party where the party leader has the required level. Everyone else can be any level, which is likely unintended. Source: Wayton Pilkin video.

since patch 2.20

Description

This mainly affects mouse wheel inputs in the replay editor where it is by default bound to zoom in/out in 5° steps. These steps become 10° as a result of this bug.

Possible cause

This bug was introduced when fixing a previous issue where turning the mouse wheel counted as pressing a button down, but never lifting it up again. This was causing the mouse wheel input to get stuck. The new version has no such issues.

since release

Description

The circular overlay that allows you to switch between players, camera perspectives, and game speed percentages can sometimes refuse to close. The game will then no longer accept any other inputs, making it impossible to hide the wheel, access any menus, or even quit the game the normal way. The process may have to be killed through the task manager.

Workaround

By trying different button combinations of modifier keys (Ctrl, Alt, Shift) and keys that are bound to bring up the wheel it is sometimes possible to get the wheel unstuck. However, there doesn't really seem to be a notable pattern to it, and sometimes it doesn't get unstuck at all.