Physics patches

madman2003 · Post by **madman2003** » 09 Apr 2006 20:22

Roadveh acceleration is still not ok, will look at it later.

madman2003 · Post by **madman2003** » 09 Apr 2006 20:51

The real patch now, with hopefully slightly better roadveh accel handling (although i'm not entirely sure yet).

Michi_cc · Post by **Michi_cc** » 09 Apr 2006 22:01

Found a bug: settings.c line 1155, you've lost a | somehwere between imperial and metric.

And another possible bug: According to the vehicle info, a MPS Regal bus makes 56 km/h, but even empty it only manages to do 46 km/h. Feight trucks seem to be okay, though. (48 km/h advertised, running 47km/h)

And finally, a small patch addition that fixes the replace train window, as an engine carrying passangers could cause the vehicle info area to overflow with all the new info.

-- Michael Lutz

madman2003 · Post by **madman2003** » 10 Apr 2006 07:54

Thanks for the info, a new patch (with more acceptable roadveh speeds).

hertogjan · Post by **hertogjan** » 11 Apr 2006 14:10

madman2003, can you please indicate what changes you have made to the patch since I last posted my version?
(Changes other than only making it compatible to the svn trunk)

madman2003 · Post by **madman2003** » 11 Apr 2006 19:10

You want specifics(i'll do my best

) or rough changes?

hertogjan · Post by **hertogjan** » 11 Apr 2006 19:44

I was not able to spot any rough changes, so tell me about the details then.
What I do know (although I did not check the details in the code) is that you made it compatible with the svn trunk changes.

madman2003 · Post by **madman2003** » 11 Apr 2006 20:46

The realistic acceleration function in train_cmd.h has been made more accurate, by moving up the scale of the integer calculations were it was usefull(to prevent rounding of errors). Some stuff was moved to int64 because of overflows. Speed is now converted to m/s^10-2, because one m/s is 3.6 km/h and that's a lot. Due to trunk changed, speed is now dealt with in km/h instead of conversion to mph and back. The roadveh accel = lines was *4 instead of *2 (which would represent the 2:1 scale of the roadveh speed (if i'm wrong about this interpretation, please tell me)), roadveh magic constant is doubled for this change. I removed the aircraft thing, because it should be a seperate patch (some dev told me speed was some x/y * speed constant, but with speed in mph, not kph, will try to find that again). I removed two of the three imperial systems, because some changes i made (or trunk changes) required me to redo some things and it didn't seem usefull to have 3 imperial systems (also didn't know exactly what to do with them). One or two things of the patch, like the FORCE variable are already in trunk and a dev is working on slowly merging the patch into trunk.

EDIT: about the *4 -> *2 with roadveh's, keep in mind that some changes got rid of some bitshifting you did in some places(can't remember exactly where). The acceleration even "felt" too fast.

madman2003 · Post by **madman2003** » 12 Apr 2006 09:30

New patches, this time seperate and combined. Hopefully roadvehaccel beheaviour has finally been fixed. It's against r4376 of the trunk.

hertogjan · Post by **hertogjan** » 12 Apr 2006 15:50

I have a few comments on what you describe here.

madman2003 wrote:The realistic acceleration function in train_cmd.h has been made more accurate, by moving up the scale of the integer calculations were it was usefull(to prevent rounding of errors). Some stuff was moved to int64 because of overflows. Speed is now converted to m/s^10-2, because one m/s is 3.6 km/h and that's a lot.

I do agree that the internal units of 1 m/s are too large. I have already my own version in which I changed this to 0.01 m/s partially. I use both 1 m/s and 0.01 m/s units: the 1 m/s for the force calculations: they need not be that accurate at all, since you will never notice the difference, and the smaller numbers have as an advantage that the numbers stay small enough. I use the 0.01 m/s for comparisons (i.e., comparing speed with max_speed) to get the maximum speeds of the trains closer to the maximum speed indicated in the train info window.

madman2003 wrote:Due to trunk changed, speed is now dealt with in km/h instead of conversion to mph and back. The roadveh accel = lines was *4 instead of *2 (which would represent the 2:1 scale of the roadveh speed (if i'm wrong about this interpretation, please tell me)), roadveh magic constant is doubled for this change.

The *4 instances you find in the code are to convert masses from 1/4 t to 1 t. They don't have anything to do with the magic constant. Therefore I advise that you revert the change of yours, since it is now even more confusing what the magic constant is.

madman2003 wrote:I removed the aircraft thing, because it should be a seperate patch (some dev told me speed was some x/y * speed constant, but with speed in mph, not kph, will try to find that again).
I removed two of the three imperial systems, because some changes i made (or trunk changes) required me to redo some things and it didn't seem usefull to have 3 imperial systems (also didn't know exactly what to do with them). One or two things of the patch, like the FORCE variable are already in trunk and a dev is working on slowly merging the patch into trunk.

The GUI parts are not the main goal of the patch and they are very easy to implement, so they may be put into a different diff. For instance, the aircraft speeds only need a few lines of code.

madman2003 wrote:EDIT: about the *4 -> *2 with roadveh's, keep in mind that some changes got rid of some bitshifting you did in some places(can't remember exactly where). The acceleration even "felt" too fast.

