Physics patches

hertogjan · Post by **hertogjan** » 10 May 2006 20:22

It doesn't seem that OpenTTD handles that callback correctly. In TTDPatch, you may be more limited in building mixed consists. But I doubt that this is the correct way of doing it.* The whole idea of having powered wagons is strange.
For now, I have left the code as it was in the previous version. I don't think it will lead to major problems or confusion. I will not (be able to) change it until there is a proper handling of powered wagons in mixed consists.

The first of the patch versions I post below does not contain new features, but contains a little clean-up of the code.
The second one is the same as the first one, but with an extra cheat option, to have road vehicles and trains ignore physical laws (like in curves and on hills) and speed limits (like on bridges, in stations and when entering depots). This cheat only works with realistic acceleration turned on, and the force equations will still apply (albeit without inclination forces). Currently, there is only one setting (on/off), but in the future there may be more finetuning (e.g. changing the curve, inclination, station, etc. handling independently).

NOTE: The cheat will not work with realistic acceleration disabled!

*I mean, from the perspective of grf, it is the correct way, since it is meant to be that way. In my opinion, EMUs and DMUs should come as units (like their names suggest), and not as a locomotive to which you have to add a certain amount of wagons.

DaleStan · Post by **DaleStan** » 19 May 2006 00:20

Kaboo Hahahein reports that this/these patch(es) has/have fallen out of sync with the trunk, and require(s) some conflict resolution. I'm willing to look at when I get the time, but you'd probably be a better person for that, as you know what your code is supposed to do.

hertogjan · Post by **hertogjan** » 21 May 2006 19:28

That "falling out of sync" happens all the time. Luckily there were only small conflicts this time; it took just a few minutes to fix them.

However, I managed to enable the cheat for the classic TTD acceleration as well. For realistic acceleration enabled, it works the same as the last version. If realistic acceleration is disabled, vehicles just behave as if curves and gradients do not exist, with the classic acceleration handling.
The cheat may behave a little bit differently* depending on whether RA is on or off. But since you will only use one of them (i.e. either on or off) at a time, this is probably not a great problem.

*This has something to do with engine/wagon speed limits and bridge speed limits.

Timberwolf · Post by **Timberwolf** » 22 May 2006 23:02

There are a couple of issues that I've found with this, using the US .grf set. I'm not sure whether they're specific to my set of patches/build environment or whatever, but...in train_cmd.c,

Firstly, the following:

Code: Select all

if (HasSignalOnTrackdir(gp.new_tile, i)) {
    v->u.rail.next_signal_tile = gp.new_tile;
    v->u.rail.next_signal_dir = i;
} else {
    v->u.rail.next_signal_dir = INVALID_TRACKDIR;
}

This can generate an assert in tile.h when the type of gp.new_tile isnt MP_RAILWAY. Try running a train across a level crossing to see what I mean. I changed it to the following:

Code: Select all

if ((IsTileType(gp.new_tile, MP_RAILWAY)) && (HasSignalOnTrackdir(gp.new_tile, i))) {
    v->u.rail.next_signal_tile = gp.new_tile;
    v->u.rail.next_signal_dir = i;
} else {
    v->u.rail.next_signal_dir = INVALID_TRACKDIR;
}

That solved it for me. Also, there's another possible assert you can get; basically building certain wagons in the US Set, or possibly building wagons without an engine. That's in the following part of train_cmd.c:

Code: Select all

if (IsBridgeTile(u->tile) && IsBridgeMiddle(u->tile) && DiagDirToAxis(DirToDiagDir(u->direction)) == GetBridgeAxis(u->tile)) {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailTypeOnBridge(u->tile))) engine_has_power = false;
    if (!HasPowerOnRail(prev_engine_railtype, GetRailTypeOnBridge(u->tile))) wagon_has_power = false;
} else if (IsLevelCrossingTile(u->tile)) {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailTypeCrossing(u->tile))) engine_has_power = false;
    if (!HasPowerOnRail(prev_engine_railtype, GetRailTypeCrossing(u->tile))) wagon_has_power = false;
} else {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailType(u->tile))) engine_has_power = false;
    if (!HasPowerOnRail(prev_engine_railtype, GetRailType(u->tile))) wagon_has_power = false;
}

Basically, it's possible for prev_engine_railtype to be invalid here. I changed it to the following:

Code: Select all

