Sometimes you have a .GeoPcDx file and you want to write a script for it. If you deal with default signals, your starting point will be the default scripts. But there is also the following method.
You copy the .GeoPcDx to a safe place outside the RW folder hierarchy.
Append .bin to the extension.
Apply serz.exe to it, creating a file with .GeoPcDx.xml at the end.
View it using Notepad or any other editor.
Search for transformname, you will see something like this:
<transformname>
<e type="cDeltaString">Mod_hd_3asp</e>
<e type="cDeltaString">Mod_hd3_Red</e>
<e type="cDeltaString">Mod_hd3_green</e>
<e type="cDeltaString">Mod_hd3_orange</e>
</transformname>
Clearly, you need to use you imagination to guess what is what, and clearly, it is not such a challenge.
You can use RW-Tools for the conversion, I believe.
In the above example,
Call ( "ActivateNode", "Mod_hd3_Red", 0)
will switch off the red light.
Cloning a signal
Since this gets asked so often, here is my base recipe to signal adaptation. The basic idea is to make a copy of a signal, and of the associated Lua script, so you are free to modify it without influencing default content.
Major uses are modifications of aspects, adding links, adding yard entries, changing the way a signal clears for the train, etc. etc.
Be sure to put a backup of the files in a safe place. Since your copy still lives in the Kuju folder, it may or may not look like default stuff to Steam and get lost on some update in the future.
You can as well transfer the copies into another folder, under your Provider and Product name, but you need to take care about changing the references in the .bin file. Basically, this is just the path part of the script name. It is not hard to do, but make this changes only after you established that the basic cloning process worked well.
Major uses are modifications of aspects, adding links, adding yard entries, changing the way a signal clears for the train, etc. etc.
- Locate a signal that comes close to what you want.
- Find the .bin file under Assets\Kuju\RailSimulator\RailNetwork\signals.
- Make a copy of this file and give it a meaningful name, e.g., by appending "new" to the name.
- Open it in RW-Tools or apply serz.exe to convert it to .xml.
- Append "new" or similar to all the names in the various languages.
- Find <_script> a bit down the file. The second line after that contains the name of the Lua script which needs to be duplicated, too. Note the name, then append "new" or similar. In case the name has an extension (.lua), you need to insert the "new" before that, of course.
- Save and close the file. If you used serz.exe before, you use it on the .xml now to create the corresponding .bin.
- Find the Lua file referenced above and duplicate it. Append "new" or whatever you appended in the .bin file, to make the file name look exactly like it is in the .bin file.
- Open the Lua file and edit it in which ever way you wish. This strongly depends on what you want and can be any of a dozen small modifications, to be discussed separately.
- Save and close the Lua file.
- Start RW. You should find the "new" version next to the original.
Be sure to put a backup of the files in a safe place. Since your copy still lives in the Kuju folder, it may or may not look like default stuff to Steam and get lost on some update in the future.
You can as well transfer the copies into another folder, under your Provider and Product name, but you need to take care about changing the references in the .bin file. Basically, this is just the path part of the script name. It is not hard to do, but make this changes only after you established that the basic cloning process worked well.
Quick guide to your first signal
I recently beat up a terse (by my standards) guide to getting a simple signal into RW, which now has been validated.
http://forums.uktrainsim.com/viewtopic.php?f=309&t=104090
I link to the forum so you have the context and understand the example. Clearly, the recipe works for many light configurations. The only thing your signal must have is 3 aspects: "stop", "expect stop at next signa"l and "clear here and no stop at next signal".
The thread also contains some discussion on the graphical aspects, including the light glow. Discussion on that is still going on as I write this, but scripting issues are all settled.
http://forums.uktrainsim.com/viewtopic.php?f=309&t=104090
I link to the forum so you have the context and understand the example. Clearly, the recipe works for many light configurations. The only thing your signal must have is 3 aspects: "stop", "expect stop at next signa"l and "clear here and no stop at next signal".
The thread also contains some discussion on the graphical aspects, including the light glow. Discussion on that is still going on as I write this, but scripting issues are all settled.
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.
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:
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)