Straight frogs - a step forward

The condition for a straight frog to render is that the curved part and the straight part of the diverging track are sections of the same track ribbon. Until today, I only knew two methods to establish this: Use the crossover tool or hack the XML files.

Now, I discovered another thing: The separate ribbons for each track section are only created if "snap to terrain" is on. Even if you lay level track on level ground, this separation takes place. But if you turn it off, all track pieces laid before you click the right mouse button form one ribbon, which results in a correctly rendered frog.


For converging track, you need a modification of the usual strategy to yield the benefit from the new insight. Instead of having the parallel (loop) tracks run beyond the diagonal which leads back to the mainline, you need to cut them off before they touch the diagonal. Then, you extend them by a short straight, then press Ctrl and snap a curve to the diagonal.

You need to practice a bit with your favourite track geometry to find out how far you need to take straight. Since the frame shown before placement is much wider than anything you see afterwards, it is a short trial-and-error exercise. But after a while, you memorized the look of the frame corner relative to the rail and sleepers of the diagonal track, and then you will be able to create converging straight frog switches with some 5-10% precision in the radius.

In Rail Simulator, you can use the same technology to get roads where the cars don't vanish. In Railworks, the problem was solved by RSC, so there is no benefit from undivided track ribbons.

Handy Key Presses for Track Laying

By chance, I discovered two handy and undocumented functions of the World Editor for laying track:

In both cases, you start track laying as usual, expanding the track ribbon. Before you click the left mouse button to really place the ribbon, you press either Shift or Ctrl and release them after you clicked.

Shift switches "camera follows track" on even if you have not select this option in the bottom left flyout. But if this function is selected in the flyout, Shift does nothing, i.e., it does not temporarily turn it off.

Ctrl toggles the "snap to track" function. I.e., if you press Ctrl and this function is not selected, then for this one track placement, the curve will snap to straights (which will turn pink in the process) to form a converging junction. If the function is selected and you hold shift, you will be able to draw a straight (showing yellow), deactivating the "snap to track" for this one section of ribbon.

Track Properties and AI

Part of the problems with the AI are related to track properties. The following is a collection of the hard and soft facts I collected over time.

Theory
The dispatcher has to find one solution of a complex search problem. The search space is constrained by the track properties set by the route author, the instructions of the scenario author, and the trains already placed. There are different possible cases.

On the one hand, a problem can be over-constraint. This means that there is no solution to it which fulfils all constraints. E.g., all routes are blocked. This is more likely to happen the more constraints you set forth, as a route builder or as a scenario author.

On the other hand, a problem can also be under-constraint. This means that there are so many possibilities that the memory or processing time is not sufficient to explore them all. AI typically uses rules of thumb, called heuristics, to cut a heap of those considerations. This generally leads to solutions which are less then perfect, but they are generated in short time while the perfect solution would take very long to find.

Nothing is known about the heuristics of the RW dispatcher. But it has been observed that he does not work too hard to find out when a blocking train will move on. Instead, he simplifies the situation for himself by assuming that the train will stay there and finds complex ways to shunt around it. While this could be a good cop out in hard cases, it is not desired in many cases where the heuristics claiming that the block will stay simply fails.

An important questions in evaluating heuristics are metrics for solution quality. Nothing has been revealed and nothing can be set by the user, and few people are aware of the issue at all. What makes a solution good, or unacceptable? This requires complex knowledge certainly not able to model in RW currently. E.g., a passenger train will not reverse into a parallel track even if it wins him 5 minute, because shunting trains with passengers in them may be prohibited, or because waiting for the station staff to perform the manoeuvre causes of loss of 5 minutes.

This means that even though everyone would wish for a clever automatic genius, arriving there is a tough challenge.

An important factor RW AI is the train density. For moderate density, i.e., about 2 clear blocks between succeeding trains, many weird solutions do not get on the table at all. But people want to see dense operation, with waiting for opposite movements and then, finding a solution gets hard and harder.

Of course, there should be an ideal golden path in the middle between over and under-constraining. There are two things to consider in this quest.

• Optimising the trade-off between desired guidance and undesired limitation cause by each information bit attached to any piece of track.
• Perfect communication between those who make the rules of usage and those who need to follow them.

Practice

• Marking a track as passenger locks out freight trains.
• Likewise, marking track as freight locks out passenger trains.
• Of course, uni-directional track locks out traffic for the other direction.

Note that freight and passenger exclusively refers to the train type selected for the driver icon in scenario editor, and nothing else.

Unfortunately, these are all the hard facts that I really can establish.

Track type yard remains a miracle. While I had the impression that it is avoided, it is clearly not a stop block for any train type. In one case, a freight train preferred 15 mph yard track over 50 mph mainline, while the same train from the same location took the mainline to reach the same destination when classified as passenger train.