As I told you, the origin of the factors 4 come from the mass units being 250 kg rather than 1000 kg. The acceleration for road vehicles may be a little bit unbalanced. It was balanced before, but somehow I felt that I had to add internal friction (which I didn't do before), but I had not enough time to rebalance the powers and weights of the buses and trucks. (I was away from home for one week, and implementing the elrail features consumed most of the time at that point, just before I left). It needs a little tweaking/fiddling which might take some time.

Maybe tonight, or else tomorrow night, I will post my current version (which is under construction now). The exact time depends on the rebalancing of the RA-RV part. I also have found some little bugs that need to be removed, and I cleaned the code in some places (e.g., removed redundant variables).

madman2003 · Post by **madman2003** » 12 Apr 2006 16:12

If the *4 is due to mass being in 250 kg, then doing accel= c1 * 4 / mass seens strange, accel = c1 / (mass * 4) would make more sense. Once i have an anser to that i will change it back

. If you also point out which things the new version brings when it comes, so i can merge the changes to my local copy.

hertogjan · Post by **hertogjan** » 13 Apr 2006 19:24

No, think of it. The masses are in units of 250 kg. So to convert to a mass in units of 1000 kg you need to divide the value by 4. For example, a truck that has a mass of 36 units (of 250 kg) is 9 tons.
Since

Code: Select all

acceleration [0.001 m/s^2] = force [N] / mass [1000 kg]

and

Code: Select all

mass [1000 kg] = mass-units [250 kg] / 4

we have

Code: Select all

acceleration = force / (mass-units / 4) = force * 4 / mass-units

Does this clarify how the code works?

Note: The conversion from acceleration in 0.001 m/s^2 to acceleration in 1 m/s^2 happens a few code lines later:

Code: Select all

speed = max(speed + (accel * RV_ACCEL_MAGIC_CONSTANT / 1000), 0);

madman2003 · Post by **madman2003** » 14 Apr 2006 09:27

I get your point, guess i was thinking the other way around.

hertogjan · Post by **hertogjan** » 14 Apr 2006 19:28

Okay, here is my current work-in-progress version of the physics patch. It does work, but there are some things that I need to look at, because I'm not sure that the code is rigid enough in some places.
I have found a number of (quite disturbing) bugs from my previous versions*, and I fiddled around with the numbers in physics.h. For instance, I decreased the magic constant for road vehicles from 80 to 45, so that road vehicle don't accelerate to maximum speed almost instantly. I did not change the weights and power ratings of the vehicles.
Also have a look at the train acceleration function, which is now partially in 0.01 m/s.

Tomorrow I will have a closer look on some issues I have thought of. Please indicate if you think that there are bad pieces of code; then I will also fix them.

*To name a few:
-In the road vehicle acceleration function, there was a line that always stored 0 to v->subspeed; this should be fixed now. The bug wasn't really noticable in the game, though.
-In the train acceleration function, the traction modes TM_FASTBRAKE and TM_SLOWBRAKE were followed by a line

Code: Select all

mode = TM_BRAKE;

which rendered the modes TM_FASTBRAKE and TM_SLOWBRAKE useless. This should have been noticable in the game, if you knew where to look for.

madman2003 · Post by **madman2003** » 14 Apr 2006 22:31

I will correct the flaws in my working copy too, the extreme acceleration was noticed already, the train braking not (i'm new at C and probably was happy that everything worked fairly well). Thanks for the effort.

EDIT: I just looked in the acceleration function and found no evidence of the bad brake with trains(maybe you had a newer unshared version), for road vehicles there isn't a slow or fastbrake mode as far as i can see. (haven't looked at your new patch yet)

hertogjan · Post by **hertogjan** » 17 Apr 2006 20:24

A new version of the physics patch.
Let me summarise what I've done this weekend:
-I cleaned up some of the code (e.g., removed the dreaded direct calls to the map array from the code).
-I changed some of the coefficients in physics.h a little.
-I added and removed some lines in the traction handlers (for trains and road vehicles), so braking should be smoother now. Also, some mistakes in the traction handlers were removed.
-I changed the way maglev trains brake. Formerly, I coded maglev trains to use mechanical brakes (a constant force) and negative traction. However, the brake force generated by the latter is insufficient to stop the train within a reasonable distance. Therefore I added airbrakes to the maglev train. Currently when a maglev train has to brake, it increases its air resistance by a (reasonably large) factor. The mechanical brakes are used only at low speeds. The negative traction remains as it was.
The air resistance factor and the threshold speed for mechanical brakes can be set in physics.h.
It is still an experimental feature, but I think it works pretty well. Comments are welcome.

Moreover, I made a little webpage with some background information on my patches. It can be found here. I think that in particular the description of the traction handler and traction modes may be useful.

(Note: From now on, I will not use separate language files, since it is too much work too maintain. All translations I have done will be included in the patch from now on.)

madman2003 · Post by **madman2003** » 20 Apr 2006 17:01

While working on some patch i found a problem which occurs when you have two engines and the second is dualhead(in my case an AL10(electric) and a pendolino(dualhead diesel)), the max traction is wrong. The problem is in train_cmd.c

max_traction += u->u.rail.cached_veh_weight * 100 * G_ACCEL * rvi_u->tractive_effort / 255;

This is the corrected line, in the original rvi_v->tractive_effort was called which belongs to the first engine, not the actual vehicle being processed. The same change is needed for the powered wagon line.

hertogjan · Post by **hertogjan** » 21 Apr 2006 12:52

You are right.
Only in the case of the powered wagons I will have to be a little bit more careful: I must make sure that the tractive effort ratio of the wagon is inherited from the engine in front of it.
To program this properly, I will have to figure whether the powered wagons already have their TE ratio stored in rvi_u->tractive_effort, or have rvi_u->tractive_effort = 0 so that we have to figure it out in the function TrainPowerChanged itself. I think the last option is the least complicated code-wise: We just have to store the TE ratio of the last engine we have come by in the consist, so that all powered wagons can inherit the value of the engine (directly) in front of it; more or less the same as is done with the tilting property in TrainConsistChanged.

hertogjan · Post by **hertogjan** » 24 Apr 2006 19:24

I have been busy implementing with what I described in the previous post.
There are, however, some problems with consistency. The issue is that powered wagons get their properties from the front engine, not the previous engine in the consist. (This how it was programmed initially, before I started changing it.)

I'll show you an example of what the problem is.
Suppose we have a (dual-headed) engine which allows to have powered wagons. Suppose those powered wagons have a power rating of 500 hp, and that the engine has 2x1500 hp. Now we construct a train with two powered wagons; it will look like this:

Code: Select all

engine1front-wagon1-wagon1-engine1rear

This train has a power rating of 4000 hp. So far, so good. Now we add a different engine to the rear of the already existing train, on also consisting of two parts, but having a power rating of 2x2000 hp, and allowing to add powered wagons of 800 hp. We (again) add two powered wagons to the train. Now comes the problem: The powered wagons are of the type of the front engine; they look the same as the first two powered wagons, so the train looks like this:

Code: Select all

engine1front-wagon1-wagon1-engine1rear-engine2front-wagon1-wagon1-engine2rear

And moreover, the wagons get the power rating as if they were wagons belonging to the front engine, hence 500 hp, and not 800 hp. The consist will have a rating of 9000 hp.
Now what I have coded already is the following: The wagons inherit their properties from the last engine encountered. So they will be 800 hp. In my patch, the train will now have 9600 hp. However, the graphics are still in the old form. So currently I have a train which looks like this:

Code: Select all

engine1front-wagon1-wagon1-engine1rear-engine2front-wagon1-wagon1-engine2rear

but its physics are this:

Code: Select all

engine1front-wagon1-wagon1-engine1rear-engine2front-wagon2-wagon2-engine2rear

Obviously, this is not consistent, and it needs to be fixed. Either by returning to the old situation, which is also confusing in my opinion, or by reprogramming, so that all properties will depend on the previous engine rather than the front engine.
I don't think that the graphics issue is a matter of the physics patch, but at least it should be consistent. So in order to decide what I am going to do, I need to know what the intended behaviour is.

Below is a version of my patch (work in progress!), to show how I changed the code to have the powered wagons inherit physical properties from the previous engine rather than the front engine.
(Note: I tested the code using the grf dbsetxlw.grf (Deutsche Bahn set). It is a good set for testing this piece of code.)

DaleStan · Post by **DaleStan** » 24 Apr 2006 20:42

hertogjan wrote:

Code: Select all

engine1front-wagon1-wagon1-engine1rear-engine2front-wagon1-wagon1-engine2rear

Make sure that the consists you are building are actually valid; most DBSetXL engines with wagon overrides also implement callback 1D. If Open doesn't support that callback yet, attempt to build the consist in Patch. If Patch doesn't let you build the consist, then don't build it in Open either.

Changing wagon-overrides to follow most-recent-engine rather than first engine is not a major issue in and of itself, but its side-effects are more onerous. Doing so would do very interesting things to type 82/83/86/8A action 2s, as the chain "knows" that such types refer to engine2type, when they really refer to engine1type. The obvious work-around is to redefine those four to refer to most-recent-engine, but that is, if possible, worse. Engines with A/B units like the USSet's F7 and PA-1, which rely on type 82 access to vars 40 and 41, will cease to work, because type 82 vars 40 and 41 for an engine would always report that the engine is the first in the consist/chain.

Transport Tycoon Forums

Physics patches

Who is online