Mini Integrated Nightly [discontinued 31/12/2006]

[klogg]

It's not that I dont't want the patch to affect the industry.
(To be honest, I don't know if I want that *confused*)
I would like to use the patch in the way that it slows down the year.
I mean so that I can play longer (real world time) with fewer years passing.
That is what the patch is basically for, isn't it?
Somebody else should think of what needs to be affected then.

klogg

[hertogjan]

Just for your information, I created a MiniIN version of the physics patch. Basically, the patch consists of realistic acceleration for trains and road vehicles. The former was already present, but is almost totally rewritten (since the old one is garbage). The latter is completely new. Of course, it also includes some extra newGRF support (for the vehicle properties that are relevant for realistic acceleration).

You can find it here.

[richk67]

I saw; and Im just adding it tonight (with the usual settings and savegame version modifications).

Edit: hmmm.... I just discovered that this just plain deletes the real acceleration routine of Sirkoz's patch. Is there any way you can make your patch optional, so that the options are a) original accel, b) Sirkoz Real Accel, c) Physics??

Alternatively, Sirkoz: are you happy to have your patch replaced by Physics?

(latter is simpler for me - but Sirkoz-RA has been one of the most reliable patches Ive had...)

[SirkoZ]

Just for your information, I created a MiniIN version of the physics patch. Basically, the patch consists of realistic acceleration for trains and road vehicles. The former was already present, but is almost totally rewritten (since the old one is garbage). The latter is completely new. Of course, it also includes some extra newGRF support (for the vehicle properties that are relevant for realistic acceleration).

You can find it here.

That's really nice, we'll see how much the old realistic_train_acceleration, corrected with my patch was garbage, however, I agree without my patch, it was really bad. I'm off to test your patch...

[SirkoZ]

Well - now I have tested the patch quite extensively and I must say it's very nice, I really like it, the trains very "fluently" "flow" on the tracks - only one thing, that is bothersome/questionable to me is - how come mag_lev trains get slowed down on the hills? That is really strange - I mean it's sliding on the magnetic field - what could possibly stop it uphill? Air resistance? No, seriously...

I know, richk67, that this patch totally replaces even my RA patch, well, let's say - I would really like the maglev question to be cleared up firstly.
Although my patch is really really simple, the behaviour of the trains comes very close to the one with the physics patch, except for bigger hill penalties with the phys_patch.

Perhaps we should make it optional...I'll decide upon maglev clarification.

S/Z

[richk67]

OK - I added the patch anyways. We can always back it out. The one effect Im really not sure I like is the rapid left-right jink is now heavily penalised... so all the Pile Transport junctions travel really slowly.

[SirkoZ]

Oh, I forgot to mention that one, yes - it's quite a slowdown...
Anyway - if it's more realistic, I'm all for it, but the hill speeds are questionable to me and also this left-right quick "flip".

At this time from what I've read in the physics_patch topic, the whole patch is heavily dependent on constants - even for trains to reach the full speed which to me sounds somewhat iffy. I don't know, I really don't...

Perhaps now, players will appreciate my patch better. j/k

[DaleStan]

how come mag_lev trains get slowed down on the hills? That is really strange - I mean it's sliding on the magnetic field - what could possibly stop it uphill?

Gravity?
Last I checked, uphill is still uphill, even if you aren't touching the rails.

If "uphill but without touching anything" didn't require any additional force, then a baseball thrown up in the air would continue going uphill forever, since it never touches anything that would make it slow down.

[Tidus97]

+ the ball would be hitting air which would also slow it down.....

[SirkoZ]

Not on such low hills and with such force/horsepower.

[hertogjan]

OK - I added the patch anyways. We can always back it out. The one effect Im really not sure I like is the rapid left-right jink is now heavily penalised... so all the Pile Transport junctions travel really slowly.

That can be fixed quite easily, however.
You'll have to change these numbers in physics.h

Code: Select all

static const int huge_curve_const[RAILTYPE_END] =   {70000, 70000, 180000, 380000};
static const int large_curve_const[RAILTYPE_END] =  {55000, 55000, 150000, 300000};
static const int medium_curve_const[RAILTYPE_END] = {18000, 18000,  45000,  95000};
static const int small_curve_const[RAILTYPE_END] =  { 6500,  6500,  14000,  30000};

For that curve, -a curve of length 2 (or more precisely, length 13/8 to 20/8)- the large_curve_const is taken. I figured out (considering the curve radii) that the constant must be approximately 3 times as large as the medium_curve_const. But it may be better to just "fiddle around" with the constants rather than actually trying to calculate realistic values.
So for increased speed in curves, just increase the constants. Note that the maximum speed is proportional to the square root of the curve constant (for a fixed vehicle weight), so in order to double the speed, multiply the constants by 4.
Please note that the large_curve_constant need not be smaller than the huge_curve_constant (as the latter is already multiplied by some factor by the curve speed function). Personally, I think that the latter series of constants is already too large (I needed the heaviest steam engine from the US set to see the effect of the huge curves).

If you want, I can fiddle around with the constants and report new (better) values to you in a few days.

Not on such low hills and with such force/horsepower.

Well, you know that the traction force equals power divided by speed (and if you didn't, you do now). The (theoretical) maximum speed is the speed where an equilibrium is reached between the resistance forces acting on the train, and the traction force delivered by the train. In that case the equation

Code: Select all

total_resistance_forces = power / speed

is valid (or more precisely: this equation is valid if and only if the train travels at constant speed).
Now suppose that we go up-hill. Then the total resistance force is increased (by a gravitational force). If the resistance forces are larger than the traction force, the train slows down. The train does not slow down indefinitely, since when speed decreases, the traction force increases! Ultimately, a new equilibrium will be reached, i.e. a situation in which the above equation is valid again, but with different values for the total resistance forces and speed.
If you have understood these physics, you will come to the conclusion that (as long as there is gravity) trains will always have a lower maximum speed up hill than they have on flat terrain.

[richk67]

If you want, I can fiddle around with the constants and report new (better) values to you in a few days.

Yeah, ok. I was more thinking that perhaps a special case can be made for a left/right jink, since all it is doing in OTTD is making up for the fact we cant do longer smoother angles; ideally we would want to step left say 1 tile in 20, but in OTTD that cannot be done smoothly, but has to be 18 forward, then a left/right jink. IMO this should not be penalised.

[hertogjan]

I can make an exception for those curves. I will add another series of constants, and add some lines of code to the function GetCurveMaxSpeed (or whatever it is called).
Indeed it is very hard to avoid those short S-bends. In order to avoid those bends (suppose going 1 square to the left) one has to go left 3 tiles, forward 2 tiles and right 2 tiles, which would cost you 7 tiles (!) instead of just one.
So the obvious fix is that we pretend* those S-bends to be longer.



*That what's (Open)TTD is all about: What you see on the screen is just an idea what it should be. Your brain will have to smoothen things out and imagine all kinds of other fantastic things. If your brain is able to do that, then it's a great game.

[meowsqueak]

If you have understood these physics, you will come to the conclusion that (as long as there is gravity) trains will always have a lower maximum speed up hill than they have on flat terrain.

I would have thought it was painfully obvious actually, but I like your explanation.

[SirkoZ]

Still maglevs do slow down quite considerably, which is questionable.

[richk67]

I have to agree with Sirkoz here. The major thing about the maglevs is that they have a massive surplus of power. On the flat, they would not run at maximum possible speed, but at a maximum cruising speed - probably about 75-80% power.

When an incline is met, rather than slow down, more power would be applied to maintain the same speed up the incline as was had on the flat.

This way timetable schedulers can plan for a constant speed and only need be concerned about the distance along the track and not the gradient.

[sc79]

hertogjan;
Is any of this optional/configurable? I admit I only scanned the topics quick, if you've made allowances, ignore me.

It sounds like a really good patch, but having train behavior dictated by what you think works best or general opinion, might not suit everyone.

Last time things were changed, train behavior around stations/signals had a pretty major impact. Most of my games with large established networks became unplayable, and though you can usually learn to work with it for new games, its a pain to have it dictated (not to mention the 'off' option is, and i assume still will be, unplayable due to trains stopping on hills).

Im not sure why, if you (as in, any developer) are going to so much effort for a patch, you cant pull a few variables from the config file so things can be adjusted.

[R2]

hertogjan;
Is any of this optional/configurable?
(...)
Last time things were changed, train behavior around stations/signals had a pretty major impact. Most of my games with large established networks became unplayable, and though you can usually learn to work with it for new games, its a pain to have it dictated (not to mention the 'off' option is, and i assume still will be, unplayable due to trains stopping on hills).

Well, we've had the discussion about everything being optional. If you want everything to be optional, play the Patch. In OTTD new features are added as its general idea is to have an improved game based on TT. The trains behaviour is unrealistic and if a proper solution can be found, so be it - and if your network gets unplayable, improve it by having less hills, better junctions etc... And if your trains stop at hills, they are too long, too heavy and too weak. Don't blame physics.

[richk67]

TTDPatch vs OTTD arguments are not welcome in the MiniIN thread. Not relevant.

The issue of optional items is because of the introduction of the "Physics" patch which has changed the realistic acceleration behaviour. So yes, Physics can be blamed for the problems.

If it reduces playability, I do not care if it is more accurate and real - OTTD MiniIN is a game, and if having real world physics makes it a less playable game, then I will not hesitate in removing the patch.

[ddream]

For me new Physics patch doesn't reduce playability. It really annoyed me, when my 20 wagons loco climbed on 7 tile high mountain without slowing. This patch makes using multi headed engines really worth it. I really enjoy playing with this patch.