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

[Milo_Thatch]

Hello ,
Weird question here, I'm not sure if it's the right place to ask.
I'm working on a small C program that simulates factorio train behavior.
I'm having fun and so far it has been possible thanks to the information given on the wiki :
https://wiki.factorio.com/Locomotive

I would like to have more information on the way trains brake in factorio.
From what I understand, when trains are moving to a planned stop, they compute a braking distance, so that they can stop at the exact position of the stop.
This braking distance is inversely proportional to the braking force research.

- Should I move this post elsewhere ?
- Is there an equation for train speed, braking time or braking distance, like in the "Maximum speed" section of the locomotive article ?

[Tertius]

I would say this thread is better moved to the "General discussion" part of the forum. This forum is for discussing how to deal with the wiki administratively and from an editor's point of view. Not about discussing wiki content.

Having said that, and hoping Bilka will move it to the proper forum, this is my recommendation for you:

In Factorio, switch to map editor mode by entering /editor into the console to enable stopping the time and single stepping through the ticks, so you can inspect everything carefully.
Then activate debug mode and activate "show-train-braking-distance" and "show-train-stop-point" display. This helps "seeing" how and when trains will brake.

The formulas to compute deceleration is probably the same as for acceleration, just with the braking force value instead of the acceleration value.

[mmmPI]

- Is there an equation for train speed, braking time or braking distance, like in the "Maximum speed" section of the locomotive article ?

I think you will find what you need in the comments there :

https://www.reddit.com/r/factorio/comme ... ments_and/

[Milo_Thatch]

Thank you for trying to help me, I found a satisfactory answer.
mmmPI : A very interesting read, but I wanted to find the real code, not make a model based on measurements. Still, it helped me.
Tertius : Understood. I'll assume Bilka will move it, if it's out of place. Those commands were very useful.

I tried for a long time to compute deceleration with the acceleration formula of the wiki, to no end. You can't just replace fuel_acceleration_bonus by the sum of braking forces of the train. And dividing it by some factor wasn't successful on my part.

Funnily enough, It's Bilka himself that answered my question indirectly, in 2019, here : viewtopic.php?t=72739.

No, it's using the old code that was on the wiki which has the wrong friction calc.
This spreadsheet has correct code: https://docs.google.com/spreadsheets/d/ ... 1156092035 (by knightelite)

The spreadsheet contains some explanation, and a much simpler braking formula :

Code: Select all

nextSpeed -= totalBrakingForce / totalWeight;

totalBrakingForce is a sum of braking forces of all wagons *[and locomotives, I assume] multiplied by (1+bonus)
As you can see, we can forget about air resistance and friction.
Here's my C script, that computes deceleration time in ticks : https://gitlab.com/universe822/factorio ... type=heads

As far as I can tell, it's precise.
I made 7 measurements (gamespeed=0.05) for different train length (1:0, 1:4, 1:8, 2:8) and varying braking research (1 or 7), starting at 298km/h (nuclear fuel).
Between the game and my program, all results were within 10% precision. Most were within 2% precision.

[mmmPI]

Nice !

If one wanted to nitpick : Artillery wagon weight is 4000 from "https://wiki.factorio.com/Artillery_wagon"

[farcast]

As you can see, we can forget about air resistance and friction.

...

I made 7 measurements (gamespeed=0.05) for different train length (1:0, 1:4, 1:8, 2:8) and varying braking research (1 or 7), starting at 298km/h (nuclear fuel).
Between the game and my program, all results were within 10% precision. Most were within 2% precision.

Out of curiosity, which train did your program give the least accurate results for?

I did a deep dive into train mechanics a while ago, and past me came to the conclusion that friction still applies while the train is braking, and is unaffected by braking research. I'm terrible at note keeping, so I could be wrong.

If I'm right, the 1:8 train with research level 0 should've gotten the least accurate prediction. 10% off is even about right, if a little low. Should be more like 13% off by my predictions.

[mmmPI]

I did a deep dive into train mechanics a while ago, and past me came to the conclusion that friction still applies while the train is braking, and is unaffected by braking research. I'm terrible at note keeping, so I could be wrong.

Well i'm not good at note keeping either, so i don't have the source datas anymore, but i found this old post of mine :
viewtopic.php?p=516084#p516084

On the 3rd 4rth graph, the one called speedvarontimedecel, you can see plotted the speed of 4 different train at every tick from their max speed to their full stop.

At first it seem line an horizontal line, with some variation due to roundings as my measurement were done ingame with the truncated speed value.

But on the right part of the graphs, there are several ticks during which the speed between 2 tick decreased less than all the previous tick. Meaning that the deceleration is slower for slower train. ( not fully linear ).

Which i think would contradict

Code: Select all

nextSpeed -= totalBrakingForce / totalWeight;

