Getting rid of derailment view

If you give Railworks to a young person, there is some chance that the cool animations of the funny flying wagons catch the attention of the recipient a bit too much. This is how you spoil the fun.

In Assets\Kuju\RailSimulatorCore\Cameras delete DerailmentCamera001.bin (or move it to some backup). Make a copy of TrackSideCamera001.bin and name the copy DerailmentCamera001.bin.

Remove write protection and edit it (using RW Tools). Change the lines for Near/Far Camera Offset to this:

700.0000
750.0000

For each of the two lines, you make two changes:
a) increase the number from 70 to 700 or whatever you like.
b) delete d:alt_encoding="...."

Without part (b), part (a) is useless.

May well be that only the NearCameraOffset is relevant and the FarCameraOffset is irrelevant, or vice versa, I did not try it out.

In addition, I set StepAhead to 1000.0000, but I guess that this was irrelevant.

Restart the game (from Windows, clicking "play again" is not sufficient to reload the modified files) and run some train across a suitable track end. Be sure to attain some speed because RW kindly stops your train without error message if you are really slow.

You will still see the derailing train for the same duration, but the perspective is pretty boring. Increase the distance if you think the view is still too interesting.

Since you will turn off updates anyway for this installation (to save yourself from some of the phone calls), there is no risk of undesired restoration of the original camera settings.

Like all such "adult saves child from the bad by hacking his computer", this hack does not spoil the fun for a well informed young person. But it will distract the true novice from this fun for a while. And after a while, doing something useful with railways should have become more interesting than crashing trains, our you lost your case anyway.

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.

Thoughts on route merging

Since it has resurfaced recently, these are my thougths on route merging in a nutshell: Basically, plan first instead of being sorry later, it is actually pretty easy, as you will see.

If you create a few route fragments just yourself, and there is a remote chance that they ever get merged, simply make one route blueprint, with one route origin, and use that for all your projects.

As long as you don't go 100 miles east or west from the origin, any projection issues do not really become an issue and even then I bet you won't notice too much, unless you compare your route to different precise sources. Therefore, I bet that the main station in your favourite town makes a fine route origin for all you projects. Or any point in that town, or anywhere else in the region. The important thing is only that you don't start a second route with any other origin, unless it is in another country.

This origin defines nothing more than the location of your tile 0/0. You need not even populate it, and you can move the scenario marker of the freeroam scenario where you want. So, really, just get along with your personal standard origin.

Merging two routes of yours will bring along quite some problems, but at least the tiles will fit together.

If you are serious about considering a merge, you will have used the same track rule in all candidates, or close derivations thereof.


If you are considering a team project, you need to discuss a lot anyway, our you will not reach your target for sure. One of the many things is the route origin, the track rule, and who becomes master of trackwork. In theory, it is possible to merge different tracks.bin files. But there is risk associated to it. Any you need to understand the details of the XML structure.

Even more important, I believe that trackwork developed by different people will look different and going over it later will show the difference. Also for the signalling, if there is no one with a master plan how to signal the route, and if this same person does not check each signal location for himself (read: do it himself in practice), then scenario authors and/or drivers will be ungrateful later. So, while it might be tempting to lay the track together with the scenery, I feel that this is one of the many occasions where as a serious route developer you must not let the cosy toy feeling of the World Editor carry you away.


Further reading: A thread at UKTS, over a year old but still current, containing one of Adam's best posts.