[Patch (obsolete)] New cornering algorithm - allows for tilting trains

[jamespetts]

Attached is a patch to change the way in which Simutrans handles corners for rail and road vehicles. The aim is to make the handling of corners both more realistic and more interesting for the player in terms of the best network design for cornering.

The present default Simutrans code deals with corners quite simply: it tests to see whether the current direction matches the vehicle's last known direction, and, if it does not match, adds a certain element of friction to the speed calculation. (Ships work the same way, but add a lower element of friction. The system is not used at all by aircraft, which can bank and corner without slowing down at all). The problem with the current system for land vehicles is that it does not draw any distinction between cornering at low and high speeds, or between wide and tight corners: all will slow the vehicle by applying more friction. Moreover, the more powerful the vehicle, the better that it can overcome friction: in real life, powerful vehicles are no better at cornering than less powerful ones.

What I have done instead is, instead of applying friction, I have applied logic to reduce the speed limit whenever a vehicle goes around a corner. That is more realistic in that a vehicle travelling slowly does not need to slow down further to take a corner: the reason that vehicles take corners more slowly is not because it takes more energy to go around a corner (it does, but not to an extent that usually makes enough of a difference to rail or road transport to have a noticeable effect), but because there is a limit to how fast that vehicles can go around corners safely without skidding off the road or tipping over. The speed limit applies only for the time that the vehicle is in the corner, and is proportionate to the speed limit of the original way (the thinking being that the faster speed the track/road, the better designed/smoother that the corners are, and therefore the faster that vehicles can take them). The degree of reduction in the speed limit is increased as the speed of the way increases to reflect the fact that there is a limit on how far that smoother corners can help to make vehicles go around them at ever greater speeds.

More than that, I have made the extent of the reduction in the speed limit depend on how sharp that the corner is. This is what took most of the work (nearly two days of reworking the code). The sharpness is not based just on the extent of the corner in a single tile, and whether it is a 45, 90 or 135 degree bend (yes, 135 degree bends are possible inside a single tile in Simutrans): it is based on the overall bend over the last few tiles, so that, for example, a 45 degree bend to the left followed immediately by another 45 degree bend to the left is treated similarly to a 90 degree bend (although the code detects that the corner has been smoothed to some extent, and applies a lesser speed limit reduction in consequence). More than that: the number of previous tiles taken into account when deciding how sharp that the corner is depends on the base speed limit of the way: the faster the speed limit, the more tiles are taken into account. That means that, as in real life, the faster that one wants to go, the more important that it is to have the way as straight as possible, and the corners as smoothed as possible. For high speed rail, any corner will give a big penalty; conversely, for a slow line used by plodding freight or a local metro train, even fairly sharp corners all over the place will not make any noticeable difference.

Finally, I have implemented some code to simulate tilting trains (in the gameplay mechanics, that is, not graphically: graphical implementation of tilting trains is one of the "denied extension requests" because it is too hard to implement). That code is not fully complete, as I have not yet written the code to read a "tilting" property from a .dat file, but the basic logic is present in the new cornering code to take account of tilting trains, and allow them both to take corners at a higher speed than non-tilting trains, and also take into account fewer tiles in determining the overall tightness of any bend.

The overall effect of this patch will be, I hope, other than adding more realism to Simutrans, to make network design more interesting, in some respects easier, and in some respects more challenging. It will be easier in the early parts of the game, when dealing with old, slow trains and bulk freight, because corners will be far less of a penalty for slow traffic than they are now. It will be more challenging in later parts of the game because it makes the design of higher speed rail networks trickier because corners will be more of a penalty than they are now for high speed traffic. It will make network design more interesting because players will have to design their networks to suit the speed of the traffic that will be using them, and, crucially, redesign their networks as the traffic needs change over time with advancing technology.

