## News:

Beta test the new forum at https://simutrans.forum/
Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

## add tractive force/effort in standard

Started by jk271, February 21, 2012, 08:27:24 PM

0 Members and 1 Guest are viewing this topic.

#### jk271

I was tinkering with some physics improvement of game. It resulted in this patch.

The patch changes way how the vehicles can move and accelerate by adding tractive power.

There are power and gear determining amount of goods, that can be carried by train at some reasonable speed.
Tractive effort/force (Zugkraft in German) is a force that determines amount of transportable mass in real world: Old locomotives did not have a lot of power but with a slow speed resulting in a little bit more tractive force (more than have fast trains) it was able to pull heavy freight train.

Tractive effort is implemented somehow in experimental, but there are used kilonewtons. It leads to small numbers and results in floating point arithmetic.
My patch uses newtons as base unit of tractive force. It causes a little bit better behavior with smaller values, no floating point arithmetic is needed.

Having friction force calculated in newtons enables see better correspondence with real world too. It can be set to more corresponding values having units (e.g. newtons in this case) revealed.

Tractive power is calculated from existing values, no savegame format changes or pak file format changes are available!

There are some important changes:
1) Vehicles with engine have tractive power. Tractive power is calculated from power, gear and maximal speed of vehicle.
tractive_force = (power*gear)/max_speed_in_meter_per_second
Gear is normalized.

2) friction factor (?unit?) is superseded by friction force in newtons. Without having units corresponding to real world it is hard to estimate correct constant.

3) Linear coefficient to calculation of friction force added.

Newtons (N) are used as kilonewtons (kN) are too big unit for calculation purpose.

Is tractive force / tractive effort desired in standard or it should be only in experimental?

The patch is for demonstration purpose, not ready for merging in master branch.

#### Combuijs

QuoteIs tractive force / tractive effort desired in standard or it should be only in experimental?

What exactly is it doing? You say it changes vehicle movement and accelleration. But in what way? And why does it improve gameplay?
Bob Marley: No woman, no cry

Programmer: No user, no bugs

#### jk271

Patch enables to distinguish usage of passenger train locomotives and freight train locomotives.
I will try to demonstrate it on example:
Imagine having 2 locomotives
Locomotive A: 1000kW, maxspeed 108km/h, gear=1.0
Locomotive B: 1000kW, maxspeed 54km/h, gear=1.0
They are able to pull same amount of cargo in simutrans standard now. You will probably use fasted one for everything.

If you use this patch, than following calculation is processed:

tractive_effort=power[in Watts]/maxspeed[in m/s]

tractive_effort_A=1000000/(108/3.6)=33333 (newtons) == 33.3 kN
tractive_effort_B=1000000/(54/3.6)=66667 (newtons) = 66.7kN

So the slower one (B) can pull double amount of cargo than faster one (A). User will use locomotive A for fast passenger trains because of it's speed. The another one (B) is more suitable for heavy freight trains as it is able to pull more cargo.

Another change included in patch is friction calculation.
There is friction_factor today depending on track: 1 on narrow track, 8 in curves, 23 on slopes up ...
I have superseded this value by friction force in newtons.
It enables setting up more easily suitable coefficient from real world situation:
20N of friction force per 1000kg of weight on narrow track.
20N of additional friction force for curves. It is 40N of friction force per 1000kg in curve together. It 2 times more than narrow track in reality (data are for curve with diameter of 500m; for 1000m as it is in game it less). This fact demonstrates, that value of 8 of frincion factor in curves is excessive.

Small change in calculation of friction on steep tiles: A little bit lower friction force on small hills (one level), a little bit bigger friction force on bigger hills (two or more levels)

Having tractive effort and friction force in same units enable to sum it up (as vectors, subtract as numbers) to have resultant force for calculation of acceleration.

To sum it up:
Slower locomotives with big power can pull a little bit more cargo.

#### Spike

Hmmm ... the gear factor was intended to simulate this to some extend. What reasons speak against giving the slower loco a gear factor of 2.0? Wouldn't this yield about the same result with the existing code?

