News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

cornering speeds of trains

Started by Vladki, April 30, 2017, 11:13:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

I have noticed that the trains go significantly slower over corners than previously. I see that there are two commits form Apr 19th that probably changed something.

The effect is detrimental if the train makes > 90 degree turn, perhaps due to poor path chosen by choose signal, like in this screenshot and save: http://server.exp.simutrans.com/debug-saves/bad-path-chosen.sve

In this case the train goes at 1 km/h throught the sharp bends. But the choose signal could have sent the train over the free track on south, keeping it much faster. Even putting an end of choose sign on northern track  did not help.

So this is a wishlist - make the choose algorithm a bit smarter and avoid >90 degree turns.
Also searching the alternative path by first turning to the side where signals are would help in improving throughput, as trains would not tend to occupy platforms used by trains from opposite direction.

I remember that there was some discussion about caluclating the corner speeds quite some time ago, but I'm not sure how do you approximate the corner radius now. I made a sketch of how I think it should be done at that time, but I could not find it on the forum, so here it is again:

The number on axes should be divided by 2 and present tile borders. Thick black is the track as shown in simutrans, green is my approach to approximation, blue is an alternative for 90 degree bends, but that makes imho too sharp corners.

So in the example of self correcting corners, manhattan distance is 4 tiles (distance between parallel tracks is 2 tiles), and radius is 3.4 tiles. = 2 x (1+sin(45)) = 2x1.7... For 90 degree bend, manhattan distance is 5 tiles, and blue radius is 2.5 tiles (half of it), green radius is about 4.25 = again 2.5 x (1+sin(45)) = 2.5 x 1.7.

So you can make it ultra simple - it does not matter, whether the corner is self correcting or not, just take the manhattan distance and multiply by 0.85 = (0.5*1.7)



jamespetts

The previous code was in error as it mis-estimated corner speeds, effectively assuming that most corners had twice the radius that they actually should have. I found that bug when I was fixing another one and fixed that, too.

The corner speed is actually calculated very precisely based on real life data: I have not the time to find the thread at present either, but it is around somewhere, and is quite detailed: the system is also documented in the code. I think that the system as it stands is indeed correct, and a great deal of work fairly recently went into designing and perfecting it.

The issue with choose signals is actually a very difficult one to solve: what if the only route beyond a choose signal involves this sort of corner? What if there are two routes with a 90 degree corner? (Actually, this looks like more than a 90 degree corner). What this would actually require is a fantastically complex optimising algorithm: no simple logic could make this work sensibly in all situations.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on April 30, 2017, 11:22:03 PM
The issue with choose signals is actually a very difficult one to solve: what if the only route beyond a choose signal involves this sort of corner? What if there are two routes with a 90 degree corner? (Actually, this looks like more than a 90 degree corner). What this would actually require is a fantastically complex optimising algorithm: no simple logic could make this work sensibly in all situations.
The screenshot is of two 135 degree corners.

I agree that the smart pathfinding would be complicated. In that case one should be able to help it by end-of-choose signals, but in this case it does not seem to work.

jamespetts

Is there, in that case, a bug with end of choose signals? If so, I should be grateful if you could start a new thread to report it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

killwater

Anyway 1km/h on a tight turn is definitely not correct.  It is just putting bigger stations to standstill and for longer trains must be a real nightmare. Could a minimum of lets say 5km/h be easily implemented?

AP

I doubt its a can of worms anyone wants to open, but it could lead back to the *really* old discussion point about turnouts. At present they are triangular (any route into a tile leads to any route out) but they could *not* be so.

jamespetts

Quote from: AP on May 01, 2017, 01:19:54 PM
I doubt its a can of worms anyone wants to open, but it could lead back to the *really* old discussion point about turnouts. At present they are triangular (any route into a tile leads to any route out) but they could *not* be so.

This would require a gargantuan amount of work. It might be worthwhile one day in the distant future, but there are higher priority projects in the meantime.

Killwater - the speed is based on a real life formula. Do you have data suggesting that this interpretation is wrong?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on May 01, 2017, 01:34:49 PM
Killwater - the speed is based on a real life formula. Do you have data suggesting that this interpretation is wrong?