Also line speed versus route length is a soft factor. I saw AI crawl along a speed restriction zone when the mainline just beside was clear and unrestricted. But I also saw AI prefer the faster track. I guess that the AI does not consider acceleration and deceleration losses. A short limit of 10 mph does not impress it, but a long one by just a few mph less makes it reconsider the route.

Sometimes I feel the the number of switches to pass is a factor. I saw AI take the loop when the clear mainline had a few more switches to other sidings in it.

A note on the hard blocks mentioned above: A a short piece of such track is sufficient for the result. This means that there is no need for miles of it. Therefore, keep direction restrictions out of places where someone might want to shunt, which is easy for route track. At the same time, make the marks long enough to be clearly seen when flying along the route. And do document them.

AI speed
This is calculated by the following interesting formula:

Line speed * (100 + tolerance) / 100 * performance

Line speed is the speed set in the track rules or by marking the track and setting the speed for this stretch. The choice of primary or secondary speed limit is decided by the train type defined in the scenario editor.

Tolerance is pegged to 60%. It is not the MaxSpeedTolerance defined in the XML of the track rule, as I believed earlier. That figure only influences the sharpness of easements, but not the speed of I, as later tests showed.

Performance is the % figure defaulting to 75% which you set for each intermediate destination.

If you want to experiment, start a scenario without being bound to a train, press F3 and then click on an AI train at an interesting place. It will shut off the power, so you need to take a quick look at the F3 display to see the value from the speed will steadily decrease. You also see the current speed limit, which can be well below the actual speed.

Given the uncertainty described above, using exactly one track class everywhere sounds most advisable, if only to rule out another factor of uncertainty with regards to AI behaviour.

In Search of a Straight Frog

In a switch, the curve can end before or after the frog (or V formed by the inner rails). If it ends before, the rails from which the frog is formed are both straight, which reduces manufacture effort, eases track maintenance, and increases the durability. But dragging out the curved part through the frog and beyond allows for smoother curves. Consequently, straight frogs are a popular choice for yards and inexpensive trackwork while curved frogs are preferred for loops regularly passed by trains.

Until today, I believed that RW simply does not render frogs in straight switches. Either the curved ribbon extends past the frog or you don't get one (and no guiderails either). Then, I saw it render straight frogs in crossovers.

After getting rid of the blocks in flangeways, I had some crossover renaissance. But creating regularly shaped trackwork using them proved very tiring.

Then, I dug into the track XML data to see what was so special with these crossovers.

Now, I know two options, both of which are not exactly attractive, but much more than I had this morning.

The task at hand is the construction of a rake of loops, 4.5 apart, connected to the mainline via 1:9 switches with a radius of 190 m. The curve of this switch is 21.0 m long (rounded to 0.1 m). The length of a 1:9 diagonal from one track centre to the next is 40.8 m for 4.5 m track distance.

Innovative usage of the crossover tool