totalBrakingForce is a sum of braking forces of all wagons *[and locomotives, I assume] multiplied by (1+bonus)
As you can see, we can forget about air resistance and friction.

Because that would yield a perfectly linear deceleration since none of the terms on the right would change over the course of the deceleration.

However when compared to the upper graphs that plot the acceleration, it is visible that the deceleration is closer to linear than acceleration which is more impacted by i suppose air resistance and /or friction.

I don't know if such precisions matters but "forgetting about air resistance and friction" is a relative term, i did forgot about it, but i guess there are situation where you are reminded there are there somehow

[farcast]

At first it seem line an horizontal line, with some variation due to roundings as my measurement were done ingame with the truncated speed value.

But on the right part of the graphs, there are several ticks during which the speed between 2 tick decreased less than all the previous tick. Meaning that the deceleration is slower for slower train. ( not fully linear ).

If I were to guess, the non linear portion is the game nudging things to compensate for where the stopping point needs to be not being where the stopping point would be when the train starts braking.

You can kinda see this happen with the train-braking-distance debug option enabled. The red stopping point stops just before where it should be when the train starts braking, then slowly drifts forward (or was it backwards?) as the train approaches. I thought this was just a visual bug, but maybe it's mechanically accurate.

[FuryoftheStars]

At first it seem line an horizontal line, with some variation due to roundings as my measurement were done ingame with the truncated speed value.

But on the right part of the graphs, there are several ticks during which the speed between 2 tick decreased less than all the previous tick. Meaning that the deceleration is slower for slower train. ( not fully linear ).

If I were to guess, the non linear portion is the game nudging things to compensate for where the stopping point needs to be not being where the stopping point would be when the train starts braking.

You can kinda see this happen with the train-braking-distance debug option enabled. The red stopping point stops just before where it should be when the train starts braking, then slowly drifts forward (or was it backwards?) as the train approaches. I thought this was just a visual bug, but maybe it's mechanically accurate.

If the train is in automatic mode, yes, it will adjust the braking force to what's actually needed. You can see this with a train going at full speed where you switch it to automatic/change its schedule to where its next stop is well within the braking distance (meaning that it should overshoot) but somehow it manages to still stop perfectly at its destination.

In manual, I don't think it'll do this, but I could be wrong.

[Milo_Thatch]

Out of curiosity, which train did your program give the least accurate results for?

Hey farcast, here's my measurements : https://gitlab.com/universe822/factorio ... ements.ods.
You're absolutely right, something is going on for certain trains. Specifically, the two worst results are for a 1:4 and a 1:8 train, both without any braking research. I did the measurements manually and their precision could be bad, so take it with a grain of salt. But I thought I was precise enough with the 1:8 (gamespeed=0.01, so human reflexes delay is minimized). I'll try to update that document with new measurements for different braking research, to see if the bad precision depends on braking research.
Friction could still be applied, and I would need to do some testing. For reference, the code in my program is :

Code: Select all

v = v - (braking_force * cumulative_effect / weight);

It outputs a completely linear speed decrease over ticks, as mmmPI predicted.

I don't know if such precisions matters but "forgetting about air resistance and friction" is a relative term, i did forgot about it, but i guess there are situation where you are reminded there are there somehow

This damned braking mechanic is breaking out . Looking at your image, it looks like the last 30-40 ticks are the problem, so 10-15% of the brake time.
It would be interesting to have a precise ingame tick-by-tick train speed measurement comparison, so I can fully compare the program with the game. But it's asking for a lot, and for the small scope of this program, I am content.

it will adjust the braking force to what's actually needed.

Interesting, changing braking force is cheating !

And if anyone cares, the files are accessible here : https://gitlab.com/universe822/factorio-trains and should be easy to download if I didn't mess up the project settings.

[mmmPI]

As far as i can remember the test i ran was on a long straight line with a regular signal turned red using combinator. Trains in manual mode located at one end of the long straight line were tasked with a temporary stop to go to the other end of that straight line past the signal turned red.

Then the value were reported using the "show braking distance" or "pathing" or something, i remember a red dot, but also a line, that allowed me to monitor at a low game speed when the train was about to start braking in the editor.

At this point i turned the game speed to 0 and instead used the editor to go 1 frame at a time, and reported the truncated value shown in game, the first few ticks when the speed had not changed yet due to me anticipating the moment the train would start breaking were not reported so i could register the exact amount of ticks it took for a train to decelerate from full to 0 speed counting the first tick when the speed wasn't the maxed speed anymore.

It would be interesting to have a precise ingame tick-by-tick train speed measurement comparison, so I can fully compare the program with the game.But it's asking for a lot, and for the small scope of this program, I am content.