I have checked the formulas, according to simuconf, and code (simvehicle.cc, method vehicle_t::calc_speed_limit). At first look it seems to be implemented according to the referred doc:
https://books.google.co.uk/books?id=NbYqQSQcE2MC&pg=PA30&lpg=PA30&dq=curve+radius+speed+limit+formula+rail&source=bl&ots=mbfC3lCnX4&sig=qClyuNSarnvL-zgOj4HlTVgYOr8&hl=en&sa=X&ei=sBGwVOSGHMyBU4mHgNAC&ved=0CCYQ6AEwATgK#v=onepage&q=curve%20radius%20speed%20limit%20formula%20rail&f=false

speed = sqrt ( radius * 87 / corner_force_divider_track ).

simuconf.tab says: corner_force_divider_track=10
comment in simvehicle.cc says: A 180 degree curve can be made in a minimum of 4 tiles and will have a minimum radius of half the meters_per_tile value (125 m)
(this is indeed very sharp curve for a train, but lets ignore that for now).

so we have sqrt ( 62.5 * 87 /10 ) = 23.3 km/h, and yet the trains slow down to 1 km/h ... so there is a bug somewhere in the code - probably in calculating the radius.

Further on: A 135 degree curve can be made in a minimum of 4 tiles and will have a minimum radius of 2/3rds the meters_per_tile value
this corner should be taken at speed 27 km/h and also slows the vehicles down to 1 km/h (as in the above screenshot and save).

I have checked the code and also the recent changes. I think the problem lies in counting  steps_to_180, steps_to_135, steps_to_90 and steps_to_45. I'm not really sure, what is counted and what not.
James, could you tell me for the two pictures above - how many steps_to_90 and steps_to_45 are (should be) on those?

------------
Just a note to the formula - I have done my physics homework and ended up with a little bit different formula:
speed in m/s = sqrt (a * radius), where a is the acceptable centrifugal acceleration. (a = G/ corner_force_divider_track)
Modifying it further:
speed in km/h = sqrt (a * radius) * 3.6 = sqrt (a* radius * 13) = sqrt ( G* radius * 13/ corner_force_divider_track) = sqrt (radius * 127/corner_force_divider_track)
So - a bit different constant - 127 instead of 87. On the other hand, Czech railway norm says that maximum for a is 0.65 m/s^2, which gives corner_force_divider_track=15. Thus the results are almost the same anyway.

