Transport Tycoon Forums

If you have a good suggestion of how to make power dependent on speed, then tell me about it.
But implementing such a feature will make the coding more complicated. And I wonder how large the effect on gameplay would be. We must not get into wasting a lot of CPU time for only a minor effect.

I like the current model of constant power, combined with max TE, because it is not too complicated, and therefore easy to understand.

[edit] This is a reply to Bilbo's message.

Perhaps keep it after all ... modelling some more realistic power characteristics will just consume probably a lot of CPU time :)

No. Really realistic acceleration is much simpler (and less CPU consumptive) than it looked:

The challenging factor of weight should not be max_speed but acceleration itself. Simply long train with one poor engine will take ages to reach max_speed. This is challenging enough as you must think much more about how to dimension/optimize you tracks to avoid using brakes at all cost (exactly as in the real world).

And I have also found why this Crr=0.001 seemed to be too high to me. Fortunately I have smart colleagues at work and they immediately pointed me to the proper calculation equations.

the resistance (rolling friction) force is:

F = Crr / r * G

where Crr is rolling friction coefficient (steel-steel 0.0003 .. 0.005) - unit is cm (yes, centimeter), r is wheel radius (in cm), G is gravity force (9.8 * weight).

So then 1000 tons train (when using Crr = 0.001 cm, r = 50 cm) gives rolling resistance 196 N (equivalent of 20 kg !!!). When using Crr = 0.005 it would be equivalent of 100 kg. Haha... (it is not worth wasting any CPU time to calculate such minor influence

Train running without power (weight 1000t, distance 270 km) will lose 270km * 196N = 53MJ.
Kinetic energy in 140 km/h is 10^6kg * (140 / 3.6)m/s ^2 / 2 = 756 MJ.
After losing 53MJ it remains 756 - 53 = 703 MJ there.
New speed will be sqrt(703 MJ / 10^6 kg) = 26.5 m/s = 95 km/h (sure it is less than 130, but much closer to expected result).


And back to the 400t train with 3000 hp engine:
When moving 60mph (TE=70kN) the rolling friction resistance (Crr=0.001, r = 50cm) is ~ 80N (~0.1 % of TE). So far from playing any dominant role on max_speed! So the current implementation is wasting of CPU. It really needs (for classic trains up to 200 mph) only weight vs. TE that gives acceleration (a = F / m) where F would be TE corrected by down/up-hill force. Did you know how much CPU we can save by making train acceleration more realistic?

OK, guys i agree that it sounds crazy, correct me if i am wrong, but the original TTD acceleration implementation seems to be much more realistic than so called "realistic" acceleration with all "physics" patches. And it was also saving CPU.

KUDr wrote: the resistance (rolling friction) force is:

F = Crr / r * G

Yes.

But when I look at
http://www.school-for-champions.com/sci ... _tires.htm or the original wiki article, I think what you mean is different constant - the Crr already takes into account the radius of the wheel.

So perhaps Crr=Cr_of_material / r, but in the end you'll end up with Crr=0.001

When I looked at http://www.roymech.co.uk/Useful_Tables/ ... _frict.htm for example, I saw "your" equation, just worded differently: F = f x W/R, but the coefficient f is in meters and were "Steel on Steel f = 0,0005m" (=0,05cm) ... so for wheel 0.5m large you'll end up with f/R = 0,001. Hmmm .. same coefficient as on wiki, same as in my original calculation. I am afraid that while your equation is correct, your constants are wrong ...

I think some more reliable source than articles or wikis should be used to "check the truth" and find proper constants (like some physics coursebook)

KUDr wrote: where Crr is rolling friction coefficient (steel-steel 0.0003 .. 0.005) - unit is cm (yes, centimeter), r is wheel radius (in cm), G is gravity force (9.8 * weight).

So then 1000 tons train (when using Crr = 0.001 cm, r = 50 cm) gives rolling resistance 196 N (equivalent of 20 kg !!!). When using Crr = 0.005 it would be equivalent of 100 kg. Haha... (it is not worth wasting any CPU time to calculate such minor influence :)

Train running without power (weight 1000t, distance 270 km) will lose 270km * 196N = 53MJ.
Kinetic energy in 140 km/h is 10^6kg * (140 / 3.6)m/s ^2 / 2 = 756 MJ.
After losing 53MJ it remains 756 - 53 = 703 MJ there.
New speed will be sqrt(703 MJ / 10^6 kg) = 26.5 m/s = 95 km/h (sure it is less than 130, but much closer to expected result).

E=1/2 * m * v^2

v=sqrt( 2*E /m)

... you forgot a square root in the MJ to m/s conversion. Correct is 37.5 m/s = 135 km/h

And since Crr on start is wrong, so basically the rest of the calculations is also wrong. Still, 77 km (from my original calculation) needed to stop without power is still quite a lot of distance ... air drag will probably reduce it to 60-70 km, but I think not less :)

