Speedrun-Specific Wishes, Issues, & Glitches

[kinkinkijkin]

Hi there, yes I already know this is one of the few games where speedrunning can truly be argued to be the wrong way of playing the game, let's get that out of the way at the top here. Every speedrunner of these games has also played the game casually, extensively, and speedruns the game as an extension of our appreciation of the game. I want to request users not to comment about this, please, we already have to deal with other speedrunners considering trucksim runs to be "meme speedruns".

Anyway, the game has a few glitches & minor problems that are almost-exclusively relevant to speedrunners, and none of them are advantageous for speedruns. We didn't feel that bug reports would be appropriate, given the nature, longevity, and non-bug natures of much of these. Also some of these are funny, and at least one would likely be expensive and time-consuming to fix. We do not think SCS would or should prioritize speedrun-specific issues, as we're an extremely small portion of the community. Also: no, we do not currently allow modded gameplay on the leaderboards whatsoever, and yes, that includes your favourite map mods. All of these behaviours are part of the unmodded game.

Glitch 1: Launches
When objects intersect too deeply, the collision resolver will end up giving at least one of them a huge amount of velocity to try to fix that. This is clearly at least somewhat intentional, in case something gets stuck. However, sometimes when driving at high enough speeds (130+ unloaded, as low as 85+ with heavy cargo, as tested by me, but hardware-dependant) your truck can be launched by any contact at any moment (including the ground or itself), if you get a long physics tick for any reason. Once launched, your truck can also enter an infinite loop of launching off of itself once it's in the air, which was accidentally used in the following speedrun that resulted in all runs with launches (including unintentional) being banned on our leaderboards:

Watch on YouTube

These unintentional launches have gotten more common in newer game versions. The newer truck physics seem to make it more likely for the truck to launch off of its own components at speed, and it seems more likely to get a physics tick just long enough to cause it, especially while streaming. Confirmed in all currently-public game versions (1.0 - 1.55) on all available platforms (Windows, Linux (native), Linux (proton)) by multiple persons. Present in both ETS2 and ATS. Slightly mitigated by having a better PC and lowering your settings. We believe the source of this bug may be rooted too deeply in how the physics engine in the game works to fix inexpensively.

Guide on how to perform an intentional launch (you know, in case you want to show it off for your friends) by dvrk7:

Watch on YouTube

Additionally, you can get a high likelihood of a launch by driving over uneven grass at very high speed. Twitch clip example (warning: significant & excessive profanity)

Glitch 2: "Death Bumps" / "Potholes"
Odd road collision that causes the truck suspension, on newer versions of the game, to freak out. Freakout attested in 1.53, not present in 1.32. We have not yet bisected versions to figure out where the suspension behaviour was introduced.

In some places in bits of old mapping, when driving over some road connections at very high speed or while speeding with a heavy trailer, you will feel a little "bump" in your truck, then a few seconds later your truck will veer off in an essentially-random direction. Mitigated by knowing where these bumps are, and lifting the accelerator while going over them, then letting back on it slowly. Example location: On the A1 just outside Newcastle Upon Tyne, southbound, correct side of the road, at the connection between the southern edge of the southmost exit and the upcoming left turn. Platform-agnostic. Newer mapping style ends up naturally avoiding these and no potholes have been found on any DLC or rework road as of yet. Not yet observed in casual play. Will return with video of this later. We have not verified the location of any death bumps in ATS.

Glitch 3: IGT pause/loadscreen inconsistency
When pausing the game, the in-game clock immediately pauses. When unpausing the game normally, the in-game clock resumes at the start of the unpause animation (screen fading in from black). In older versions of the game (1.31/1.32 for certain, 1.45 maybe?) when a loading screen is triggered (such as by using a ferry, or changing graphics settings to despawn traffic) the in-game clock doesn't continue counting until the loading screen is done. You have control immediately after a loading screen, so loading screens waste typically less than a frame's worth of IGT on older versions. In newer versions of the game (uncertain from when, present in 1.53 for certain) when you regain control from a loading screen, around a second's worth of in-game time will have been wasted (compared to 1.5 seconds when plainly unpausing). As all of our IGT city-city runs except edinburgh-london have moved to 1.53+ for the new fastest truck, this means we're no longer allowed to pause for any reason during these 2-hour constant high-speed driving speedruns, as every pause always loses at least a third of an in-game minute. This seems like something relatively easy to fix, and I can (& likely will) collect the necessary information to make an official bug report. This one is not fun or funny.

