Select Page

Some questions we get more than others, so much, in fact that we have created this FAQ to answer them all.

If your answer isn’t here, feel free to contact us on either Discord or via the Contact form.

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 select right-hand signals for non-UK railways?

This was only recently suggested and does seem do-able. All graphics are stored in a file called ‘Borland.res’ on the GitHub source code page, and can be examined using a resource editor such as Resource Hacker I’ll have a think about it for the future but… no promises!

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.

Pin It on Pinterest

Share This