One important feature of the history of railways that I am hoping that this patch will help to simulate is the fact that, when railways were first built in the 19th century, relatively slow and underpowered steam locomotives were enormously hampered by hills, but found corners to be of little trouble, since they went slowly enough to negotiate even relatively tight corners at near enough full speed. The railway building strategy, therefore, was to skirt around hills wherever possible. Conversely, modern high speed trains are powerful enough not to be troubled by all but the steepest of gradients, but have to slow down considerably for corners to be able to traverse them safely. The modern railway building strategy, therefore, is to go over hills in a straight line rather than around them. The additional challenge and interest in Simutrans will come when players have to adapt their early networks to meet the needs of modern transit, which may well involve substantial redesigning. That should help to keep the game fresh in the later stages.

I have not changed the cornering system for ships, since the added effort to turn corners is what makes ships slower in turning corners: transport vessels rarely go fast enough to be in any danger of tipping over when turning. I should be very grateful for any comments, questions or suggestions for refinement. I will look into how to read a tilting property from a .dat file, add that to the code, and update the patch when I can.

Edit: A newer, better version, compatible with the latest nightlies  (as of the 5th of January 2009), is now available here.

[Combuijs]

Interesting idea, well thought out!

[Ashley]

This sounds like a really well thought out patch, finally giving some reason to make smoother corners on high speed networks (will really introduce a great end-game challenge, in rebuilding networks to construct high speed links). Quite intuitive too, since it works the way one would expect it to.

Now if only we could have weight limited ways too

[jamespetts]

This sounds like a really well thought out patch, finally giving some reason to make smoother corners on high speed networks (will really introduce a great end-game challenge, in rebuilding networks to construct high speed links). Quite intuitive too, since it works the way one would expect it to.

Now if only we could have weight limited ways too

Ahh, I'm planning on doing that, too. As Prissi said in a recent thread, there's already some code for it, but it's not enforced during routing. The reason that it was not developed I suspect is because it was considered potentially too confusing for players to be told that their vehicles would not route if one of the bridges (etc.) along the way had a weight limit of less than the vehicle's weight. The way around that problem, I think, is to impose a less harsh consequence of exceeding the weight limit: instead of refusing to route at all, just make the vehicle go a great deal slower on the weight limited way if it is overweight (perhaps as little as 10% of the speed), with a big, visible notice (in the style of the "NO ROUTE" or "STUCK" notices) saying "VEHICLE OVERWEIGHT FOR WAY". That should add more interest to bridge construction without being too confusing for players (and could also make for interesting alternative track types using the weight limits).

In any event, I am glad that you both like the cornering patch. :-)

[VS]

If it does what you say, I can only applaud.

You keep finding areas of code where no additional input from non-coders is needed... that in itself is a huge advantage!

EDIT: allow me to clarify that - "input" meant further work, as in material input - new images etc.

[Fabio]

I can't wait to see this patch working... it's an awesome change! does it work also for highways?

[DirrrtyDirk]

Fabio, I can only guess but...

Attached is a patch to change the way in which Simutrans handles corners for rail and road vehicles.

... my guess is: yes.

[The Hood]

This looks good!  Hope it works...  As for weight restrictions, I agree with the speed restriction for overweight vehicles - it would be less confusing and also this happens in real life anyway (speed restriction should be very low, no higher than 20km/h, or at least that's what gets applied on Britain's railways).

[prissi]

Actually, the is a lot more energy needed to go around a corner due to fixed axes on trains. And tilting is just for the comfort of passenger, the physics of the carriages are not affected. Any trains could go as fast as a tilting train. Only then the comfort limits on the pasengers would be exceeded. (A very commond misconception, but often repetition makes in not any correcter.) You can prove that very simple because on trains like Talgo or X2000 the engines do not tilt ...

Apart form that, please obey coding rules, if you ever want to include your work. Every block must be closed, and on a sepearte line.

if(x) y; is forbidden

if(x) {
  y;
}

is the style. There is a file coding rules in the document folder.

