Nonsense rail physics?

[DrSuperGood]

The very first horse drawn trains have arrived to the server game. However I am struggling to get them to cope with inclines. A single 18 km/h horse will pull a single passenger truck at 18 km/h on the flat but fall to a painful <<1 km/h on a single incline (1 elevation difference, not a double incline). Trying with 2 such horses yields similar, but slightly better results. Only with 3 horses per passenger truck can it go up single elevation inclines at a reasonable speed while still dropping to 1 km/h towards the top of a single incline.

So I went ahead and tried the silly thing of 0 trucks and 1 horse. The results are that a horse pulling no load can achieve 18 km/h on the flats but only 7 km/h climbing an incline. The UI says it will drop as low as 4 km/h if multiple are chained but it seems pretty stable at 7 km/h. Now I am no expert on horses but I am pretty sure they can gallop up hills at a faster speed than 39% of their flat gallop speed, after all horses are often found in hilly areas.

Now I do not really know about rail physics but from a game play perspective this is kind of ludicrous. I understand that single slopes are meant to represent an incline of ~26.565 degrees which is kind of steep as far as transport goes. However that is the shallowest one can make an incline due to game limitations meaning more realistic inclines of 10 degrees or less over longer distances is mechanically not possible for the player.

I am not saying the physics itself is wrong but game play wise something is off.

[jamespetts]

This is quite a complex issue to solve, as it is necessary for all the various values to be fully consistent with one another in order for there to be any possibility of balance. There was discussion about this in relation to road vehicles some time ago, and not much in the way of resolution was reached, as no data was forthcoming. Indeed, without data, it is going to be very difficult to find any sort of resolution to this issue in a way that is meaningfully consistent with the rest of the game.

Do you or does anyone else know of any data on this subject that would allow the tractive effort and/or power of rail horses and/or the rolling resistance of horse drawn rail vehicles to be calibrated more accurately than they are at present?

[ACarlotti]

It seems that the main issue is that we can't directly build gentle slopes. We probably need some system for averaging these out over a longer period of time. (A similar problem arises in handling corners, although the solutions might not be exactly analgous.) To help account for the difference between the visual slope and the simulated slope, it would then be good to add the current gradient (averaged along its length?) alongside the speed in a convoys status window. However, I'm not totally sure how computing gentler gradients would work, and also whether it should be stored in the way (as a fractional adjustment to the way height), or computed on the fly for each convoy.

[jamespetts]

There is a system already that adds the effect of gradients together (working on the fly), although this is inherently difficult to calibrate accurately.

[ACarlotti]

Is that the case also on roads? Because at present, I seem to see road vehicles affect by gradients only as they are actually on the sloped road tile, whereas I was suggesting spreading the effect of (single) gradients over a number of tiles.

[jamespetts]

Is that the case also on roads? Because at present, I seem to see road vehicles affect by gradients only as they are actually on the sloped road tile, whereas I was suggesting spreading the effect of (single) gradients over a number of tiles.

I think that it works on roads - but I must confess that I cannot recall for sure now. I do not recall differentiating this by way type when coding the feature, however.

[DrSuperGood]

Possibly the way info window should show the interpolated gradient of the way tile? That way if the convoys have problems climbing a hill one can see what gradient they are struggling with. It need not even be in degrees, but could be in some internal unit as long as it is clear what is flat and extremely not flat.

[jamespetts]

I cannot see how this can be done, as the gradient is calculated on the fly based on the convoy's route and can thus vary depending on how the convoy has reached the tile.

[Ves]

Can't the logic from the rail cornering be used? I believe that calculates a radius based on multiple tiles. Or, perhaps that was what you where saying is happening on slopes too already, James?

[Kirill Stepnoff]

Now I do not really know about rail physics but from a game play perspective this is kind of ludicrous. I understand that single slopes are meant to represent an incline of ~26.565 degrees which is kind of steep as far as transport goes. However that is the shallowest one can make an incline due to game limitations meaning more realistic inclines of 10 degrees or less over longer distances is mechanically not possible for the player.

May be it would make sense to accept different Z-scale?
26-degree incline on 250 meter tile gives height of 125 meters per Z-level. And it means for pak-Britain-ex that twodecker-tram or tall ship cannot fit in 100+ meter clearance of "low" 1Z-height bridge - clearance more than enough for Nimitz-class carrier.

[jamespetts]

Can't the logic from the rail cornering be used? I believe that calculates a radius based on multiple tiles. Or, perhaps that was what you where saying is happening on slopes too already, James?

Corners are slightly different, in that what is calcualted is the turn radius by taking the angle between any two straight sections and the number of tiles between those two straight sections and working out what the maximum radius of curvature consistent with those angles would have to be in the Simutrans scale.

However, the basic idea of adding up tiles is indeed what is used for slopes - but this is done based on each individual convoy's route, not held statically in the tiles.

Kirill - what sort of calibration for the different Z-scale were you thinking of here, and how would this fit into all of the various sybsystems?

[Kirill Stepnoff]

Kirill - what sort of calibration for the different Z-scale were you thinking of here, and how would this fit into all of the various sybsystems?

I just was scared of 500 per mille gradients assumed by DrSuperGood However there are no traces of them in the code.