Maybe if more precision was the goal, it would be possible to do the same with a train expected to have a very long breaking time. As such it would be easier to see if the speed if decreasing by the same amout during the whole deceleration, or not. In order to rule out friction/ air resistance. As those maybe exist during the whole process, but are only visible at the end with the trains i used for testings. Maybe it's not that hard to automate the previously described process, i couldn't tell. But that doesn't seem necessary for your purpose

If I were to guess, the non linear portion is the game nudging things to compensate for where the stopping point needs to be not being where the stopping point would be when the train starts braking.

You can kinda see this happen with the train-braking-distance debug option enabled. The red stopping point stops just before where it should be when the train starts braking, then slowly drifts forward (or was it backwards?) as the train approaches. I thought this was just a visual bug, but maybe it's mechanically accurate.

I also see Fury's theory that's why i gave more precision on the test method i think i used and i know it's possible to force a train to come to a full stop instantly using combinators but i would say this one is a little different. Still i'm not sure if we are not all 3 talking about the same things using different words so here's mine ( description of the nudging process ? ):

I would link this to the fact that the position of the train cannot take every single value, as the game need to draw the train on pixels, and the game divide the world in small tiles subdivided into tiles. This could translate into roundings occuring between the theoric speed calculation given a formula that is linear as OP uses in its script. And the current position of the train, that is another calculation, where the game after knowing the speed of the train, will put it in the closest area that train are allowed to be ( drawn/located).

It would be more visible when train have low speed, as at high speed the roundings occuring inside a single tile are negligible compared to how many tile the train moves per tick. This i think was hinted in the reddit post, as it would seem that calculating the precise position is process that first involve calculating the speed and then applying it to the positionning system the game uses.

In-game only measurements would yield values hard to understand as coming from a simple formula. Precise understanding would require some knowledge of related other game system.

[FuryoftheStars]

You can measure all of this in manual mode. Holding the movement keys as you time step works. I just imagine that in Automatic, it's possible for their calculations of when to start braking could be off and thus they also have the extra code to force it to slow down faster if required.

Of course, I suppose this also depends on exactly what you want your measurements to be of and what the end goal of the measurements is.

[farcast]

I've re-traced my steps and cleaned up my spaghetti code. This is how I figured out that friction counts towards braking force.

Braking distance meter

Braking distance meter.jpg (916.74 KiB) Viewed 3095 times

I improved on knightelite's design for measuring braking distance by taking advantage of diagonal tracks having an irrational (square-root 2) length. 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 (7.842081225095 + 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.

The design directly measures a low estimate. The highest and lowest values ever detected are stored in memory. The highest is the closest minimum value, and the lowest + 2 + 2 root 2 is the closest maximum. As the train loops around, the minimum and maximum converge on the true value.

Potentially arbitrarily precise measurements can be obtained this way, though in practice only 2 or 3 decimal places are usable. Not because of 32 bit integer limits, but because I suspect each additional decimal of precision requires exponentially more diagonal track (and thus train length too), and since train positions are discrete the train likely needs to loop around exponentially more times to get the best measurements. The train can't be allowed to stop as that would reset its decimal position, so you'd eventually need to manually refuel it, or use modded fuels, or modded trains that don't need fuel.

...Going through that reddit thread again, the actual precision limit is probably from factorio restricting train positions to multiples of 1/256 of a tile. Thanks Allaizn for that info.

The constant length from the train itself is just 7 * #rolling_stock. I got that part by letting a 1-59 train slowly crawl its way through the detector. It got a minimum value of exactly 420.0 tiles, and 420 / 60 = 7. Each additional rolling stock must add 7 tiles so I think it's a fair conclusion to have.



Anyway, I used this to precisely measure braking distance of a train at max speed. Measurements are taken from trains at constant speed, so there should be no nudging involved. Going from no braking research to max research should double the braking force. If braking force was the only force, doubling the braking force should halve the braking distance, but braking distance is not halved. Including friction perfectly accounts for the difference (1800 Newtons per rolling stock, or 0.5 after converting seconds to ticks).


MATH!

Measured braking distances taken from a 50 locomotive train running on nuclear fuel at max speed with no braking force research and max research.

Code: Select all

No research:
M_1 = 181.363937 to 181.378210 meters
Difference = 0.014273

Max research (braking force * 2):
M_2 =  92.892929 to  92.903039 meters
Difference = 0.010110


Energy = Force * Distance         \\ energy lost when braking
       = 0.5 * Mass * Velocity^2  \\ energy of a moving train


Force = locomotives * (braking force per locomotive * research bonus + friction per locomotive)

50 = locomotives
b  = braking force per locomotive
r  = research bonus
f  = friction per locomotive

Force = 50 * (b * r + f)

Mass     = 2000 * locomotives
Velocity = 82.8