Since calc_akt_speed is the second most time consuming routine in the game, could you please provide some profiling on the effect?

And finally I feel that a history of 16km is completely over the top. Two tiles or may be four is imho ok, this would cover switches and the like adequately. Also the fact that is immediately halves its speed when a it enters a curve is not too pleasent for me.

[jamespetts]

Prissi,

thank you very much for your reply :-) Sorry about the coding styles - I will change that and re-upload the patch when I have finished with weight limits. As to the history, the maximum currently set is 10 rather than 16 tiles, although the array is 16 items large to allow for overhead. There is an element of ambiguity with the distances, because Simutrans (purposely - for playability) uses two inconsistent scales at the same time: there is the routing scale of 1 km/tile, and there is the large scale of the actual trains, buildings, etc. I was aware of those different scales, and quite deliberately chose to align the cornering algorithm with the scale used by the length of the trains, rather than the 1km/tile scale, because that is what makes more sense: it is more intuitive and consistent if the scale adopted for the cornering algorithm is the same as for the length of the trains. Adopting the 1km/tile scale would mean that there would be virtually no interest or challenge in designing track, as almost any turn of any radius would have the same effect as any other: exactly the thing that this patch tries to avoid. With the full history, track has to be smooth in comparison to the length of the train: a far more pleasing and satisfying approach.

To put it another way, in a world where a train can be 10km long, it makes perfect sense for the corner history also to be 10km long. Of course, if there continues to be a substantial difference of opinion over the optimum level of history, I could just make all the values read from simuconf.tab, and let the users and/or pakset authors decide which is preferable :-) As for tilting trains, I take the point about the main reason for having them; that does not alter, however, the fact that tilting trains can take corners more quickly than ordinary trains, and the additional gameplay mechanics to which I refer ought still be included.

As to immediately halving speed, although that is not ideal, I do not think that there is an easy solution, since any attempt to read through the history when deciding whether to impose a speed limit resulted in erratic behaviour, including slowing on straights. Any attempt to read ahead and look for a corner in front would, I imagine, create significant computational overhead, as well as being enormously difficult to code. The original algorithm in any event was not much smoother: it, too, caused vehicles to first start slowing for a corner the moment that they entered a corner. Although this code does not produce movement as smooth as is ideal, that is a cosmetic matter in comparison to the function provided by the code itself. Any increased smoothness of reducing speed to match a new speed limit ought perhaps be implemented in the code for adjusting to new speed limits, rather than the code for setting the speed limits.

Finally, as to profiling, I have not done any formal profiling, although on the tests that I have conducted, performance was not noticeably hampered. The difficulty with profiling is that the version that I have of the source code contains not just the cornering algorithm, but a large number of other changes (to the speed bonus, to obsolete running costs, in respect of weight limits, etc.) that make comparison difficult. Is there a standard model of profiling that you would suggest, or a fixed method that you consider preferable in those circumstnaces?

[VS]

With all respect, the "tilting problem" is a fallacy:

If change in speed is dictated by [wheel] friction, moving car body is useless. The only way to involve something more than bogies I can see is throwing the body away bit by bit, creating a reactive engine opposing the force that pushes the car and its wheels to side

Since tilting is done for passenger comfort, involving tilting as a variable must be necessitated by accommodating some cargo parameters - in other words, if tilting allows higher speeds, trains must slow down because of something going on "on board". Then a question arises, what with other cargos than passengers - glass for instance?

In other words, a decision must be made, if the model:
1) is strictly physics-based and simple - no tilting
2) is strictly physics-based and takes into account cargo - tilting ok, but new parameter for friction varying with carried freight (even if there is only one difference for psg.)
3) aims for "most fun" and follows physics only where it brings something interesting.

At the moment this seems to be (3).

[jamespetts]

VS,

