Physics patches

[hertogjan]

I guess that it will be merged soon, as the bug it fixes is quite annoying.

[DarkFenX]

hertogjan, could you update patch for ottd trunk? I can't resolve and compile it w/o errors by myself (more precise - i can, but build_trains' gui doesn't have enough height to fit all train parameters - so i'm doing sth wrong...)

[hertogjan]

Here it is.
This version fixes the compatibility issues with the code changes in trunk.

[hertogjan]

The following versions (trunk and MiniIN) take out the TE ratio values for trains, and replaces them by 0, which is handled as a default ratio of 76/255. This fixes the issue that grfs may assume that if the TE ratio is not set, it then defaults to 76/255. This is what happens now. This behaviour is compatible with TTDPatch.
People who want custom TE ratios for the standard vehicles should use appropriate grfs.

Note that this is what one might call a "negative update": I have only taken out some code, and therefore the trunk version is smaller the previous trunk version.

[hertogjan]

Time for an update again.

This time, there are some radical changes.
Some constants that were predefined before, such as gravity acceleration, steepness of hills and the effect of curves on speed are now controllable by changing the values in openttd.cfg (not in the patch settings window!). How they can be set is described in a little text file that I added to the patch. In the future, some more configuration options like these may be expected.
Of course, the patch is made compatible with the existing trunk code. That is, maximum tractive effort is now also made available for semirealistic acceleration (i.e. the "realistic acceleration" of the trunk code).

There are a few issues however, which may or may not be visible. I did not check all combinations of settable parameters and grfs. It may well be that a certain train engine from a certain grf goes crazy in a world where gravity is huge and air drag is tiny. Also, there are some constructions in the code which I think are ugly (I will not get into details about this now).

It would be nice if some users test would this patch and tell their experiences (i.e. errors*, suggestions for improvement**, etc.).

Note that saving with this patch applied produces savegames that will not be compatible with other versions. I am aware of this issue, and I know exactly how to fix it, but with the patch currently in development, this way is easier.

*This may be: Weird behaviour of vehicles (e.g. sudden jumps in the speed), wrong values displayed (maximum speed, weight, power, maximum tractive effort).
**This may be: Extending the range of the configurable parameters, if the current ranges are not sufficient for some users.

[Rubidium]

Please take a close look at r8285 in branches/MiniIN.

[hertogjan]

This one should fix that issue in the trunk version.
The other changes are to keep the patch code compatible with the trunk code.

Note: Savegames made with previous versions of this patch may not be compatible with this version. (This is intended behaviour, not a bug )


Is there no-one who has tested this patch willing to give his/her opinion about it?

[skidd13]

Is there no-one who has tested this patch willing to give his/her opinion about it?

Nice patch! I like the ability to play OTTD like a realistic simulation. What about an option to sync the speeds with the changing days.

[DarkFenX]

