I'm looking for information on the train braking mechanic.

[mmmPI]

I would say like farcast, that the friction no aero model is the most accurate. Not because "the lower delta" is better, but rather , the flatter the line is better. It's not super visible from the graphs because of ABS(delta) but with the signed value, the frictionless models sometimes predict too much sometimes too little, while in the process, being "perfect" in some cases, whereas the friction no aero model seem to have a more constant distance and trend compared to the precise ingame measurement.

By trend i mean it's slightly diverging when braking research increases. While being as mentionned constantly at a difference of at least 10.

The graphs i think clearly identify the aero model as wrong, especially the 1-0 where it's supposed to be the most impactful, is the one having the largest delta, and the better the breaking research, the less time/steps of divergence for the prediction so it looks more accurate but it's obviously not the correct formula.

I think the "more precise" result for the frictionless model with higher braking force are an artifact, just because the overall braking time is shorter, it gives less and less time for the "wrong" formula to shows it's the "wrong" formula as friction's impact is becoming increasingly marginal compared to the braking power coming from the research.

This because i think the frictionless model appear to neglect a phenomenon ( friction ), but it's not always visible because of another unknown one ( some adjustment ? ) as such when friction has low impact, it can be exactly balanced out by the other phenomenon and look 100% accurate but with more or less braking time, giving more or less time/Steps for the frictionless model to diverge ; the prediction is sometimes too much, sometimes not enough. As such i think the frictionless model is not accurate as a formula similar to aero whereas the friction model would be more accurate as a formula (over time or different conditions ) except it needs a little something more for more precision.

In my opinion i trusted the latest in game measurement the most.( they can validate/unvalidate models because exhaustive and precise ) I think it means that the shorter braking time/distance, the more difficult it is to predict what the game does ( as the "most trusted model" is the "friction no aero" for me) because the game is doing something like a nudging or an adjustment, which is made more visible when it's not given much time to hide it. ( better breaking research, making a (flat or bounded ) adjustment from the game more visible in the total % of difference compared to the prediction).

When looking at the first picture from Milo's last post, with the red and green line, i think some hypothesis can be made to describe the adjustment.

I suppose the game is made so that trains "knows" their braking distance (using the friction model). That's what we see with the debug tool as a line and how they know when to actually start braking. ( human drivers are supposed to know the braking distance of their car/truck in order to drive properly and stop at the correct spot and i don't see how to do otherwise in a model where train don't share block reserved for potential braking like racing driver in F1).

=> The train known when it needs to brake, then it start braking. The amount of time between the 2 action is either 0 or more ticks. If 0 ticks, it is very unlikely that the train using its full braking force would happen to end up at 0 speed at the exact place where it need to stop. Because time is made of discrete ticks, the train maybe one tick would end up a few pixel too early, and the next tick, a few pixel too late if using its full braking power.

= a hypothetic train going at full speed as a theorical braking distance of say 120.00000 tiles, but a speed of 1.2300 tiles/tick.
Tick 0, should brake ? distance to target = 123 tiles, no ,
Tick 1, should brake ? distance to target = 121.77 tiles, no ,
Tick 2, should brake ? distance to target = 120.54 tiles , yes ,
Tick 2 Need to start braking, tick 3 is too late. But tick 2 is a little too early, train will stop 0.54 tile off if using full braking power according to those precise math formula no ?

This is already a source of potential imperfection/adjustment that would be made relatively/significantly worse overall compared to the total amount of tick predicted from a prediction with a high braking force, because that would be a small amout of tick and as such the adjustement would in % be higher, which seems to be the trend in the graphs. ( initial offset slowly increasing with braking research always positive delta for imprecision )

Now of course it can be that train anticipate more than 1 tick their decision to start braking and that the adjustment account for the distance during that tick, and as such i suppose the imperfection would be overall greater for faster train but the measurement were all made with trains running at 1.38 tile/tick and i havent added this to my doc

TL DR : Friction no aero seem to me the more accurate model

TL DR hypothesis : braking distance and travel distance left might never be exact modulo. if trains takes a little more time to brake than what is predicted by the friction model it could be because the train first brake at its full power and then fill in the 0.54 tiles gap from the example leading to extra ticks at very slow speed just before the complete stop

[farcast]

So... trains start braking 1 meter before a rail signal, effectively adding ~1 meter to the braking distance and changing stop time accordingly.

