Table of Contents
Basic Guide to Sim ConstructionA Sim is constructed by a developer through data population of a number of data files; these modules then feed into core-code which uses the data to compile the sim correctly. Each file can recognise a number of KEYs preset against which data is written. For example the X and Y co-ordinates of a signal, or point, the length of a track circuit, speeds and so on. We have an editor which can ease the process and in some cases automate some of the data entry.
Different developers will have their own techniques for writing a Sim but essentially it comes down to the following in some form or other.
First what you see on the screen; leaving aside points and signals 99% of this comes from the Picture Element file (PEL). PELS can be fixed (e.g. platforms, text, or dynamic e.g. track showing grey, white and red- but it is essentially the same PEL source.
Track Circuits are made up of a Shapes file (SHP) and this sets out what PELs will be ‘live’ for a given route and which points are in the shape and whether Normal or Reverse for a given route. The shapes can vary from a simple straight to a complex junction.
By convention the ends of the shape are labelled from A to Z in a clockwise direction from the 12 O’clock position.
e.g.
Straight will be
B---A
Up left Junction will be
C--\
B---P---A
Where P is the point
A ULC is the sub route along a particular TC in all usable axies; e.g. A straight has a AB and a BA ULC and the Up Left a CA,BA,AB,AC ULC. It can be useful when reporting a bug related to a TC to know what the ULC is.
The track circuit file is made up of ULCs which set out the individual characteristics of each; it is not necessary to define all the ULCs if the reality is not all directions are used (but a set of default data will be generated for unused ULCs so trains can be reversed in the sim under the appropriate circumstances).
The data defines the length, the speeds whether Up or Down direction, whether and where the signals are, gradients, permanent speed restrictions (mainly whether the line speed changes mid way through a ULC), additional train type speed characteristics (e.g. HST or DMU) and whether the train will fall-off the sim at the end of it (e.g. siding or Sim edge).
E.g. T123 has ULC U123AB length 1000m, speed 90(pax), 75(frt), Gradient 1:200 (up) and Signal 567 is 180m from the end of the TC.
Points are either Normal or Reverse and on launch they should all be in the Normal position (which may not be the horizontal orientation). Co-acting points will always move in sync with each other and are normally denoted by the same number but with an A, B and C (or more) suffix. Points can also be interlocked e.g. by flank locking which means one point requires another to be in a specific position before it will move (or moving one will force another to also move if free to do so).
Signals come on 2 types- controlled and automatic, the former can have an automatic mode but is still a controlled signal. Automatics will only be found on plain line and the aspect is normally controlled by the passage of a train and the aspect of the next signal. It is linked to the TCs between it and the next signal and, where separate, the Overlap of the next signal.
Controlled signals will always have a cursor (white element that flashes when you first click on the entrance signal to set a route). All valid routes between two signals will be pre-coded by stringing together the relevant ULCs between it and the next signal. There can be more than one type of route between two signals (Main, Warner, Call-on, Shunt) and which is selected can be automatic depending on the circumstances or may have to be determined by using different exit arrows.
Signals belonging to the next box (Sim) will normally be coded as external automatics, they work exactly the same way as normal automatics except the aspect colour will always display as grey on screen- but will be read correctly by the passing train. For debug purposes these signals may be shown as automatics with an aspect colour, but should be converted later (if I remember).
Flags are mainly internal to the Sim and are just a set of instructions that can be written to ensure something happens in a specific order and to add additional controls. Normally a tester will be unaware of these but for debug purposes a set of PELs maybe created to display the state (1,2,3 etc or ON/OFF). Some flag PELs can be set to respond to right and left clicks and are an integral part of the Sim operation (for example the AB block switches and indicators on NE Scotland or the ACI on/off switches).
TD berths are coded to match the track they are on (normal/open) or as blocks and even black space for use off track. Instructions are written to make the TD stem along with the train. The most common trigger is occupancy of a TC and then additional conditions are written to test which route is set so the TD will step to a required berth. With automatic signals there is no route to test against and generally the TC occupation will suffice. Where it is possible for the trigger to step a TD to be met in other conflicting circumstances additional conditions are necessary to achieve the desired move.
Other TD stepping triggers can be clearing a signal or setting a specific route testing for a ULC being set.
The ENT file contains the data related to entry points, and set out which ULC the train will enter along and any conditions that will prevent or delay entry (e.g. conflicting route). By default an entry point is a KEY location.
As well as being coded to the ‘official’ ULC covering the location it is possible to code any location to any ULC and that enables diverted trains to be ticked off as they pass.
The LOC file contains all the locations, with their name, which ULC they can be found and where appropriate the stopping point within a ULC. If a location is a KEY location then it must be in the PTH file where all the paths between key locations are mapped out. Non key locations can be used anywhere in a timetable, though in the wrong place is not recommended.
The path file contains the map of all linked key locations and at its simplest allows trains to be timetabled from entry to exit by setting out the start LOC / end LOC and the respective Up/Down direction at each.
Eg. ENT1 to LOC1; LOC1 to LOC 2 and LOC3; LOC2 to LOC10, LOC 3 to LOC 8 and 12 and so on. Timetables can only be written if the sequence of key locations is recognised by the PTH file.
With ARS sims it becomes far more complicated as each possible PTH between LOCs needs to be spelt out in fine detail.
It is possible to automatically insert key locations to timetables, primarily used for ARS sims but can be used in others. This is handy where the locations is not a mandatory timing point and saves working out a time. The time is set by applying a factor to the known times at the previous and subsequent location. If there are engineering or pathing allowances in the area the result has been known to be a bit off.
ARS Sims need two things, an ARS sub-area and a detailed PTH as mentioned above.
The sub-area is the visible button that appears on the screen and switches the ARS on and off for its area. Every route is allocated to one or more sub-areas depending on which areas the route passes through. E.g. if the Up and Down lines have separate sub-areas then an Up route will be allocated to one and the Down route the other. However, if there is a route connecting both lines then both sub-areas should be allocated to the route. This is because for safety reasons if you pull the route the ARS needs to be switched off to prevent any conflicting routes being set until the problem is resolved. All routes should be allocated to at least one sub-area for the safety reason but the route itself can be de-allocated from ARS which is when you get the “manual route required message”.
The PTH needs to describe in unique terms how to get form LOC A to LOC B, where this is a single route this is straight forward list of TD berths and signal routes alternately (auto signals are given a dummy route label) ending at the Berth of the end location. For this purpose it is normal to have a location ULC coincide with the berth TC of a signal. There will be no need for any Path, Line or Plat codes to make this work.
It then gets more complicated at a junction
The approach PTH will be as above but there will be two identical PTHs save that each will be coded with the unique departure line codes. The insertion of the line code makes the use mandatory in the timetable which is why you get the can’t find valid route message if you get it wrong.
e.g. ENT to LOC1 Line=UM. and ENT to LOC1 Line=UF.
It is possible to have a third PTH with no Line code at all which will be the default if you don’t specify a value. Insertion of the correct Line code in many cases is automated in some circumstances.
Once you have got to LOC1 the next PTH follows on starting with the Berth of the previous PTH- as you will see that then means the PTH has a common starting point so those PTHs will also be coded with the relevant Line code to maintain the continuity.
Both PTHs will end at the same location but on different ULCs so the PTH needs to be identified by use of the path identifier. Reversing the above example.
LOCA to LOC1 path = DM and LOCB to LOC1 path = DS
Here there will need to be 2 onward PTHs one from each path approaching LOC1.
Again this will force the use of a path code in the timetable and again it is possible to have a default PTH with no path requirement.
In more complex locations you can have a PTHs with various combinations of line and path codes as well as platform numbers making each PTH unique- the important thing is that there is a continuous trail of paths, lines and platforms coded in to the PTH.
Last edited by Edgemaster on 03/07/2019 at 18:55