I'd like to see it in the trunk too (like realistic behaviour of everything) as 'realistic behaviour' and keeping classic TTD behaviour as non-realistic.
But i had in latest versions (don't have enough time to compile it today, exam tomorrow) bug/feature - trains were not slowdowned like in trunk 'realistic' behaviour while entering/exiting station/depot during all that action, only initially...

[MagicBuzz]

also i dont think it should replace the current improved acceleration, as that works well, whether its actually realistic or not

I think it's a bit poor that a train can ride over a small hill faster than it can detour around it. Those little S-bends are a disaster to speed when horizontal, but not when vertical!

It depends. By exemple, for the TGV, there are a lot of slopes on the lines, to prevent many curves. At very hight speed (> 250 km/h) vertical changes are less important than the lost energy in curves.

[hertogjan]

What about an option to sync the speeds with the changing days.

I don't quite understand what you mean here. Can you explain what you mean by "syncing the speeds with the changing days"?

[DarkFenX]

For combining train speeds with daylength patches (lesser daylength - slower trains). But it's not a subject to be added to physics patch

[skidd13]

For combining train speeds with daylength patches (lesser daylength - slower trains).

Yes, I thought over something like this.

[hertogjan]

This version fixes some complaints made in a diversity of forum topics:
-The fact that OpenTTD works with internal units equal to km/h and newgrf with 1/1.6 mph caused a small discrepancy (of approximately 0.6%) in speed values of vehicles loaded from newgrf. This version addresses that issue by correcting the speeds loaded from newgrf. Moreover, the unit conversions for displaying values is now based on the principle of rounding decimals smaller than .5 down, otherwise up, instead of always down. The multiple rounddowns sometimes caused speed values to decrease by 1 mph or 1 km/h. The fix results in showing the values for both the standard set and newgrf sets correctly. I haven't found any rounding errors so far.*
I am pretty confident that no more rounding errors appear in the speeds. From now on, winning the jackpot is more likely than finding such a rounding error.
-Some people seem to dislike the fact that trains slow down too much in stations and depots. Using two new configuration options, these speeds can be adjusted. Consult the included documentation for more details.

This should be sufficient to silence these complaints, at least.


*I've tested this for all vehicle types.

[DarkFenX]

Could you update it for current trunk? I get too much conflicts which i can't resolve by myself.

[hertogjan]

I'll have a look at it soon. I know that there are several merging conflicts which are not easily solved. I have to study them myself too. Also, I will try to fix some strange road vehicle behaviour (mostly concerning vehicles during overtaking). Moreover, there is some dirty code (most of it appears when I try to find quick solutions to conflicts), that needs to be cleaned up.
I expect that I can post it here on Monday or Tuesday.

[hertogjan]

As promised, here is an updated version of the patch.
This version features:
- Several bug fixes for road vehicle behaviour. For instance, in the old versions a vehicle being overtaken by a faster vehicle would be stopped as soon as the overtaking vehicle came in front of the overtaken vehicle. This faulty behaviour is fixed. Also, if a vehicle cannot be overtaken (e.g. on a bridge or in a tunnel), the faster vehicle (i.e. the one that is behind) will slow down to the speed of the vehicle in front of it, instead of stopping.
- A new maximum speed setting for road vehicles in stations. Vehicles will now stop a little more smoothly. The effect is best seen in drivethrough roadstops, but applies to the classic roadstops as well. The speed can be adjusted in the config file.
- A change of the internal representation of the railtype physics to a different format. All parameters are now contained in a single struct. This will make it easier to add more railtypes in the future (e.g. narrow gauge, high speed rail or some futuristic railtype). Also the maglev specific properties (i.e. absence of max tractive effort, use of negative traction and the specialised maglev braking method) are constants in this struct, so that it will be easy to implement these features for future new railtypes.
- Some code changes to restore compatibility with trunk.

[hertogjan]

I managed to update the physics patch a little, thereby removing some errors (mainly in road vehicle behaviour) and compatibility/merging issues.
There are no new features this time. Just scroll upward and read to see what nice features were already included.

Is there still nobody finding any bugs in this patch?

[hertogjan]

No actual new features today, but the road vehicle behaviour has been fixed where it was broken, and I think it has been improved a little. As a bonus (not really a new feature since most things automatically go well) the physics patch also applies to trams when realistic acceleration for road vehicles is enabled.
Have fun with it.

[hertogjan]

This version contains a new experimental feature based on an idea of Bilbo. For trains, it shows the effective maximum speed of a fully loaded train. That is the speed for which the traction force of the train is equal to the resistance forces. This allows you to determine whether your train is powerful enough for its job.
Moreover, I extended Bilbo's idea a bit: I also added an indicator for the power needed to maintain the maximum speed of a train. This serves the same purpose: You will be able to determine whether a train has enough power.
This function works for realistic acceleration and semirealistic acceleration.
Anyone is free to test the correctness of the values. Rounding errors may cause some slight differences, but in general the estimates are quite accurate.
For coders who wish to know where the code is that is responsible for this feature: The functions are at the beginning of train_cmd.cpp.

Note that if you change a realistic acceleration setting (switch RA-T or SRA-T on or off, or change a RA-T parameter by the "patch" command on the console), the effective speed and necessary power indicator are updated only when the train is changed in a depot, or when loading or unloading.