the reason that trains slow down on corners is because the speed around corners is limited by regulations, not because it is harder for trains to push themselves around corners. Whilst there is some extra energy involved in a railway train cornering, that is limited in comparison to the necessity to limit the speed for safety and/or comfort reasons. Trains are almost always powerful enough to take corners far faster than is safe or comfortable to do so (in so far as they are powerful enough to go that fast on a straight section, at least).

As to tilting trains: the only tilting trains that exist in so far as I am aware are for passengers (no doubt because no other cargo is transported at speeds where tilting will make any difference). One would expect pakset authors to reflect this in their designs. Tilting most emphatically does enable trains to take corners faster than non-tilting trains: see here and here for information: that the reason that they can go around corners more quickly is for passenger comfort does not alter the relevance of the gameplay mechanic.

I don't understand the suggestion for varying friction with carried weight - the whole point of this patch is to replace the idea of corners adding friction with the idea of deliberately limited speeds on corners to ensure safety/comfort, because speed limits and not added friction are overwhelmingly the primary limiting factor in cornering speeds of trains.

[jbode]

Hi, as soon you have friction --> wheel flange is touching the track ... you will have a real serious problem. In normal operation the wheel flange should never touch the rails. Railroad wheels are conical and directly connected, so in curves the different radius (resulting by shifting the touching region of the conical wheels) keeps the train on track. Trains having a side motion around the needed wheel position - this is stabilizing the movement.

Problems coming up when trains are to slow in a banked track (such tracks are then not planned for being slow ), or when moving over switches (most people know the ugly sounds...). Switches are an important reason to slow down traffic. In Germany we had some wheel defects on high speed trains. The main candidate to have caused to much stress on the wheel/axle structure are likely the switches and worn out tracks from other traffic. All other countries have their high speed trains completely separated from normal commuting and freight train system ...

As said above the tilting trains are purely for passenger comfort - to compensate for centrifugal force. The human sense of balance does not allow too much force to the side ... Miscomfort will prevent people from traveling such trains. Even when 95% could not determine why it is feeling peculiar ...
Tilting of trains is not necessary for goods transport. Any good to be carried needs anyway to be packed properly ...

Speed limit to be applied on freight trains are caused by weight (stress on track, needed energy to accelerate and braking distance). Sure not forget the stress on the vehicles ..., but less important ...

Jörg

[VS]

Ok, I have re-read your first post... this makes sense. Apologies for the misunderstanding.

(One problem is that you hide the important bits of information in too much text, but so do I, often...)

That said, perhaps instead of tilting on/off, the safe corner speed (fraction?) itself could be part of vehicle definition, configurable by author? I can imagine that flat railcars can turn faster than doubledeckers.

[prissi]

Actually most trains do not have to slow down in corners on mainline tracks apart from some very curvy riverside track or highspeed (and that means more than 160km/h). Even for devoted highspeed lines like in France or Japan the corner speed is not limiting the total speed, since the track is tilted enough.

Only for mixed operation the track tilting is limited to avoid a starting good train to fall over on the tilted track. But the speed is only limited for comfort reasons. Or how was is possible to go 480 on a track built for 260 for the german ICE? (For the world record 45km was needed ... )

On the same note, the TGC doing the 571 km/h also did many curves with much higher speed than allowed. But alle those records were done near the end of straight stretches because friction is severe in curves, as written before. This gets even worse with higher speeds, since the centripetal forces are stronger and thus friction of flanges and track increase proportional to the applied pressure (with is quadratic to the speed, if memory servers me correctly).

And even the very run of the mill switches can in principle stand 80km/h. Only several switches close together are closing problems, i.e. left and then right. With this in mind one could think about limiting speed for two subsequent direction changes. Thus would require much less overhead and would not destroy the relative smooth movement of the friction code.

[jamespetts]

Prissi,

it may be different in Germany, but speed restrictions due to tight corners are very common on UK railways. As noted in the original post, the fact that older railways were built around hills (incorporating more bends but fewer gradients) is a problem for modern trains, needing fewer bends but not having such a difficulty with gradients. That is part of what I want to simulate with this patch.