• Lay some 500 m of straight track for the mainline.
• Create a crossover to the right (since the loops will be at the right). Radius 190, length of curve 21.0. To make sure this radius is used, you need a track rule specifying it.
• Unfortunately, the crossover tool only works on parallel (or very near parallel) track. Therefore, we only get one loop of it. The technique to produce it does not scale to a higher number of tracks.
• Therefore, delete the curve at the far end of the crossover. Extend the straight track by some long straight, for working purposes only.
• Move this new straight to the left, by some 20 m, without rotating it. It will help to inspire the crossover tool end then be deleted.
• Now, add 40.8 m straights to the diverging straight (in place of that straight that we just moved to the side). Their number is equal to the number of loop tracks.
• Now, select the crossover tool, place the gizmo exactly at the small red triangle separating two of these 40.8 m sections and create a crossover to the temporary track on the left. Curve radius is 190 again, and length 21.0.
• After you did this for all the tracks, you delete the temporary track (which now is fragmented into 40.8 m pieces, and the curves connecting to them, leaving nothing but a range of nice switches with parallel tracks of equal length.

Fine, now we only need the opposite and then connect the two. Then, you find out that this simply does not work. The parallel tracks we created are never as exact enough. The will be off by a small number of centimetres, but this is enough to keep RW from joining the track. What is worse is that RW refuses to make such minimal S curves to compensate the small deviations.

You may be able to drag up a 1:100 curve (I hardly managed to created "flatter" ones), but the curve with "snap to track" (where the found target turns pink) does not work at this angle. RW always creates straights, which then do not join, exactly because the are a little apart. I also tried splitting and welding the straights of such an extra-sharp X. Sometimes it works, sometimes not.

Of course, there is not problem with using the join tool to simply make the straights ahead jump that centimetre or three, no one will notice. But what about the other end?

For converging switches, the recommendation I follow is to have a diagonal track across the whole rake and insert curves using "snap to track". If you pick a trackrule that has a somewhat smaller minimum radius, with some practice and patience, you will end up with a row of converging switches in the range of 185 to 195 radius, to approximate 190. However, these switches are of the "usual" type, not rendered as such and marked by a big red rectangle.

So you revert to the crossover method for both ends.

A clever variant is to make sure the parallel lines from the second end cross those from the first one, then you only need to find the place where they perfectly overlap and insert a piece of straight track there, after you cut them back. Less nasty than parallel track, 3 cm apart.

Still, all this is just too much pain in my view.

Poking into the XML
The track layout consists of ribbons which again consist of segments. The difference between a correctly rendered switch with straight frog and on that is not is this: The diverging branch of the switch is formed by a single ribbon, having two segments, first an arc (curved part), and then a straight. The crossover tools creates them that way. In contrast, when you create a curve, followed by a straight, the editor creates two separate ribbons with one segment each (at least when you are near other track or a switch).

Apart from fixing the core game, the solution is this:

• You locate the two ribbons in Tracks.xml (easier in RW thanks to showing part of the ribbon ID in the editor), and in the corresponding file in Track Tiles.
• You cut the cCurveStraight bit from the straight ribbon in the Track Tiles file, delete the now empty hull, and insert the cut out bit after the end of the cCurveArc segment in the curved ribbon.
• In Tracks.xml, you remove the definition of the straight ribbon, noting its length before; then the node which connects the straight ribbon with the curved one.
• Then, you look for the remaining mention of the straight ribbon and replace it by the key of the curved ribbon.
• Then, you add the length of the straight to that of the curve (still in Tracks.xml). Also replace the old length by the new one in the rest of the record, namely for the height and track properties (track rule) information.

Sounds like work, because it is. But at least it has some potential for automatising, which gluing nearly joint track together has not.

Clearing Blocked Flangeways

We all love the crossover tool for creating those lovely frogs where the diverging track is continued through the flangeway of the straight track, looking truly stupid. By chance, I found out that this has to do with the opposing switch. Therefore, decoupling the two switches of the crossover solves the problem.

This is how I do it:

Case 1 - with intermediate straight. In this case there is a single straight between the two curved ribbons of the switches. Select the split tool and click somewhere in the middle of this straight. If only one of the two buffer stops appears, don't panic. Select the weld tool and click on the grey cube that will appear where you split the track. Reload the route to see the result, overcoming the usual track rendering issue. You should see two perfect switches and no buffer stops or track gaps at all.

Case 2 - without intermediate straight. In this case the two curved ribbons directly connect. Using the split tool again, cut off a bit from one of the two ribbons. Be careful not to cut into the guiderails and don't make the bit ridiculously short. 1m is fine. Like above, the result will look like a mess. Just pick the weld tool, click on the one cube showing where you cut, once. Then reload the route and enjoy.

Even tough I applied this method often with success, I urge everyone to keep backups of the Networks folder outside the Steam folders. Keep a series of version, so when you find a problem, you have several steps to go back and retrieve a version where the problem has not yet appeared.

Route Building Do-s and Don't-s

My personal selection of Do-s and Don't-s in route building, all documented elsewhere, just to pass on recent experiences.

Do not create scenarios before track-laying is closed.
Who can resist to run a train on his nearly finished route? And who can resist some fine tuning later, tearing out something here and adding something there? Only problem: If you used something in a scenario, you should not tear it out or RW will issue the maximum penalty, "something bad happened, you will so see your route again".

If this happens -- or better, before -- move all scenarios to a safe place or better don't create them.

Clearly, there are compromises, just create free-roam ones with a starting place that will not change in the life of the route.

Do not believe what you see after deleting track
In particular when you delete pieces of track that formed or might form a junction, RW sometimes, but not all times deletes one more than you selected. Do not place a new piece to close the gap. Exit and reload the route and the missing piece will be back.

Do not expect signals or AI to work after you modified either anything scenario-related, or any signal. Just reload, it is the lesser of two wastes of time.

Do not remove parts of double or single slips.
I remembered that as a valid technology, to create a slip and then remove the crossing pieces, to obtain a regularly shaped curve. Don't do it. RW gets angry about the missing pieces of the slip and you sit debugging Tracks.xml.

Do make backups.
The most critical file in my view is Tracks.bin. Since the above mentioned crisis, I do a simple Ctrl-C, Ctrl-V in the Networks folder of the route I edit, whenever I cycle to "play again" and back, which is what you need to do if you want to know if your route still loads.

Pressing the play button in the world editor does not to the checks that are done on loading. I.e., you can "test" your route, then edit some more, etc., and the next day you find out that a lot of work is lost.

If you click "play again" on the main menu, everything is initialised as if you would have started the game, if you can load your route now, you will be able to do so tomorrow.