Why are named location lengths always 100m?
This represents a compromise between simulation and reality. In the simulator, trains are always two track elements long, this being the length needed to display the four-character headcode.
Track element lengths can be set anywhere from 20m to 999km, implying a train length of between 40m and 1999km. Long implied train lengths out on the track don’t matter too much provided that there is enough track to accommodate the number of trains using it, and if there isn’t then the relevant track element lengths can be shortened appropriately. Named locations in my view need to reflect reality more closely. A track element can be several km long but a platform can’t if it is to retain any resemblance to reality.
The choice of 100m per element is itself a compromise, in that it is long enough for a five coach train, with two elements enough to hold a ten coach train and also a simulated train without any overlap. Where it falls down is when platforms need to be long enough for several simulated trains, as is the case at major stations, when the overall length can be quite a bit longer than reality.
Shunt signals aren't flexible enough.
When the game was first published there were only four-aspect signals, which was a bit limiting so at one of the updates I added the others, which I was pleased to find was easier than I had expected. But there remains a problem with shunt signals, in that they are implemented as normal two-aspect signals but with different graphics, so they behave in all respects as normal signals.
This is a real limitation I know, so sadly it isn’t possible to simulate all shunt signal behaviour, which would require a lot more programming. Sorry about that. Maybe one day…
Why are there compatibility issues?
Search me – they are a real pain! Compatibility didn’t seem to be a problem in the early days, at least no-one reported any problems to me.
When Windows 8, then 8.1 and now 10 came along it all started. Colour compatibility was the first effect, when the box for track and train information was found to have a transparent background, so text couldn’t be read. I assumed that this was due to the program being compiled on Windows 7 and run on later operating systems, but recently I tried compiling it on Windows 10 on my laptop and guess what? It worked fine on Windows 7 but had exactly the same transparency issue on Windows 10! That I don’t understand at all.
A program compiled on a particular operating system should work properly on that operating system, but not in this case. Other issues that have come to light include frequent flashing, and incorrect behaviour with high DPI settings (discovered and cured by Mark Jones – thanks Mark). The latest release – v2.2.0 – cured the colour problem on my Windows 10 laptop, so I hoped it would cure it for all Windows 10 computers, but I think I was overoptimistic.
I fear that the different settings that can be applied when running an operating system can change the behaviour of applications in unexpected ways. I guess all anyone can do when faced with incompatibilities is to experiment with different compatibility settings in the hope of finding one that works. It isn’t satisfactory and it annoys me no end, but how an operating system interacts with a program is very largely outside the programmer’s hands, sadly.
Why can't we have three-way points & slip junctions etc?
I agree these would improve the appearance of a railway but would require the underlying basis of the program to be changed. Each track element has up to eight links: two vertical, two horizontal, and two each for the two diagonals, and can allow up to two routes across it – for points, crossovers and bridges.
To implement the above features would mean increasing the number of routes, which would change so many aspects of the program that it would represent a major rewrite. It isn’t just that the definition of an element would need to be changed, which would be relatively simple, it’s that very many functions operate on the basis that no more than two routes are possible, so all such functions would need to be changed, and testing that all circumstances had been properly accounted for would be all but impossible with any confidence.
The good news is that anything that the above features can achieve can be achieved with the elements provided, though I have to admit that they don’t look as good.
Why does the program pause when a user switches to another application?
This was added because it was found that the program froze on reactivation under some circumstances, including routes being set and points changing, and odd things could happen to the timetable clock.
Forcing a controlled pause on deactivation was felt to be the best way to avoid these situations. Besides what signaller wants to abandon his or her post in the middle of an operating session? Come on now – own up – you’re fired!
Why can't the timetable be edited during operation?
When the user clicks ‘Load Timetable’ the whole thing is loaded into memory, not as it is written but as a set of machine-readable instructions for every train. It is checked for validity at the same time and if there are errors then it won’t load. On-the-fly editing is therefore not possible.
I don’t think it would be a good idea anyway because changes would need to be validated and errors reported before they became operational, which is a different task to operating the railway and in my view one best done separately.
Changes to train movements can be made during operation of course by invoking signaller control.
Why can't we have random signal and train failures and automatic route setting?
These are a couple of additions that I foresaw as useful for the flood of new programmers to develop when they descended on the source code, eager to make their mark and make the program fly.
We’re all still waiting sadly, so in the meantime you’re stuck with me – a lazy old excuse for a software developer, and getting lazier and older every day that passes. I do a bit now and then as the fancy takes me so please keep the ideas coming.
I don’t promise anything but I do consider all ideas, and any that are (or seem) reasonable I try to program in next time the programming bug bites me, which it does from time to time. I do promise however to give any bugs my closest and early attention.
Why won't my timetable validate?
There are so many reasons for this that a separate help document has been prepared. Download ‘Timetable Error Messages.pdf’ under the ‘Download’ tab.
Why can't I set up routes and then load a timetable?
A saved railway file doesn’t store routes, and a session file stores routes and the timetable that was loaded when the file was created. Therefore it isn’t possible within the program to edit or create a timetable when routes are already set. This isn’t normally a problem for small and medium sized railways because automatic signal routes can be set fairly quickly after a new or revised timetable has been loaded. It can be a problem however with big railways, when it can take a long time to set automatic signal routes. Having to wait for these to set each time a timetable is modified is therefore quite time consuming. To work around the problem there is a way to store the track and routes directly from a session file, and load these into a new session file created with a modified timetable. The document that describes this procedure can be found under the ‘Download’ tab and is called ‘Changing a timetable in a session file whilst retaining routes.pdf’.