Superelevation can usually compensate up to 1 m/s^2 = G*h/s (h = superelevation - max 150mm, s = track gauge 1435-1470 (wider in corners).
If superelevation is ever accounted for, it could be so, that if the corner is without junctions, then it may be considered to be superelevated; otherwise it must be flat.


jamespetts

I am afraid that I cannot see the pictures to which you refer: are they on Imagur, by any chance? I can never see images on Imagur for some reason.

I am currently staying away from home for work, so cannot look into the code at present. May I ask why you think that the formula that you set out is preferable to the one in the source to which I refer; have you a source?

As to superelevation, it would add some considerable extra complexity, and I am not quite sure how that would best be handled. I think that this was discussed some time ago.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on May 01, 2017, 10:23:09 PM
I am afraid that I cannot see the pictures to which you refer: are they on Imagur, by any chance? I can never see images on Imagur for some reason.
They are in the first post - uploaded directly to the forum.

Quote
I am currently staying away from home for work, so cannot look into the code at present. May I ask why you think that the formula that you set out is preferable to the one in the source to which I refer; have you a source?
I have most sources in Czech, but have a look here: https://en.wikipedia.org/wiki/Centripetal_force
Centripetal force F = m*a = m*v^2/r   (r = radius, m = mass, v = speed, a = centripetal acceleration, g = 9.81 m/s^2)
Centriperal and centrifugal force (acceleration) are equal. So centrifugal acceleration is simply a = v^2/r. So v=sqrt (r*a). If you want speed in km/h = sqrt (r*a)*3.6 = sqrt (r*a*13)
In simutrans you specify maximum a=g/corner_force_divider. So the formula is speed[km/h]=sqrt (r*13*g/CFD) = sqrt(radius*127/CFD)
Czech railways norm says that maximum acceptable (comfortable) centrifugal acceleration is 0.65 m/s^2 (CFD=15)
All of the above applies to flat curve (no superelevation).

Here is a table of allowed speeds on different curves: http://martin_vondracek.sweb.cz/CD_koridory.html, I'll put here the numbers for flat curves and a=0.65 m/s^2
R [m]    v [km/h]
120         32
180         39
260         47
280         49
300         50
350         54
400         58
500         65
650         74
800         82
1000         92
1200        101
1400        109
1600        116

Table for typical models of railway switches
radius    speed
[m]          [km/h] 
----------------------------------------------------------------------------------------
190            40   
300            50   
500            65   
760            80   
1200           100


Quote
As to superelevation, it would add some considerable extra complexity, and I am not quite sure how that would best be handled. I think that this was discussed some time ago.
I understand that it would make things more complex. I just thought that the presence (or absence) of junction in the curve, might be easy enough to detect, in which case a different (pre-defined) corner_force_divider_track would be used. So it would not be computationally expensive.

jamespetts

If junctions were treated more leniently with speed than other corners, would players not just make all their corners junctions?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on May 02, 2017, 12:01:04 AM
If junctions were treated more leniently with speed than other corners, would players not just make all their corners junctions?
I meant quite the opposite. Superelevation is NOT possible on junctions. So a corner with junction will be treated like it is now, but corner _without_ junction, would have lower corner_force_divider to emulate superelevation.

jamespetts

Something more detailed than that would be needed, as superelevation is a modern invention.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Where do you lack the detail? In the calculation? Or do you want to limit the game effect of superelevation by timeline?

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

It would have to depend on the type of track I think, as to whether superelevation would be permissible.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

#15
I think that for very old (and thus slow) waytypes, superelevation would not add that much speed anyway.

I have just checked for fun. The sharp 180 degree U-turn, with radius of half tile (62.5 m should be passable at 23 km/h. (or 36 km/h if superelevated). Now the question is if tracks that historically were not superelevated, were fast enough to even gain any advantage from superelevation.

Anyway back to the topic. The originally reported problem is that trains pass U-turn at 1 km/h instead of 23 km/h

Ves

Quote
The issue with choose signals is actually a very difficult one to solve: what if the only route beyond a choose signal involves this sort of corner? What if there are two routes with a 90 degree corner? (Actually, this looks like more than a 90 degree corner). What this would actually require is a fantastically complex optimising algorithm: no simple logic could make this work sensibly in all situations.
What if, if the  choose signal cannot find any route without 90 degree bend, either it runs the search again now with allowed +90 degrees, or the choose functionality gets disabled and it is treated as a normal signal. If such an occasion occurs, it is anyway the players fault for laying the track work poorly.

Regarding the super elevated track, a parameter in the datfile that tells wether the track is super elevated?
Then let the super elevated track run a different corner speed calculation, taking into account for the super elevation.

killwater

@James
I do believe it is not physically possible to run a train at 1km/h by hand. In such a case the 180 deg turns should be prohibited.
Anyway the minimal allowed radius for tracks in Poland is 180m on station sidings and 200m on running tracks in mountains/400m on plains. I think that 125m/tile should be good scale enough to justify enforcing similar requirements.

@Vladki
a is dependent on radii and speed though:

For passenger trains:
V<160 a=0,8
V>160 a=0,6
But if:
200 m < R < 250 m a=0,5
R<200m a=0,45

For goods trains it is depended on the usage as well and varies between 0,2-0,6.
Could the radius in your calculation be 125m though? We have two tiles for 180deg U-turn so assuming that tracks are on outer edges of a tile rather than in the middle it would give us a radius of almost 125m.

Vladki

Quote from: killwater on May 02, 2017, 06:20:39 PM
@Vladki
a is dependent on radii and speed though:

For passenger trains:
V<160 a=0,8
V>160 a=0,6
But if:
200 m < R < 250 m a=0,5
R<200m a=0,45

For goods trains it is depended on the usage as well and varies between 0,2-0,6.

Minimum radius varies by country and track type. Not only mainline/branch/industrial siding. It is also much shorter for trams and narrowgauge. I do not think it is necessary to make limit on radius. What would be nice is to have an option to forbid routing over sharp 90° turns  (from one diagonal to another) which are part of U-turn. I think I have seen such option somewhere, but it may have been Transport Tycoon...

The maximum allowed value for a is also dependent on country, and is decided by railroad administration with varying safety/comfort margins. I would not complicate this issue any more by having different a for different radius of curve. It is enough that we have different values for different waytypes. Adding second value for superelevated curves would be more than enough complexity.

Quote
Could the radius in your calculation be 125m though? We have two tiles for 180deg U-turn so assuming that tracks are on outer edges of a tile rather than in the middle it would give us a radius of almost 125m.
I have used the radius which was suggested by the comment in the relevant code, to show that there must be a bug. For consistency I would prefer to always think that the track is in the middle of tile. Slowing a train down to 20 km/h is IMHO OK. It will not block the track for ages, but still will be a very noticeable slowdown to make the player think about improving the track layout.

killwater

I would still insist that a value of a=0,45 should be used for tight turns - it is 25%  difference after all. U turns on 62,5m radius are insane though - it is like going on a bigger roundabout but with a 2 km long train going at 32km/h. Its not only unrealistic - it is completely crazy.I would like to see it with my own eyes though ;D

Vladki

It was 23 km/h... I agree that seeing 2km long train in such turn would look weird but I can imagine a tram, metro, s-bahn or narrow gauge train in such turn without problems. I even saw a video of American extra long freight train in quite tight railway spiral. It was longer than the spiral, and quite slow.

The passenger comfort and lateral forces between train and track are really dependent only on a = v^2/r so radius is already taken into account.

Lower limit for a on tight turns may be due to the nature of railway wheels, especially the size of flanges, which cause higher wear in tight turns. Also longer waggons with only 2 axles would have problems. This is solved for trams by smaller flanges and use of bogies. Czech railways impose 3 different speed limits: standard, higher for tilting trains, lower for CoCo (6-6) engines like "taiga drum"

Anyway, I have no problem if such turns are forbidden. But if not forbidden, then they should be passable at a speed appropriate for radius of half tile, which is more than 1 km/h. And that is the bug I originally reported.

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

Thank you for your reports: I think that I have fixed the problem with cornering at 1km/h. Would you be able to re-test to confirm?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Tight corners seem to be OK now.

However I still feel that the wider corners are taken too slowly. Have a look at the passenger train leaving trnava in direction to trnava predmestie. It goes 45 degrees right, 11 diagonal tiles, 45 degrees right, 6 straight tiles and again 45 degrees right, then 16 diagonal tiles and 45 degrees left. The second turn is taken at 80 km/h, third turn is taken at 57 km/h. These speeds seem to be OK for tighter corners of 5 and 3 tiles. I see that in the code you divide the steps_to_90 by 2. Why?

BTW, are there any wider instances of 180 and 135 degree corners than these tight ones? Aren't any wider corners considered as a sequence of 90 degree turns?

Could you please comment the two diagrams of 90 and 45 degree corners (in the first post) - just tell me how many steps_to_90/45 they have and what radius should that be?

jamespetts

You write that you feel that they are taken too slowly - is this just a feeling, or is there an empirical basis for this?

The reason that the number of tiles is divided by two is because of the way in which diagonal ways work in Simutrans: although the way looks straight, it is actually occupying a sequence of adjoining tiles meaning that the distance between the start and end point of a diagonal section is actually the Manhattan distance, so it is necessary to divide by two to get the radius (as opposed to the diameter) of the corner.

As to whether there are instances of 180 or 135 degree turns other than tight ones, it is possible to have a hairpin bend on a railway line where the two parallel tracks that come out of the hairpin bend are several tiles apart.

As to the diagrams, the second diagram would be regarded as having a radius of 3 tiles. The first example is actually a special case provided for in the code, and has the radius given in simuconf.tab by the parameter assumed_curve_radius_45_degrees.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

What radius would be the first diagram if assuned_curve... is not applied?

Otherwise it is a strong feeling that something is wrong. That is why I want to exactly understand how you count the corners, to see if the bug is in:
a) counting steps_to_90 (or 135, 180, 45)
b) converting steps... to radius
c) converting radius to speed.
d) really just my feeling