Issue/wish: some means of verifying mods in video
We want to add categories in certain very popular map mods, or to allow moderator-sanctioned mods for setting up certain categories, but it's currently not possible to allow mods as we're unable to verify that mods on a profile are the real mod they're claiming to be. Some in-game tool to make players look at, which can be used to verify mods in video, and isn't susceptible to splicing / editing, would be seriously appreciated. Needs to be resilient to simple checksum matching, workshop/non-workshop cloning, & players being on different platforms. Since most runners are fairly technically-inclined and this isn't likely to be useful for normal users, this can look as crude as necessary, as long as it doesn't require setting the developer option to 1 to see (as setting developer mode is also banned & must stay banned on our leaderboards).


I think there was more, but I can't remember them right now. I'll be linking this thread in the trucksim speedrunning discord for other runners to comment on (as well as prove that i finally actually wrote & sent it lol ive been promising to for months). Feel free to comment on / replicate these yourself. Launches in particular are very funny.

[Grizzly]

I do wonder about glitch 1 in the context of project road trip. Give people powerful cars in the game and they will drive fast so maybe they'll have to improve the time resolution of the physics.

[kinkinkijkin]

I do wonder about glitch 1 in the context of project road trip. Give people powerful cars in the game and they will drive fast so maybe they'll have to improve the time resolution of the physics.

I doubt road trip will be significantly affected. The likelihood of random launches scales with a combination of weight, suspension complexity, and speed, and trucks are susceptible to so many random launches due to being heavy and having cabin suspension. Would hate to eat my words here, since I'm hoping one of the Road Trip cars will be optimal for ATS city-city runs, and it'd suck if they get tons of random launches.

Also, I said I'd be back with video demonstrating "glitch 2", Death Bumps. 100% clarity: it's most likely these aren't a physics issue but just weird road geometry. And again, none have been located in ATS as of yet.

Watch on YouTube

[automaton]

Weird road geometry makes sense. That seems to have gotten a lot less common as the regions drastically improved in qua0lity since ~2010 when the original UK map was made... which is probably why they're much rarer (if not gone altogether) in ATS.

[Some newbie driver]

I will guess most of the physics related problems root from the main loop of the game being single core. For sure they had to put limits in the complexity of the physics calculations in order for them to not consume too much. That means that, when your specific situation is an outlier of what it's expected (for example, trucks driving at way higher speeds than expected); weird things are more prone to happen.

We know they are improving the game engine piece by piece to achieve a more proper multi-core main loop. Probably that's one of the reason for the migration from Bullet to PhysX that is happening. If they eventually can move all physics calculations to its own CPU core, most of the physics-related glitches should be gone for good (among lots of other potential improvements).

Regards

[kinkinkijkin]

I will guess most of the physics related problems root from the main loop of the game being single core. For sure they had to put limits in the complexity of the physics calculations in order for them to not consume too much. That means that, when your specific situation is an outlier of what it's expected (for example, trucks driving at way higher speeds than expected); weird things are more prone to happen.

It's more likely to be related to exactly *how* physics calculations are done; the engine doesn't use fixed-rate physics (so, physics ticks can represent any amount of time, ie anywhere from a millisecond to a kilosecond, and more) and figures out how to resolve problems after figuring out where to move things. Pretty normal for something that's not needing deterministic physics, but it ends up meaning that any calculations based on the depth of intersection of two objects can be effectively-random (eg, damage currently also seems to be based on this, and as a result is effectively-random) if the performance varies moment-to-moment by a large amount. If you then have a small lag spike from, say, loading random traffic, you can end up seeing odd things happen.

For a point of reference as to why I say this, look at the Trackmania series. These games almost all run in a single thread, but they have deterministic physics that are calculated at a fixed rate. Changing framerate in those games doesn't end up causing any new physics bugs, the game just gets choppier.