Distance       =    0.5 * Mass * Velocity^2 / Force  \\ braking distance of a moving train
               = (0.5 * 2000 * 50 * 82.8^2) / (50 * (b * r + f))


M_1            = (0.5 * 2000 * 50 * 82.8^2) / (50 * (b + f))
50 * (b + f)   = (0.5 * 2000 * 50 * 82.8^2) / M_1
b + f          =      (0.5 * 2000 * 82.8^2) / M_1


M_2            = (0.5 * 2000 * 50 * 82.8^2) / (50 * (b*2 + f))
50 * (b*2 + f) = (0.5 * 2000 * 50 * 82.8^2) / M_2
2b + f         =      (0.5 * 2000 * 82.8^2) / M_2

b =                         (2b + f) - (b + f)
  =      (0.5 * 2000 * 82.8^2) / M_2 - (0.5 * 2000 * 82.8^2) / M_1
  = (0.5 * 2000 * 82.8^2) * (1 / M_2 - 1 / M_1)

f =                      (b + f) * 2 - (2b + f)
  =  (0.5 * 2000 * 82.8^2) * 2 / M_1 - (0.5 * 2000 * 82.8^2) / M_2
  = (0.5 * 2000 * 82.8^2) * (2 / M_1 - 1 / M_2)

Using values of M_1 and M_2 that give the smallest and largest results:

Braking force per locomotive = ~35994.1 to ~36005.1 Newtons
Difference: ~11.0

Friction per locomotive = ~1793.49 to ~1807.47 Newtons
Difference: ~13.98

Edit: Apparently the number I used for curved track length was slightly wrong.

[Milo_Thatch]

Hi again friends, thank you for your answers and hard work. I did some additional in-game measurements to compare several braking formulas.
I can also say, as you did, with some confidence, that friction is a thing, even if I can't get a perfect result for some reason.
I wasn't able to find out the exact braking formula, but I'm still happy because the new formula with friction is 96% accurate for 1:0 trains and 97+% accurate for really heavy trains, like a 2:8.

As you all said, the game probably does some position rounding, so getting the perfect formula might be tricky.
However, I'd like to show you the tick results of several train accelerations I made in game, compared to the C program :
In game ticks for a 1:0 train, coal fuel : 802.8; Program ticks for the same train : 805; Delta-tick (%) : 0.3.
In game ticks for a 1:0 train, solid fuel : 465; Program ticks for the same train : 466; Delta-tick (%) : 0.2.
In game ticks for a 1:0 train, rocket fuel : 242.1; Program ticks for the same train : 242; Delta-tick (%) : 0.0.
In game ticks for a 1:0 train, nuclear fuel : 149.1; Program ticks for the same train : 149; Delta-tick (%) : 0.1.

Delta-tick (%) is simply :

Code: Select all

(game_tick - program_tick) / game_tick *100
Lower is better.

This is simply to show you that the formula given in the wiki gives very precise acceleration measurements, even with the position rounding of the game and with the random precision of the operator (me).

The game code is supposedly* :

Code: Select all

for every tick {
	train_speed = train_speed - (total_braking_force / weight);
}

* https://docs.google.com/spreadsheets/d/ ... 1156092035
However, I couldn't make it work with a simple for loop. The program would give me completely wrong results (acceleration of 60+ seconds for a nuclear 1:0 train).
I had to calculate the final tick variable directly with an arithmetic progression formula, but that's beside the point.

The point is that I checked three total_braking_force formulas :

Code: Select all

(1) total_braking_force =  (braking_force * cumulative_effect) / weight);
(2) total_braking_force = (braking_force + friction) * cumulative_effect / weight);
(3) total_braking_force = ((braking_force * cumulative_effect) + friction) / weight;

With :
- braking_force = (locomotive * 10 + wagon * 3);
- cumulative_effect, a number that belongs to {1, 1.1, 1.25, 1.4, 1.55, 1.7, 1.85, 2}
- weight = locomotive * 2000 + wagon * 1000;
- friction = (locomotive + wagon) * 0.5;

And the third one gave me the best results in delta-tick (%) overall :

Code: Select all

(1) 1:0 train, 0.27; 1:4 train, -4.85; 2:8 train, -5.46
(2) 1:0 train, 5.17; 1:4 train, 6.05; 2:8 train, 5.39 
(3) 1:0 train, 3.81; 1:4 train, 3.1; 2:8 train, 2.45 

Each result is in fact the average of 8 measurements (from braking research 0 to braking research 7) I made in game and compared to my program's output.
You can find more details here : https://gitlab.com/universe822/factorio-trains in the .ods file.

I'm happy with the result, as its precision looks proportional to the train length, but it still itches me that I couldn't find the precise formula.
I'm tempted to directly ask the devs, but I wonder if that would be rude.

[mmmPI]