The good news is: This doesn't happen when a train is stopping at a train stop.

The bad news is: Now there's a ~10 tick difference between calculated and measured stop time even for a 1-18 coal powered train.

I can't find a train & research bonus where the difference isn't about 10 ticks. I'm running out of ideas.

[mmmPI]

So... trains start braking 1 meter before a rail signal, effectively adding ~1 meter to the braking distance and changing stop time accordingly.
The good news is: This doesn't happen when a train is stopping at a train stop.

On the one hand i'm tempted to ask how did you come to this conclusion with math and explanations, but on the other hand, last time i wasn't able to follow everything, so i can understand you'd want to avoid that Maybe you'll spot the differences with my tests.

My guess for signal vs train stop is because signal are only 1x1 entity wheras train stop are 2x2, so that a train can shoot for the middle of it unlike a signal where train has to anticipate a little. I used a train stop for my test.

The bad news is: Now there's a ~10 tick difference between calculated and measured stop time even for a 1-18 coal powered train.

According to my calculations , a 1-18 coal powered train has only enough fuel for 60000 ticks, during which it won't reach more than 15 km/h.Was it the speed at which you got a 10 ticks difference ?

At this speed the friction model predict a braking time of 19 ticks, and my (rough) measurements give also the same 18 or 19 ticks. With the margin of error of a little coal left in the train after it burned almost the 3 stacks when braking, it wasn't exactly at its 60K ticks speed but after 60K tick speed variation per tick is almost 0.

29 ticks of braking time would mean the train is at 23 km/h instead of 15km/h which i would have definitly noticed. Same as 29 or 9 instead of the measured 18 or 19.

I'm still working on the formulas because i don't want to have 60K lines in the .ods ; i did 20K before realizing trains could have 3 stack of fuel this is the linked version

i added acceleration modeling that's when i realied it would take forever for such train to reach max speed and i would instead wait in game for the train to be almost fuel empty at speed x64, and saw the speed was around 15km/h and not increasing fast at all x) So i added +0.003 speed in the doc to make sure the braking model has same input as what's visible in game. 15.0 km/h

I then put a train stop a little in front of the train while game was paused and tasked it to stop at the train stop instead of the far away temporary point targeted for constant acceleration.

Then saved the game, and monitors when the "braking line" would turn from green to red, and from this moment i measured the ticks and counted 18 before complete stop at 19.

Which is also what the friction model predict if you give it a 1-18 trains coal powered train running at a speed of 0.6942 tile per tick or around that value which correspond to 15km/h.

TL DR : i was not able to reproduce the 10 ticks difference you mention but the example is quite and extreme case and am quite rusty with those maths

1-18 train about to slow down 3.zip

(1.32 MiB) Downloaded 73 times

speedsimu2.ods

(1.89 MiB) Downloaded 83 times

1-18 coal powered train projected speed.png (8.73 KiB) Viewed 2413 times

[farcast]

TL DR : i was not able to reproduce the 10 ticks difference you mention

1-18 coal powered train:
Total mass: 20000 kilograms

Total friction: 34200 Newtons = 19 rolling stock * 1800 Newtons per rolling stock

Total braking force:
-No research bonus: 264600 Newtons = friction + 36000 Newtons per locomotive * 1 locomotive + 10800 Newtons per cargo wagon * 18 cargo wagons

-Max research bonus: 495000 Newtons = friction + 2 * (36000 Newtons per locomotive * 1 locomotive + 10800 Newtons per cargo wagon * 18 cargo wagons)

Max speed (with forward facing locomotive in front): 4 meters per second = 14.4 km/h

Note about max speed

Drag with a forward facing locomotive in front: 450 Newtons per (meter per second)

Thrust = 36000 Newtons per forward facing locomotive * Fuel acceleration bonus * forward facing locomotives - friction
= 36000 * 1 * 1 - 34200
= 1800 Newtons

Max speed due to drag = Thrust / Drag
= 1800 / 450
= 4 meters per second

Getting the numbers for thrust and drag requires its own set of measurements and calculations that I'm not going to get into here.

Momentum = Mass * Velocity

Force = Momentum / Time
= Mass * Velocity / Time

Time = Mass * Velocity / Force