So far I have found different formula for c) and I also think that b) should be a bit different but I still do not understand how you count a). Could you tell me the values for the example diagrams?

jamespetts

As written above, the second diagram has a radius of 3.

When looking at the code to give the numerical answer to the question of what the first example would be but for the assumed curve radius, I found that I had omitted to apply a correction to this calculation that I had applied earlier in response to the reports in this thread regarding 90, 135 and 180 degree turns, which I have now applied. Thus, the steps (in tiles) to the second 45 degree corner are divided by two (with a minimum value of 1), and the radius is this figure (or the assumed radius, whichever is the greater) multiplied by the meters per tile value multiplied again by two (as, for a pair of self-correcting 45 degree turns, the radius is double what it would be for a 90 degree turn with two 45 degree corners the same number of steps apart).

Thus, in the first example, if the assumed radius were set to 1, the number of steps to 45 degrees would be 4. Divided by 2, this would give 2. Multiplied by 125, this would give 250, and multiplied by 2, this would give 512. The default assumed radius is 750, so, unless the default radius were set to 1 or similar, the radius actually used for speed calculations here would be 750.

Incidentally, if the assumed radius is set in simuconf.tab to zero, a pair of self-correcting 45 degree turns will not count as a corner at all for speed limit purposes.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: jamespetts on May 10, 2017, 10:59:30 AM
As written above, the second diagram has a radius of 3.
How many are there steps_to_90 ? I would guess that 5, which should give radius of 2.5 (blue curve), but due to integer calculations it would be only 2.
I have updated versions of the diagrams with red circle showing your approximation. Could you check if that was what you intended?