It may well be that experimental runs of record breaking trains need straight track so as to minimise energy dissipation, but that is a long way from the constraints of normal operation. Really, to circumvent any disagreements, the sensible thing will be to make the values for the corners adjustable in simuconf.tab so as to let pakset authors and/or end users decide the numbers for the cornering code: there is little point in debating what hard-coded values could be when it is quicker to make the values user-adjustable . It would even be easy to have a "use old cornering algorithm = 1" option to give people the choice between my way of doing it and the old "friction" method.

I am not sure that I follow about subsequent direction changes and the friction code: the idea of using friction as the limiting factor for corners is a problem, since it has the bizarre effect of slowing a train however slow that it is going to start with (and, as you noted in the opening of the post, many trains do not have to slow down at all for corners - if the corner is wide enough, and the train is slow enough, at least), and making the extent to which a train slows on a corner dependant on how powerful that the locomotive is. The code that I have written does take account of cumulative direction changes - that is part of the point of it (to encourage smoother corners). I am not sure how this could be accomplished with less overhead without compromising function.

As to switches - if there is an easy way of detecting when a vehicle is currently passing over a switch, it should be easy to code a speed limit for that, too. What I will do is make all of these settings user-adjustable in simuconf.tab, and upload a new version of the patch (with the corrected coding style) and we can take it from there :-)

[isidoro]

My idea:  why not a combination of Prissi's and James'?

Let there be a fiction but make that friction depend on both speed and corner history (the friction can even be zero for open curves or low speed).  The idea is to make the train speed look smooth while preserving James' ideas.


Second point (in connection to but apart from this one):

Once the code is built for the history of a vehicle, why not taking into account also slopes?  I don't like the way it looks a vehicle climbing a mountain straight.  It is more natural to build a road snake-like.  I always do that, now for aesthetic reasons.  An example in the image:

[jamespetts]

Isidoro,

an interesting idea, but that would not address the real problems with having corners increase friction: (1) they will slow all trains, regardless of how slowly that they are already going; and (2) the extent to which corners affect trains will depend on the power of the locomotive. Those are the fundamental reasons that I changed from increasing friction to lowering the speed limit. Smoothness, if desired, can be implemented elsewhere (if it is not too computationally expensive).

The gradient history idea, however, is a very interesting one indeed, and deserves further thought. Perhaps you could code a patch?

[prissi]

The friction does not work the same for all speed, since its enters non-liniear in this equation. But of course the friction could depend on the maximum speed or the current speed (this would just require to change a very few lines in simconvoi.cc).

[The Hood]

Seems to me a combination of the two could be best because
1) friction does apply on corners, so from the pure physics of it, trains will always slow down when cornering unless they have the power to accelerate quickly enough to counteract this
2) trains in commercial operation are made to slow down on corners anyway for safety / comfort reasons

So I propose the following logic:
- to address point (1) above, use a friction component to decelerate the train (as now?) - but maybe this needs to be tweaked to be less severe for lower speeds.
- to address point (2) above, *also* impose a speed restriction around the corner depending on shape of curve (encourages straight/smooth track for higher speeds later in game, so probably ~4-tile history) which is not enforced (or less severe) for tilting trains (for a real life example, take the newly modernised West Coast line in the UK - tilting trains are permitted to travel at 125mph, non-tilting are restricted to 100mph).

This way you are encouraged to allow for higher speeds on your network by building straighter track with smooth curves (e.g. French TGV network) or buy expensive tilting trains (e.g. UK West Coast) to allow higher speeds on existing curvy routes, whilst keeping physical principles intact (routes with lots of corners have always needed higher power locos anyway to get over problem 1). 