Including friction perfectly accounts for the difference (1800 Newtons per rolling stock, or 0.5 after converting seconds to ticks).

To be fair, i'm not understanding all the method that leads you to this conlusion. I think i understand how you get the distance using the energy and velocity^2 equation. That part i only got it when looking for the 5th time after Milo_Thatch posted his method. I can imagine that from this and precise measurement of where the train stops in game, ( which can be made arbitrarily precise thanks to the magic behind sqrt(2) and a not-less-magical-to-me setup exploiting this) you know the energy of the moving train, and make a prediction on where it is going to stop, looking at this prediction, you are able to deduce that some energy is dissipated away that is not coming only from the braking force, but also due to friction, otherwise doubling the braking force would halve the distance and the predictions are correct only if you account for the energy dissipated by friction.

There are some gaps in my understanding and i'm not sure how to interpret the difference of 11 and 13.98 at the end. It seem to me that those are the very very tiny variation you have using your updated method of prediction that include friction and your results with in-game measurements. Which then could either come from a very very tiny adjustment in the formula or from a very very tiny imprecision on the measurements due to the need of exponentially more train test for more significant digits.

It seems both of you are agreeing on this formula ( regarding how to add the friction's effect during braking ):

(3) total_braking_force = ((braking_force * cumulative_effect) + friction) / weight;

Force = locomotives * (braking force per locomotive * research bonus + friction per locomotive) = 50 * (b * r + f)

But now i'm confused because i don't know if it's "perfect" or if there is still some little imprecisions and if so at which order of magnitude and what could cause it. As the interpretations of the results' precision seem to differ. is it perfect ? or is it 4% off sometimes ? and is it just me that didn't understand that it comes from the measurement methods ?

I thought of comparing with things that are known inspired by Milo's sanity check on measurement methods with acceleration because in the doc linked in previous post , the air_resistance that is known to have an impact on acceleration is using this formula:nextSpeed *= (1.0 - totalAirResistance / (totalWeight / 1000.0));
Which in the case of a train with 50 locomotives would give a multiplication of the speed by 0.999925 each ticks . 1.0 -(0.0075/((2000*50)/1000))
The 0.0075 being the air_resistance of a locomotive as indicated in the readme from the gitlab
In the case of a train with only 1 locomotive it would give a multiplication of the speed by 0.99625 each ticks . 1.0 -(0.0075/((2000*1)/1000)).

Now if you take a number like 100 to represent the speed of a train, and you multiply it by one or by the other again and again, to represent how much impact it would have, it is possible to plot the equation 100*0.999925^x=50 or 100*0.99625^x=50 in wolfram alpha, with the idea of looking at how much time it would take for a train to lose half its speed due to air_resistance, ( as if it was the only force that apply to a train liberated from friction ). And well, the results are : 9241 ticks for the heavy 50 loco trains and 184 ticks for the only 1 loco train. ( it makes sense intuitively that the super heavy train keeps going for a long time and not the lighter one ).

I know air_resistance is not supposed to be part of the deceleration calculations, but i am in doubt since my test were showing non-linear behavior for deceleration and the formula both of you seem to agree on would yield a linear deceleration i think. The impact of air_resistance if it was to be accounted for in the deceleration as a multiplication by a number very slightly under 1 repeatedly would yield a non-linear deceleration so i like this idea it is a confirmation biais maybe. I think it would also explain why the formula seems more precise the heavier the train in Milo's test and why it's super precise on farcast's test with a 50 loco train but i'm not sure i understood that part correctly, 50 loco train would yield a negligible air_resistance, but the setup can be made arbitrarily precise, though it's 0.999925 vs 1 we are trying to measure with a 50 loco train if there was air_resistance in the deceleration. ( how many times did the train took to stop ? )

It seems to me that the two numbers are close enough to 1 so that the impact would be barely noticeable given what i think is the relative time a train needs to come to a full stop : air_resistance is 0.0075 for a loco vs 0.5 for friction,If friction is a small variation to account for, air_resist could be even smaller. If i knew how many ticks does trains need to stop i could test my hypothesis or at least know if the supposed impact of air_resistance is within an order of magnitude that would be significant/noticeable given the measurement in game. ( plz send raw data and i can give it to wolfram myself ).

I realize now i thought i was going to help and it's me who need help understanding because i'm not sure my reasonning is correct and i'm curious to understand

You can find more details here : https://gitlab.com/universe822/factorio-trains in the .ods file.

How ?
I couldn't open the file i downloaded and read something it doesn't open a table, but an empty Math interface.

I'm happy with the result, as its precision looks proportional to the train length, but it still itches me that I couldn't find the precise formula.
I'm tempted to directly ask the devs, but I wonder if that would be rude.

Me too it itches

And i don't think it's rude if you are genuily interested in someone's work, and not trying to steal a secret formula to put in your own copy
But also don't expect an answer, i think it wouldn't be rude from the devs not to answer, because they could explain something, how to open a file on gitlab to me for example, and i would not understand, and ask more questions, and be explained again, and again, and again, to a point maybe the (very busy) dev feels i'm wasting its time and don't know how to say nicely and decide to avoid the awkward situation later like guideline.

Also i'm acting like i know what's rude or not because you asked and i posted a lot of message on this forum but really i don't know. I can say that i almost never see devs answering questions whose answer is a google search away or in the wiki. But if you can't find a simple formula that may also be because there is no simple formula and a knowledge of derivatives and integration and understanding of code is required and that could lead to an awkward math lesson that maybe no dev is willing to risk attempting to give to a random stranger on the internet x) .