(I mean this questions honestly. I don't know the code well enough these days, and I might be wrong with my assumption that a gear factor of 2.0 still does what I think it would).

#### Combuijs

QuoteImagine having 2 locomotives
Locomotive A: 1000kW, maxspeed 108km/h, gear=1.0
Locomotive B: 1000kW, maxspeed 54km/h, gear=1.0

I could be horrible wrong, but:

Say you could just about pull 6 wagons with Loc B at 54 km/h then I'm quite sure that you can't pull the same 6 wagons at 108 km/h with Loc A. At 54 km/h with Loc A yes, but not at higher speeds.

So I think that behaviour is already there in Simutrans standard. What am I missing?

QuoteSo the slower one (B) can pull double amount of cargo than faster one (A)

That looks very strange: Two locs with the same power should be able to pull the same amount of cargo at the same speed.
Bob Marley: No woman, no cry

Programmer: No user, no bugs

#### TurfIt

I'm rather missing the point here too. Why add a link between the top speed and power?

There's a difference between a governed speed (top speed in Simutrans), and achievable speed (how fast is possible with power/weight - in new speedbonus calc).
Also note the "power" figure is used in the physics formula as a force instead of a power already. And gear is simply a multiplier intended to allow tuning of desired ingame performance given real power figures in a vehicles .dat.

The patch just looks to me like renaming/rescaling the values, and removing the flexibility of having power, speed, and gear all separate.
As to the friction component, there are no real world values used. The friction factors are simply numbers that result in good enough ingame behaviour.

Finally:
Quote
+         // one tile 1km = 1000m, height of 1 tile = 10m (from landscape settings) ==> 10/1000 = 10 per mille
This 1 tile = 1km thing really needs to die. There's no such scale in Simutrans.

#### jk271

Quote from: Hans on February 21, 2012, 10:00:17 PM
Hmmm ... the gear factor was intended to simulate this to some extend. What reasons speak against giving the slower loco a gear factor of 2.0? Wouldn't this yield about the same result with the existing code?

(I mean this questions honestly. I don't know the code well enough these days, and I might be wrong with my assumption that a gear factor of 2.0 still does what I think it would).

Yes, gear solves problem with locos. It one part of the task.
My intention was to understand the way, how the friction in game is computed too. And compare it with values from real world. To make it more understandable for me, I changed (scaled) some constants (friction factor) to SI units (it were newtons in this case).

Quote from: Combuijs on February 21, 2012, 10:54:33 PM
I could be horrible wrong, but:

Say you could just about pull 6 wagons with Loc B at 54 km/h then I'm quite sure that you can't pull the same 6 wagons at 108 km/h with Loc A. At 54 km/h with Loc A yes, but not at higher speeds.

So I think that behaviour is already there in Simutrans standard. What am I missing?

That looks very strange: Two locs with the same power should be able to pull the same amount of cargo at the same speed.

Power [measuted in Watts] is speed (in m/s) multiplied by force (in newtons). Locos usualy have constant tractive force, so maximal power is usualy reached at maximal speed. Unless some gearing is available.

Example:
I tried to show, that in case of A pulling 6 waggons at 54 km/h, B is able to pull 12 wagons at 54km/h. So B is better loco for coal transport. A is better for passenger transport because B is slow.

Another example to this topic: Ferrari and bus. First one is faster but can not carry so much passenger

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
I'm rather missing the point here too. Why add a link between the top speed and power?

Power [measuted in Watts] is speed (in m/s) multiplied by force (in newtons). Locos usualy have constant tractive force, so maximal power is usualy reached at maximal speed. Unless some gearing is available.
==> Dividing power by maximal speed (of locomotive, not calculated "maxspeed" value) yields force.

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
Also note the "power" figure is used in the physics formula as a force instead of a power already.
My aim was to correct this fact to make it more consistent with real physics.

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
And gear is simply a multiplier intended to allow tuning of desired ingame performance given real power figures in a vehicles .dat.

I use in calculation in the patch "gear" too.

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
The patch just looks to me like renaming/rescaling the values, and removing the flexibility of having power, speed, and gear all separate.
I do not see any removing of flexibility. It makes user to think and distinguish between locos: Not all locos are good for freight transport. Using fastest locos for everything from fast passenger trains to coal tranport makes game monotone. I am trying to avoid it.

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
As to the friction component, there are no real world values used. The friction factors are simply numbers that result in good enough ingame behaviour.
"friction factor 1" tells me nothing. Having seen curren friction force of vehicle is 320N tells me much more.

Quote from: TurfIt on February 21, 2012, 11:16:20 PM
Finally:This 1 tile = 1km thing really needs to die. There's no such scale in Simutrans.
Is there any scale, that can be used in physics calculations?

#### TurfIt

Quote from: jk271 on February 22, 2012, 01:13:15 AM
Locos usualy have constant tractive force, so maximal power is usualy reached at maximal speed. Unless some gearing is available.
Most locos I'm familiar with are constant horsepower machines - at least at trackspeed. Constant force at slow speeds but the horsepower requirements quickly exceed availability as speed builds. That's where I wasn't understanding why you calc'd force off power/topspeed.

I'll touch on the rest of your post tomorrow as I have to go...

But to perhaps spur discussion: TE is already in standard, it's just called power. So are there compelling gameplay reasons to add actual power into the game physics?

#### prissi

Actually, I know the formula is wrong. I hold a degree in physics ...

But, this is a game. And the formula used has two very big advantages:
- slower acceleration until reaching top speed
- an overloaded engine is still moving a reasonable speed

These two points are almost impossible to achieve with quadratic acceleration (i.e. power). The current formula is physically wrong but asthetically pleasant.

And if the speedbonus is used for passenger engines, then the running cost of a 1000kW/100km/h machine should be much higher than for a 1000kW/54km machine (correctly balanced). That is nearly independent of the formula. If a pak set does not want to use the speed bonus; well then it is their decision.

Finally, there are more vehicles in Simutrans than just trains, Planes for instance are constant force machines, as well as ships, and even steam engines ...

#### jamespetts

The physics in Experimental work well (and physics for acceleration and top speed are about to be joined by physics for braking in the next release, and this, together with the original acceleration physics, all thanks to Bernd Gabriel). The necessity to use floating point arithmetic is not a difficulty now that Bernd Gabriel has created a deterministic floating point class that is network safe.

I daresay, if one wanted a distinction between tractive effort and power in Standard, it would make more sense to use the existing model in Experimental than to re-invent the wheel. The reason that it is not used in Standard, I rather suspect, is that the developers of Standard believe that the game is better with a very simplified model of physics, as described by Priss, not because of the particular implementation of the additional realism in Experimental.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### prissi

Tractive effort/power is a model only working for trains. But simutrans is not train centric, at least standard. It is almost the only transport simulator with a very vast choice of road transport and useful shipping support.

And the other way is that I find the behaviour in experimental not fell natural.

On a sidenote:
Due to the several time scaled/length scales involved, the formula in SE are only mathematically more close to the one in real world physics. But du to the distorted time and length scales, they are not correctly reproducing reality. Otherwise almost everything would just jump instantaniously to maximum speed (even a high speed train does not need more than 2 min to get to maximum speed). This would be very "real" but not pleasant at all.

#### jamespetts

Quote from: prissi on February 22, 2012, 11:23:11 AM
On a sidenote:
Due to the several time scaled/length scales involved, the formula in SE are only mathematically more close to the one in real world physics. But du to the distorted time and length scales, they are not correctly reproducing reality. Otherwise almost everything would just jump instantaniously to maximum speed (even a high speed train does not need more than 2 min to get to maximum speed). This would be very "real" but not pleasant at all.

We are perhaps wondering off topic here, but may I ask you to elaborate? I am a little unclear on what you mean here: Experimental has a variable distance per tile scale. The default is 250m/tile. I tested the physics a while back against real figures for acceleration of trains, and found it to be more or less spot on. Trains in reality can take many kilometres to reach full speed.

Vehicles other than trains generally accelerate much more quickly (in Experimental), and even, for example, old lorries from the 1930s can get to 50km/h in about a tile.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Carl

Quote from: prissi on February 22, 2012, 11:23:11 AM
On a sidenote:
Due to the several time scaled/length scales involved, the formula in SE are only mathematically more close to the one in real world physics. But du to the distorted time and length scales, they are not correctly reproducing reality. Otherwise almost everything would just jump instantaniously to maximum speed (even a high speed train does not need more than 2 min to get to maximum speed). This would be very "real" but not pleasant at all.

It's relevant to note that recent versions of Experimental have an option to display the time passing in "real", "vehicle time" (I believe it's show_month=8) -- and when this is switched on, the gradual acceleration is realistic in the way you describe. The only side-effect is that "months" have irregular lengths of (e.g.) 3h 12m.

#### prissi

Also in simutrans standard trains take many kilometers to accelerate ...

I mean with "real" time scales (like 1 month in 1h) time still passes about 700 times faster than in reality. As such everything reaches maximum speed in less than a second (which is 10 min in reality). Thus you can only make reality in time or distances for a useful game, not both.

The same stuff also happened for real world modell railways. Tank engines at HO size usually max out at 300 km/h or so, if scaled to reality, smaller sizes can be even worse. But the customer do not want engines slowing creeping along the tracks, so the company distorted the scales deliberately.

#### jamespetts

Ahh, I see what you mean; as Carl pointed out, this has been addressed with the new system for timing, where a "month" lasts a few game hours. According to that scale (the hours), the vehicles do accelerate in a realistic time as well as over a realistic distance. The same scale of timings is used for travelling, waiting and loading times as well as speeds.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.