As an aside, implementing this could also be used to make the new narrow gauge trains better at cornering than standard gauge (e.g. have less severe speed restrictions for equivalent corners, and maybe reduce the friction deceleration effect).  Narrow gauge trains were used in mountainous regions because they could corner easily and take long curvy routes up hills without so many problems, and this could be encouraged.

[jamespetts]

I suspect that we are not going to reach an agreement on the importance of friction in cornering: I still strongly take the view (see here, for example) that the primary limiting factors for cornering is safety and/or comfort, and that the additional drag caused by cornering almost never stops a train from going the full speed that it is allowed to go around the corner without any non-trivial more difficulty than it would have going that speed on the straight.

However, we do not have to agree: a friction factor on corners can be made entirely optional in simuconf.tab. What I can do is add a "cornering_friction_coefficient" line to simuconf.tab, and also a "restricted_speed_cornering" line (1 for on, 0 for off). The first would be the value of the additional friction to be added (as in the original code, which would be executed before the speed limit code; 0 would bypass that block of code entirely), and the second would determine whether any of my new code is executed. I could also smooth the speed limit variation factors (so that track with a speed limit of 395kph does not allow faster cornering than track with a speed limit of 400kph), and make those values customisable in simuconf.tab as well.

The narrow gauge point is interesting - from my understanding, the broader the gauge, the more stable that the train, and therefore the faster that it can take a corner: that is why the GWR used broad gauge in the early years: to enable higher speeds. The advantage of narrow gauge track is that both it and the trains that run on it are cheaper. It is certainly easier to build narrow gauge track around a corner, but I strongly doubt that a narrow gauge train can take a corner of any given radius faster than a standard gauge train: if anything, the opposite would apply.

Because of the physical characteristics of the trains, one can have sharper corners on narrow gauge track than it is possible to have at all on standard gauge track without the axles locking up entirely, but the trains cannot take them any faster than they can at standard gauge. Unfortunately, Simutrans does not enable a sufficiently fine-grained implementation of corner radii to be able to simulate the differences in allowable minimum radii for narrow gauge in a useful way.

[isidoro]

My point about friction was not that, James, I'm afraid.  It is a more practical one.  We want trains to be slowed at corners.  Today's method can be improved.  Your suggestion is: for reasons A and B, I want a speed limit on curves that is a function of some variables: sl(speed, curve radius, etc.)

My suggestion is: once we know the enforced speed, let's work the way back: let's calculate what friction will be needed for the vehicle to get to that speed and apply that friction.  Simple.  If a similarity to real life is wanted, that friction will come from the brakes of the train to slow it down, not from the corner itself...  Would be more natural than a sudden reduction of the speed to half the value.