I think Allaizn wrote the reddit post 5 years ago as a player and not as a dev yet at the time, and mention receiving an answer after "asking nicely" to the devs so it happens sometimes i guess

[Milo_Thatch]

But now i'm confused because i don't know if it's "perfect" or if there is still some little imprecisions and if so at which order of magnitude and what could cause it. As the interpretations of the results' precision seem to differ. is it perfect ? or is it 4% off sometimes ? and is it just me that didn't understand that it comes from the measurement methods ?

There are a lot of elements in my posts that aren't clear, sorry about that. It's hard to make concise and meaningful bullet points, and I'm far from understanding everything correctly .
I'm confident in my measurement method because :
- I implemented the acceleration code, as it was explained in the wiki, in the "time2accel.c" program (gives time in ticks for a train to accelerate, among other things).
- It gave very precise results compared to the game, in the range of 0.1-0.3 delta-tick (%). I can consider that the main culprits are my sausage fingers and reflexes, because the measurement method isn't automated.

I'm working on a "time2brake.c" program now.
I tried to implement the braking code from https://docs.google.com/spreadsheets/d/ ... 1156092035 with a for loop and the results were completely wrong.
So I used the arithmetic progression method* and it gave me 90% accurate results.
Then I changed the total_braking_force formula by adding friction. It gave me 97% accurate results.

* I think that looks like what you already tried with wolfram. If I have a speed formula like "speed = speed - constant", I can easily calculate :
- How many steps it takes for the speed to reach 0.

Code: Select all

steps = initial_speed / constant

- How many tiles the train travelled

Code: Select all

tiles = (steps + 1) * ((2 * initial_speed + steps * constant) / 2)

But results aren't perfect.

I know air_resistance is not supposed to be part of the deceleration calculations, but i am in doubt since my test were showing non-linear behavior for deceleration and the formula both of you seem to agree on would yield a linear deceleration i think.

You're absolutely right, this might be it.
What I will do now, is to retry implementing the for loop, because it's required if I want to implement the air_resistance term in the train speed braking formula.

I couldn't open the file i downloaded and read something it doesn't open a table, but an empty Math interface.

Sorry I didn't specify that it was a "libreoffice calc" file. You can open it with google sheets if you understandably won't install the libre office suite .

[mmmPI]

Sorry I didn't specify that it was a "libreoffice calc" file. You can open it with google sheets if you understandably won't install the libre office suite .

Google sheets did it, i tried using the libre office suite i knew it was this , but for some reason it kept opening the file not as calc but with this functionnality of open office https://www.openoffice.org/product/math.html , and i didn't know what to do. But now i can see it all

- It gave very precise results compared to the game, in the range of 0.1-0.3 delta-tick (%). I can consider that the main culprits are my sausage fingers and reflexes, because the measurement method isn't automated.

I understand that you have an order of magnitude difference in precision between acceleration and deceleration when you compare your formula with in game behavior. Acceleration is 0.1-0.3% off, whereas Deceleration is up to 3% off. Both test being done with the same measurement method. The logical conclusion to me is that the formula for deceleration is less precise than the one for acceleration. (but farcast used the same formula as far as i understand and the results are more precise than 3% off, but the measurement method used by farcast i don't understand well enough to conclude anything and train is different that's confusing me)

You can, in game, use speed 0 by the way "pause" in editor, and only use "next frame" to go 1 update at a time, then map this to a hotkey, and do several trains at a time, press a key, write down their speed values, press a key, write down their speed values, and so on if you want to remove the reflexes part. Though that would still not be automated and quite tedious if 1 speed value takes 3 second to write in a .calc it will take 10 minutes for 200 ticks of manual recording x). i don't know how to write a command to " Export the speed of a locomotive entity every tick in file".

* I think that looks like what you already tried with wolfram. If I have a speed formula like "speed = speed - constant", I can easily calculate :
- How many steps it takes for the speed to reach 0.