KUDr wrote: OK, guys i agree that it sounds crazy, correct me if i am wrong, but the original TTD acceleration implementation seems to be much more realistic than so called "realistic" acceleration with all "physics" patches. And it was also saving CPU.

Maybe more "realistic", but maglev slowing down from 640 km/h to 30 km/h on small bump is pretty annoying

It would be realistic if you declare the slope to be extremely steep. (perhaps almost as steep as it look in the graphics :)

According to http://wiki.openttd.com/index.php/Game_Mechanics: "A vehicle traveling at 100kph will cross 5.6 tiles per day. This means that for vehicle speed purposes, a tile is 429km on a side!"

Maglev that could be able to run 640km/h on flat surface will slow down to 30 km/h when having to climb 50 m on 429 km long track? .... Nope. Not even slightly realistic. Perhaps on some planet with 500 g gravity (if such large planet could ever exist), but not on earth-like planet :)

Yes, you are probably right. My source was book from technical university in Prague. I have also found web of another university (in Brno - unfortunately also czech) where they have 0.005 cm material Cr for steel-steel contact which means Crr 0.0001 (for 50cm wheel radius). So I assumed it is correct. Now when searching elsewhere it looks like we in czech have 10x lower rolling friction because:
- all czech sources I found have those numbers in the same range, but 10x lower than en-wiki
- czech train doesn't stop after 70 km (from 140 km/h) as you showed it should.

Something is wrong ...



And yes, deceleration is another caption. Up to now we were talking about realistic acceleration (and acceleration itself). And i would like to stay there as i am old model (cpu without multithreading support). I still would like to know why you guys think that so called 'realistic acceleration' is more realistic than the one implemented by Mr.CS.



Still the same as I stated before is valid about max_speed for train with 400 kg mass and 3000 hp engine.

And assuming that if you don't reduce the max speed unreasonably, you will need to unreasonably increase up-hill effect, sorry, it is crazy. Now when using 3000hp engine i can't reach 100 mph with very light train (400 tons is nothing). After such a change it will slow-down from 100 to 50 when moving one tile uphill? I must tell: NO!

Is it not enough if long/heavy trains will have much lower acceleration as in a real world?


Be reasonable please. Why do you want to make this game unreasonably hard at all costs. And at the area which shouldn't be that complex. Effect of acceleration is clear to everybody. Adding unreasonably high air-drag and rolling friction makes no sense. There is already option that increases effect of the mass. Is it not enough? Then add some optional even harder conditions. But please don't name it 'physics' patch. Name it 'high gravity' or 'high friction planet' patch.

This topic has name that implies that the goal of this patch is to make trains behavior more realistic. And the current implementation definitely needs to be repaired. So I wanted to look around for a real solution and found this one. And it is about everything else but physics.

KUDr wrote:Yes, you are probably right. My source was book from technical university in Prague. I have also found web of another university (in Brno - unfortunately also czech)

A proč unfortunately? :)