I think that better approximation for both diagrams would be the green curve - which has radius = steps / 2 * (1 + sin(45)) = steps * 0.85355339
This could be used for both 90 degree bends and self-correcting 45 degree bends (wider than assumed_radius).




jamespetts

I have modified the code slightly to eliminate the rounding inaccuracies by dividing, not the steps_to_90, but the radius, by 2.

I am not clear on the basis on which you think that the alternative suggested calculations would be preferable - can you elaborate?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I was thinking about it long ago when you asked about solving the two self correcting 45 bends. I wanted to approximate it with two circles that touch the track in the middle of the diagonal part and in the same distance on the straight part. Such circle (arc) is tangential to the track in both places. Your approximation is tangential only on the straight part.

Then I realized that the same approach could be used for bends that form 90 degree curve. Just construct a circle that is tangential to all three sections of the track. And that is the green curve on both diagrams.

I suppose that your original intent on 90 bend was the blue curve, right?

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

Yes, indeed, and necessarily so, I think, as the tiles at -8 and -10 in your diagram might well themselves be not straight, but part of a previous corner in a different direction, or alternatively have next to them some obstruction making the theoretically wider curve impossible. It would be very confusing if corners were deemed to have a much wider radius than in fact they have (the green arc indicating a radius of 5 tiles), and it is not clear why this would be a good thing, as it would be overly lenient on players who used excessively tight turns. Part of the point of railway construction is that players need to be good civil engineers and lay straight routes where possible.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

#30
I agree that tracks should be as straight as possible, but my point is all about consistency. Why should a sequence of two 45 degree bends have very different radius just because once it is self correcting, and other times they form a 90 degree turn. Look at this screenshot:
.
Why should a train running from south to north be significantly faster than train going from south to east ? (think of assumed_45_radius set to 1 for now). The train making 90 degree turn has in fact one tile longer distance between the two 45 degree bends than the train taking the pair of self correcting turns?

If your (blue line) approach to the 90 degree turns is taken absolutely, then the sharpest 90 degree turn should have a radius of 1/2 tile - the same as 180 degree turn. Also if you look at the 90.png diagram you will see that the green line is entirely on the same tiles as the black line of track, while the blue line crosses two extra tiles. Overall the green line is much closer to the track than blue line.

If the tile between -8 and -10 would be a part of another bend, then of course the speed of the train would be limited by that shorter bend which would be a pair of 45 bends with one straight tile in between. Wouldn't it?