That's the logic i had in mind when using wolfram, more precisely "how many steps for the speed to reach 1/2 of original speed". Because i only used the equation for the air_resistance of acceleration. such formula is " speed = speed * constant " where constant is approaching 1 but constant is always less than 1, depending on the weight and on air_resistance of the first rolling stock. (1.0 - totalAirResistance / (totalWeight / 1000.0) with 0.0075 for totalAirResistance when there is only a front loco.

In such case it takes infinity to reach 0. This yield a non-linear behavior unlike the "speed = speed - constant ". Because when speed is high, more speed is removed than when speed is low. But that's just a vague notion, i wanted to go more precise but i don't know the proper math so i tried something that would give me an order of magnitude for the supposed maximum hypothesis of the impact of air_resistance.( considering air_resistance exist and have an impact, left alone, how much time is required for a human player to notice it, or to measure it in the case of 1 loco and in the case of 50 loco).

Maybe this could explain why in one case the formula seems perfect, and in another case 3% off i thought.

I think it shows that for 50 loco trains, the impact is an order of magnitude less than for a single loco train. ( 9000 tick vs 200 tick needed to half the speed). As such it may create a discrepancy between predictions without air_resistance and considering there is air_resistance that would way more be noticeable for a single loco, and not for 50 locos, if the overall braking time is closer to 200 tick for both trains.

My idea is that the overall speed in game may be calculated doing first "speed = speed - constant" ( to account for friction and braking force) and then " speed = speed * constant " ( to account for air_resistance ) both for acceleration and deceleration. But i don't know how to make a prediction for step 150 without being forced to math step 149 and 148 and 147 and 146 like in 1 formula to easily compare the results ... So i did this in a .calc Now that i was able to open the .ods i could compare my predictions and your measurements .

It shows the "constant part" and the "variable part" using the datas i found from this thread, weight, friction number of loco and wagon allow to compute for 2 constant, one to subtract thus "constant part", one to multiply thus "variable part" because the amount of speed lost is not the same at all tick it depend on current speed.

I don't know what to think of it yet. I took for comparaison point a 1-4 trains like you did so i could reuse the 1.38 tile/tick speed as this is hardcoded in my .ods and compared my prediction with air_resistance as if it was to be applied in the same way for braking and acceleration , your prediction with friction model3 , and the result in game from your measurement which i understand now the method to measure time with a phone chronometer x).

My prediction with air_resistance, is not accurate. Less precise than your model3, it gives the train too much braking power and my predictions are consistently telling that the train will stop in less ticks than what you measured.

When i plotted the delta speed that the prediction with air_resistance would give between tick (x) and tick (x+1), it's not a straight line. That's what i called non-linear, which i suppose means it's not an arithmetic progression.(i'm not sure the meaning in english) I think one can say the derivative is not an horizontal lane if this is considered a function. Since the difference between 2 terms is smaller at low speed than at high speed. That's what i expected from my old measurement graphs. But it doesn't seem to fit really with the in-game number either.

I still need to try and re-do the top speed calculation based on fuel so that i can compare the prediction with more datas instead of re-using 1.38 tile/sec. But i no longer think air_resistance apply the same way for acceleration and deceleration. It would be too strong to miss its impact. In any case here is the doc :

speedsimu.ods

(51.46 KiB) Downloaded 61 times

[farcast]

Including friction perfectly accounts for the difference (1800 Newtons per rolling stock, or 0.5 after converting seconds to ticks).

To be fair, i'm not understanding all the method that leads you to this conlusion.

I made two braking distance measurements. For each measurement, I calculated the total force needed to stop in that distance. I know the only difference between the two forces is that braking force is doubled, so the mathematical difference is just the braking force.

By "perfect", I mean I can't find a train where the calculated braking distance is outside the bounds of the measured braking distance. Note: "braking distance", not "braking time". The braking distance as measured by my contraption doesn't actually agree with the actual braking time, something I didn't know about until this topic.

I've edited the math in my post to (hopefully) make it more readable.

There are some gaps in my understanding and i'm not sure how to interpret the difference of 11 and 13.98 at the end. It seem to me that those are the very very tiny variation you have using your updated method of prediction that include friction and your results with in-game measurements. Which then could either come from a very very tiny adjustment in the formula or from a very very tiny imprecision on the measurements due to the need of exponentially more train test for more significant digits.

The latter. A single measurement has a range of values that the true value it measured could be. Any calculation that uses that measurement will have a range of possible results dependent on the range of the measurement. Given the formulas for 'b' and 'f', only combinations of the minimums and maximums of M_1 and M_2 need to be used to find the range of 'b' and 'f'.

This imprecision certainly leaves room for the former, though. Yet the formula I used is already "perfect", so there is (or was) no way of knowing what, if anything, needs to be fixed.