KUDr wrote: where they have 0.005 cm material Cr for steel-steel contact which means Crr 0.0001 (for 50cm wheel radius). So I assumed it is correct. Now when searching elsewhere it looks like we in czech have 10x lower rolling friction because:
- all czech sources I found have those numbers in the same range, but 10x lower than en-wiki
- czech train doesn't stop after 70 km (from 140 km/h) as you showed it should.

Hmm ... have you or somebody else tried how long the train need to stop? Send me the links to czech materials, I'll look at them. I won't trust that article on wiki much, since the numbers apparently came from another article about car tires, so I won't trust these numbers completely either. Although they match with another calculation from the other site.

Now I realize that this is friction for only rolling the wheel, but the wheels are also rolling in their sockets, so there would be additional friction (not sure how high, depend on quality and type of the sockets). I guess it would be rougly comparable to rolling friction of the wheel, though if you have ball bearings, the balls have smaller diameter and thus maybe higher friction, but there are more of the balls and the force is somewhat distributed over them and such calculation would be ugly and complicated..

Current equations will be physically accurate IF the constants would be tweaked to be physically accurate, since even the old realistic accel is basically almost correct (except some weird cases - like safeguard, where underpowered train will maintain 1 km/h uphill, in case where the force is not enough to pull all the wagons).

heh, I overlooked where you are from
Ok, so here it is. Chapter 8.4-Valivé tření.

Yeah, socket friction you can completely ignore I was told (dunno why but they are machine engineers).

KUDr wrote:heh, I overlooked where you are from :)
Ok, so here it is. Chapter 8.4-Valivé tření.

Yeah, socket friction you can completely ignore I was told (dunno why but they are machine engineers).

When I looked at http://www.converter.cz/tabulky/valive-treni.htm and there are more values for steel, so perhaps it depends on type and quality of the steel (and may differ amongst wagon manufacturers) - and both mine (corresponding to first line of table) and your value can be correct. Also, the friction coeficient for sockets seems to be 100-500 smaller than for wheels. Well, even though the balls in the ball-bearing sockets are much smaller, I can say yes, ignore it :)

Still, calculation of this friction is easy (multiply weight of train by constant), so not much will be done by ignoring it. Won't stop the train from achieving max. speed, but still may slow down the acceleration a bit for weaker engines. And air drag can't be just ignored by very high speed trains (maglevs...) as it is quite significant ....

Well, I wonder how will the vehicles behave if all the parameters will be tuned for maximal realism. Perhaps the game won't be much playable then :)

Well it will depend on the acceleration caused by each hp of engine per ton of mass. This one is related to time which is scaled anyway, so we can tune it.

And yes, air-drag should probably play some role for high speed trains. But still it should not prevent train from reaching max_speed i think. Limiting factor for mag_lev is also the construction preciseness, material quality and so on. TE should be still big enough there.

In the older ttdp i played with some ancient version of TtdAlter and tried to tune trains to lower power and higher max_speed and it looked realistic. It took trains longer to achieve the max_speed and needed well balanced network. Otherwise it took them much longer to deliver cargo. Dunno if such behavior would be accepted by users, but it is challenging enough if you use one complex network.

I have to make a comment on the realisticness of the physics models.
Neither of the three (original acceleration, semirealistic acceleration and realistic acceleration) is entirely realistic. As I said before, the values must be as realistic as possible, but one should not forget gameplay. For the realistic acceleration of this patch, I balanced the values (assuming default settings) such that the game becomes more challenging, but not unplayable. As I said before, you have to be more careful when selecting locomotives, and sometimes you have to use two of them. Also track layouts may be a thing to think about when you want to run trains smoothly with high speeds. I did this because the original (unrealistic) acceleration is silly, and the realistic acceleration of trunk is incomplete (it does not feature all possible newgrf properties), not challenging (trains reach their maximum speed way too quickly) and there are some minor annoying things (some speed limits are too low).
If you do not like the realistic acceleration of this patch, use one of the other two models instead. But I have to point out that if you are not happy with the behaviour of your trains (or road vehicles), you can always change the configuration in openttd.cfg or by the patch command in the console. Information about the configuration options is included in the patch. The configuration can be set such that the trains move even faster than the old realistic acceleration. Therefore I will reject any complaint about trains being too slow and this patch ruining your gameplay experience. I have had some complaints in the past, and this encouraged me to make a lot of the parameters user-configurable.