if (IsBridgeTile(u->tile) && IsBridgeMiddle(u->tile) && DiagDirToAxis(DirToDiagDir(u->direction)) == GetBridgeAxis(u->tile)) {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailTypeOnBridge(u->tile))) engine_has_power = false;
    if ((prev_engine_railtype >= RAILTYPE_END) || (!HasPowerOnRail(prev_engine_railtype, GetRailTypeOnBridge(u->tile)))) wagon_has_power = false;
} else if (IsLevelCrossingTile(u->tile)) {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailTypeCrossing(u->tile))) engine_has_power = false;
    if ((prev_engine_railtype >= RAILTYPE_END) || (!HasPowerOnRail(prev_engine_railtype, GetRailTypeCrossing(u->tile)))) wagon_has_power = false;
} else {
    if (!HasPowerOnRail(u->u.rail.railtype, GetRailType(u->tile))) engine_has_power = false;
    if ((prev_engine_railtype >= RAILTYPE_END) || (!HasPowerOnRail(prev_engine_railtype, GetRailType(u->tile)))) wagon_has_power = false;
}

I think there are better ways to get it working, but that seems to do the trick.

Also there's an issue which can be specific to certain GRF-sets with tenders and the like - at least I've found it with the USSet. Basically, there's a few lines with the following calculation:

Code: Select all

... / u->u.rail.cached_veh_weight

It's possible for u.rail.cached_veh_weight to be zero, in my experience. I'm pretty sure it's contained solely in the 'Curve Handling' section of train_cmd.c, although I'm not sure what's the best way to deal with it - I've used solutions both of ignoring zero-mass wagons, and also setting the minimum mass to 1 - both work quite well even if they're not optimal.

hertogjan · Post by **hertogjan** » 23 May 2006 20:42

Thank you for the information. These are errors that might only appear in some "exceptional" situations (i.e. some grf-sets). I will fix them as soon as possible.
About the second issue, the wagon power part, there are still some other problems taht need to be solved. Basically, I need an answer to the question: Do powered wagons in mixed consists (i.e. more than one engine type) inherit their properties from the front engine, or the most recent engine in the consist. (If it is the former, then we have to use the existing trunk code, otherwise some other things have to be sorted out on top of this patch code).

Post by **peter1138** » 24 May 2006 07:01

If you want to make it use the last engine for livery overrides and powered wagon/power, only minor changes are needed to TrainConsistChanged() and its friends.

In the DBsetXL, it still doesn't work properly though, because they are not designed to be mixed.

hertogjan · Post by **hertogjan** » 24 May 2006 15:29

Isn't it possible to prevent mixed consists from being created for grf sets where it doesn't work properly? Maybe just by showing an error message that "these engines/wagons cannot be combined to one consist"?

Post by **peter1138** » 24 May 2006 15:34

Yes, but that is up to the GRF to control. The game has no way of automatically determining this.

hertogjan · Post by **hertogjan** » 24 May 2006 15:46

Let me state it as follows: If the grf is coded* to have forbid certain combinations, is it then impossible to build such a combination in OpenTTD? (In other words: Does OpenTTD handle the callbacks properly?)

*Coded properly in the sense that it works at least in TTDPatch.

Michi_cc · Post by **Michi_cc** » 28 May 2006 19:10

I've updated the physics patch for current trunk, which is rev5005. This version doesn't include the unit GUI changes and the airspeed part, but incorporates the fixes mentioned by Timberwolf.

-- Michael Lutz

hertogjan · Post by **hertogjan** » 28 May 2006 20:38

Nice.
I had also made version*, but unfortunately I am not able to test it now, since the code won't compile properly (and that's not due to this patch). During the following week, I will have another look at it. Not tonight.

*I have rewritten the curve handling, and put it in a separate function. The main difference is that wagon lengths are counted, instead of number of wagons. For wagons which do not have the standard length, the old method does not always provide the proper length of the curve.

Sacro · Post by **Sacro** » 07 Jun 2006 23:31

Is this still going? I'd like to see it in the MiniIN, and even better in trunk!

hertogjan · Post by **hertogjan** » 08 Jun 2006 21:08

Sorry, it has been a while since I posted a version, for a number of reasons I will not bother you with*.
Unfortunately, someone decided to cut the bridge branch from the trunk. I had already simplified some of my own functions using functions from that branch. I have fixed that now: I replaced some of the code that I used before bridge was merged, and made some functions loosely based on the bridge branch myself, to protect myself from rewriting the acceleration controllers every time code is changed elsewhere.