It seems both of you are agreeing on this formula ( regarding how to add the friction's effect during braking ):

(3) total_braking_force = ((braking_force * cumulative_effect) + friction) / weight;

Force = locomotives * (braking force per locomotive * research bonus + friction per locomotive) = 50 * (b * r + f)

But now i'm confused because i don't know if it's "perfect" or if there is still some little imprecisions and if so at which order of magnitude and what could cause it.

I will admit that there technically needs to be a third measurement to confirm, with any level of confidence, that I'm actually using the right formula. The two measurements could've ended up with any numbers and I would've gotten some result for 'b' and 'f'. Only with a third, where using any two measurements gives roughly the same results for 'b' and 'f', can I say the formula is at all accurate.



I think once the train drops below a certain speed, or is within a certain distance, the game adjusts the braking force so the train lands exactly where it should when it stops. I'm still trying to figure out exactly how fast and exactly how far, and all the math involved, but it would explain why all my own stop time measurements are about 6-8 ticks higher than the calculated stop time. Except for a 1-18 coal train, which should have a max speed of 4 meters per second, a braking distance of about 0.6 meters at zero research, and a stop time of a little over 18 ticks. It's actual stop time was 48 ticks, which works out to about 1 extra meter of braking distance (that my measuring tool definitely isn't measuring).

[Milo_Thatch]

I made new measurements that are a lot more precise, and the .ods is now a lot easier to read imo https://gitlab.com/universe822/factorio ... ements.ods

This time, I made graphs because it's quite hard explaining everything. I trust this data a lot more because there's more of it and in higher precision.
The for loop I talked about in my previous post now works as intended, and it makes me wonder what I did wrong the last time .

I can forget about the arithmetic progression, as it isn't easy to use if I want to test aero drag.
For every braking research, I made three braking tick measurements in the game, following mmmPI's advice.

You can, in game, use speed 0 by the way "pause" in editor, and only use "next frame" to go 1 update at a time, then map this to a hotkey, and do several trains at a time, press a key, write down their speed values, press a key, write down their speed values, and so on if you want to remove the reflexes part.

Here's how it looks in the game. I used the "." and "play for limited time" extensively.

How I measured everything

In my program, I implemented several models and compared their tick output to the new and better game measurements.

Friction

Code: Select all

for (brake_t=0;; brake_t++){

	train_speed -= (braking_force * cumulative_effect) / weight;
	train_speed -= (friction / weight);
	//train_speed *= 1 - (air_resistance / (weight / 1000));
	
	if (train_speed <= 0){
		printf("%d\n",brake_t);
		return 0;
	}
}

Frictionless

Code: Select all

for (brake_t=0;; brake_t++){

	train_speed -= (braking_force * cumulative_effect) / weight;
	//train_speed -= (friction / weight);
	//train_speed *= 1 - (air_resistance / (weight / 1000));
	
	if (train_speed <= 0){
		printf("%d\n",brake_t);
		return 0;
	}
}

Friction+Aero

Code: Select all

for (brake_t=0;; brake_t++){

	train_speed -= (braking_force * cumulative_effect) / weight;
	train_speed -= (friction / weight);
	train_speed *= 1 - (air_resistance / (weight / 1000));
	
	if (train_speed <= 0){
		printf("%d\n",brake_t);
		return 0;
	}
}

Frictionless+Aero

Code: Select all

for (brake_t=0;; brake_t++){

	train_speed -= (braking_force * cumulative_effect) / weight;
	//train_speed -= (friction / weight);
	train_speed *= 1 - (air_resistance / (weight / 1000));
	
	if (train_speed <= 0){
		printf("%d\n",brake_t);
		return 0;
	}
}

As you can see, I simply disable the parts I don't need with //.

And here are the results :

1-0 train

1-4 train

2-8 train

• It's weird. The frictionless model gives more accurate results almost everywhere, especially for light trains.
  However, it's not accurate for heavy trains with long brake time (low braking research).
  Every time aero is implemented, the results are (far) worse.
• This data gives weight to the code from https://docs.google.com/spreadsheets/d/ ... 1156092035 that completely ignores friction and aero. After this post, I will ask Bilka his opinion on the subject, and if he can give me more info on the in-game implementation. Maybe my code is wrong because the braking distance is used as a condition instead of being a simple point to display.
• The more I think about it, the more I think our early conclusion that "the game adjust braking distance in real time to stop at the right tile" has some value.
  That would explain why low braking distance (high braking research) gives the best results : the game has less time to make its micro-adjustments and ruin the prediction. Tell me your opinion on the data because I'm pretty lost .

[farcast]

I made new measurements that are a lot more precise.

If you subtract 10 ticks from all your game time measurements, the friction model is the most precise across the board. I'm not saying the numbers are wrong, I see this as another clue for how to change the friction model.