Now I claim that my realistic acceleration function is better than the one in trunk. I have several reasons for it, and I have also a few things by which you may argue that it is worse. First, I will list some advantages over the trunk version:
-The realistic acceleration uses as much of the newgrf properties as possible. The trunk version still doesn't do that.
-Most constants are configurable by the user without having to recompile, and some other are easily changed in the source code. In the trunk version, nearly all values are hardcoded.
-The code of the new patch looks more like physics than the old one, but this is only a slight difference.
-The new function is slightly better documented than the old one.
-The traction handler (which we did not speak about yet) of the new version is better than the old one. That is, engines really don't deliver power when the train is stopped. The old version just does this by enforcing with a few "v->cur_speed = 0" lines. This is ugly. The ugliness is most prominently seen in the road vehicle behaviour (compare with and without RA-RV enabled), but it applies to trains as well.
Now some disadvantages:
-The new function probably uses more CPU power than the old ones, but you can't get nice features for free. Moreover, I'm planning to implement a feature that allows the function to be called every so-much ticks, and use a cached acceleration value for the other ticks, thus reducing CPU load for only a minor decrease in quality of the physics model*.
-There are still some "magic" functions, which are not obviously based on any physics (e.g. those for the TM_FASTBRAKE and TM_SLOWBRAKE modes for the traction handler).
-Some properties, such as brake force, and also rolling friction, have to be "guessed" since there are (as far as I know) no newgrf properties that define them. I can't do much about it.

As I said before: If you don't like it, either don't use it, or come up with suggestions such as new values for the constants, or improved code.


*Note: This is only an idea, so I have no indication on what the impact on gameplay will be.

hertogjan: ok, sorry if i seemed too offensive. One nice day I wanted to proudly present this game to my uncle (train instructor) because he loves all what is related to trains. And the result was one big shame. He started to complain about the max_speed and was asking 'why? the engine is strong enough!'. Then I wanted to secure the situation and applied your patch on top of it. The first disillusion came when i wanted to load his game. It was not possible. So I explained him that he must start again. 'OK, no problem.' Then he tried something very similar and the result was even worse.

And i can tell you something: I don't care about any constants or hidden tricks or about how many options are there. I care about default settings when feature is switched on.

Most of server owners now have switched on that 'realistic' acceleration (because of its name) and game is annoying. So I don't play online so much as I would otherwise.

When I try to imagine what would happen when your patch was in trunk i become even more unhappy.

Before that I was looking for some inspiration how to fix the problem (in 'realistic' accel. in trunk) that i pointed to at beginning - too low max. speed caused by friction. I am unhappy from its current behavior as i am sure that i.e. 1550 hp engine is strong enough to make its max_speed 80mph pulling 726t mass on straight track. Current 'realistic' implementation stops accelerating at 68mph which is way too low. It virtually reduces the engine power to 300hp. And it is wrong. Regardless of gameplay or anything else. And because I don't like blind fiddling with constants i looked here again and tried your patch hoping that when its name is 'physics patch' that it will be more realistic in this particular thing (that it was already fixed). And it is even worse. 3000hp engine pulling 400t train has its max_speed at 60mph. So I wanted to figure out why is that by reading the article. And the only what i found about it was that you have applied some change there to show max_speed depending on the current power and mass. Sorry, it seemed soooo ridiculous to me. Instead of fixing this misfeature you add workaround for it to make player's life bit easier. If you want to apply so unreasonable friction to slowdown the train, isn't it easier to just reduce its power (and also show the reduced one)? It would be much less confusing to tell 300hp instead of 3000hp. It is better than those lies (meaning max_speed 60mph with 3000hp / 400t).

