Physics patches
Moderator: OpenTTD Developers
TTDPatch's solution, which works well enough, IMO, is to set a minimum speed of 1 speed-unit (approximately 1mph). Regardless of engine power, train weight, &c, no train will ever get stuck; it'll just start going r..e..a..l..l..y s...l...o...w...l...y.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
The difference is the torque. The average car is run on a petrol engine, whereas the average truck is run on diesel, such engines having a lot more torque than a petrol engine, so tend to be run at lower revs and hence a lower overall speed, purely for efficiency's sake. The rest is down to gear ratios. With enough gears you can get a 4 cylinder 1.4 engine up to any speed you like but generally you don't, because all those gears would soon become too heavy for the engine to even pull.gkirilov wrote:That's not true. The Vmax is dependent on the power(A LOT). THere are cars with 5 gears that reach their Vmax on 4th gear. That's because they dont have the power to do that on 5th.
But you are right the Vmax AND the accelaration are functions with many parameters.
Admittedly it's not a linear relationship. Each extra gear won't get you quite as much speed, because of things like the weight of the car, its aerodynamics and the size of the wheels, but that's less to do with engine power than with the torque.
Brignell’s law of consensus: At times of high scientific controversy, the consensus is always wrong.
Okay, here is a new version of the physics patch.
I will summarise what I've done:
-Some round-off errors have been fixed, and otherwise minimised. It seems that the program uses miles of both 1600 m and approx. 1609 m. Where possible, I have fixed this (for trains, that is).
-The "magic constant" was lowered, since acceleration was a little too fast in the previous version.
-Different trains have different air drag coefficients now. By default, trains have a coefficient which depends on their maximum speed. Faster vehicles have lower coefficients. Currently, all standard engines have the default air drag coefficient.
-Slow speed power handling has changed: Now train engines have a property which is called "tractive effort ratio", which determines the maximum force an engine can deliver*. This force is also displayed in the purchase window, if the patch is switched on. This force also determines the maximum brake force of the train.
-Stopping at stations is smoother.
-Some passenger/mail dual-headed trains have got a new property. This is "tilting cars", which gives them a higher speed limit in curves. This behaviour can switched on and off in the patch options window. I have given this property to the SH 125, TIM, Asiastar, and Millennium Z1. Only passenger/mail cars behind a tilting engine get the curve speed bonus, e.g. coal cars do not.
-Custom air drag coefficients, TE ratios and curve tilting from newgrf files are supported.
I think the train acceleration method is pretty good right now. Maybe there are still some unexpected bugs, or some constants may have been changed, but otherwise it looks fine to me.
Now you all know that OpenTTD is not all about trains; otherwise it would have been named Railroad Tycoon or something. Now my "physics patch" is not named "train physics patch". The consequences should now be clear to you all.
*Maximum TE does not apply to maglev. Maglev trains use a different type of propulsion (i.e. no mechanical contact). If you had looked closely to the previous version of the patch, you could already have seen that maglev engines brake by negative traction, not normal brakes. (Oh wait, I think I already said that earlier isn't it?)
I will summarise what I've done:
-Some round-off errors have been fixed, and otherwise minimised. It seems that the program uses miles of both 1600 m and approx. 1609 m. Where possible, I have fixed this (for trains, that is).
-The "magic constant" was lowered, since acceleration was a little too fast in the previous version.
-Different trains have different air drag coefficients now. By default, trains have a coefficient which depends on their maximum speed. Faster vehicles have lower coefficients. Currently, all standard engines have the default air drag coefficient.
-Slow speed power handling has changed: Now train engines have a property which is called "tractive effort ratio", which determines the maximum force an engine can deliver*. This force is also displayed in the purchase window, if the patch is switched on. This force also determines the maximum brake force of the train.
-Stopping at stations is smoother.
-Some passenger/mail dual-headed trains have got a new property. This is "tilting cars", which gives them a higher speed limit in curves. This behaviour can switched on and off in the patch options window. I have given this property to the SH 125, TIM, Asiastar, and Millennium Z1. Only passenger/mail cars behind a tilting engine get the curve speed bonus, e.g. coal cars do not.
-Custom air drag coefficients, TE ratios and curve tilting from newgrf files are supported.
I think the train acceleration method is pretty good right now. Maybe there are still some unexpected bugs, or some constants may have been changed, but otherwise it looks fine to me.
Now you all know that OpenTTD is not all about trains; otherwise it would have been named Railroad Tycoon or something. Now my "physics patch" is not named "train physics patch". The consequences should now be clear to you all.

*Maximum TE does not apply to maglev. Maglev trains use a different type of propulsion (i.e. no mechanical contact). If you had looked closely to the previous version of the patch, you could already have seen that maglev engines brake by negative traction, not normal brakes. (Oh wait, I think I already said that earlier isn't it?)
- Attachments
-
- patch(debug)_physics_r3426_25-01-2006.patch
- Physics patch (still a debug version) - 25 jan 2006 - r3426
- (69.99 KiB) Downloaded 422 times
That's silly. With this, you're assuming that only the powered axles have brakes, in reality all axles have brakes (except perhaps for the very early wagons), so the maximum braking force is the train weight times this ratio, not just the adhesive weight, or in other words, the maximum braking deceleration is 9.80 m/s² times this ratio.hertogjan wrote:Now train engines have a property which is called "tractive effort ratio", which determines the maximum force an engine can deliver*. This force is also displayed in the purchase window, if the patch is switched on. This force also determines the maximum brake force of the train.
In fact, it is not that simple as I stated in my last post. In fact, it is incorrect
.
All carriages have a constant braking force, and the brake force of the engine (not the train) is indeed the TE ratio times the engine weight (and that is indeed equivalent to a deceleration of 9.8 m/s^2 times the TE ratio).
Still, braking is still a silly business, as sometimes the speed is controlled by a different function (for instance, at red signals). Also the dynamic braking, used for decelerating in curves and at stations, can exceed the maximum brake force of the train.
And it is at this point impossible to account for unpowered axles with brakes. Then you would need an extra constant (for instance, a ratio equivalent to the TE ratio, except then for brakes, i.e. brake force divided by engine (or wagon) weight).

All carriages have a constant braking force, and the brake force of the engine (not the train) is indeed the TE ratio times the engine weight (and that is indeed equivalent to a deceleration of 9.8 m/s^2 times the TE ratio).
Still, braking is still a silly business, as sometimes the speed is controlled by a different function (for instance, at red signals). Also the dynamic braking, used for decelerating in curves and at stations, can exceed the maximum brake force of the train.
And it is at this point impossible to account for unpowered axles with brakes. Then you would need an extra constant (for instance, a ratio equivalent to the TE ratio, except then for brakes, i.e. brake force divided by engine (or wagon) weight).
And that's hard because? It's not like different rail vehicles are going to have substantially different maximum braking decelerations.hertogjan wrote:And it is at this point impossible to account for unpowered axles with brakes. Then you would need an extra constant
If you use the 0.30 that TTDPatch uses as the default TE ratio, then max braking deceleration is 2.94 m/s². Period. I don't see much reason to make this configurable by engine, except possibly rail-driven vs gear-driven[0] locomotives. To my knowledge, in all the graphics sets, there's only one of these; the Class C Shay from the USSet. The solution might be to use the larger of 0.30 and the engine's TE ratio, but I'm not sure if it's worthwhile to check the engine's TE.
[0] These are probably not the official terms. Most locomotives are "rail-driven". "gear-driven" locomotives are the ones that have third, toothed, wheel in the middle, which meshes with toothed rail in the middle of the track.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
"Cog railway." That's the term I was looking for. Thanks. I knew I wasn't coming up with the right terms, but I just could not remember the right one.
It isn't really supported in TTDPatch either; the Shay is just an ordinary engine with some very non-ordinary specs: a very large TE ratio, and a max speed of 30 mph. So it's great for hill-climbing, where most steamers would stall out, but useless on the flat, because it's just too slow.
It isn't really supported in TTDPatch either; the Shay is just an ordinary engine with some very non-ordinary specs: a very large TE ratio, and a max speed of 30 mph. So it's great for hill-climbing, where most steamers would stall out, but useless on the flat, because it's just too slow.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Again, a new version of the physics patch. There's not much news, except that it works better now:
-I cleaned the code a bit. The previous version was a bit messy (code-wise), and this is fixed now.
-Problem for newGRF support for tilting cars was fixed.
-Bridge speed limits are now handled the same way as curves: Not a jump from the previous speed to the speed limit, but a gradual (albeit quick) decrease.
-Better traction handling for red signals: Traction is switched off when train stops at red signal. Moreover, it should now be easy to implement yellow signals as well (i.e. combination of this patch and a yellow signals patch is an easy job now).
The physics details in the train window are still there for debugging. If all works fine, then I will remove them (either completely or partially).
For now, it needs some testing. For instance, I am not sure that the maximum traction force for powered wagons is computed correctly.
So please try the patch in your own game (don't fear to use newGRFs), and report any errors you may find (e.g. trains stopping for no obvious reason, erroneous values in the purchase window, etc.)
-I cleaned the code a bit. The previous version was a bit messy (code-wise), and this is fixed now.
-Problem for newGRF support for tilting cars was fixed.
-Bridge speed limits are now handled the same way as curves: Not a jump from the previous speed to the speed limit, but a gradual (albeit quick) decrease.
-Better traction handling for red signals: Traction is switched off when train stops at red signal. Moreover, it should now be easy to implement yellow signals as well (i.e. combination of this patch and a yellow signals patch is an easy job now).
The physics details in the train window are still there for debugging. If all works fine, then I will remove them (either completely or partially).
For now, it needs some testing. For instance, I am not sure that the maximum traction force for powered wagons is computed correctly.
So please try the patch in your own game (don't fear to use newGRFs), and report any errors you may find (e.g. trains stopping for no obvious reason, erroneous values in the purchase window, etc.)
- Attachments
-
- patch(debug)_physics_r3493_31-01-2006.patch
- Physics patch (debug) - 31 jan 2006 - r3493
- (74.11 KiB) Downloaded 443 times
Okay, new patches today.
I post three versions:
1. The train physics patch with debug options
2. The road vehicle physics patch (still under construction) with debug options.
3. A version that merges the two above, but without the debug options (the extra info shown in the train/road vehicle window).
Number 1 has not changed a lot, except that I moved around some code.
Number 2 is entirely new. It is still under construction. The road vehicle controller functions are quite a jungle, so I need more time to figure out how to implement things correctly. So it might not work properly in some places. However, the most important part -the physics- works.
Number 1 and 2 are designed for debugging: If you want to understand what is going on, then you should use 1 or 2. They are not directly mergeable; in this case 1+2=3 does not work that easy. I merged the patches 1 and 2 to 3. Number 3 should therefore be downloaded by anyone who wishes to use the patch, without debugging.
Okay, here they are. Have fun playing (or searching for errors, if you want).
I post three versions:
1. The train physics patch with debug options
2. The road vehicle physics patch (still under construction) with debug options.
3. A version that merges the two above, but without the debug options (the extra info shown in the train/road vehicle window).
Number 1 has not changed a lot, except that I moved around some code.
Number 2 is entirely new. It is still under construction. The road vehicle controller functions are quite a jungle, so I need more time to figure out how to implement things correctly. So it might not work properly in some places. However, the most important part -the physics- works.
Number 1 and 2 are designed for debugging: If you want to understand what is going on, then you should use 1 or 2. They are not directly mergeable; in this case 1+2=3 does not work that easy. I merged the patches 1 and 2 to 3. Number 3 should therefore be downloaded by anyone who wishes to use the patch, without debugging.
Okay, here they are. Have fun playing (or searching for errors, if you want).
- Attachments
-
- patch_physics-rv+t_r3575_07-02-2006.patch
- Train and road vehicle physics patch (no debug) - 07 feb 2006 - r3575
- (94.62 KiB) Downloaded 404 times
-
- patch(debug)_physics-rv_r3575_07-02-2006.patch
- Road vehicle physics patch (debug) - 07 feb 2006 - r3575
- (33.45 KiB) Downloaded 377 times
-
- patch(debug)_physics-t_r3575_07-02-2006.patch
- Train physics patch (debug) - 07 feb 2006 - r3575
- (78.15 KiB) Downloaded 416 times
The new, highly improved road vehicle acceleration patch has arrived!
Again, two more downloads: one debug version with only the road vehicle acceleration functions, for those who want to know how it exactly behaves. The other version is a combined version of road vehicle and train realistic acceleration with all debug stuff removed.
I decided not to upload a new train physics patch this time, as it has not changed that much since last week.
Let me summarise the new features and changes:
-The automatic assignment of power and weight for road vehicles was removed, and replaced with vehicle-specific data.
-Road vehicle data such as speed, power, weight, air drag coefficient, max tractive effort from newgrf supported.
-Speed limit of road vehicles lifted to 255 km/h. This can easily be changed to higher values as well*.
-When "Show SI units (...)" is enabled, weights are displayed in kg instead of t**. For road vehicles, the weight precision of 250 kg is therefore visible; i.e., you will be able to see the difference between a 10000 kg and 10500 kg truck.
-Relevant physical data is shown for road vehicles: If realistic acceleration for road vehicles is enabled, you will be able to see weight and power of trucks and buses, otherwise this information is hidden.
-Hitting the stop button will now not stop a truck instantly, but it will slow down gradually. The braking distance is way shorter than that of a train, of course.
-When a road vehicle is blocked or stopped, the speed is really set to 0. (This was not the case in the previous version).
Finally, I have a few remarks to make:
-If you have patched your version, do a complete rebuild. On my computer, a partial build gave strange errors.
-Since the patch changes a lot of code, including the newgrf features which the main dev team is working on (currently), the patch may easily give some conflicts during merging with newer revisions of the trunk. I will try to keep my version of the physics patch as up-to-date as possible.
Please report any bugs you find.
*For those who remember a post of me last week. This feature does not cause instability anymore.
**The cargo units for the cargos which come in "tonnes" is still "tonnes". There is a difference between the cargo unit "tonne" and the weight unit t - only a formal difference of course, because the weight of the cargo unit "tonne" is always equal to 1 t = 1000 kg.
Again, two more downloads: one debug version with only the road vehicle acceleration functions, for those who want to know how it exactly behaves. The other version is a combined version of road vehicle and train realistic acceleration with all debug stuff removed.
I decided not to upload a new train physics patch this time, as it has not changed that much since last week.
Let me summarise the new features and changes:
-The automatic assignment of power and weight for road vehicles was removed, and replaced with vehicle-specific data.
-Road vehicle data such as speed, power, weight, air drag coefficient, max tractive effort from newgrf supported.
-Speed limit of road vehicles lifted to 255 km/h. This can easily be changed to higher values as well*.
-When "Show SI units (...)" is enabled, weights are displayed in kg instead of t**. For road vehicles, the weight precision of 250 kg is therefore visible; i.e., you will be able to see the difference between a 10000 kg and 10500 kg truck.
-Relevant physical data is shown for road vehicles: If realistic acceleration for road vehicles is enabled, you will be able to see weight and power of trucks and buses, otherwise this information is hidden.
-Hitting the stop button will now not stop a truck instantly, but it will slow down gradually. The braking distance is way shorter than that of a train, of course.
-When a road vehicle is blocked or stopped, the speed is really set to 0. (This was not the case in the previous version).
Finally, I have a few remarks to make:
-If you have patched your version, do a complete rebuild. On my computer, a partial build gave strange errors.
-Since the patch changes a lot of code, including the newgrf features which the main dev team is working on (currently), the patch may easily give some conflicts during merging with newer revisions of the trunk. I will try to keep my version of the physics patch as up-to-date as possible.
Please report any bugs you find.
*For those who remember a post of me last week. This feature does not cause instability anymore.
**The cargo units for the cargos which come in "tonnes" is still "tonnes". There is a difference between the cargo unit "tonne" and the weight unit t - only a formal difference of course, because the weight of the cargo unit "tonne" is always equal to 1 t = 1000 kg.
- Attachments
-
- patch_physics_r3596_12-02-2006.patch
- Physics patch - version 12 feb 2006 - r3596
- (119.8 KiB) Downloaded 407 times
-
- patch(debug)_physics-rv_r3596_12-02-2006.patch
- Road vehicle physics patch (debug) - version 12 feb 2006 - r3596
- (62.79 KiB) Downloaded 422 times
I can remember when we started working on train acceleration. We never really finished and to be honest, I don't like the result.
What we did was that we read Davis formula to tell about draft and resistance and so on. Then we also read stuff about steam and electric traction on grades and stuff. Then something happened when we made the code, I can't really remember what. Oh well.
As for this patch, I haven't read it yet, but reading about it, I noticed some things.
All rolling stock got a speed limits. It migth be set by power, but more often it's set by max RPM in the engines/bearings or some other weak link. One of the weak links are the electric engines that goes into too high RPM. If they do that, they risk to throw off the copper string they are made of and the engine will then be completely dead. You need to rebuild the internal parts. Electric and diesel-electric trains don't have a transmission to set to neutral, so even when they are pulled, the electric engines rotate and you have to take their RPM into account.
Other speed issues are stuff like stability. You might have power to go 300 km/h, but if you got bogies, that will derail at 160, you should not try to reach 300.
Now the question is how to set different types of bearings and so on. I think we used 3% grades (this is steep), but I'm not sure.
Here are (some) of the links we used:
http://www.railway-technical.com/st-vs-de.html
http://www.railway-technical.com/
http://www.uwm.edu/~horowitz/PropulsionResistance.html
and we didn't use this one, but it looks interesting anyway:
http://www.arema.org/eseries/scriptcont ... apter2.pdf
What we did was that we read Davis formula to tell about draft and resistance and so on. Then we also read stuff about steam and electric traction on grades and stuff. Then something happened when we made the code, I can't really remember what. Oh well.
As for this patch, I haven't read it yet, but reading about it, I noticed some things.
All rolling stock got a speed limits. It migth be set by power, but more often it's set by max RPM in the engines/bearings or some other weak link. One of the weak links are the electric engines that goes into too high RPM. If they do that, they risk to throw off the copper string they are made of and the engine will then be completely dead. You need to rebuild the internal parts. Electric and diesel-electric trains don't have a transmission to set to neutral, so even when they are pulled, the electric engines rotate and you have to take their RPM into account.
Other speed issues are stuff like stability. You might have power to go 300 km/h, but if you got bogies, that will derail at 160, you should not try to reach 300.
Now the question is how to set different types of bearings and so on. I think we used 3% grades (this is steep), but I'm not sure.
Here are (some) of the links we used:
http://www.railway-technical.com/st-vs-de.html
http://www.railway-technical.com/
http://www.uwm.edu/~horowitz/PropulsionResistance.html
and we didn't use this one, but it looks interesting anyway:
http://www.arema.org/eseries/scriptcont ... apter2.pdf
I think in the end, it will be a balance between what is decent and as close to realistic given the "game" factor of it all.
I mean seriously, do you want to apply the details of bearings, widgets, springs, and worbels to a game engine that could make better use of those CPU cycles to something like better 3D generation?
I mean seriously, do you want to apply the details of bearings, widgets, springs, and worbels to a game engine that could make better use of those CPU cycles to something like better 3D generation?
-Buggi
Programmer and TTD fan...
Programmer and TTD fan...
I agree with Buggi - you're definitely overcomplicating things. In practice, the maximum speed a diesel or electric locomotive is allowed to travel is not determined by engines, governors, traction motors, bogies or bearings. It's determined by what the sticker says.
- Attachments
-
- 80.jpg (29.79 KiB) Viewed 10688 times
We are not talking about the same. The sticker do not say anything about rolling resistance and it's actually a great factor. Also the sticker says a max speed and I said WHY they got a max speed. I read that this patch should be able to remove the max speed and make trains go even faster if they got enough power to do so.PikkaBird wrote:I agree with Buggi - you're definitely overcomplicating things. In practice, the maximum speed a diesel or electric locomotive is allowed to travel is not determined by engines, governors, traction motors, bogies or bearings. It's determined by what the sticker says.
- bobingabout
- Tycoon
- Posts: 1850
- Joined: 21 May 2005 15:10
- Location: Hull, England
yet on trainsim, i drove my class37 at 120MPH.
JPG SUX!!! USE PNG!!!
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
You cannot incorporate all factors into a patch. At some point, you will have to say, I will will take these factors into account, and I disregard all other factors.
At this point (considering the train acceleration) the most important factors are taken care of. I don't think that adding more factors will change the behaviour significantly. If adding those factors does not change the behaviour so much that it is noticable, then you could better forget about them.
But, as I told earlier, the new physics patch is better than the old realistic acceleration option, since the old function contained a lot of unphysical formulas. At least the formulas are correct now, including the units.
And finally, about this:
I mean, those formulas in those sources make me laugh. Those pages are certainly not a good example of how you should deal with physics!
At this point (considering the train acceleration) the most important factors are taken care of. I don't think that adding more factors will change the behaviour significantly. If adding those factors does not change the behaviour so much that it is noticable, then you could better forget about them.
But, as I told earlier, the new physics patch is better than the old realistic acceleration option, since the old function contained a lot of unphysical formulas. At least the formulas are correct now, including the units.
And finally, about this:
Bjarni wrote:Here are (some) of the links we used:
(...)
and we didn't use this one, but it looks interesting anyway:
(...)

I mean, those formulas in those sources make me laugh. Those pages are certainly not a good example of how you should deal with physics!
If people are talking about forces in pounds, they mean pound-force, which equivalent to the weight of one pound (i.e. the gravitational force exerted on a mass of 1 pound). But it is quite confusing. So (correct me if I'm wrong) one pound-force (1 lbf) is equal to approximately 3.7 N or 4.5 N, depending on which pound you are talking about.
The best way to do things is with SI units*. No ambiguous values, no people getting confused, etc.
When I read such texts, the first thing I do when I come across a formula is to check that the dimensions (and units) are right. If not, I stop reading it immediately. Which was the case with those links.
*Unless you study particle physics or quantum field theories. Then you measure almost everything in eV (electron-volt), which is in fact rather useful since on such scales SI units would give you extremely small (or large) numbers.
The best way to do things is with SI units*. No ambiguous values, no people getting confused, etc.
When I read such texts, the first thing I do when I come across a formula is to check that the dimensions (and units) are right. If not, I stop reading it immediately. Which was the case with those links.
*Unless you study particle physics or quantum field theories. Then you measure almost everything in eV (electron-volt), which is in fact rather useful since on such scales SI units would give you extremely small (or large) numbers.
with the force of a pound I assume you mean gravitational force? doesn't it then also matter where on earth you measure?
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
Who is online
Users browsing this forum: No registered users and 2 guests