I have played a lot and checked the speeds to see if they are as expected. Here is a test save game (pak128.britain-ex) which I will comment further. http://server.exp.simutrans.com/debug-saves/cornering-test.sve
I have put a HST train to run non stop from Trnava to Selpice. When you load it it should approaching station Selpice. HST is fast enough to be limited by the curves on the track. However I found a few discrepancies.
bug #1 - steps_to_X should be reduced by one before any further calculations (for diagonal tracks), or the algorithm to count steps should be revised (according to bug#2)
If you watch the train from selpice it accelerates to full speed given by track (160 km/h). It starts to slow down at nemcanka (signalbox), as there is a 90 degree bend, just exactly the same as on the above diagram. It has 5 diagonal tiles, so the expected radius would be 5*125/2 = 312.5 m. And the speed = sqrt (312*87/10) = 52 km/h. Yet the train slows down to 57 km/h, (at 74,83) which gives steps_to_90 = 6. The same then applies to similar bends at (59,52) - 31 tiles, speed 131km/h is for 32 steps, and (25,49) - 11 tiles, speed 80 km/h should be for 12 steps. So the calculation of steps_to_90 returns the result greater by one than it should.
Also short pairs of self correcting 45 degree bends are off by one. This can be seen on the milk train approaching nemcanka - it will move to the third track at (92,87), slowing down to 73, as if the diagonal section had 5 tiles, but it has only 4. And again when approaching the dairy it takes the tightest pair of 45 degree bends - 2 tiles, at speed 57 km/h which should be for steps_to_45=3.
bug#2 radius should not be calculated from manhattan distance, but real (euclidean) distance.
Very interesting is the stretch of track of 6 E-W tiles at (30,44). The train slows down to 61 km/h (7 steps_to_90). Lets assume that the off by one bug from above applies, so it would be calculated with 6 steps_to_90. Then the radius is 3 tiles, which is completely wrong. See the screenshot - blue line. I think that for this kind of 90 degree turns, and using you original approach, the radius should not be steps/2 but steps*sqrt(2)/2 (red curve):

To be consistent for curves with middle part either diagonal or orthogonal to tiles, one has to use euclidean distance in the calculation, not manhattan. For your approach to 90 degree curves it should be radius=dist*sqrt(2)/2, or for my (more gentle) approach it would be radius=dist*(sqrt(2)/2+1/2).  Euclidean dist for diagonal tracks is steps*sqrt(2)/2 so we get back yours radius=steps*sqrt(2)/2*sqrt(2)/2=steps/2, or mine radius=steps*sqrt(2)/2*(sqrt(2)/2+1/2)=steps/2*(1+sqrt(2)/2)=steps/2*(1+sin(45)). The same applies to pairs of 45 degree bends.

bug #3
The behavior on the way back is somewhat inconsistent. There are two stretches of 15 tiles (those with crossings - one at new cemetery, other at trnava predmestie stop), that form a pair of self-correcting 45 degree turns. On the way to trnava, the HST slows down to 131 km/h at the end of both. But on the way back, it drives at 133 km/h (at 58,52)

bug#4
the HST when leaving Nemcanka station has to pass a tight pair of self correcting 45 degree bends (at 93,86). I have set the assumed radius to 100 to avoid its effects. While it worked well on the milk train passing this turn at 57 km/h, the HST train passes it at 93 km/h. As if it applied a speed limit of 16 tiles long 90 degree bend - and indeed there is such - the station is 16 tiles long. But the following short bend is ignored.


So If I may suggest to change the handling of corners to the following:
a) if there is a 90 degree hairpin turn (i.e. 180 or 135, e.g. at 22,127) - set the radius to 1/2 tile, without any more calculations.
b) if there is a pair of 45 degree turns (whether forming a 90 degree turn or self correcting S-turn), calculate the radius as radius=dist*(sqrt(2)/2+1/2)=dist*1.207, where dist is euclidean distance


Now I realized that the current algorithm is producing the red curve from 90.png, which may be intentional, but is still one step longer for 45.png

Vladki

#31
James, I'm still thinking about the cornering. I consider writing some patches, but first I'd like to know what was your intention on approximation. I have drawn part of the track from the above mentioned savegame, and drawn what corners would be appropriate for the current code. Could you confirm that the blue line was your original intent? The grid is tile grid - numbers are manhattan distances or corner radiuses in tiles multiplied by two (due to the limitations of the software I used).

Update: added a green line showing what would be my idea of ideal approximation. I'm interested in other thoughts on this as well. If we agree on that I'll try to implement it.

Just to explain how I constructed the green arches - they are tangential to both segments of track. One touch point is in the middle of the shorter segment of track, the other is in the same distance from the 45 degree angle.

jamespetts

Thank you very much for your feedback on this, and apologies for not having had time to look into this in more detail recently: I have been spending quite some time working on implementing passenger classes. To answer your question, without checking and calculating in detail, I think that the blue lines in the diagram in your last post do represent the original intention of the code (i.e. that, for 90 degree corners, the radius should be the actual radius of the turn as if it were continuous and not made of straight lines and sharp angles).

Edit: Incidentally, if you want to try writing a patch for this, and you want to use the Euclidean distance, use the shortest_distance() method, which is a method for measuring the shortest distance in tiles between two points taking into account that it is possible to go only straight and diagonal.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.