Please think about it. The game is so nice and so easy to play with most of people using it as a toy (much cheaper than model railway). Including me. And you make it lying even more in name of 'better gameplay'.

Why do you care about physics and newgrf variables on one hand if you ignore the reality so badly on the other? It looks to me like wasting of your effort and our CPU time. There must be something what i have missed. Your code looks good. You obviously know what you are doing. I would like to understand what is the base idea behind this all.

What I think that could make it challenging (if you really want to) is tunning the time and distance factors as they are unclear anyway. But you did it by changing virtual power of engines. This could make the game hardly playable at early years with high running costs set and some newgrfs (i.e. DB engines).

Why you don't learn from real trains? It is also challenging to empower train enough to make it accelerating fast enough or to deliver cargo to the hill. You can easily do that by increasing mass influence to the acceleration. Train professionals would tell 'great, it is like a real train, it also takes ages in the real life to reach the top speed'.

KUDr wrote:Most of server owners now have switched on that 'realistic' acceleration (because of its name) and game is annoying. So I don't play online so much as I would otherwise.

Not realistic, but not annoying players with "one step will slow down any engine to 30 km/h" problem.

I know, same way professional driver would be annoyed by Need for speed for example (bah, not realistic, you can crash in 300 km/h and there are just few sparks and you continue unharmed :)

