train keeps derailing on curves for no reason

[minningguyteen2]

if i drive any train for a great length of time this happens:

[EternalBlueFlame]

It's a long-standing issue with the pathfinding (far as I know this issue has existed since before 1.5x).
For most turns it's best not to exceed 80km/h or that will almost always happen.
Sometimes it can happen randomly with low TPS as well.
Longer locomotives such as the ICB are more prone to it than the smaller ones as well, so it's best to go slower with them.

The only fix is to rewrite the entire pathfinding mechanism, which is quite extensive especially considering each rail shape has it's own path calculation that's more or less pre-defined via calculus over an arc between start and end points, rather than an actual path.

This is fixed in the rewrite by using actual paths and segmented block-safe movement, but due to difficulty and the planned timeframe of it's release, it's unlikely this will be fixed before the rewrite.

[quentfr21]

hello

this can be solved if you adjust the ypos in the MoveOnTCTurn method i personally add 0.15 to the y

this make train "fly" a little on track but no more derail

[NitroxydeX]

No attack right here but @quentfr21 your quality of solutions were never good. All rails have the same position-system so adding something to the y won't make it magically work. In fact in that current system values too high and too low can make it WORSE. So 0.15 could already be too much especially for a flat track.
The problem is the current system of handling that stuff and breaking when the performance of minecraft drops below the stable 20tps

[EternalBlueFlame]

If it was a concern of the Y position then it would never work in the first place because that never changes during a curve or the transition onto one unless coming directly off a slope, which clearly isn't happening in the image.

The issue is primarily because the pathfinding code is checking by the full motion at a roughly calculated point for the front bogie based on the rotation, so the longer the train the more inaccurate the estimated position of the front bogie will be, and the faster the movement the further apart the check.
So if you are moving faster than 1 block per tick (which several TC trains can do, even more so on servers/clients with low TPS), you are actively skipping blocks during the check, and if you miss a single block on a turn, you're going in the dirt, likewise if you miss one on a slope, the train will think you ran into a wall or fell off the track.

I have actually managed to fix this issue completely in the rewrite by segmenting the motion into a loop for every 0.3 blocks/meters. This does mean a good bit more processing depending on train speeds, but fixes the error perfectly and prevents derails at speeds upwards of 500km/h with wagons up to 80 blocks long around any size corner or slope.
Additionally because the update processing of trains in the rewrite is less than a tenth of current TC's, and slowly improving, it can afford the overhead.

[Melon1917]

Howdy
I made an account just to comment about this, because this issue seems to persist in the current version of traincraft. more specifically, i noticed this only happens in jungle and swamp biomes. Maybe i'm incredibly unlucky or maybe its some random issue with the biome and the tracks. either way, no matter how slow or fast or what locomotive i use, i will always derail 100% of the time on any sized curve. like i said this issue only came up in the 2 biomes and no where else when i build curves. is there anything about this issue at all? Much thanks.

[EternalBlueFlame]

There is the chance that those specific tracks didn't save correctly, and breaking them and placing again will fix it.

But in most cases, jungle and swamp biomes are a lot more likely to have additional entities and moving blocks, these create extra strain on the entity update tick phase, which is a troublesome subset of the tick phase that can fall behind even when the normal 'world' or block ticks don't.

Everything moves by what's essentially a small teleport 20 times per second, then smoothed out for rendering, but every missed tick from having too much to process will effectively double how far it has to move that next tick, this isnt so much of an issue for things like creepers. But for trains, at that rate you can imagine how quickly it can add up and how easily it would be to create a teleport big enough to end up off the track block.
The user level solution is basically get better single-threaded performance, like turning off hyperthreading if your BIOS allows, or getting a CPU that has better single threaded performance. I realize how bad of a solution this is, no one just bleeds money to go buy new CPU's at the drop of a hat, especially in the current market, but that's exactly what it falls down to for a user level fix.

The 5.0 builds fix this by putting the movement in loops of 1/3 or less of a block, and then doing it in a sequence for the entire movement length, but this is a persistent issue in TC4/TCCE builds and will likely not be addressed in those builds, especially as TC5 gets more fixes, and expands to better cover the features that TC4 had.