Gradients that present in the code are rather steep - up to 40‰ for 1Z slope and 80‰ for 2Z slope for railways, and slow and weak vehicles (read "horses") are more prone to reach maximum gradient penalty :-(

[jamespetts]

I just was scared of 500 per mille gradients assumed by DrSuperGood However there are no traces of them in the code.

Gradients that present in the code are rather steep - up to 40‰ for 1Z slope and 80‰ for 2Z slope for railways, and slow and weak vehicles (read "horses") are more prone to reach maximum gradient penalty :-(

Thank you for taking the trouble to look into the code for this. I have to say that I have had trouble calibrating gradients - anything less than I have specified seems to have no effect on more powerful trains, which then gives players no incentive to build level track, which is entirely at odds with reality, but these values seem to be too harsh on horse transport. I wonder whether we might fudge it a little by reducing the effective gradient slightly for bioligically powered vehicles until we can find a way of calibrating this more accurately, which improved calibration has so far proven elusive?

[ACarlotti]

As far as I can tell, the code for determining calculating resistance due to the gradient is in simvehicle.cc line 1963, vehicle_t::calc_drag_coefficient(). This only takes into account the slope of the current tile, although it seems to update to the new gradient on a hill over two steps, and then takes a few steps to return to the base level after climbing a hill. If curve_friction_factor is nonzero, the behaviour doesn't look sensible

It does not do any averaging over surrounding tiles, which I think is necessary to simulate gentle slopes, such as are needed on a railway. Such averaging could be done either as an attribute of the way, or within the vehicle or convoy. The former approach seems better, as this would involve less computation, and would be consistent between all vehicles using the way.

I think a reasonable approach would be to assign a 'microheight' to each edge between adjoining way tiles. If this tile is an intersection, then this microhieght is forced to be the displayed height, and if the tile has an obstacle (another way tile or building) within two levels above or below it, then this microheight is forced to be at most or at least the displayed height. Otherwise, for each slope tile, search up to 2N tiles along the way (where N is the maximum distance in one direction to average over), until reaching another slope, an intersection, or a obstacle above/below the tile (depending on whether we're averaging a downhill or uphill slope). The linearly interpolate the microheight between the two end points (which are either the middle of a slope tile, with a height of +/- half the height difference per level relative to the level section of way; or the edge of an intersection or tile with an obstacle, with a height equal to the displayed height). This gives a height at each edge, which can be used to assign a gradient to each direction on each way tile.
(Note that there are some inconsistencies in what I write here that should not be included in an implementation, but the basic idea is correct.)

I'm not sure what the best value for N would be - that's probably something to determine partly by experimentation. However, given that shallow gradients are (I believe) currently 4% (uphill in the physics engine; downhill is less for some reason), a value of N=4 would give a minimum gradient of about 0.5% (+/- some imprecision in my definition of N). Does that sound like a reasonable gradient for an early railway? Perhaps N should be different for rails and roads, although that would create inconsistencies for street-running trams.

This does mean that building sloped ways will come with some implicit earthworks (in open terrain, but not in busy terrain). This could be taken into account in the cost of building sloped ways, although it could equal be decided that the land should never have been perflectly flat up to the slope in the first place, and we are just countering Simutrans' lack of infinitesimal variations in height and gradient.

[jamespetts]

These are very interesting ideas - thank you for that. This might well be a worthwhile thing to implement. I will have to look into this when the current set of projects are completed.

As to the calibration of the gradient height, perhaps if gradients are re-done, it might be worthwhile having this as a simuconf.tab setting to allow easy recalibration in the future?

Edit: I have now added this suggestion to the list of projects. Also, as to the cost: I think that it would be clearer for the player not to vary the cost of building on an upward slope (especially as there will be some circumstances in which there are no implicit earthworks, so it will be very confusing to players to know what to pay), and we can sensibly assume for our purposes that the land being simulated is only approximately depicted by the displayed terrain in any event as you suggest in your final paragraph.

[Vladki]

Hello,

just a link to previous discussion about the slope/gradient issues:
https://forum.simutrans.com/index.php?topic=16815.0

Please look at it I have started some research, but did not find time to finish it (got distracted by other interesting things)...

My idea is that you cannot scale the Z-axis in the same way as XY-axes. That woud be full height slope being 24.23° (or 45%) and half height  12.40° (or 22%). Both are indeed very steep.

What I propose is to make it according to required clearance. Half height slope has not enough clearance under bridges, but full height does. What about 4 m for half height. If we make the calculation with 125 m/tile and 4 m for half height slope, we get some gentle 3% (or 6% for full height). Nice slope for road, but still quite steep for rail.

I'm not sure if penalising consecutive slopes is good idea. IMHO two consecutive half-height slopes should be easier to climb than one full-height slope.

Also the game physich works with "friction factor", which IIRC is the slope in %. Roads have a default friction factor =2 even on level road. I think this shloud be removed, because for all vehicles  their own rolling resistance can be specified, and there are already some sensible default for road/rail/... So this is just extra non-sense penalisation of road transport.   However a per way extra friction would be nice to differentiate between dirt road/gravel/cobblestone/asphalt/...

If you have any questions, just ask. I'm willing to dive into the code again and try to find a solution

[jamespetts]

The most important thing with any changes of this nature is to make sure that everything stays consistent with everything else and does not produce anomalies. There is no problem in principle with a different scale (for physics purposes) on the Z axis than on the X and Y axes, sine this will not cause anomalies elsewhere, and we should indeed make sure that whatever the gradient of a half height slope is presumed to be, it is always exactly half of whatever an equivalent full height slop is presumed to be, but, if I have understood A. Carlotti's proposed system correctly, this symmetry should not be broken (A. Carlotti - have I understood this correctly in this regard?).

In relation to the friction factor, surely there is no problem with the current arrangement, given that the gradient is (if I recall correctly) added to rather than multiplied by the base friction factor? (If it is multiplied, then perhaps changing it to be added would make the hill physics more consistent? Indeed, if this is multiplied, that might explain some of the difficulties. I have not looked into this recently, and do not recall the precise algorithm used.)

[ACarlotti]

In the diagrams below, "-" represents level ground, "+" represents an intersection (or equivalently a restrictive over/under bridge), and "u"/"U" and "d"/"D" represent uphill and downhill slopes from left to right, with capitals representing steeper slopes. I'm going to list the physics gradient of each tile assuming that 40 represents the gradient of a single change in level in the length of a single tile. I'm going to take N to be equal to 4.

+u+ = 0|40|0
+U+ = 0|80|0
+uu+ = 0|40|40|0
----u---- = 2|5|5|5|6|5|5|5|2
----U---- = 2|5|5|5|46|5|5|5|2
----uu---- = 2|5|5|5|23|23|5|5|5|2
+u---- = 0|23|5|5|5|2
----ud---- = 2|5|5|5|6|-6|-5|-5|-5|-2 (this is slightly different to the literal specification in my previous post)
+-u-+ = 0|13|14|13|0
+u-+ = 0|27|13|0


There are a couple of issues to take into consideration.
Firstly, how should the scaling change if the metres per tile changes? Either we can say that each level corresponds to a fixed height difference (which means that bridges have a consistent height), in which case the displayed gradients will be steeper with less metres per tile. In this case, we can in increase N to ensure that gradients in open terrain are reasonably gentle. However, this present problems in cities when the junctions could be too close together. Alternatively, we can scale the height difference in proportion to the metres per tile. However, this then means that bridge height vary depending on the metres per tile setting, which seems undesirable. As James suggests, this could be a pakset setting, in which we don't really have to pick one option or the other here.

Another issue is that this only partly mitigates the issue mentioned by Vladki, in which convoys struggle with hills adjacent to intersections. One way to improve this would be allow gradients to be spread out through intersections as well, but that will increase the complexity of the code.

[Vladki]

@ James: base friction is added to slope "friction", not multiplied

I think that slope height should be independent of meters_per_tile scale. Perhaps specified per pakset in simuconf.tab.
The question is if slope height is to be specified, which will lead to different slopes with different meters_per_tile, or if the gradient (in %) should be directly specified - leading to different "height" with different meters_per_tile. I would advocate for specifying the gradient directly. Then it would be easier to balance it somehow reasonably. Even if it would mean that the clearance under the bridge is non-realistic. It is not realistic for ships and planes anyway.

[jamespetts]

A. Carlotti - thank you very much for your helpful illustration of your suggestion here. I agree with Vladki that it would be better for this not to be dependent on meters per tile, as the meters per tile setting is intended to define the x and y axes, and this system assumes a different scaling for the z axis in any event.

What we might do is have a "meters_per_vertical_tile" setting in the pakset, which would then be easy for pakset maintainers and players alike to understand and make consistent with the existing systems.

[ACarlotti]

(Written in reply to Vladki:)
I would rather go with settings "height per level" and either "minimum physics gradient" or "gradient smoothing distance". We would then have that 2N (or maybe it should be N?) in my earlier post corresponds to "gradient smoothing distance" divided by "metres per tile", and "minimum physics gradient" equal to "height per level" divided by "gradient smoothing distance".

If height per level and gradient smoothing distance can both be set, then together they determine the gentlest gradient that you can build. On the other hand, the steepest possible gradient would be determined by "height per level" and "metres per tile". If trying to handle a really small "metres per tile" we run into issues with the city road building code not adapting to different settings of "metres per tile", which makes steep slopes unavoidable. But maybe undesirable stuff happens in that case already.

[ACarlotti]

The current code and settings for pak128.Britain use (I believe) a height per level of 5 metres, which can currently be smoothed over a maximum distance of 125 metres (equal to the metres per tile). My suggestion is to make 5 metres per level explicitly configurable, and to make the maximum smoothing distance equal to 1km by default.

[Vladki]

AFAIK there is no height per level setting now.

Currently the friction on first tile of half height slope is 23, full height 47.  If I understood the code correctly, it is the slope in per mille (I might have errorneously written % somewhere). That is not very steep for road, and the height difference for one tile (at 125 m) is 2.875 m for half height and 5.875 m for full height. Just barely enough for single decker bus. Not enough clearance for overhead wire or double decker. Yet road vehicles have problem to climb this hill. So there has to be a bug in the slope physics code or in calibrating the tractive effort (maybe it is using per cent instead of per mille somewhere). If we get this right, we won't need the "gradient smoothing" proposed by ACarlotti, and I would prefer to get rid also of the current system of making consecutive gradients steeper.

[jamespetts]

Vladki - that is interesting. I wonder whether there is a bug somewhere - but would a recalibration of this mean that moderately powerful trains would then find all gradients to be of no significance at all? It is important that any change to the physics code allows for even relatively modest grades to have a significant effect on the performance of railway locomotives, especially steam locomotives.

[ACarlotti]

There is certainly a bug in there, in that the behaviour of the current code is inconsistent, although it's hard to tell what the intended behaviour is. I don't think it's worth worrying about in detail though, as if convoys are failing to get up short hills now I think they would also fail in a corrected version, and I think the whole section of code should be modified.

Vladki, I think we really do need some system of smoothing to be able to balance the game. To give some relevant figures:

Steepest UK mainline rail gradient: Lickley Incline, 2.65% (over 3km, so a rise of about 80m)
Early railways: apparently limited to around 0.05%
Steepest road: around 30%
Steep roads: 10% counts as steep (on signage), I'm not sure if anything gentle is signed.
Modern railways: I don't think I'm aware of gradients less than around 0.5% (or something similar) being marked as such.

If we wanted to simulate this full range of possible slopes directly, then we would need almost 1000 different possible gradients. Now I think we can probably ignore some of the more extreme gradients, but we certainly need more than two different gradients to get any degree of realism.

With the numbers I suggested above, we would be able to simulate slopes ranging from 0.5% to 8%. This does still chop off stuff at each end of the range, but it might be enough to work with.

[Vladki]

I have managed to buy a book about the Budweis Linz railway (horses 1820's). I'll look for an translate relevant info (slope gradients, curve radii, how many horses pulled how much load and how fast.

[Kirill Stepnoff]

----ud---- = 2|5|5|5|6|-6|-5|-5|-5|-2 (this is slightly different to the literal specification in my previous post)

I think that something like
2|6|6|6|2|-2|-6|-6|-6|-2
would be more realistic for this case - "vertical curves" tend to be S-curve and avoid rapid gradient changes.

[ACarlotti]

That's true for railways and high speed roads, but not as true for low speed roads. However, the reasons for this (comfort and avoiding derailment/skidding, due high vertical acceleration) are not simulated in Simutrans. The gradients I listed were calculated according to a single consistent rule, and I think deliberately trying to implement vertical curves would be unnecessarily complicated (although certainly doable). Most of the gradients I calculated did happen to have curved ends, but that was only a side effect of terminating the slope in the middle of tiles, and not a deliberate design decision.

[jamespetts]

Thank you all for your thoughts on this. ACarlotti - can you elaborate on the inconsistency that you have found in the behaviour that leads you to believe that there is a bug in the code?

[ACarlotti]

Some of the main issues in the results of the current code:

• The force due to downhill slopes is less than the force due to uphill slopes. They should (from a physics perspective) be equal.
• The current code for smoothing gradients gives inconsistent results to the total force (averaged over distance) for some combinations of different slope values, due to varying use of min and max without accounting for what the previous slope was.
• The addition of curve_friction_factor looks problematic, but might be ok as long as it's never too large.

I could fix these issues separately, but I think it would be more efficient to leave that code alone until we've decided whether or not implement gradient smoothing properly.

[jamespetts]

Some of the main issues in the results of the current code:

• The force due to downhill slopes is less than the force due to uphill slopes. They should (from a physics perspective) be equal.
• The current code for smoothing gradients gives inconsistent results to the total force (averaged over distance) for some combinations of different slope values, due to varying use of min and max without accounting for what the previous slope was.
• The addition of curve_friction_factor looks problematic, but might be ok as long as it's never too large.

I could fix these issues separately, but I think it would be more efficient to leave that code alone until we've decided whether or not implement gradient smoothing properly.

Ahh, yes, that would be sensible indeed. I am in favour of gradient smoothing as indicated, but will not be likely to have time to implement this myself until after the current round of vehicle management features are completed.

[Vladki]

This is going to be a longer post about roads and early railways in Austro-Hungarian Empire

First I will deal with roads - so called imperial roads (or state roads) were built 1740–1850 accordig to "french style" most probably it was the method of
https://www.britannica.com/biography/Pierre-Marie-Jerome-Tresaguet
https://amedia.britannica.com/700x450/45/23945-004-EA668418.jpg
Such roads had very similar surface to later macadam roads, the difference was in lower layers (macadam was cheaper).
So for the sake of rolling resistance, we can consider them to be the same as macadam. They were often built in straight line, so they also had to climb quite significant hills. The maximum gradient was 4.16 % (imperial roads exactly 3 inches/fathom, austrian inches were a bit larger than english, but 1 fathom is 6*12 inches in both systems), 4.70 % (state roads), 5.50 % (land roads) and 6.25 % (regional roads). The state norms defined also the width and other parameters, but that is not important now. There were often pubs or post stations at the bottom of steeper gradients, where it was possible to hire extra horse(s) to help. Maximum permitted weight of loaded waggon was 3360 kg (i think including the waggon itself). No more than 6 horses were allowed to pull single waggon. I have checked a piece of old (land) road that is still in use and it has 5% gradient (50m/1km). https://en.mapy.cz/s/2rdle  I think we can safely assume that 6 horses can pull 3.36 tons on 5-6% gradient even if very slowly (3 km/h ?)

To get an idea about speed of travel: in 1826, fast post coach with passengers travelling cca 310 km from Prague to Vienna took cca 34 hours, including stops for meals. So the overall average speed was almost 9 km/h (without stops it could be even 10 km/h). There is no information how often they changed horses. The road exists till today - just with modern surface, but the trajectory is the same as 200 years ago. https://en.mapy.cz/s/2rdbs

To be continued - about horse drawn railway Budweis - Linz

[jamespetts]

That is very interesting - thank you.

[Vladki]

So, about the horse railway Budweis (České Budějovice) - Linz. I was built between 1827–1836. The primary purpose was to carry salt from austrian salt mines (that's where Salzburg got its name) to Bohemia. Water channel was considered many times to connect Donau and Vlatava, but in early 19th century a railway was recommended. The chief engineer F.A. Gerstner visited England before the construction, so he knew about steam operated stockton-darlington railway. He decided that stationary engines pulling cars on cables are not the way to go. Although this railways was horse drawn, he built it with steam operation in mind. The northern part is built with max gradient 1.0 % and min curve radius 189 m (100 austrian fathoms). It is constanly rising up from the Vltava walley to the watershed on Bohemian-Austrian border. Unfortunately, the construction in this manner was too expensive, and F.A.Gerstner was fired. The southern part was built by M. Schonerer more like narrow-gauge railway. Cutting costs per mile to half in comparison with the northern part, but minimum radius was only 38 m. It was also going up 2.17% and down 1.43%, closely copying the terrain. When the track was rebuilt for steam operation in 1870's, the norther part was used almost "as is", only with some curves rebuilt to radius 250/284 m. But  the southern part was completely abandoned, and new track was built in different trajectory (max grade 1.3 %, min radius 284 m).

I don't know where Acarlotti got his information about early railways having only 0.05% gradients, but as you can see horse railways were able to overcome some decent hills. Of course at the steepest part of this railway, trains had to be split and extra horses employed. More on that later.

This is the design of rails: https://cs.wikipedia.org/wiki/Kon%C4%9Bsp%C5%99e%C5%BEn%C3%A1_dr%C3%A1ha_%C4%8Cesk%C3%A9_Bud%C4%9Bjovice_%E2%80%93_Linec#/media/File:Konka_koleje.jpg

to be continued...

[ACarlotti]

I don't know where Acarlotti got his information about early railways having only 0.05% gradients, but as you can see horse railways were able to overcome some decent hills. Of course at the steepest part of this railway, trains had to be split and extra horses employed. More on that later.

From a terrible source -  https://en.wikipedia.org/wiki/Grade_(slope). So I think we can probably disregard that figure. In any case, that seems to be referring to early steam locomotives, rather than horses, and it also doesn't imply that they were incapable of handling steeper gradients.

I think 0.5% would be a sufficiently low minimum gradient (and we could make that a bit steeper if desired). What about the steep end? Do we want gradients above 8%?

[jamespetts]

That is not an entirely easy topic. It is often said that the steepest railway gradient in the UK is the Lickey Incline at 1 in 37, but in fact the line between City Thameslink and Blackfriars in central London is 1 in 27. 0.05% is 1 in 200, which, for a railway, is quite a gentle incline, and almost negligible for a road. Perhaps the shallower incline might be 1% (1 in 100) and the steeper incline perhaps 5% (1 in 20), making it largely impractical for a railway, and challenging for road vehicles. Of course, these should be really set in simuconf.tab if the code is to be modified, so these can easily be calibrated by in-game testing.

[Vladki]

I think, that for now it would be best to make the gradient for both half and full slope configurable, and also to remove the code that makes consecutive gradients steeper. This would allow for more experimenting and balancing.

[jamespetts]

I think, that for now it would be best to make the gradient for both half and full slope configurable, and also to remove the code that makes consecutive gradients steeper. This would allow for more experimenting and balancing.

Would it be not better to implement A. Carlotti's system for gradient steepness if one were changing this code? Of course, if one were making it configurable, one might simply have an option to turn on and off the Carlotti Gradient System.

Incidentally, as to gradient steepness: perhaps the maximum steepness of a gradient might be 1 in 30 or so, which would reflect the possibility of inclines such as that at Blackfrairs (albeit these are only really usable with electric trains; this incline was built long after the steam age, in the 1980s, I believe).

[Vladki]

Just a few links about the most extreme stuff

https://en.wikipedia.org/wiki/List_of_steepest_gradients_on_adhesion_railways
https://en.wikipedia.org/wiki/Baldwin_Street

ACarlotti's system of gradients looks nice. But I think we should first focus on getting simple gradients right (together with the rest of rollling and air friction physics). When I was studing the code I got lost a bit maybe due to the fact that the calcualtions are not always in SI units - mixing tons with kg, km/h with m/s, etc, etc...

[jamespetts]

Interesting information! I am not sure that there is much to be gained by improving gradients in two distinct stages rather than tackling it all at once, however.

[Vladki]

My idea is first to get right the physics with simple model, and then we can add the smoothing.

I was thinking how steep the gradients should be. Let's take the budweis-linz railway as an example, as if I'd like to make a model of this railway in simutrans.
The lowest point is Donau in Linz: 246 m above sea level. Vltava in Budweis is 379 m. Highest point at Kerschbaum is 709 m. Total distance is 128.8 km. In simutrans that is 1030 tiles (at 125 m/tile). Kerschbaum is exactly in the middle. There were 5 passing loops on the line - approx 20-22 km apart.

The question is how many height steps should the line pass? If we consider that full height slope is necessary for double-decker to pass under, it will be some 8 m. (4 m half height). That would be 82 half-height steps only for the nothern part, and 115 on the southern. That is too much for simutrans. Should we take the smae scale for height as for distance, we get 25 m for half-height (five levels make a cube). That would be 13 steps for northern half and 18 steps for southern.  A 1 % slope would be 1 half-height step every 20 tiles. That looks much better for long distance, but makes non-sense for single tile slopes...   

Nah, I can't come up with something tha would work equally well for both long distance (>10 km), and short distance - i.e. bridge over road/river.

[ACarlotti]

Under my proposed system, setting the smothing distance equal to (or less than) the tile distance would effectively disable it.

James: In terms of actually implementing this, I would be hesitant to deal with the configuration settings, but could probably manage the rest of the changes fine. So if you were to make a branch and add a gradient smoothing distance and a height per level setting to the configuration (and tell me how to access that setting), then that would be helpful for me.

[jamespetts]

Under my proposed system, setting the smothing distance equal to (or less than) the tile distance would effectively disable it.

James: In terms of actually implementing this, I would be hesitant to deal with the configuration settings, but could probably manage the rest of the changes fine. So if you were to make a branch and add a gradient smoothing distance and a height per level setting to the configuration (and tell me how to access that setting), then that would be helpful for me.

Certainly - I will branch from master rather than vehicle-management, as that is a complex project that will take many months to complete (and I have not been working on it for the last few weeks on account of being preoccupied with other things). I will let you know when this is done.

Edit: I have now added the relevant settings on the gradient_smoothing branch. I hope that this is helpful. Do feel free to change the names, units or default values if you think appropriate; it should be fairly straightforward to work out how to do so by looking at the commits.

[Vladki]

Further notes about horse power:

The original privilege to build the horse railway stated that a single horse should be able to pull 10 times more load on railway than on road. The official test proved that it can pull 30 times more. There's a picture of 2 horses pulling a road waggon loaded with 12 barrels (of salt), and a single horse pulling 3 rail waggons with 40 barrels each. So really 10 times more. Another picture shows 2 horses pulling 5 waggons. Other pictures show passenger transport with one coach pulled by 2 or even 3 horses (that was probably on the steepest part of track). Another report says about 2 horses pulling 2 waggons form Budweis to Kerschbaum, but then it was split in two for the descent to Linz. In general, all trains on the southern (steeper) part were split in two, and had extra horse for the steepest (>2%) part. More pictures here: https://de.wikipedia.org/wiki/Pferdeeisenbahn_Budweis%E2%80%93Linz%E2%80%93Gmunden.

One of the very first rides on unfinished railway was documented: 2 horses pulled 7 waggons with 14 tons of load "easily" at 30 km/day. Downhill towards Budweis, probably without changing horses, so they had to have a rest.

Passenger trains took 14 hours to travel the whole line, with 1-hour lunch break in the middle. (avg speed 10 km/h).
EDIT: German wikipedia says average speed 10 - 12 km/h erreicht, maximum downhill speed 15 km/h.

Cargo trains took 3 days. On the steepest part (2.17 %) they needed 2 horses to pull 1 waggon with 2.52 t of load.
Average over the whole line was that one horse on railway pulled 3.92 tons while one horse on road only 0.56 ton.

I could not find how fast were the cargo trains. But the timetable was that at 5 AM a passenger train departed from Budweis. Only after that they could load, assemble and dispatch a cargo train. It arrived at 10 AM to next station Holkov, changed horses and continued further on. Horses were fed, had a rest, and at 2 PM, another cargo train back to Budweis was dispatched. It had to arrive and unload before 7 PM when passenger train from Linz arrived. So I think the train must have gone the 20 km to next station in at most 4-5 hours, i.e. 5-4 km/h (EDIT: german wikipedia says 4 km/h average speed for cargo trains, and 40 km/day - no traffic during night)

Amount of horses for each train was dependent on the gradient of the section to the next station.
They needed 2x more horses for the southern half of line than for the northern.
In 1846 they experimented with oxen but not sucessfully.
In 1854 they experimented with steam engine on the wooden rails, but it was too heavy and damaged the track.

Another old report says about one horse pulling 100 barrels of salt downhill towards Budweis.
Some bridges were wooden, as there was a report of sabotage by burning a bridge. Other bridges were stone viaducts and survived today.

Fix about loops - there were stations every 20-22km where horses were changed (both cargo and passenger trains), but later some extra passing loops were added, probably every 7-8 km.

1868-1872 track was rebuilt for steam operation
And that's all I found in the book and other sources about this line

[jamespetts]

Thank you - that is very interesting.

[ACarlotti]

Nah, I can't come up with something tha would work equally well for both long distance (>10 km), and short distance - i.e. bridge over road/river.

Yeah, that is a difficulty. I think doing this properly might require allowing a larger range of possible tile heights and changes to the map generation system. But that's getting somewhat off the original topic, and away from my current experience (I haven't tried generating or playing very large maps yet).

[jamespetts]

I suspect that changing the map generation system would be much more difficult than the originally proposed idea; as for increasing the number of heights, this would require such an enormous amount of new graphics that it is probably not feasible at all.

[ACarlotti]

I think you misunderstood me. I'm not suggesting increasing the number of different tile slopes, just the range of possible tile heights. At the moment there seems to be some sort of limit to around 30-40 different altitudes, which would correspond to 150m-200m, and at these heights tile selection seems to be a bit buggy. If this altitude limit could be increased then we could have a higher range of possible altitudes - e.g. 256 would corrsepond to almost 1.3km, which encompasses almost the entire variation of heights in the UK.

My reference to the map generation system was based upon a couple of observations: firstly that such a large range of altitudes would probably require some modifications to the generation code just to give usable landscapes; and secondly, that on that sort of scale you might want roughness to vary across the map - e.g. there is a big difference in roughness between Scotland and southeast England.

In any case, this is not relevant to game balance, but could be something nice to have in the (distant) future.

[jamespetts]

Ahh, yes, I see: apologies for misunderstanding. I can see the merit in this: while it would still be quite a lot of work, it would at least not be an unmanageable amount.

[ACarlotti]

I've been investigating this a little (and have tested some interim code changes that fix the bugs but don't yet implement gradient smoothing) and am wondering if the problem lies in a poor understanding of the physics of horses. I probably need to think about the physics a bit more, but in essence my concern is that hooves don't work in the same way as wheels, and I am suspicious that the current physics engine may not allow for this.

So, two questions:
1. Have there been any issues observed in convoys not powered by horses?
2. Does it seem plausible that we have got the physics of horses wrong in some way? (An alternative explanation would be if the figures used were derived from how much a horse can pull, ignoring that it is also moving itself.)

[DrSuperGood]

Mechanically I imagine horses to work like normal road vehicles except with very good relative tractive force and breaking power for their power compared with a train.

Ultimately when climbing a hill tractive force and power is all that matters. If tractive force is too little then the horse would slip a lot so not be able to apply all its power. If the tractive force was minimal, eg horse on ice covered hill, then the weight of the coach will pull the horse backwards as the horse cannot apply any power. If the tractive force is excessive (spider man like hooves) then the up hill speed of the coach is entirely limited by mgh and frictional losses.

Assuming a coach weighs 1.2t with 11 passengers of 70kg each that is 1.97t of coach. This is the sort of coach one has in the late 1700s in Pak128 Britain. With a tile being 125m, a half height tile is an increase of elevation of 62.5m. Gravity is ~9.8m/s/s. Hence the total kinetic power converted into gravitational potential power by the full coach climbing up a single slope tile is {1970 * 9.8 * 62.5} = 1,206,625J of energy. Assuming a horse outputs 1 horse power (a reasonable although incorrect assumption) that is 745.7W. As such it would take a single horse {1,206,625 / 745.7} = 1618s = ~27minutes to climb a single height ramp. This results in a top speed of 0.077m/s or 0.278km/h, which is painfully slow. Now obviously it would take the horse longer in reality due to rolling resistance and other losses.

However no single horse pulls a coach. I imagine 4 horses being more reasonable so one can assume the time of ~7 minutes and 1.112km/h. Still very slow and sub 1km/h. If one averages out the half height slope over 8 tiles, 1km, then one gets a time of ~7 minutes at 8.899km/h, much more reasonable but still slow.

However a horse is not 1 horse power. A horse power is the amount of sustained power one can harvest from a horse over a 4 hour working period without straining the horse, eg using it to drive a mill every day. A horse is capable of considerably more than 1 horse power for short periods. Additionally larger or stronger horses which have less stamina might be capable of more power over short periods. As such for this example lets say the 4 horses apply 3 horse power each for the duration of a single height slop averaged over 8 tiles. The result is the climb takes a time of ~135 seconds or 2.25 minutes achieving a speed of 26.698km/h which well beyond the maximum speed a horse can go at so they would be having to use considerably less than 3 horse power.

So why not give the horse a value of 2 horse power or 1491.4W? Well the problem is that Simutrans Extended is simulating the horse itself as a load and not just the spare power from a horse, which is what a horse power is defined as. As such in real life a horse producing 1 horse power of power is actually producing a lot more due to having to move itself around in the process. Additionally a horse does not have wheels, so although mass acceleration formula do apply, standard rolling resistance does not. This is a big thing to consider as a horse weighs a good part of a ton itself and so requires large amounts of mgh energy to climb a half tile slope.

So what is the problem with horses and hills? Simutrans Extended does not support "stamina" and hence it cannot accurately simulate organic convoys climbing hills. Power output of horses is currently averaged where as in real life they would be producing more when climbing hills and less when on flats. For horses to properly be simulated on will have to simulate energy consumption and variable power output.

[Vladki]

Acarlotii: the same problems were observed with diesel trucks. They were unable to climb a hill if they had to stop under it (bus stop or congestion).

[jamespetts]

Thank you for your thoughts on this (and my apologies for the delay in replying: I have been very busy in the last week).

I do not know a great deal about the physics of horses in particular, although I did find a source once which gave some information on what loads that a horse could pull (although I do not think that it dealt with gradients). The physics code was written by someone other than me, so I have not had much involvement with the details.

It is certainly possible that the physics of horses would need to be treated differently (I know that the physics of steam locomotives are treated differently, as steam locomotives are constant force machines whereas most other types of locomotion are constant power machines), but I am afraid that I do not know the details.

I have not noticed issues with motive power other than horses, although I should be very grateful for any feedback from anyone else as to whether they have (even if they have not).

Edit: I had not spotted that Dr. Supergood had responded when I posted the above, as I had not noticed that the thread had moved into a separate page.

Dr. Supergood's post seems to give a good analysis of the nature of the problem: (1) that we do not simulate stamina (this would involve quite a lot of additional complexity I imagine); and (2) that a horsepower does not take into account the amount of power that a horse needs to move itself. I wonder whether we could try to find the necessary data to fix the second issue (which should, with the necessary information, be straightforward to fix) and see the extent to which, having done so, the first problem remains significant?

Does anyone have any data such as to enable us to get a reasonably accurate idea of the extent of the adjustment necessary to rectify the self-haulage issue?

[ACarlotti]

I too had missed most of DrSuperGood's post - I read it before it was edited, at which point it was (I think) much shorter.

DrSuperGood: I think there is an error in your calculation. You assume that one (half height) tile is 62.5m, but for the physics engine I believe that is incorrect. As we discussed earlier in the thread, the current code uses a gradient of 4% for a half-height (non-road) uphill slope, and 8% for a full height slope, which corresponds to an increase in height over 125m of 5m. This would suggest around 2.5 minutes for a horse to climb a hill, but this is less than is observed without the temporary reduction in resistance for road vehicles.

The stamina issue could perhaps be simulated by having some reserve of 'power' which can be drawn upon for short periods of time (so that for higher than nominal power output can be attained for a period of time). This would also be relevant for steam locomotives, which can increase their power output for a short period by running down the boiler pressure. In both cases, this would help to deal with the effect of hills.

A horse will have some sort of resistance to motion; I do not know if this force can be approximated as a rolling resistance (i.e. independent of non-zero speed, and proportional to weight).

I think the primary thing to do now is to check that the current values allow for the horse pulling its own weight as well as that of any wagons, although if we can find out any more about the physics, that would be helpful.


As for the current code, I have been gradually working on understanding it. The algorithmic parts shouldn't be too hard for me to check; so far I've been msotly working out how the class hierarchy and inheritance work. It seems to be that there was an intention (back in 2009) of making some further changes to the division of code between classes; as it is, I think it is unnecessarily complicated, so I might see if it is possible to simplify the structure without hindering functionality or efficiency. If you know of any information regarding the class hierarchy (of convoy_t and its descendents) beyond the code and its comments, paricularly regarding the long-term intent, then that could be helpful.

[DrSuperGood]

DrSuperGood: I think there is an error in your calculation. You assume that one (half height) tile is 62.5m, but for the physics engine I believe that is incorrect. As we discussed earlier in the thread, the current code uses a gradient of 4% for a half-height (non-road) uphill slope, and 8% for a full height slope, which corresponds to an increase in height over 125m of 5m. This would suggest around 2.5 minutes for a horse to climb a hill, but this is less than is observed without the temporary reduction in resistance for road vehicles.

This is not made clear in game. In any case that is why I used a value of averaging 1 half height over 1km as I was aware there was some averaging going on, just not to what extent.

Stamina would be a mechanic that goes well with implementing fuel economy. A simple powered vehicle could be given 2 power values and an energy capacity value.

• The sustained power output, this is how fast stamina energy is recharged.
  
• Maximum power output, this is the maximum amount of power that can be drawn from stamina energy, trying to maintain speed.
  
• Stamina energy, this is the amount of energy stored by a convoy for deployment in short bursts.
  Fuel energy is then the amount of sustained power used to recharge stamina. There would be a fuel multiplier, efficiency, and the cost per kwh of fuel is standardised based on fuel type and could be made to vary with respect to time.
  
  Of course stamina model in real life is a lot more complex. However this might just be enough to have powerful horses for hill climbing in a realistic way.
  

[jamespetts]

Thank you both for your thoughts: this is most useful. The idea of a stamina mechanic is most interesting, although quite how it might be coded is another matter, as I struggle to understand the physics code myself as it is. If A. Carlotti is able to code this, that would be extremely helpful.

I should note that Dr. Supergood's suggestions for using efficiency, fuel burned per unit of time and cost per kwh of fuel (or rather, cost per unit of weight and kwh per unit of weight of fuel) are consistent with what I hope to do to implement more realistic running costs, and data to support these values has existed for some years in the physics balancing spreadsheet for steam railway locomotives (which so far is used only to produce power values from data about the locomotive, but is also intended to be able to be used to specify running cost and range).