This isn't claiming that fixed-rate, deterministic physics would help the trucksim games, though; these have a tendency to be difficult and time-consuming to program, and significantly increase the processing power required for every little bit of complexity. For a game like ETS2 and ATS with very complex suspension simulations, random traffic with its own suspension being simulated, which is also not a competitive racing game, dynamic-rate physics make a lot more sense. The unfortunate fact of the bugs that dynamic-rate physics can cause/exacerbate is that fixing them is kind of an exercise in physics tuning, which is basically just rotting your brain rebuilding the game over and over with slightly different values in some specific numbers until the bug is no longer noticeable.

But that's all speculation, of course

[Some newbie driver]

Yeah, I mean how are they calculated but not only in the sense of what you mean but also in other senses

The regular equations we could learn to solve lots of physics events are NOT suitable for real-time "low-CPU-footprint" scenarios like video-games. In those cases, lots of those "standard" equations are translated into other calculation methods that are more suitable as far as your calculations are restricted between the range of values those alternative methods are meant for. Because those alternative methods return approximations that are only good enough if you remain in the expected range of input values they had been tuned for. Is like all those fast alternative methods to calculate pi (that maybe you remember from school); they were good enough depending on how many precision needed the calculations you were doing after.

Several years ago I remember Max explaining us here why the physics of the game in that moment did weird things when driving cars (from some mods). The simple reason was the weight of the car was so low (compared with a truck, even if only the cabin) that the physic formulas he coded in the game were returning results that were plain wrong. Those formulas weren't adapted to deal with vehicles of little more than a ton of weight.

He and other devs had been improving physics all those years, little touches here and there. But the essential remains because how CPU constrained they are: whatever calculations they make have to share CPU with almost everything else and that limits how often the physics thread can work and how much time he has to return results. That's why I said an hypothetical full multi-core development in the future has potential to solve most of those issues; the physics engine could potentially be working all the time in it's own thread with it's queue of job requests but not being interrupted to make room for another thread.

And that's WAY MORE easier said than done.

Take as example the recently launched BF6 demo. The amount of physics calculations they had to manage to depict all that scenario destruction, it's insane. No wonder that, in opposition of the tides in the industry, their developers had clearly stated that NO WAY for them to switch to Unreal Engine. They have been working for years polishing the Frostbite engine that allows them to achieve that result. They aren't going to throw all that effort to trash bin and switch to a crappy generic engine just because a bunch of ignorant people keep yelling "use UE5" on social media.

Regards

[kinkinkijkin]

Forgot to respond to this when I read it, yeah sorry I assumed you were going about a misconception a lot of gamers have about threadedness of games improving function directly. It makes sense 100% that some threading would allow SCS to make the physics calculations to be more strict / less approximate, given the CPU load of the game & its likely threadability. Was a bit jumpy there with my response.

Though yeah, this gets into why the current thought is that launches would be expensive & pointless to patch, since they almost exclusively affect gameplay that only ~128 people have ever tried, and only ~6 currently actively do, and improvements to physics tend to be pretty crammed against cputime budgets. If they do end up breaking off a physics thread, and reworking the physics to use the new cputime budget, I would personally love to see launches gone, though. They're very funny from a casual / viewer perspective, but they're one of those killers that strike in the night, for our speedruns, and they're pretty disruptive when casual players manage to experience them as well.

[kinkinkijkin]

and oof, 1.57 both adds the new fastest truck (2-10km/h faster on good highway, not worse at anything, notably good in IGT runs) and changes the loading procedure so the truck instantly has 0 momentum after changing your graphics settings.

this ends up meaning that city-city IGT runners like me have to choose between running an objectively-slower version of the game, or needing to pray through the entirety of the run that we don't get trapped by traffic, since we can no longer despawn traffic without the run being dead immediately. In effect, city-city IGT runs are functionally dead (except edinburgh-london, which is still run on 1.31, though that might change after the britain rework) unless some other way of avoiding being trapped by traffic finds its way into the game. Due to all of the invisible walls & their role in trapping in the first place, this would mean changes from SCS to old areas, not new speedrun techniques. Newly-mapped areas are less-significantly affected due to SCS putting the invisible walls in more advantageous locations, and less roads having barriers that don't exist in real life.

I'll say that I understand this from a casual QoL perspective, and a bugprevention perspective while working on new physics, which actually makes it more disappointing to me that it's happened, since it means it's not likely going to ever be changed back.

[Madkine]

I'm hopeful but not confident that they'll fix the loss of momentum when changing settings. Though their explanation of why it changed wasn't great since it's worked the previous way for years now.