Perhaps there should be 3 choices ... current "realistic" keep as semirealistic (for people who don't know trains it is not bad), the "old" and new "realistic", which could be as much realistic in default settings as possible.

KUDr wrote: Please think about it. The game is so nice and so easy to play with most of people using it as a toy (much cheaper than model railway). Including me. And you make it lying even more in name of 'better gameplay'.

Model railway is nice. I had one, but now it is stored in few boxes, since there is no place for some decent tracks (I don't have extra at least 1x2m flat place in place to build at least somewhat decent tracks (H0 is quite big) in flat where I live)

KUDr wrote: Why you don't learn from real trains? It is also challenging to empower train enough to make it accelerating fast enough or to deliver cargo to the hill. You can easily do that by increasing mass influence to the acceleration. Train professionals would tell 'great, it is like a real train, it also takes ages in the real life to reach the top speed'.

Unfortunately, not everybody know someone who is train instructor or who have similar knowledge about real trains. For some people it is not apparent that train will continue tens or hundreds of kilometers when power is cut and no braking is applied. I bet if you ask any person this question,, most of them (those who are not train professionals) will guess considerably less than 60 km (my calculation) or .... something even more (your calculation)

Perhaps with help and suggestions from your uncle we can put together really realistic train acceleration.

BTW that savegame issue would be quite easy to fix ... just change PHYSICS_PATCH_SAVE_VERSION in patch to current savegame version +1 and bump the savegame version

Today, I have been looking into my own patch a bit. I am busy with rebalancing the coefficients. This has to be done no matter what, since the code contained a serious bug that caused the airdrag coefficient to be calculated in a wrong way. The bug was such that the airdrag coefficient for the first engine was a factor 100 too low, therefore making the newgrf airdrag property almost useless. It is hard to see the difference in-game. The rebalancing is needed because the airdrag coefficient per wagon must be lowered in order to get a total coefficient of the same order of magnitude.

There are more bugfixes and other little changes. Expect a new, improved version of the patch in a couple of days.

Any news on this patch?

Yes, there is.
Sorry for the delay... I have taken more time in order to fix some issues more carefully.
However, I fixed some dirty bugs[1], and rewrote some pieces of the code in order to maintain compatibility with trunk.

Here is a more detailed description of what I have done (since r10628) and what I am planning to do:

Added:
* Rolling friction patch option
* Ignore S-bend patch option

Fixed:
* Compiler warning for function SqrtLinApprox (inlined)
* Overflows and wrong results for maximum speed estimates
* Bug which gave maglev trains non-maglev behaviour for max tractive effort, and vice versa (!)

Partially fixed, partially to do:
* Rebalance physical coefficients

To do:
* Disable some GUI parts for dedicated server version
* Fix speed bouncing for trains in mode TM_ACCEL (does not always happen)
* Clean up code wherever necessary

Not to do:
* Trying to resolve savegame compatibility issues. This will fix itself when the patch is accepted to trunk.

Possible split-up of the physics patch:
1. Realistic acceleration for trains, realistic acceleration for road vehicles, and related settings, GUI and newgrf functions
2. Proper unit conversions and proper rounding for displayed values (not necessary; to be reconsidered and reviewed)
3. Estimate of maximum speed and necessary power of fully loaded train (not necessary; to be reviewed and cleaned up (GUI-wise))

I have some more ideas, but some of these are not directly in the "core" of the patch (being the RA functions), and it isn't sure that they will eventually make it to real features.

Ideas:
* Add a tab to the vehicle details window which shows info about all physical parameters, including the results of the speed estimates and necessary power (related to part 3 of the split-up mentioned above; the idea for that part is originally Bilbo's). This will allow more information to be displayed, without messing up the top half of the details window.
* Presets for the physical parameters which can't be set in the patch settings window. This feature should be in the same style as the difficulty settings; i.e., you can select from a few presets, or use "custom" settings.

I should note that I am still not happy with the current coefficients in physics.h, but this may be a matter of personal taste.
Have fun with this new version. And as always: Suggestions and comments are welcome!

[1]The most infamous bug that comes into mind is marked with an exclamation mark (!) in the list.

Another update for compatibility with trunk.
I have not thoroughly tested it this time, but all features should work more or less as intended.
Have fun with it.

to make a humble comment to your physics exercise:

An interesting alternative for speed limits would be to let the player chose th maximum speed.
higher speed -> higher costs
(for maintenance, noise protection, energy..)

This would add an additional thing to consider for planning a network, and a money sink.

Realistic or not.. one thing that some players want is also high speed, one prestige-track for ego.. or just to give the mountains of money some sort of use.

hertogjan wrote:Another update for compatibility with trunk.
I have not thoroughly tested it this time, but all features should work more or less as intended.
Have fun with it.

Hi there, can you update your patch to the actual trunk ?

I have a working version of the patch myself, which I updated recently, but unfortunately I cannot upload it now. You will have to wait until next week.

Also I will probably split the patch into two parts (one for trains and one for road vehicles) and I might throw out some of the unnecessary parts, so that only the realistic acceleration functions remain, an a minimal amount of extra source code to support it. Hopefully that will make it easier to get the patches integrated into trunk. Currently the size* of the patch seems to scare off the main developers too much. Smaller patches are preferred, since they are easier to be tested.**
In addition, I might be maintaining the full version as well with all the extra features (for the people who don't care about testing the code), but the chances that the full patch will eventually make it to trunk in one piece will be practically 0.


*Although a significant part cannot be considered source code since it is merely data or documentation, so actually the patch is smaller than you might think.
**Imagine that the game crashes due to the patch. The more lines of code the patch has modified, the harder it will be to find the line(s) of code responsible for the crash.

hertogjan wrote: ...

Thank you very much, i wish to use your mod in my EMP mod pack.
I have main interrest only for train physics, so vehicles are not so important for me. And when you split it to the two separate patches, that maybe helps them to integrate to the trunk due they size.

I have one request for you, maybe new idea to implement.
When you have so complicated calculation used there about hourse power/traction/speed and others things, you can calculate how most is actualy engine used. So is there way, how to implement real fuel callculations ? Every train have value Running Cost per year. The game calculate and take payments in cycles (for time period). So very simple way would be to change this value thru game code, dependig on what is actualy engine doing. Something like when engine is going on 100%, original running cost per year stays. But when is idle (going down from the hills) the running cost can be reduced to 15%. When is standing in stations or on signals, then 5% or 10%.... That is what i miss in this game. Anyway, that can be also separate additional mod to the existing one.