No research:
Time = 20000 * 4 / 264600
= ~0.30234 seconds
= ~18.14 ticks
Measured time: 26 ticks

Max research:
Time = 20000 * 4 / 495000
= ~0.16162 seconds
= ~9.7 ticks
Measured time: 19 ticks

Measurements are from when train state switches to ARRIVE_STATION to when it switches to WAIT_STATION, starting the count at 1 and including the first WAIT_STATION tick. Train state is viewable with show-debug-info-in-tooltips enabled.

Debug tooltip.png (218.37 KiB) Viewed 2378 times

The save you provided has max braking force research.


The extra meter when stopping at a signal can be seen visually:

Extra meter for rail signal.png (335.16 KiB) Viewed 2378 times

Just one tick earlier and the stopping point would be just barely more than 1 meter from the final stop point.

This extra meter also affects when the signal turns yellow, so it must be exactly 1 meter otherwise it would affect my braking distance meter. If it's exactly 1 meter, I can say it was accidentally removed from the braking distance measurements along side train length.


Measuring stop time to when the position stops changing gets closer to the actual stop time, but there's still a few extra unexplained ticks.

[mmmPI]

The save you provided has max braking force research.

That's it i didn't realized it was the case in the save due to /cheat all, it was not reported properly in the speed calculation which gave 14.4kmh/H and i shouldn't have approximated it to 15km/H. Using the correct value of 2 for cumulative breaking force effect gives a prediction of between 9 and 10. Which does not correspond to measured value by 10 ticks as you said.

Quite puzzling. I think i will focus on the case with train stops firsts, and assume signals are treated specially.

[mmmPI]

Getting the numbers for thrust and drag requires its own set of measurements and calculations that I'm not going to get into here.