Now an evil twist: when a car is approaching another car and not overtaking it, the speed reduces to zero.  Can some friction be applied to it instead, enough to make them not crash? (I would like an evil emoticon here, but don't have it  :'( )  I love emoticons so much...

[KrazyJay]

Don't take it personal James, this is the way simutrans works, I never got used to it either... but I guess eventually there will be a patch that pleases both you (representing the ambitious newbies) and the dedicated old folks (not in age but in yrs spent on this game). And that's what we all need

[jamespetts]

Isidoro,

ahh, so you thought to use friction to simulate smooth breaking, rather than to simulate corner friction? Then that makes more sense - but there is a problem: it would likely be very computationally expensive to calculate for each corner exactly what level of friction is required to be added to slow the train to the correct speed within a reasonable time: the current speed of the train, its weight, its power, and the desired speed limit would all have to be computed for each train for each corner; Prissi was already concerned that the algorithm as it is might slow things down (noting that the calculation of a vehicle's speed at any given point is one of the most computationally expensive aspects of the game engine).

Also, I have just checked: any reduction from one speed limit to a lower speed limit involves the vehicles slowing down just as rapidly as they do with this cornering algorithm. It makes sense that, if a corner is treated as imposing a speed limit, the smoothness of reduction of speed in a corner should be the same as for any other speed limit. It would be nice to smooth all speed limit reductions, but I have doubts that it can be done without unduly impacting on performance. If somebody can code something for any speed limit reduction that does not unduly impact on performance, that would be a good addition to Simutrans generally, but ought not be considered a prerequisite for the adoption of this patch, since it addresses an entirely different issue.

I am not sure what you mean about the car thing: do you mean that they stop too suddenly behind other cars? That is not new after my patch, is it? I think that they do that in any event.

KrazyJay,

the patch that pleases everyone is, I hope, the one that is programmed to allow people to set in simuconf.tab how they want things to work, so that all the different preferences can simultaneously be accommodated. If everyone can have what they want at once by adding more options, there is no need to debate or compromise on which setup is the best

[Fabio]

Couldn't be possible, to look - say - 4 tiles ahead looking for a speed limit (either imposed by tracks, either by corners) and, if so, start reducing gradually the speed?
These limits could be considered by the routing procedure the way signals are, using the smooth breaking used for a red signal.

[jamespetts]

Couldn't be possible, to look - say - 4 tiles ahead looking for a speed limit (either imposed by tracks, either by corners) and, if so, start reducing gradually the speed?
These limits could be considered by the routing procedure the way signals are, using the smooth breaking used for a red signal.

That would be better, certainly - but I'm worried about the impact on performance. If looking a number of tiles ahead is already done in the signalling code, however, it might work. Indeed, the calculation of the speed limit could be done x tiles ahead instead of on the fly, rather than as well as, making the computation not take much longer (except when it first starts, when it will not have any data as to the next tiles). Do you happen to know where the look-ahead part of the signalling routine is in the code?

[VS]

Not much on topic, only on the programming techniques mentioned...

Look-ahead is costly only if you read N tiles for every tile advanced, if you keep "driving" the virtual convoy head in front of it and remember what you passed, you have to read only one tile per advance again... I don't know how to explain this better. But the question can be freely chosen from "is looking at more tiles [from map] per move costly" and "is looking at more data [of any form] costly".

Also the relevant data structures could be implemented as a linked list or some other container that has zero cost for returning from end to front and linear cost for any add/remove operations with items.

[jamespetts]

VS,

ahh, that's a good point. A linked list would also make the curve history functions faster. Does anyone know whether there is a generic linked list class already in Simutrans that I can reuse? Otherwise, I will write a new one.

[VS]

Perhaps the closest thing is slist_tpl...

[prissi]

Lists are evil with modern computer, since they are scattered all over caches and the idex of an element cannot simply calculated. Why not just sum up the last cornering movement with a counter? 45° +1, 90° +2 and decrement by 1 each step. The result would be multiplied with the friction factor. That would make very slow movements in switches, but fast on a single curve and would be very low in computation costs.

[jamespetts]

Prissi,

using the friction factor for setting the speed for cornering at all defeats the whole purpose of this patch, which is to remove the twin problems of (1) the speed being reduced on a corner even if the speed is very low; and (2) the vehicle's power having an effect on how well that it corners (any increase in friction will inevitably do both of these things). I am in the process of implementing VS's suggestion now, and also making the code that I have already written for cornering considerably cleaner, which I hope will make cornering work well and quickly, and also smooth speed limit transitions.

Edit: Incidentally, the lists that I will be using should not be too evil, since they will be trimmed to only a few items (as many as are needed) each hop.

[isidoro]

[...]
I am not sure what you mean about the car thing: do you mean that they stop too suddenly behind other cars? That is not new after my patch, is it? I think that they do that in any event.
[...]

No.  It has nothing to do with your patch.  Something talked about elsewhere.

[...]
the patch that pleases everyone is, I hope, the one that is programmed to allow people to set in simuconf.tab how they want things to work, [...]

One has to be careful, though.  I cannot fully agree for three reasons:

 
• I get lost when trying to play OTTD with so many options.  I don't know if it is a game or many games in one.
• Size of executable can have an impact in speed.  And, here, size does matter.
• Code has to be maintained.  Some options conflicts with others or complicate programming of new capabilities.  Some are even lost in nowadays code and never used again.  For instance, when programming overtaking, driving on the left (optional) made the code larger and more difficult to program.

[...] Also the relevant data structures could be implemented as a linked list or some other container that has zero cost for returning from end to front and linear cost for any add/remove operations with items.

I wouldn't use a linked list myself.  I would use a fixed size array with two indices (head and tail) and modulus operation.  Or something similar to Prissi's counting of changes.

[jamespetts]

No.  It has nothing to do with your patch.  Something talked about elsewhere.

Ahh - can you tell me where it was talked about? I don't think that it was on these English language forums, or else I'd probably have seen it. What is the problem, exactly? What are the steps necessary to reproduce it?

One has to be careful, though.  I cannot fully agree for three reasons:

 
• I get lost when trying to play OTTD with so many options.  I don't know if it is a game or many games in one.
• Size of executable can have an impact in speed.  And, here, size does matter.
• Code has to be maintained.  Some options conflicts with others or complicate programming of new capabilities.  Some are even lost in nowadays code and never used again.  For instance, when programming overtaking, driving on the left (optional) made the code larger and more difficult to program.

If the options are in simuconf.tab, only users who know what they are doing are likely to go there in the first place; that will not, therefore, confuse newer players. Pakset authors can then use the program in a more flexible way, determining which options are used. The size of the executable should not be non-trivially increased by my cornering code: it is a drop in the ocean compared with the rest of the code. As to the maintenance of code: there is nothing about the cornering system that is particularly difficult to maintain; I am currently working on putting the new code for cornering and weight limits in a separate method to make maintenance easier. If there is a substantial disagreement between people on how best to do something, that means that there is a substantial demand for both ways of doing things, which is itself a strong countervailing reason to have multiple options.

Edit: Can you explain a little more about the sort of array that you suggest?

[Fabio]

Indeed, the calculation of the speed limit could be done x tiles ahead instead of on the fly, rather than as well as, making the computation not take much longer (except when it first starts, when it will not have any data as to the next tiles).

This would be great and also wery realistic, because each vehicle in RL is driven taking into consideration what is expected to be on their way in the next few km. the number itself of tiles ahead could depend on the max teoretical speed for a given vehicle (a high speed train will consider more kms of way ahead rather than a slow truck, because their braking time is different). and if this routine limits the speed in switches as well, this is good, because switches slow down trains in RL as well.

[corsa319]

VS,

the reason that trains slow down on corners is because the speed around corners is limited by regulations, not because it is harder for trains to push themselves around corners. Whilst there is some extra energy involved in a railway train cornering, that is limited in comparison to the necessity to limit the speed for safety and/or comfort reasons. Trains are almost always powerful enough to take corners far faster than is safe or comfortable to do so (in so far as they are powerful enough to go that fast on a straight section, at least).

As to tilting trains: the only tilting trains that exist in so far as I am aware are for passengers (no doubt because no other cargo is transported at speeds where tilting will make any difference). One would expect pakset authors to reflect this in their designs. Tilting most emphatically does enable trains to take corners faster than non-tilting trains: see here and here for information: that the reason that they can go around corners more quickly is for passenger comfort does not alter the relevance of the gameplay mechanic.

I don't understand the suggestion for varying friction with carried weight - the whole point of this patch is to replace the idea of corners adding friction with the idea of deliberately limited speeds on corners to ensure safety/comfort, because speed limits and not added friction are overwhelmingly the primary limiting factor in cornering speeds of trains.

One of the reasons trains tilt is because if a HST for example went around a tight curve the g forces and aerodynamics would change to cause it to A: come of the rails B: Half of the wheels would come of C: Everyone would be thrown about, the dynamics of trains is explained on this video http://uk.youtube.com/watch?v=BbTD9maVBek hope that makes sense.