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.

How to signal a route

After bugging various people on various occasions with various subsets of the stuff below, I brought it all in one place, hopefully.

Basically, you need an idea of (1) how it is done in the prototype, (2) how RW treats signalling, and (3) where the major pitfalls are.

High level

Blocks should be of similar size. Calculate the maximum occupation time and communicate it to scenario authors. This is calculated as the distance from the signal at the start to the furthest remote link (the ones with the number on the arrow) of the signal at the end plus the maximum train length, all that divided by the usual travel speed in this block. Minimal intervals for scheduled trains should be a few minutes more than this figure, at least.

At portals, extend the branch by a few miles of plain track and place proper block signals (about two per direction). This will greatly help scenario authors debug their scenarios in case of congestions.

Make the speed limit which is set as a track property (and in the track rule) somewhat consistent with the signal distance. See here (and Mark's pointer to his handy measuring tool a few posts down) for more on the topic.

Don't worry too much about the finer details, just try a full brake application (not emergency brake) at maximum speed in a few places with a selection of trains and note the braking distance. Then add some 30% or 50% and people will love you. The important thing is fundamental awareness of the issue to avoid player frustration.

Be sure to have some space between the signal and the next switch. Rules vary widely (two quick figures: 6m - 200m), but basically, the signal is meant to keep trains from running into switches which are not set for them and/or collide with trains there, and this means that the train must safely halt before such points, and safety margin is a good thing to have. At the same time, many station layouts simply don't allow for big margins, compromise like they do in the prototype. And remember that the length of the safety margin should fit the speed of the train, in principle.

Medium level

The track network must be spanned by complete networks of signals for each possible direction of travel. This means that every remote link (with a number on the arrow) must point to a link 0 of another signal without a switch in between. For single link signals, the unnumbered link 0 must point to the next link 0, again without a switch in between.

There should be no occasion to drop off wagons within the links of a junction signal, i.e., don't place your remote links deliberately far.

With the default signals, you must keep the shunting in "yard areas". These are reached via "yard links" and left via dedicated "yard exit" signals. Yard links are the last links of signals having 1E or 2E in the name (and you guessed it: 1E signals have 1 such link and 2E signals have 2).

Be sure to have each and every track in every station marked, be it platform, siding, destination. Also those that you find irrelevant, other may not. Granted, there are scenario-based markers, but how are you going to communicate about the trackwork without a reference name.

I also suggest placing a destination marker on each route track near the station, it may help the scenario author to make his orders very clear if the dispatcher needs it.

Low level

Be sure to have the remote links beyond the curved part of any switch. Look at the ribbon frame, not the blades. The logical "node" of the switch in the abstract track network is where the curved ribbon meets the straight track pieces.

Be sure to have the remote links before any further signal. They need to send information in the direction of the arc, so if link 0 of the next signal is behind them, you cannot expext things to work.

Any AWS & TPWS goes before link 0, i.e., on the side of the arriving train. The arrow of these objects must point to link 0 of the signal to which they refer.

Be sure to pick the right signal. Refer to Mark Brinton's guides and/or the Wiki for details, they do not fit in any blog post. As a general rule, link 0 goes next the signal post, link 1 goes beyond the switches in the "most important" track, link 2 and following go to lesser tracks. If you have 4 tracks beyond a junction, you need a signal with 4T in the name.

When you place a signal shape, you need to rotate it by dragging the mouse to the side until the orientation roughly fits. If you get this wrong, just delete the signal. You can rotate it and then click on the links hoping for them to switch directions, but it is safer to redo this one signal.

References

Mark Brinton's guide, part 1 and part 2

The RW Wiki (unfortunately still lacking the illustrations as of this writing):
Signal Asset Glossary
Setting Up and Using Signals

Keep the last track piece clear

KRS had the following problem: If you put an engine on the last piece of a terminal track, you hit a bug in the code which does nothing but issuing a complaint in LogMate that it "cannot back propagate". However, this consumed time and if you happened to trigger this for a lot of track pieces, you ran into serious trouble.

Will not happen, you say, but you forgot about turntables. They have a large number of short tracks leading from them, typically just single straight pieces, and many of them hold an engine. Turntables had a reputation for creating weird problems. Adding a (really) short piece of track at each track end cured the problem, as far as I remember the feedback from people.

Now in RW, this error seems to have mutated to a fatal scenario loading error, where the game talks about "Invalid Constist Error". I looks like RSC wanted to rule out the above bug by forbidding the placement of trains on the critical track piece. But this last piece can be really long, if the route builder does not know about the issue.

The workaround for the time being is that all route builders split and reweld the last piece of track near the buffers, or add a foot of track there. That way, no one can place anything in the critical place and it does not matter if the bug currently leads to slow game performance, crashes, or refusal to load a scenario.

Child elements

Not everyone knows that any object in RW can have an unlimited number of child objects. These are simply other objects (more specifically, blueprints from a restricted subset of all the available ones).

Uses include:

• Signal panels attached to a post (which acts as the main element, but it could be the other way around just as well).
• Plates and other supplements attached to rolling stock (or station buildings).
• Freight items (called FreightAnim in MSTS)
• Lamps (tail lamps, head lamps)
  
• Sounds
• People (staff, passengers)
• Editor-only objects to show information or a bounding box to the routebuilder without disturbing the appearance in the game. Thanks Rail Similarity.
  

There are four ways to attach a child to a parent.

1. The official way. You have the source of both parent and child. You start the Asset Editor to show the parent and interactively position the child with the mouse.
2. The hacker version of (1). You add the reference to the child by editing the XML file which is the blueprint. This saves you the hassle of using the Asset Editor and often you will know the exact location from your documentation on the model (or by clicking on some vertex in the model in your 3D modelling programme). As long as you do not want rotation, this method can save time and nerves. See here for details.
3. The unofficial way. You do not own the sources of parent and child and still want to combine them, which is perfectly reasonable in a wide range of cases from the above list. You convert the BIN file of the parent to XML and add the reference there. Don't forget to convert the XML file back to BIN. See here for details.
4. You use RW Tools to do (3) in a user-friendly way.