I think you did it the hard way with measurements, but it may be possible to do using the fact that locomotive have 600 kw energy consumption which is 600 kg m2 s−3 and then 0.5 friction and 0.0075 air_resistance in some yet-to-precise units ? I mean i tried but i'm not sure if i fail because of poor math or missing a conversion somewhere, or if because i attempted something for which i was still missing data and didn't realize when trying to move around the equations. ( that's a long time since i did units analysis which i was never good at )

As the train runs through, the length from the rear of the train to the stopping point is measured with a mix of diagonal tracks and straight tracks, plus a constant from the bend in-between (8.55 + 0.5 root 2). Each multiple of root 2 from the diagonal tracks has a unique decimal measurement, and any remaining length is measured by the whole number length straight tracks. Rail signal spacing limits diagonal measurements to multiples of 2 root 2, and straight measurements to multiples of 2, but the idea is the same.

I'm not sure i'm understanding properly this part but i think it relate to the previous sentence that's the method used to do the measurements. I noticed in this thread :

viewtopic.php?p=594021

8.55 - sqrt(2)/2 = 7.84289321881 whereas it would seem that ingame the value is : 7.842081225095013

I don't think it could explain the constant discrepancy since i'm using another (less efficient) method than yours to predict time of braking and i'm still having that same 10 tick difference on a straight piece of rail.

But i'm curious now to know where this 8.55 - 2sqrt(2)/2 is coming from and if it is trully correct and/or in which context maybe it could help for the other topic

I think maybe comparing the last 60 value of speed in game and in model when braking to full stop and noting as you shown me the debug state could be interesting because i remember my old measurement giving non-linear results, whereas for deceleration the current model that has the 10 ticks difference which counts friction but no air resistance, should yield linear deceleration.

Method i used being just simulating every step. It could help to localize more precisely when it start to diverge between predicted speed/position and measured speed/position. But i don't have much ideas otherwise.

[farcast]

Getting the numbers for thrust and drag requires its own set of measurements and calculations that I'm not going to get into here.

I think you did it the hard way with measurements, but it may be possible to do using the fact that locomotive have 600 kw energy consumption which is 600 kg m2 s−3

The 600kw provided by the tooltip is both the wrong unit and the wrong number for modeling train acceleration (Edit: I suppose the number would be right if you used the unit for momentum, meaning 600 momentum is added every tick). If you actually try to use it like I did so long ago, you'll get acceleration curves that don't line up with what happens in game at all. What actually works is force, or thrust. Trains are rocket powered I guess. They run on rocket fuel so it makes sense. There should totally be thrusters on the locomotive sprites!

I made a bug report about the tooltip recently but the devs decided against changing it. I tried to be funny by taking it way too seriously but maybe that was a bad idea?

0.0075 air_resistance in some yet-to-precise units ?

You get this number if you take the number and unit I used for drag, convert seconds to ticks, and divide by 1000... for some reason. Precision concerns maybe. It's effectively multiplied by 1000 when it gets used so that last part doesn't matter. If you then divide by mass, and multiply by 1 tick, you get a %change in speed after 1 tick of constant drag force. This is how the number is used by the game, but the 1 tick multiplier is omitted because multiplying by one doesn't do anything and computers don't care about units.

I noticed in this thread :

viewtopic.php?p=594021

8.55 - sqrt(2)/2 = 7.84289321881 whereas it would seem that ingame the value is : 7.842081225095013

...are you saying reddit lied to me?! How could this be! ;~;

I fixed the numbers and blueprint in my post, but the difference is small enough that the conclusion didn't change.

It could help to localize more precisely when it start to diverge between predicted speed/position and measured speed/position.

Seems worth looking into to me.

[mmmPI]

The 600kw provided by the tooltip is both the wrong unit and the wrong number for modeling train acceleration (Edit: I suppose the number would be right if you used the unit for momentum, meaning 600 momentum is added every tick).

I made a bug report about the tooltip recently but the devs decided against changing it. I tried to be funny by taking it way too seriously but maybe that was a bad idea?

I wish it was the reason of my failed attempt but looking at your bug report i realized there was other mistakes in my work. Still to me kw is related to second, so it would not make sense that it should be added every tick without dividing by 60 first. That one i don't consider it my mistake !

I don't think it was a bad idea to be overly serious as joke. It's good to know it exist somewhere, for modded trains or fuel, for signal-less junctions, for general understanding of train behavior, for curiosity and for fun even if it didn't lead to a change in the game formulas / display one can always get back to it when needed even it's not "right" from a physics standpoint.

...are you saying reddit lied to me?! How could this be! ;~;

I fixed the numbers and blueprint in my post, but the difference is small enough that the conclusion didn't change.

I was not sure if the number you used and the one on reddit were correct and representing something like an average of right and left turn distance, or something you come up with from mathing out a certain layout, or the supposed "exact" value used by the game, now i understand it's not the correct number for what it was used ,but it would have been very hard to find the exact number used by the game from math, little by little i understand the measurement method

In the other topic when i put the number from reddit the difference was called "ginormous" ! I realized later it was also the one you used.

But i wasn't expecting it to change conclusions here either given which decimals are changed, it would have required many tests, to have just 1 tick where the speed is rounded unexpectedly, or an impossibly long braking distance for human eye to notice.

I would feel more enclined to do the long testings enabled by very precise model if i had an hypothesis to test or a particular need for a project . I know those math can apply to jumpings trains from the mod renai transportation, which are hard to use because one need to be very precise in managing their speed when going on a ramp and their braking distance and overall momentum, and different trains react differently, it would give some spice to the further research

[aaargha]

If anyone is interested in doing further tests on this in the future I made a small mod to make the measuring easier. The mod listens for train state changes and starts tracking trains that go into defines.train_state.arrive_station or defines.train_state.arrive_signal. While a train is tracked some simple characteristics are logged to a file called train_brake_measure_results.txt in the script-output folder. The tracking stops once the train changes to another state/is destroyed/similar.

The data logged has the following |-separated format:

game.tick|train.id|train.speed|train.pos.x|train.pos.y

The values for position are taken from the position of the "front" stock in the direction of travel.

To use the data, simply import it to you favorite flavor of spreadsheet program
Multiple trains can be tracked in parallel without issue as long as you sort the results by train.id first and game.tick second.

The mod is shared under the Unlicense so anyone is free to use/adapt it to their needs. If you want to log more data, simply add it to the measure_train() function.

Do note that it should not be used in normal gameplay, the mod will happily log data until your disk is full.

[mmmPI]

i don't know how to write a command to " Export the speed of a locomotive entity every tick in file".

If anyone is interested in doing further tests on this in the future I made a small mod to make the measuring easier.

That's perfect, i'm interested in using the mod and looking at how it's done thank you !

There are plenty of mods on the portal that are tagged as "for personnal use only" , or hidden as "internals" maybe yours would please someone not following the english discussion on the forum, but still happy to run precise measurement

[aaargha]

Cheers! I hope you're able to get some useful results!

The mod would need some additional work before it's ready for public distribution, at least a way to cap the output size would be needed; anyone finding it in this thread and manually installing it will be aware of the potential side effects and the limited intended context of use. As I don't really intend to do more work on this mod, I wouldn't be comfortable putting it on the portal when I won't support it and it can potentially cause issues for peoples whole systems.

[Milo_Thatch]

Hello friends,
First of all, shout-out to this thread : viewtopic.php?f=5&t=110072. They are modeling maximum theoretical train throughput, it's a very interesting read for people that I assume are interested in train braking because they want to model train behavior, or just bored.

The old graphs didn't sit right with me, you can't really see what's going on, I wanted something visually clearer.
So I graphed train speed over time thanks to aaargha's cool new mod (thank you), and compared it to both of my C program's braking loops output. I tested both frictionless and friction models.
=> C source code of the (currently) best model just after the graphs.

Using the mod was easy, it's a very elegant solution. Taking those in-game measurements manually was very tedious
In case someone else needs the info, here's how I used it, following aaargha's instructions :

1. First, paste the mod archive to factorio/mods
2. Launch the game, make a new (Modded) Editor Extensions map, make one huge (and I mean huge, you'll need it) rail loop and place your train.
3. Send your train to the other side of the map, make sure they hit max speed, wait.
4. When that train is stopped, you will find a new .txt file at factorio/script-output. Rename that file to the configuration you tested. Done!

Now I need a mod that does the same thing but for acceleration. Validating models that way feels pretty good! I'll look into it but I don't know lua.

Two weird behaviors:

• At tick=0, the train speed is 1.38, but that is also the case at tick=1, so I always delete that tick=0 value.
• Increasing game speed didn't work : the data was weird, with speed going up instead of down. I stayed at normal speed. Could be user error.

Results :
Speed over time for two trains : 1:0 and 1:20. There are 3 data columns per train : in-game values, frictionless braking and friction braking.

braking research 0

Friction model fits In-game result the most, not even close

lvl0.png (320.03 KiB) Viewed 891 times

Zooming-in on the non-linear part of the curves : friction model is wrong for the last ticks (no surprise here).

Zoom

Whether long or short, in-game trains need about 10 additional ticks to stop. Constant? Idk but seems that way

lvl0-zoom.png (211.93 KiB) Viewed 891 times

Additional validation with max research : it fits, until it doesn't. Same +10 tick difference from friction model to in-game values.

braking research 7

Validation on higher braking research, same +10 tick difference but I can't link more than 3 images here.

lvl7.png (310.51 KiB) Viewed 891 times

Here we can see the difference between models is smaller, and a frictionless model will give us a more precise braking-time value.
That's the mistake I made earlier, and I won't use frictionless if precision depends on research. Friction fits the in-game curve way more.


And here's the source code for the braking function in the C program :

Friction braking loop

Code: Select all

void friction_braking_loop(int loco, int wagon, int research, float *speed, float *position, int *tick){

	int braking_force = loco * 10 + wagon * 3;
	int weight = loco * 2000 + wagon * 1000;
	float friction = (loco + wagon) * 0.5;

	float multiplier[8] = {1, 1.1, 1.25, 1.4, 1.55, 1.7, 1.85, 2};

	while(*speed >= 0){

		fprintf(fptr, "%d,%f\n", *tick, *speed); // Output time and speed values to a .txt file
			
		*speed -= (braking_force * multiplier[research]) / weight;
		*speed -= (friction / weight);
		*position += *speed;
		*tick = *tick + 1;
	}
}

Conclusion:

• You were right, friction is applied during braking, and the way I displayed results from last time was bad, delta-speed% couldn't properly show what was really going on, no wonder the results were confusing.
• From there, it seems like we can approach the real braking time from the friction result just by adding 10 ticks to it. My next step is to try to make the same graphs with a bunch more trains. If you have a request for specific trains, don't hesitate. I'd like to be pretty sure that the friction model works, with a bit more examples and train length. That way, I can get an average on that "~10 ticks" value, and see if it varies with train length and research.
• Concurrently, I think I will need a factorio dev to comment on precisely why that nonlinear behavior is happening, and if it is possible, to replicate it using simple inputs. My math knowledge is pretty basic, so if you have an idea how, tell me. I'd like to avoid a complex program, especially in the scenario where "~10 ticks" is constant. An academic would precisely replicate the behavior, but an engineer would probably say "who cares, just add 10 to the result" and call it a day .

As always, thanks everyone for the continued interest.

[Milo_Thatch]

Hello friends,
Using the same method as in the previous post, I plot speed over time of a train's in-game values and compare them to the output of the C program's braking loop function.

Additional weird behaviors from the mod: It happened only once for now, but the speed value suddenly went down in one tick, as if train braking had a huge boost.

script output

Code: Select all

1300266|310|-1.38|495|-377.890625
1300267|310|-1.245|495|-379.13671875
1300268|310|-1.2380780634363|495|-380.375
1300269|310|-1.2311563432308|495|-381.60546875
1300270|310|-1.2242348418024|495|-382.828125

The problematic value here is the second one, going from 1.38 to 1.245 in one tick. It's pretty easy to spot so not really a problem, but could indicate wrong measured values in general. I'll assume the mod still gives precise-enough measurements for now.

Results :

1-4 train

good model, 8.7 average tick difference

1-4.png (393.05 KiB) Viewed 679 times

For each (friction) curve, I indicate braking tick difference between in-game values and braking loop values "(-9)". Negative because I have to remove 9 ticks from the in-game values to match friction values.
The average tick difference is then 8.7

4-16-4 train

good model, 10.6 average tick difference

4-16-4.png (382.74 KiB) Viewed 679 times

The average tick difference is then 10.6

Conclusion:

• Model seems to work and the braking time precision can be easily increased by adding 10 ticks. Going from a frictionless to a friction braking increased that precision from 95% to about 100%.
• I was going to test other train length, like 1:1, 1:2, 2:8, etc. But the results are pretty much random. They're so close together that I can't really tell if they're increasing proportionally to anything, or if the mod measurement method changes the results randomly. I'm not seeing a lower precision proportional to brake research either, it appears to be random, even if the worst values are pretty much always for max braking research and short trains.
• The worst precision was for a 1:0 train with max braking research, at 134 ticks (model) vs 146 ticks (ingame). Adding 10 ticks to that model result gets us a precision of 98.5% for that worst case. With more wagons that precision increases. Examples : 99.6% (1:0 lvl0) , 99.8% (1:4 average), 99.9% (4:16:4 average), 100% (1:20 lvl0).
• For now, I'll add 10 ticks to the brake time result. Because even in that worse case, we're talking about a braking time difference of 2 ticks. That precision is high enough to make me happy, and I can safely move forward with other cool projects using that function. Factorians are very welcome to take everything on my gitlab and increase that precision even more : Others made the hypothesis that the factorio train braking algorithm is updating braking force in real time to stop at the right position, and that's why we see that non-linear behavior. There is also the 1/256 tile resolution that could impact the position results. I don't have the required knowledge to reverse-engineer the factorio source code, and I didn't find any additional information on how that algorithm works, so I'll stop my work there for now.

Bonus : here's the optimized source code for the braking function. It's using two arithmetic progression formulas to quickly get braking tick and distance.
You can do the same for the acceleration loop code, but it will be arithmetic-geometric. It's a bit longer to do.

Friction braking arithmetic

Code: Select all

/*
 * Arithmetic implementation, "fast" (avoiding loop)
 * ticks = initial_speed / constant
 * tiles = (steps + 1) * ((initial_speed) / 2) assuming final speed is 0.
 */
void compute_braking(int loco, int wagon, int research, float *speed, float *position, float *tick){

	int breaking_force = loco * 10 + wagon * 3;
	int weight = loco * 2000 + wagon * 1000;
	float friction = (loco + wagon) * 0.5;
	float multiplier[8] = {1, 1.1, 1.25, 1.4, 1.55, 1.7, 1.85, 2};
	float braking_constant = (breaking_force * multiplier[research] + friction) / weight;

	*tick = *speed / braking_constant;
	*position = (*tick + 1) * (*speed / 2);
	*tick += 10; // Simplistic offset for non-linear behavior of braking train
}

You have no idea how much faster the code runs with it. In one of my project I went from waiting 2 minutes for my code to execute, to 0.07s

Thanks everyone