People who've started playing SuperTuxKart after 1.0 came out or who didn't play it too much have likely never encountered or even heard of this bug present from STK 0.9 to STK 0.9.3.
I. The bug
The bug would manifest itself as the kart hovering very slightly above ground. Because it was technically still in the air, wheels were unusuable for steering. With an uncontrollable kart, a crash was extremely likely and the only question was how much time would be lost.
The issue would only happen in a specific places that shared a common characteristic : a descending slope. Shifting Sands and Cocoa Temple were the two most notable tracks where the issue could occur, but it could and did happen elsewhere (quoting qwertychouskie: "I have seen this issue a lot in many places, once a kart leaves the ground, it doesn't want to go back on the ground if it has a downward slope.").
Another reason it didn't happen to everyone was that the kart also needed to jump off the ground first, and in Cocoa Temple the place where it would happen needed the player to have jumped on the rocky ledge right of the road. While this was the optimal path, only a select few players were using it on purpose. In Shifting Sands, the bug was much more common, but less catastrophic in its consequences. Here is an old video demonstrating the bug in Shifting Sands.
II. The cause
The observed triggers of the bug and further investigation by hiker and myself revealed the "cushioning" system as its cause.
SuperTuxKart used to have "cushioning" logic, introduced during the development cycle of STK 0.9. The purpose was to slow down a falling kart just as it was about to touch ground to prevent the collision from being too strong. A too strong collision would overwhelm the kart's suspensions and cause a collision between the kart's chassis and the ground, triggering the crash sound and making the landing less smooth with the likelihood of lost speed or possibly a deviation in trajectory.
But it didn't account for the fact that, as the kart would continue to move forward, the height of the ground would also change. As a consequence the cushion impulse would be too strong and the kart would not fall enough on the following frame to actually touch the ground. In this old video starting around the 12s mark, the hover bug can be seen occuring in Cocoa Temple not once, but twice in a row.
III. Attempts at fixing
The bug was declared solved after hiker introduced logic to disable cushioning for a set period of time after it had been first triggered. Without repeat activations of the cushioning impulse, there was no hover bug anymore.
Unfortunately, the cure was worse than the poison.
Hiker deemed the first report a track issue, but more instances of the bug happening quickly made clear it was much worse than that. The final nail in the coffin of this theory was Qwerty's bug report accompanied by a video showcasing a kart skipping through the air.
The problem with the initial fix was that it assumed that the correct vertical speed the kart should be slowed to was 0, which only worked if the landing spot was fairly flat. As soon as slope was involved, this expectation was wrong, and 0 vertical speed would mean the kart would "bounce" off the track immediately after having touched.
I made a series of commits to address this issue (here, here, here, here, and here), taking into account the kart's height above ground, the slope and then trying to fix second order issues of the kart bouncing up in cases where the ground height changed suddenly.
It essentially worked, but it was a patchwork of ad-hoc tricks, and it was bound to have some rare edge cases where it would fail, the fact that several commits after the initial implementation were needed to patch out those that were discovered pointed in this direction.
At this point, hiker got fed up. I was first asked to revert my commits, and then the entire cushioning system got removed, replaced with much stronger suspensions.
While it didn't always help quite as much as the cushioning system, the stronger suspensions had no weird edge case to worry about and the code got much simpler. In the end, the better solution was also the simpler one.
I. The bug
The bug would manifest itself as the kart hovering very slightly above ground. Because it was technically still in the air, wheels were unusuable for steering. With an uncontrollable kart, a crash was extremely likely and the only question was how much time would be lost.
The issue would only happen in a specific places that shared a common characteristic : a descending slope. Shifting Sands and Cocoa Temple were the two most notable tracks where the issue could occur, but it could and did happen elsewhere (quoting qwertychouskie: "I have seen this issue a lot in many places, once a kart leaves the ground, it doesn't want to go back on the ground if it has a downward slope.").
Another reason it didn't happen to everyone was that the kart also needed to jump off the ground first, and in Cocoa Temple the place where it would happen needed the player to have jumped on the rocky ledge right of the road. While this was the optimal path, only a select few players were using it on purpose. In Shifting Sands, the bug was much more common, but less catastrophic in its consequences. Here is an old video demonstrating the bug in Shifting Sands.
II. The cause
The observed triggers of the bug and further investigation by hiker and myself revealed the "cushioning" system as its cause.
SuperTuxKart used to have "cushioning" logic, introduced during the development cycle of STK 0.9. The purpose was to slow down a falling kart just as it was about to touch ground to prevent the collision from being too strong. A too strong collision would overwhelm the kart's suspensions and cause a collision between the kart's chassis and the ground, triggering the crash sound and making the landing less smooth with the likelihood of lost speed or possibly a deviation in trajectory.
But it didn't account for the fact that, as the kart would continue to move forward, the height of the ground would also change. As a consequence the cushion impulse would be too strong and the kart would not fall enough on the following frame to actually touch the ground. In this old video starting around the 12s mark, the hover bug can be seen occuring in Cocoa Temple not once, but twice in a row.
III. Attempts at fixing
The bug was declared solved after hiker introduced logic to disable cushioning for a set period of time after it had been first triggered. Without repeat activations of the cushioning impulse, there was no hover bug anymore.
Unfortunately, the cure was worse than the poison.
Hiker deemed the first report a track issue, but more instances of the bug happening quickly made clear it was much worse than that. The final nail in the coffin of this theory was Qwerty's bug report accompanied by a video showcasing a kart skipping through the air.
The problem with the initial fix was that it assumed that the correct vertical speed the kart should be slowed to was 0, which only worked if the landing spot was fairly flat. As soon as slope was involved, this expectation was wrong, and 0 vertical speed would mean the kart would "bounce" off the track immediately after having touched.
I made a series of commits to address this issue (here, here, here, here, and here), taking into account the kart's height above ground, the slope and then trying to fix second order issues of the kart bouncing up in cases where the ground height changed suddenly.
It essentially worked, but it was a patchwork of ad-hoc tricks, and it was bound to have some rare edge cases where it would fail, the fact that several commits after the initial implementation were needed to patch out those that were discovered pointed in this direction.
At this point, hiker got fed up. I was first asked to revert my commits, and then the entire cushioning system got removed, replaced with much stronger suspensions.
While it didn't always help quite as much as the cushioning system, the stronger suspensions had no weird edge case to worry about and the code got much simpler. In the end, the better solution was also the simpler one.