I did not spend a lot of time testing (I've only tested that the bridge speeds were correct, with RA enabled and disabled), so there might be errors that slipped through. But my expectation is that it works fine (since it also did before, and not much has changed after all).

*Technical problems concerning the patch. And laziness

White Rabbit · Post by **White Rabbit** » 09 Jun 2006 16:17

I got a lot of warnings when compiling with your patch and OTTD ihas become unstable, crashing without apparent reason. The patch is fully functional though and I'm quite impressed.

I would, however, like it if the TE units were in kNs, because that's what the Patch uses and is more accurate. For example, he DE-AC33C of the DB Set XL has a TE of 517kN, but OTTD displays it as '51 ton force'.

hertogjan · Post by **hertogjan** » 11 Jun 2006 10:57

White Rabbit wrote:I got a lot of warnings when compiling with your patch and OTTD ihas become unstable, crashing without apparent reason. The patch is fully functional though and I'm quite impressed. I would, however, like it if the TE units were in kNs, because that's what the Patch uses and is more accurate. For example, he DE-AC33C of the DB Set XL has a TE of 517kN, but OTTD displays it as '51 ton force'.

For SI units, the force units are displayed in kN. For standard imperial and standard metric units, it is currently displayed in (metric) ton force.
If you wish to change one of these to kilonewton, change the line(s)

Code: Select all

		 835, 13, STR_UNITS_FORCE_METRIC,

in strings.c to

Code: Select all

		   1,  0, STR_UNITS_FORCE_SI,

or you may change it to any unit you like.

I have not seen many unstabilities in my version of OpenTTD, at least not anything that could be related to the patch. Concerning the compiler warnings: I also get some warnings, and I don't really know how to get rid of them, but they don't seem to do any harm. Not to my version anyway.
If you have some warning that concerns you, please let me know what it is (and what compiler you use).

White Rabbit · Post by **White Rabbit** » 11 Jun 2006 18:14

Thanks for that information.

Now that I've played with the physics patch properly, two problems have cropped up: with the train speed limit turned on, engines never reach their maximum speed, but stop accelerating at 1km/h or 2km/h below the maximum; with the train speed limit turned off, engines reach speeds they were never capable of doing in real life (the Challenger locomotive, with its high HP, can reach way above 200km/h!), thus removing the realism. Are you aware of these issues?

hertogjan · Post by **hertogjan** » 12 Jun 2006 10:53

Yes, I am aware of those issues.

The fact that engines never reach their maximum speed, is caused by the traction handling. I implemented some tolerance value, such that when the speed is above the maximum speed plus the tolerance value, the engine brakes, if the speed is below the maximum speed minus the tolerance value, then it accelerates, and if the speed is between those values, the engine goes into cruise control (acceleration is kept at 0 if possible). The tolerance is actually needed to prevent the speed from bouncing up and down when the maximum speed is reached.*
I will try to find a way to get the maximum speeds up a little. It has to be finely tuned, since we also do not want the engines to go a little faster than the maximum speed.

The option to exceed the speed limit makes some powerful engines to go far beyond their maximum speed. I actually finetuned the force parameters (i.e. the numbers that control air drag, rolling resistance, etc.) so that the standard vehicles are just able to reach their maximum speed (for trains: that is with some wagons and cargo; some fully loaded road vehicles and extremely heavy trains may not reach their maximum speed). I found that the engines in some newgrf sets are a lot more powerful than the engines in the original set. This is causing them to go way faster than they were designed for.
I am considering to change this option to a cheat.
Fiddling around with the constants may cause the game to be unplayable with the original set, so I will not do this.

*This is caused by the following: If the speed is a little below maximum speed, the engine accelerates, and the speed increase above the maximum speed, but then the brakes are applied, and the speed is decreased to below the maximum speed. Then the whole process starts over again.

hertogjan · Post by **hertogjan** » 19 Jun 2006 21:18

I have fixed the problems with engines not reaching their maximum speed. At least they will accelerate to the maximum speed or 1 km/h below (due to round-off errors).
Also, I have changed the order of the unit systems, so that the first three unit systems coincide with those of the unpatched version, to prevent having the wrong unit set when loading a savegame from an unpatched version into the patched version.
I also fixed a number of small GUI problems. The purchase windows for road vehicles and trains are a little bit larger, and (for trains) the powered wagons data is now split to two lines (to avoid text overflow).
Maybe there are some more little changes, but I can't exactly remember which.

There are two versions. One is to be patched against trunk, the other against the MiniIN branch. They should behave exactly the same. (If they don't, then it's a mistake.)

hertogjan · Post by **hertogjan** » 30 Jul 2006 20:12

A little update: I changed the curve handling a bit. Now not only the weight of the last vehicle in the curve is used for computing the maximum speed, but the maximum of the weights of all locomotives and carriages in the curve. I discovered that previously the front engine was not counted at all (since it is never the last vehicle on a curve). As a side effect, trains seem to be slower in curves; this is of course caused by the large weight of the locomotive(s), which get counted all the way through the curve, not only at the end.
To balance gameplay, I have increased some of the curve constants to compensate for the heavier effect of the curve handling.

Again, there is a version for the trunk and a version for the MiniIN.

SirkoZ · Post by **SirkoZ** » 30 Jul 2006 22:34

Very nice patch, hertogjan, tranins and road vehicles travel very "fluently" with it I must say. The hills do tire them down though.

Quite realistic.

One question though - why do maglevs get slowed down on the hills (to such extent) - is it really >>all<< just air resistance?

At any rate - I have posted more about this in the MiniIN topic together with richk67's reply.

S/Z

Transport Tycoon Forums

Physics patches

Who is online