When a locomotive has a top speed greater than 65 km/h, as soon as it is given a cart to pull its speed caps at 65 km/h even though the locomotive's GUI says its max speed is much greater than that. When not pulling a load, it goes at its top speed. For example, when a Hiawatha 1935 MILW Baggage cart is attached to an ICB, the ICB's GUI states that its max speed is 279 km/h. However, if I actually drive the train, I cannot get it to go faster than 65 km/h.

Looking into this more it's actually not a bug, the max speed when linked is reduced based on the weight pulled as compared to the MHP of the train, trains with higher MHP like the DD35 (at about 5k MHP) aren't effected by it much because they have the power to haul it, but weaker trains like the ICB (700), or older steamers, that don't have the power to haul heavier loads, will be effected much more.

The real issue is that the weights system is just flat out unbalanced, as the passenger cars should be much lighter then freighters with big loads, but it's most all about the same, which makes the trains look unbalanced rather than the stock which is the more accurate cause.

I think you misunderstood. The exact same thing happens with all locomotives faster than 65 km/h, however. The ICB was just one example. I have tested this with many locomotives and every single one I tried had their speed reduced to 65 km/h regardless of their max speed or MHP.

When I take an ICB, which in-game is listed as having 13080 Mhp, and attach a Hiawatha 1935 MILW Baggage cart, with a mass of 5 tons, the max speed stated in the GUI is 279 but when I drive it, it will not go faster than 65.

When I take a DD35, with 5069 Mhp, and attach the same 5 ton baggage cart, the stated max speed is 143 km/h but when I drive it, I cannot get it to go faster than 65.

When I take a Coronation Class, with 1545 Mhp, and attach the same 5 ton baggage cart, the stated max speed is 182 km/h, but when I drive it, I cannot get it to go faster than 65.

When I take a Forney, with 600 Mhp, and attach the same 5 ton baggage cart, the stated max speed is 69 km/h, but when I drive it, I cannot get it to go faster than 65.

The same thing happens if I use a cart with a different mass.

The problem is that no matter which locomotive I test, and I've tested many others, no matter what amount of Mhp it has, as soon as any amount of weight is applied to it, its speed is capped at 65 km/h, which cannot be right. Locomotives with max speeds less than 65 km/h behave as expected - I can drive them at about the same speed as what is stated as the max speed in the GUI, plus or minus 1 km/h. Also, once enough mass is applied to a locomotive whose max speed is above 65 km/h that the max speed stated in the GUI is less than 65 km/h, it will start behaving as expected as well.

One possible difference between what I am seeing in my game and what you are seeing in yours is that I set REAL_TRAIN_SPEED = true in my configs. I liked the fact that, since 1 block in Minecraft is considered to be 1 m wide, the locomotives were literally going the speed they said they were going, which I don't think was the case before, though I never actually measured it; I just know that they seem to be going faster now, so long as the locomotives aren't pulling anything. I'm not sure yet if this still occurs if that config setting is set to false as it is by default.

It seems this bug does not occur when REAL_TRAIN_SPEED=false. However, I would hate to leave it set to false because of how much slower the trains are. I measured the speed of the Forney with REAL_TRAIN_SPEED=false and found its speed to be a pitiful 23 km/h when it should be going 70 km/h. This makes trains less useful.

Is this intentional? Is there a reason a locomotive carrying any sort of load must have its speed capped?

The real train speed toggle is only a GUI change, it shows a more direct relation to the movement speed in minecraft units, rather than real ones. It doesn't actually effect movement.

However after a LOT of digging around i did find two sources of the issue, one of which made the calculations very inaccurate, and another one which stopped the calculation from even happening in the first place.

I reworked the calculation to be a bit more accurate, and i made it so it's actually called.
I also had to rework the datawatcher to transfer a float rather than a string for the max speed so it could be properly used on client.

forgot to tag this issue thread in the git push
53c1657

It doesn't affect movement? I'm not trying to argue; I'm just very confused because this does not line up with what I am seeing in-game. A few days ago I made a 2,000 block long track in a superflat world to see how fast the trains really were and figure out what the real train speed config option did. The first 1,000 blocks gives the locomotives plenty of time to accelerate to their max speed, and when they hit the second 1,000 blocks, marked by some wool, I use a stopwatch to measure how long it takes them to travel 1,000 blocks at top speed. It was while messing with this track that I discovered the cart-pulling issue. I did an experiment.

With real train speed set to false, the VL10, with a max speed of 100, took 1 minute 48 seconds to travel 1,000 blocks at top speed. I quit the game and changed real train speed to true. In the GUI, the VL10's max speed is still said to be 100. This time, the VL10 took 36 seconds to travel 1,000 blocks. When you do the math with 1 block = 1 meter, in the first test the VL10's actual speed was 33 km/h and in the second it was 100 km/h. That's why I thought the real train speed config changed the movement speed and not the GUI and was very excited when I figured this out before I found out that attaching any carts capped a locomotive's speed to 65 km/h.

Well from what I'm seeing there's nowhere in the code it actually applies to entity velocity, all the uses are just used for the GUI.

But this is TC, so it is possible something is more or less reverse engineering the resulting data somewhere, for some god awful stupid reason....

This has become a much more confusing issue than I expected. Although, I do greatly prefer the faster trains with accurate speed. Why is it that locomotives are so much slower than they say they are? I mean, it's well known that 1 block in Minecraft is 1m x 1m x 1m. So, when a locomotive said it goes 100 km/h, I expected that to be the same as kilo-blocks per hour and was so confused why the locomotives were significantly slower than I calculated they should be. With the locomotives going at their actual speeds thanks to REAL_TRAIN_SPEED = true, trains are now the fastest thing in the modpack I'm working on, which also has airships and jetpacks, which is nice.

It really does seem to have become a rather complex issue.
The biggest factor is that none of the values in the mod for speed, acceleration, load bearing, linking distance, entity positioning, rotation, etc, are accurate, not even close to be fully honest, never have been.

As to why, I'm not sure, but judging by the code I'd assume the previous maintainers were having a hard enough time keeping it stable and implement the larger rails (which the old notes they left behind note as highly unfinished), let alone trying to reach accuracy, and some look to be there for an attempt to balance it as a game rather than be the real values.

There isn't much I can do for it until the rewrite, since most of it would require rewriting sections of code that would dwarf the changes I linked above, many of them would also require restructuring various data management parts which could do even further damage to the reliability of the NBT, and other saving systems.
And there's some parts, like entity registration and the enums that just straight can't be fixed without changing crucial mod save data like ID's, which would remove them from the world, or turn then into other objects, probably with the NBT and metadata which could go as far as corrupting the chunk.

So meantime it's more of a question of what can be fixed without needing to deal with the bigger problems, so that way the current mod is at least usable while the rewrite is still under heavy development.