This release makes one minor improvement and fixes three relatively minor bugs.

Improvement:

When timetabling the add and subtract minutes (‘Add mins’ & ‘Sub mins’) features required the timetable to be saved before they could be applied. This was never really necessary so the requirement has been dropped. Minutes can now be added or subtracted provided that the current entry contains at least one time and the minutes box contains a number. The reason for the earlier restriction was that many features do require the timetable to be saved, and this was just lumped in with the others without my giving it much thought. It was a nuisance having to save the timetable every time before adding or subtracting minutes, and this modification should make timetabling a bit easier.

Bugs fixed:

1. The reminder message for events that included both arrivals and departures stated that notifications would be given at both the arrival time and departure time, whereas only a single notification is given at the arrival time. The message has now been corrected.

2. When a train was selected to terminate early and become a follow-on service, all later location passes were listed as departures in the floating information window. These are now listed correctly. Thanks are due to Albie Vowles for notifying me of this by email.

3. When a shuttle train was selected to terminate early and become a follow-on service, the follow-on headcode was given as the first service headcode, rather than the repeat headcode as it should have been. The correct headcode is now given.

The main change in this release is something that I hope won’t be noticed at all – compilation using version 11.3 of C++Builder. Although this shouldn’t cause any changes I did see one peculiarity – the actions due and performance panels displayed slightly smaller than before. I don’t know why that happened but I could easily compensate by increasing their size. I hope that’s the only difference but please be on the lookout for any differences, especially in the display, and let me know if you find any – thanks.

Stephen Smith suggested retaining the existing loaded railway when a user starts to load another railway but thinks better of it and cancels the load, rather than clearing the existing railway as before this release. Not only did he suggest this but offered the code change as well – which I was happy to incorporate – how good is that! I only wish that happened more often!

I discovered an error in the timetable editor when changing the order of a timetable to alphabetical or time order. The ‘Validate timetable’ button was available after changing the order, but instead of validating the revised order it validated the original order. The reason was that the timetable is stored in two forms: the original .ttb file, and an array of entries that is used internally by the program. When the order is changed only the array changes, not the .ttb file, but when ‘Validate timetable’ is clicked it validates the .ttb file, not the array. In most cases this wouldn’t matter, but in some cases it could, and a misleading result would be given. Now that button is unavailable until the timetable is saved, which saves the array as a .ttb file (and warns the user that the change will be permanent).

A small change was made in skipping timetabled events. I added a message that nothing will be skipped after the departure if the next event is selected (nothing was skipped earlier but no message was given). This was because of a query on discord (ticket 36).

This version corrects a couple of issues relating to performance logging for zero powered rolling stock and trains prevented from departing due to another train in front. Earlier versions gave a ‘departed at’ log message when the timetabled departure time was reached which was inappropriate in these circumstances. In this version the message states that the train is unable to depart for whichever reason applies, and also gives a warning log to draw the users attention to the fact that the train can’t comply with the timetable. Thanks are due to JasonB for notifying me of this.

The timetable editor has also been updated to include train split distribution information for ‘fstp’ and ‘rsp’ commands.

New and changed features:

This version adds the ability to set timetabled event reminders for any train under timetable control. It was suggested indirectly by Flyin9 Scotsman and is such a useful feature that I don’t know why it didn’t occur to me before. It works in the same way as timetabled and automatic warnings in that the event is repeated at the top of the display in the scrolling warning log and also in the performance log, and these are now accompanied by three short beeps to draw attention to the reminder/warning if sound is turned on. The warning log has also been made more prominent in that the current warning is in bold red text, whereas earmier warnings are shown in regular blue text.

***Please note that sessions that have reminders and are saved in this version will fail to load in earlier program versions.***

The ‘actions due’ panel behaviour has been modified to avoid the annoying rapid switching of trains in the list. This was due to frequent updating of the list where times to act were recalculated and often changed order because the calculations weren’t precise. This was frustrating when clicking on a particular train, only to find that an update had changed the list and the wrong train was clicked. Now the regular updates are much less frequent, but are immediate when a new route has been set or cancelled, so there is no delay for events that have a direct effect on the times. It is still possible for an update to change the list order but it should be very much less noticeable.

All timetable restrictions apart from movement for unpowered rolling stock have now been removed, e.g. direction changes, splits, description changes, change of service etc. These were only in place (I think) because it didn’t seem appropriate to allow such events, but on further thought I don’t think that’s a good reason. I can’t recall any more serious reason and hope there wasn’t one, none has come to light during testing anyway.

Bugs found:

There was an error in the ‘skip timetabled events’ function where the last event was sometimes left off the list, this now works properly.

Bugs have been corrected in both train split functions where an error could be triggered inappropriately after the split had taken place.

New features:

This version allows non-station named elements to be placed on points, crossovers and diagonals. It has been a lot more difficult to develop than expected, largely because of train splits that now have to allow for trains on more complex elements than previously. Because of this a number of functions have had to be rewritten.

***Please note that railways and sessions that have named points/crossovers/diagonals and are saved in this version will fail to load in earlier versions.***

A ‘Time Order’ button has been added to the timetable editor which lists services in order of train starting times.

Performance improvement:

Failed train coasting behaviour has been made more realistic after Albie V found noticeable inconsistencies when a train coasted on very long track elements.

Some existing bugs have also been found as follows:

The route search function failed if a very long route tried to extend across both tracks on points or a crossover. It’s a fault that occurs when a path attempts to double back on itself which in practice will only happen if a railway has very convoluted paths between a starting point and a finishing point. It has been corrected by an internal check for this situation.

The recent variable mass and power split when train splitting failed to show up in the performance log when the split was 50-50. It was present in the floating information window and has now been included in the logs.

It was found that the background colour wasn’t always set correctly when a train was prevented from moving by the presence of another train immediately in front. This has now been corrected.

The floating train information window didn’t always give the correct headcode for follow-on services – now corrected.

New feature:

A new ‘Expand repeats’ button has been provided in the timetable editor – enabled when a repeating service is selected. It expands the service into separate equivalent services. For example a service that repeats every 30 minutes with 2 digits increase per repeat and 8 repeats in all can be expanded into 9 separate services at 30 minute intervals, consisting of the original service and 8 repeats. In addition every service that links to the repeat – splits, joins and new services – will also expand similarly.

This can be very useful when developing timetables that have similar services but with different stopping patterns, uneven headcodes or timings. This is usually the case with real timetables. A repeat service is created first from the first such service in the real timetable, then expanded, and each separate service edited to correspond with later services in the real timetable. This is normally a much faster process than repeated copying and pasting, especially if there are several linked services.

It has been provided in recognition of the missing documentation for the utility ‘json2ttb’, which was able to create multiple services in a similar manner but the earlier links to its documentation are now broken, so although it is still provided new users are very unlikely to be able to use it without documentation.

Bugs and behavioural changes:

Further testing revealed a number of bugs in v2.16.1 and earlier which have been corrected in this version.

When loading an old session file trains lost their descriptions, these have now been re-instated.

After loading an old session file and resaving as a new session, the program entered an infinite loop on reloading. This was traced to an error in saved train description data that has now been corrected.

A couple of signal sequencing errors were found (a) following a forced route cancellation and (b) after reloading a session that was saved while signals on a continuation route were in course of updating after a train had exited. The faults were inadequacies in the signal sequencing functions that had been patched a number of times to cater for earlier new features. All these functions have now been re-written to get rid of the existing patches and (hopefully) to avoid the need for further patching.

An error in the location name edit function when using extended characters has been corrected.

Minor improvement – In the timetable editor the timetable name has been moved more to the left to avoid overlapping the existing ‘single entry’ text.

This is a bug-fix version that corrects bugs found in earlier versions.

Kaelon noticed that a train that has its description changed during operation also caused service repeats to begin with the same changed description. This was not intended but I had overlooked it during development. This was corrected but the correction led to a significant number of other bugs relating to description changes found by both Kaelon and me during later testing. What I had thought would be a fairly simple modification (to allow descriptions to be changed) turned out to be extremely complicated. I just hope that all associated bugs have now been found and corrected. Thanks to Kaelon for reporting the issues.

When testing Commuterpop’s new Generic Metro System it was noticed that an incorrect error message was sometimes given in setting a route, the message being ‘Must select a valid signal…’ when the selected signal was in fact valid for the intended route. The correct message should have been the long ‘can’t find it’ message. It was caused by the search function searching along a looping route that found the correct signal element but because of the loop the signal was facing the wrong way for that route. This has been corrected to give the right message.

NOTE: Session files and timetables saved in this program version will not load successfully in earlier program versions if there are any train description changes.

The new feature in this version is the ability to use extended characters in location names. This will be useful for non-uk railways where some location name characters have special marks such as accents, umlauts, cedillas and so on. Additionally the restriction on starting a location name with a number has now been lifted. The only restriction now is that a name can’t begin with ‘digit-digit-colon’ because when the timetable validator sees that it is assumed to be the beginning of a time entry.

Note that a railway that uses extended characters can only be loaded into this version, the load will fail for any earlier version as extended characters won’t be recognised.

A bug in the earlier version was found by Cameron whereby attempting to save a blank timetable entry caused a crash in certain circumstances. This was quite an easy fix and won’t (shouldn’t!) happen again. Thanks are due to Cameron for reporting this fault.

This is largely a bug fix version: the only behavioural change is an improvement in the warnings given when using timetable alphabetical mode. These make it much less likely that an alphabetical timetable will overwrite a non-alphabetical version in error.

Bugs fixed:

On-screen help was hidden behind the main screen, it now displays in front as it should. No-one complained about this so it must not be used very often.

Gap graphics persisted after flashing during build and operation, now corrected.

It was possible to have multiple “Must select valid signal…” messages during route searches in some circumstances. The reason was traced to a particular feature of the search function which has now been amended to ensure that the message is only displayed once.

It was found that when truncating a route that leads to buffers or continuation, the signal in a linked rear route didn’t change to red as it should. This was a bug introduced in v2.15.0 that has now been corrected.

When testing a new railway (Crewe) it was found that trains waiting to enter at a continuation could crash even though the route was protected by a signal if an earlier train was removed under signaller control. This was traced to an error in the removal function and has now been corrected.

Please be on the lookout for errors and unexpected behaviour in this release as there have been many significant program changes, particularly in the timetable functions. I have tested them extensively but it is impossible to test exhaustively, so there may well be new bugs lurking in the undergrowth. Please send me any error files that are generated and let me know of any oddities during use, and I’ll try to make corrections as soon as possible – thanks.

New features:

1. Perhaps the main upgrade here is the addition of a 64 bit Windows version (thanks are due to Krizar here as I hadn’t realised the free Embarcadero compiler was capable of 64 bit compilation). This will (or should) work exactly the same as the existing 32 bit version but if your computer runs 64 bit Windows then you should use the 64 bit version. The 32 bit version should only be used if your Windows version is 32 bits but Windows computers shipped over the last several years have 64 bit Windows. To find out look at this article: https://support.microsoft.com/en-us/windows/32-bit-and-64-bit-windows-frequently-asked-questions-c6ca9541-8dce-4d48-0415-94a3faa2e13d

The 64 bit version will be more future-proof as 32 bit programs are now regarded as legacy software, and although as far as I know there is no intention yet to stop supoporting them that time will come eventually.

In order to avoid ambiguity the program names have been changed from railway.exe to RailOS32.exe and RailOS64.exe. Each release package also comes with a number of .dll and .bpl files, and although some of them have the same names in each release they are different files so please do not get them mixed up or the program won’t work.

Additionally the 64 bit version should be more compatible with non-Windows operating systems. MAC computers in particular have dropped support for 32 bit programs in their later operating systems.

2. Routes can now be truncated from the start as well as from the end. After left clicking the ‘Cancel or truncate a route’ button right click the track element immediately in advance of a facing signal and it will truncate from the start. Also when an automatic signal (blue) route is truncated or cancelled the signals at each end now attach to any existing route that precedes or follows it.

3. The timetable editor now includes the ability to invert a timetable entry to make construction of return journeys easier (this was added at v2.14.0 Supplement 1).

4. The timetable editor now allows more options for new services ‘Sns’ and ‘Sfs’. These can be followed immediately by ‘Fjo’ – finish and join another service, and ‘Frh’ – finish and remain here. These options make it easier to simulate drop off and pick up of wagons and empty coaching stock. Note that these changes can only be used with program versions from 2.15.0.

5. The timetable now includes the ability to change a service description when stopped at a location. A new command ‘dsc’ is available, e.g. 13:25;dsc;Birmingham Snow Hill to London Marylebone. Again this new addition can only be used with program versions from 2.15.0.

6. The floating train information window now includes speeds in mph as well as km/h.

7. Split trains can now vary the mass and power distribution as a fourth element in the split event in the timetable – e.g. 09:25;rsp;2F25;20-30. In this case the mass of the train that splits off will have 20% of the train mass, and 30% of the train power prior to the split. Mass can vary between 1% and 99%, and power between 0% and 100%. If there is no fourth element then the split is 50% for both mass and power as before. Note that these percentages relate to the current mass and power of the train, not its original mass and power.

8. The ability to stop the left hand side warning icons from flashing has been added by a new button below the icons that toggles the flash function.

Bugs and behavioural changes:

1. After a discussion on Discord about brake rates on 23 & 24/01/23 I realised that halving the brake rate for each train after a split was wrong. The brake rate should stay the same so the performance stays the same. To correct that the brake force for each train is now halved, as are power and mass.

2. A bug was corrected as a result of an error reported by BWJM on 10/02/23 where there were two linked continuations with no signal between and trains entering and leaving every minute. The error occurred when the program tried to calculate the delay times to reset the signal immediately before the continuation first to double yellow, then yellow and then green. In this case the program couldn’t find a signal so it threw an error. It was easily fixed – there was no need for an error at all – if it can’t find a signal then it just breaks out of the calculation. Thanks to BWJM for reporting this error.

3. Another bug was uncovered by BWJM, reported on 18/02/23, where a train that was joined at a later time by some empty wagons (represented as a train with no power) had its maximum speed set immediately to the empty wagons’ maximum speed. This was a silly error on my part. When the timetable was first compiled internally and Fjos and jbos were married together, the speed of the jbo train was set to the Fjo train’s speed if it was lower than the jbo’s train. I can only explain it by assuming I had overlooked the fact that this should only occur when the join took place, not when the timetable was compiled. In fact the speeds are set properly anyway when the join takes place so that part wasn’t in error. The fix couldn’t have been easier – I just deleted the speed change. Thanks again to BWJM for reporting this error.

4. FinsburyPark reported an error on 15/03/23, in that when a session with failed points and TSRs was stopped the 10km/h speed limits remained. This was an oversight on my part – I had removed the failure graphic but forgot to reset the speed limit. This has now been corrected. Thanks to FinsburyPark for reporting this error.

This release adds several new features and corrects a number of bugs and inappropriate behaviours as follows:

Main new features:

Delays and failures have been separated so that there are two tabs available during operation, each with none, minor, moderate and major settings. There are now sixteen possible combinations rather than four, so the settings have been saved in session files rather than having to be reset if required after a session reload.

A number of users have asked for a means to cut out a single segment of an automatic signals (blue) route, to allow infrequent use of a crossover or diverging route without affecting the rest of the route. While this would make operation easier it would be very difficult to implement because of the way routes are handled within the program. However, to help with such situations there are now two half buttons for blue routes like there already are for the green route buttons. Therefore a blue route that is cancelled to allow an infrequent train movement can easily be restored quickly afterwards without having to recreate it signal to signal as before. In fact this change was requested by Andrekoener last year, and I was reluctant to include it on the basis that blue routes shouldn’t be changed once they are set. Although I still think that, it doesn’t seem fair to try to force that rule on users that don’t want it, so hopefully this should make life a bit easier for those users – and I have to admit for me too sometimes! An associated change has been made to the shortcut keys. Whereas before ‘4’ selected the bottom green route button it now selects the bottom blue route button, with ‘5’ selecting the bottom green route button. This provides a more logical layout.

Ground signals now work more like they do on real railways, at least in the UK. Formerly a facing ground signal in a route between two four-aspect running (i.e. non-ground) signals would cause the signal behind the ground signal to skip an aspect. For example, a signal at red at the end of a route with no trains, followed in rear by a ground signal would cause the next running signal in rear to show a double yellow aspect, whereas correct practice (at least on UK railways) is to ignore ground signals in setting aspects of running signals, though the ground signals themselves still clear. So, with the example above the running signal in rear of the ground signal would show a single yellow aspect, and the next running signal in rear of that (regardless of how many facing ground signals there are in between) would show a double yellow aspect and the next to show a green aspect.

Automatic signals (blue) routes can now be pre-set through facing ground signals and can begin at a ground signal if other conditions are met. Formerly ground signals prevented blue routes from being pre-set, though they could be manually set if required. If there was a good reason for that limitation I’ve forgotten what it was, and suspect it was just a SLAGIDATT – seemed like a good idea at the time!

Session files have also been amended in light of ground signal route changes. If a session file saved by an earlier version program is loaded into this version, existing routes are recreated in line with new ground signal behaviour. If a session file saved by this version is loaded into an earlier program version then on loading the routes will comply with new ground signal behaviour, though subsequent train movements will cause them to revert to the earlier form.

Bug fixes and behavioural improvements:

An error occurred in a Windows .dll file during timetable load that couldn’t be reproduced and failed to occur subsequently with the same railway and timetable. It appeared to be a temporary glitch but to avoid crashes in future a message is now given instead that the timetable failed to load. Thanks to Albie Vowles for reporting this.

Micke reported a situation where a train created without power included a ‘jbo’ command but could not join at the appropriate time as only an ‘Fjo’ command permits a join for an unpowered train. The fault here was that the timetable validatation allowed this command when it shouldn’t have done. This version corrects the fault. Thanks to Micke for reporting it.

After finishing a running session it was found that temporary speed restrictions (TSRs) remained on the railway. These should have been cleared when operation stopped and now do so in this version.

It was found that when a session was saved just after a train had been called on but before it moved, it caused a SPAD on reloading and running when it passed the signal. The problem was that although the flag for calling on was saved and reloaded with the session file it wasn’t tested after reloading. This has now been corrected.

When a location name was removed by entering a blank name, and then another location name was similarly removed, a message was given that there is another location named ‘ ‘ (i.e.unnamed) and will be erased. Clearly that was an inappropriate message and has now been removed.

This release corrects a number of bugs and inappropriate behaviours as follows:

A temporary speed restriction could be applied immediately a session was loaded prior to play starting. A new condition prevents this, though one could still be applied as soon as play starts.

A train on an automatic signals route that was stopped at or approaching a failed signal didn’t show in the actions due list. This has now been corrected.

A train stopped under signaller control without power had an action due time of ‘NOW’ and a normal background colour. This wasn’t appropriate so now it isn’t included in the actions due list and the background colour is caramel – stopped under signaller control.

It was found that the estimated action time for the ‘next’ action in the train information window was often incorrect. This has been made more accurate when an estimate can be given and no time is provided when it can’t.

After making the actions due panel movable outside the railway screen area the main area often lost focus, causing some shortcut keys to become inactive. Regular checks are now made within the program for mouse position so that whenever it is within the main screen area it regains focus and the shortcut keys work as before.

Thomas Groenewold submitted an error file that showed that a specific track element had suffered two temporary speed restrictions (TSRs) and both were stored. That wasn’t appropriate. The error was thrown when the second TSR reached its repair time but was found not to be in the failed state. Only one TSR can now apply at any time to a track element, as already applies for points and signals. Thanks to Thomas for reporting this error.

All references to ‘ROS’ as the abbreviation for Railway Operation Simulator have now been changed to ‘RailOS’, to avoid conflict with the same abbreviation that is for Robot Operating System. If anyone finds any that have been missed please let me know – thanks.

BummerDude69 noticed that the CTRL and SHIFT keys were missing from the shortcut key listing in the manual and on-screen help for adjusting the viewpoint position movement amount. These have now been included and thanks are due to BummerDude69 for pointing it out.

This update is needed to correct an error relating to the configuration file.

If file Config.txt is absent then under some circumstances the default values for track element length and speed limit are not set correctly, leading to saved railways failing to reload or to an error file being generated.

The error was discovered independently by two users Jason and Jade, and I am grateful to them both for reporting it.

Version information for v2.13.0

The main new features in this release are random delays at locations, random points and signal failures, and temporary speed restrictions.  These are described in section 6.13 of the user manual and on-screen help.

The Actions Due and Performance logs look the same as before but now they are Windows forms rather than panels, and as such can be moved outside the main display area.  This will be useful for those with high resolution monitors where ROS doesn’t fill the entire display area, and for those with two or more monitors.

More detailed preferred direction checks have been incorporated to help identify discontinuities that are hard to spot by visual inspection.

A ‘flush’ command now follows every write to the performance log so that external inspection tools have access to up to date information.

Several Beta versions available on Discord preceded this release to allow wider testing in the community and I am grateful for the work done by members and for their suggestions and error reports.  The result is better for their input.

Please don’t try to load any session files saved by Beta versions prior to Beta4 because they are likely to fail.  Code for forward and backward compatibility had not been completed in those versions.

Bugs

There have been quite a number of bugs reported since the last release as follows:-

An error in the timetable validator was found to cause a crash when track element identifiers contained unexpected characters.  The situation should merely have reported the syntax error which it now does, rather than crashing the program.  Thanks to Amon Sadler for reporting this error.

An error in the timetable ‘New Entry’ function was found to occur with an empty timetable when the keyboard shortcut was used rather than the button.  The program failed to make the necessary check which it now does.  Thanks to mathstrains19 for reporting this error.

An error was found when joining two trains under signaller control when they should have joined under timetable control.  This situation is now detected and a message given rather than the program crashing.  Thanks to Micke(Commuterpop) for reporting this error.

It was found that a train at a station that had suffered a random delay could have the delay removed by taking signaller control.  This happened on restoration of timetable control and was caused by that function forcing a recalculation of the train’s departure time which bypassed any existing random delay.  It was a relatively easy fix to avoid the recalculation and carry out the necessary actions within the timetable restoration function itself.  Thanks to FinsburyPark for reporting this error.

Another error was found by FinsburyPark when skipping timetabled events, where one more event was skipped than should have been.  This was found to be due to my having added the word ‘Timetable’ in the floating information window to make it clear that the times listed didn’t take account of random delays.  The program however interpreted it as a timetabled event that needed to be skipped, with the result that one too many events were skipped.  Once identified it was a simple matter to make the program ignore this line.  Thanks again to FinsburyPark for reporting this error.

This wasn’t really a program bug as such but a further anomaly caused by Windows’ management of high resolution monitors.  The ‘Actions Due’ panel displayed larger than it should have done, resulting in the wrong train being identified on clicking a headcode in the list.  The solution is to override high display settings in program compatibility mode.  In response to this I strengthened the advice in the ‘High Resolution Monitor Scaling Issues’ page of the website.  Thanks to josco for reporting this issue.

The main new feature in this release is the ability to become a follow-on service at a different location and a different time to that specified in the timetable. This is common proctice in the real world and normally used to turn a service round before the scheduled turnaround location when trains are running very late. It extends the ‘skip timetabled events’ feature introduced in v2.11.0, which is used to skip events within a single service, by allowing all successive events to be skipped in a service as well as events in the follow-on service up to departure from the current location.

The conditions that need to be met for this option to be available for a train are as follows:

stopped at a location and has power;
has not already skipped events after its departure;
is running in timetable mode (i.e. not under signaller control);
must have a follow-on service (i.e. last entry before any repeats is Fns, Fns-sh, Frh-sh or F-nshs); and
the follow-on service must either stop at or pass the current location.

These should be easily met in most cases.

The option is shown when it’s available by right-clicking the train when it’s at a location, and is ‘Terminate here and become follow-on service xxxx’, where ‘xxxx’ is the service reference of the follow-on service.

The new service will face the opposite direction to the original service, which is mostly what is required. If the direction change is not wanted then it should be changed under signaller control.

Other changes include:

(a) showing the departure direction for new services in the floating window when the mouse is hovered over a train with train information selected. This is useful when a train changes to a new service at a location with platforms specific to different destinations. Knowing the departure direction (indicated by the first location after the current one in the follow-on service timetable) allows the signaller to route the train into the correct platform.

(b) the right-click menu now only shows the options that are available. It was becoming a bit too cluttered so I think this makes it easier to use.

Bug fixes:

An error file was sent in by Cameron on 28/01/22. This was caused by a train braking when exiting at a continuation. I failed to find out why it was braking, as this should never happen, but was able to fix the effect of the error which was in the time-to-act calculation function. That function assumed that trains would never come to a stop on an exit continuation, as indeed they should never do, but this error showed that it was possible. The fix involved allowing for zero speed and ignoring it, which is fine as no time-to-act entry is needed for exiting trains.  Thanks to Cameron for notifying me of this error.

I noticed that a train that was stopped because of a train in front had signaller control options to move and step forward still available. Nothing happened if these were clicked but it wasn’t appropriate for them to be available in these circumstances so an additional ‘train-in-front’ check was included to prevent it. Additionally a ‘stop’ option had been offered when a train under signaller control was exiting at a continuation, but it would be ignored in these circumstances so the option has been removed.

This is mainly a bug-fix release but includes a small change requested by Dan (Discord DanG#4669) when track linking.

Track linking change:

In earlier versions in Track Build/Modify mode when the ‘Link all track together’ button was clicked missing links were checked first then when all links were ok track positioning was checked (e.g. signals too close to each other or to buffers). This was found to be inconvenient because it required temporary buffers or continuations to be added to unconnected track ends before faulty positions could be found, and it’s generally better to have correct positions before final linking is carried out. It was a relatively simple matter to swap these checks around, so now track positions are checked first and when all are ok missing links are checked.

Bugs:

Kevin Smith sent an error log file after a program crash and at the same reported some odd behaviour. These two issues were unconnected, so he found two bugs for the price of one – and both were quite challenging to sort out.

Odd behaviour: A train that was created at a station and due to depart after a few minutes did so with a clear route ahead, but immediately stopped again after moving just one track element. This turned out to be due to a fault that was introduced when the program permitted the same location to be listed in a service twice or more with no change of direction between them. That happens when there is a loop involved where the train loops back and retraces its steps back through the same stations, which it did in this case. The train’s starting position at the station just happened to lie behind the platform stop element (used to set the stop position when trains arrive in the normal way). What happened was that the train departed, but only moved a single element before reaching the stop element, and since the station was listed again later in the service the program assumed it had missed all the intermediate stops and arrived in accordance with the later timetable entry – about 80 minutes early! It was something I overlooked when modifying the program earlier, and I’m surprised it hasn’t come to light before. It was fixed by checking whether the last timetable action was a departure from the station in question, and if it was skipping the arrival procedure – i.e a train can’t depart then immediately arrive at the same station.

Program crash: The error that caused this occurred when the mouse hovered over a train’s position when there was no train there but the program thought there was. It was due to a coincidence – Kevin manually removed a train at exactly the same time as another train left the railway – within the same clock cycle which lasts only 50mSec. The function that handles trains leaving the railway can handle two trains exiting at continuations at exactly the same time but not one exiting and another being removed manually or joining another train. This function has now been modified so that after it handles one train leaving (for whatever reason) it returns without looking for any others. Any other that left at the same time has to await the next clock cycle before being dealt with, and if there are more than two (very unlikely) then they will be dealt with in successive clock cycles. This won’t be noticeable to the user as the interval between cycles is so short.

Xeon reported a session file reloading error where a train had been unable to enter the railway because a route was set against it. This potential failure had been present for some considerable time, and was due to my failing to update the session file integrity check function after adding this warning. The function has now been updated in this release

IMPORTANT NOTE: there are two new files in the Railway folder – IndyCore260.bpl and IndySystem260.bpl. These must be copied to the folder on your computer where the new version of railway.exe resides or it won’t work.

The main change in this version is the ability to skip timetabled events in order to compensate for late running. This feature is described in detail in the user manual and on-screen help in section 6.12.

Other changes:

If a train is behind the performance or actions due panel when it is left-clicked in the list of actions due it is now centred on screen rather than just having the mouse arrow indicate where it is without any information. This corrects an oversight in the last release.

The minimum track element length has been reduced to 10m from 20m in response to user requests.

The default track element length (100m) and speed limit (200km/h) have been included in the configuration file Config.txt. These can now be changed by editing that file (instructions are included in the file) and reloading it from the ‘Mode’ menu. Note that background colour, signal handedness and default file locations can’t be changed by direct editing.

The user manual and on-screen help have also been updated to reflect these changes.

This version fixes a few bugs and also incorporates a number of changes.

New features:

Krizar has added new files and program modifications that allow real-time information extraction during program operation. These open up great potential for future development using external interacting programs.

Another brainchild of Krizar’s is the inclusion of a new folder in the zip called ‘Metadata’. Metadata is data about other data, or information about other information. The folder contains two files, one for each of the two railways that come with the download – Birminham and Liverpool. The files are of type .toml – ‘Tom’s obvious minimal language’, which provides a format that is both human and computer-readable. Going forward it is intended to make more use of computer file reading, so users are encouraged to provide these files with any new railways that they submit to the website. More information about toml files can be found at https://toml.io/en/, and a list of country codes is provided at https://www.iso.org/obp/ui/#search/code.

The response to clicking a headcode in the ‘Actions due’ panel was always to move the viewpoint so the relevant train was centred on screen. This was often found to be annoying for railways that mainly fit on a single screen, as the viewpoint had to be reset again manually afterwards. Now, if the train is already visible on the current screen, the viewpoint isn’t moved, the mouse position is all that is moved to hover over the train, wherever it is on the screen. If the selected train isn’t visible on the current screen then the viewpoint moves as before.

A train direction analysis has now been included with the others when the ‘Conflict analysis’ button is clicked in the timetable editor. This looks for (a) trains that are created facing buffers (as they often are if the rear and front element IDs are entered the wrong way round); (b) potentially missing changes of direction (cdt’s) – expanding on single service missing cdt check in the timetable validator by examining all linked services; and (c) potentially unnecessary cdt entries, where a cdt is entered when the train is already facing the right way.

Undesirable behaviour:

It was pointed out by Simon Banham that when a route is locked ahead of a train that is moving and positioned immediately in front of the signal that forms the start of the locked route it continues past it without a SPAD. The signal turns red as is required but it has no effect on the train. This wasn’t strictly speaking a bug because the train was behaving as designed. Although the train looked as if it hadn’t yet passed the red signal the program regarded it as having done so, and already occupying the first half of the signal element, the next half-element move only being shown when the train had covered the distance to the half way point. Nevertheless this reason couldn’t justify what appeared to be wrong, so a modification was introduced to ensure that in these circumstances a SPAD would be triggered. This was something that I hadn’t previously noticed so thanks are due to Simon for pointing it out.

Bugs:

A screenshot was sent in by Albie Vowles showing a failed train with a green (stopped at a signal) background rather than an orange background when it was standing in front of a red signal. Investigation revealed that this would happen when a train was awaiting a call-on into a station (purple background), and failed while waiting. The train kept the purple background after the failure instead of changing to orange as it should have done, and when the call-on was no longer available (the train infront having left the station) the background changed to green as it would for a non-failed train. It was corrected by disallowing a call-on for a failed train. Thanks to Albie for reporting this error.

Jason Bassett sent in an error file showing that timetable validation had failed where there was a non-station named location (blue elements) that included blue elements without track (as is quite normal) during the check for enough named elements to allow a split. This error highlighted the fact that although concourses had been taken into account non-station named locations without track hadn’t. Once recognised it was relatively easy to fix by taking proper account of such elements. Thanks to Jason for sending in the file.

Sam Wainwright and later Bengt sent in error files that were generated when the Windows clipboard couldn’t be accessed. When developing the clipboard functions I had trapped all (or thought I had) clipboard errors in order to prevent a program crash, but just issue a message or do nothing instead depending on circumstances. The clipboard is a resource that is shared between all applications so it can be changed outside the railway program and appear to it as if it is corrupt or inaccessible. Such cases generate a clipboard error but it isn’t a fatal error, at worst it’s merely an inconvenience and often not even that, so it isn’t appropriate to stop the program. However Sam and Bengt found an instance where I had failed to trap one of these errors, and it was in a function that is called regularly by the system clock so the clipboard isn’t necessarily even in use. Happily it was easily fixed so it shouldn’t happen again. Thanks to Sam and Bengt for reporting this.

The user manual and on-screen help have been updated to reflect these changes.

I sincerely hope that this release cures the preferred direction problems associated with the Windows clipboard. It seemed like a good idea to include preferred directions at v2.9.0 but given the trouble they’ve caused now I’m not so sure.

One good thing is that one of the corrected bugs explains the error found by Daniel Gill at v2.9.0 in response to which the code was strengthened for v2.9.1, but it continued to bother me because I was unable (then) to reproduce it.

I have tested this release extensively but still feel quite apprehensive, my fingers and everything else are well crossed! Please let me know if you see any odd behaviour and send in any error reports if they are generated – thanks.

I have also to confess to another error, not a bug this time but a plain blunder on my part. I had noticed a while back that the performance log omitted exit counts – early, late and on time exits – so in an earlier release I included them, but forgot to initialise them all to zero! A schoolboy howler! I only noticed it recently but I’m sure others heve seen it too, with exit numbers listed in the hundreds of millions or billions! These have now been corrected.

I was ready to release the new version when Simon Banham sent me an image of a railway with a locked route and signals on it all green! That was clearly not right. On investigation it was found to occur when a segment of automatic signal route had a segment of non-automatic signal route behind it, and that route was locked. When a train in advance of the locked route passed a signal all signals behind it were reset, but the resetting function failed to take account of the locked route so signals were reset as if it didn’t exist. Fortunately it was quite an easy fix, so that shouldn’t happen again. Thanks are due to Simon for pointing this error out.

This is a bug fix release as a result of an error reported by Daniel Gill when rotating a segment of railway. I have not been able to reproduce the fault but made improvements to the rotation and associated functions and these seem to have cured it. Also included are a couple of minor changes that were awaiting the next release as follows:-

The ‘Comment’ entries in the timetable service list have been changed to show the first 15 characters of the actual comment as this is felt to be more meaningful.

A timetable time has been added to all warning logs that are shown in red at the top of the screen.

This update represents a bit of a tidy-up – adding features that should ideally have been added earlier.

The main addition is to include preferred directions (PDs) in selected railway areas for cutting, copying, rotating etc. This omission had become an odd man out since the other track attributes were included some time ago. It was left because although PD elements are derived from track elements the data they embody is stored separately from other track data, so new selection and manipulation functions were necessary to capture and manage them. These functions are now included and work with all types of selection, including use of the Windows clipboard.

Another addition is to include a check function able to find and highlight potential PD conflicts. When building PDs it is very easy to miss short segments of track, especially on one leg of a set of points, leaving them without any PD and thereby preventing automatic and PD routes being set across them. The check function is available in the ‘Edit’ menu in PD mode and is explained in section 4 of the manual and on-screen help.

Level crossings are now included in zoom-out mode, and they are shown flashing for manual crossings that are open to trains without any routes across them. This is to remind users to close them because heavy time penalties are incurred if they are forgotten – which I’ve done to my cost more than once! To further remind users about such level crossings a warning icon is also shown flashing on the left hand side of the screen.

The main change in this version is the ability to use the Windows clipboard so that areas of railway that are cut or copied can be pasted into another railway application. The user manual and on-screen help have been modified to explain the process in section 3.5.

Minor changes:

1. After selecting an area of railway in track build mode the track elements now become visible so that the selected area can more easily be filled with a particular element.

2. If an area of railway was cut and moved and then cancelled, it used to be pasted in the new position which wasn’t appropriate, so now it’s pasted back in its original position.

3. It was found that if a route was set for a call-on into a platform where there was already a train, and that train changed direction, the route was cancelled. It happened because of an earlier change that cancelled stub routes ahead of a train when it changed direction and the excess route beyond the train was no longer wanted, but the route direction wasn’t checked so any route was cancelled. Now the route direction is checked and only routes leading away from the train are cancelled.

4. It was found that a route could be set across a level crossing that had only just begun to close to trains if the route setting was done very quickly. The final signal before the crossing stayed at red so trains would be protected but the route was present and shouldn’t have been. The program check routine has now been modified to include routes that are in course of being set in addition to routes already set.

This version incorporates a number of functional changes that will hopefully make operation easier as follows:

In response to Josco’s suggestion via Discord of adding information to trains listed in the ‘actions due’ panel this is now included. The same information as is selected via the ‘information’ menu is shown when the user hovers over a headcode and clicks the right mouse button. The mouse button click was added instead of just plain hovering to avoid distraction when the information isn’t needed.

There are now two options available when selecting preferred direction (green) routes. The green route selection button is split into upper and lower halves, the upper half working as before where the route is built by clicking on each consecutive signal (or buffer/continuation at the ends) – this reflects normal practice. The lower half button allows routes to be built from signal to any following signal (or buffer/continuation at the ends). Routes built in this way must still follow preferred directions, so should be more accurate first time than unrestricted routes that don’t have to follow preferred directions. In fact this change was suggested by Bjorn years ago!

When a train exits at a continuation and there are two or more possible exits to choose from, there is currently no way during operation to know which is/are designated as correct in the timetable. The exit element identifier (ID) is shown only if the exit isn’t named. In this version the allowable exit IDs are listed in the timetable information window. This change was prompted by my abysmal performance at the last signalling social when operating Liverpool St to Romford. I repeatedly sent trains out from Romford on the slow line when they should have used the fast line – don’t tell anybody! I won’t have that excuse in future so I’ll have to find a new one.

When a train was stopped at a signal and a call-on offered and accepted, the time to act remained ‘NOW’ until it passed the signal. That was inappropriate so now as soon as a call-on is accepted the train is removed from the list.

The manual and on-screen help have been updated in accordance with these changes as have the file specifications.

One correction was made relating to train colours:

I noticed that on returning a train to timetable control at a stop location after being under signaller control the train colour changed to ‘running’ (grey) when the route in front cleared, even though the train wasn’t due to depart. The colour should have remained pale green (stopped at location) until the departure time. The fault was found and corrected.

This is simply a fix for a bug introduced in the last version relating to two locations having the same name. What I overlooked was that in a developing railway locations can be saved before they are named, and in these cases they have a null name, which is an empty string – meaning unnamed. The name checker failed to ignore these locations so the warning message was given in error – causing confusion – each time such a railway was loaded. Happily the fix was quite simple – a new line that checks for nulls and bypasses the name check if any are found. Thanks to Micke(Commuterpop) for reporting this issue.

This version includes a number of small functional changes, a couple of bug fixes and documentation changes.

Small Functional changes:

In response to Bill78’s supporting program to merge two .dev railway files there was a need to check that two locations didn’t have the same name so as to prevent the merged railway being saved as a .rly file. There is an existing check but this is made on entering a name, and this prevents two locations having the same name, but with two separate railways being merged each might have a name that appears in the other railway. A new check is now made on loading a railway file, and if the same name is found a warning is given to say that the railway can’t be saved as a .rly file. The check and warning is repeated if an attempt is made to save as a .rly file.

When gap setting the existing arrangement marks gaps to be set, but in a detailed railway these can be hard to find. Now the marks flash in both zoom-in and zoom-out modes and are easier to spot.

During operation, after taking signaller control of a train, it was easy to click ‘step forward one element’ inadvertently if two clicks were made in quick succession. The position of the pop-up menu has now been moved slightly so that the mouse does not lie over any of the options so as to prevent this nuisance.

If a train was removed by the signaller there could be a short stub route left over ahead of the removed train. This is now removed up to the next signal (similar to route removal behind a train that has changed direction).

Bug fixes:

Androeker discovered an error & notified it via discord on 16/12/20. The error was that if a location name containing a continuation was changed then a timetable that included it would validate and therefore allow the program to load and operate, the reason being that the list of continuation names [ContinuationNameMap] wasn’t updated in these circumstances [it’s only updated in TryToLinkTrack, so if that isn’t called, as it isn’t for a name change, then the error wouldn’t be seen by the program]. When the program was exited and later restarted and an attempt made to reload the (flawed) timetable the continuation name list was updated (as it is whenever track is linked), so the program saw the error and the load failed. This correction rebuilds ContinuationNameMap whenever a name is entered or changed so the timetable validator now gives an appropriate error message.

It was noticed in the ‘Actions due’ panel that the time to act was sometimes too short for trains that were approaching a stop location. The time corrected itself when the train stopped. What happened was that when running early the time calculator didn’t take account of the extra time needed at the next station before reaching it. This version updates the time calculator to take account of the dwell time.

Additional changes:

User manual and on-screen help updated in line with latest program changes.

The file specification document has been expanded to include session files, timetable files and the configuration file as well as railway files. It now also incorporates the earlier ‘Changing a timetable in a session file whilst retaining routes’ document.

This version includes a number of functional changes as well as several ‘corrections’ (i.e. improved undesirable behaviour) and bug fixes.

Functional changes:

A selected area can now be filled with a specified track element, which can save a great deal of time when building long sections of horizontal or vertical parallel tracks.  This was in response to a request from Wilsteady.  The user manual and on-screen help have been expanded to explain this feature in section 3.5.

Level crossings can now be opened and closed manually by left clicking them.  This was in response to a request from Krizar.  The user manual and on-screen help explain how to use this new feature in section 3.1.1.  Note that program versions earlier than v2.6.0 won’t load a session file that includes any manually opened level crossings.

When railways, timetables or session files are in folders other than the defaults, and a user navigates to them for loading or saving, the new folder locations are stored in a configuration file (Config.txt) and are used thereafter by the program.  This is helpful for users who prefer to locate their files in other than the default folders and is in response to an initial request from Micke (Commuterpop) and subsequent suggestions from Bjorn and Krizar as to how it might be done.  The feature is described in the user manual and on-screen help in sections 2.3 and 6.3.  Config.txt also now stores the background colour and signal handedness, making the earlier files that were used for these purposes redundant.

Horizontal & vertical signals can now be used in named non-station (blue) locations.  Wilsteady suggested this a few months ago.  I think I was just playing safe in disallowing them but on further thought I can’t see why there should be problems and testing didn’t reveal any, and it makes them consistent with station locations where signals can already be used.

Corrections:

If a timetabled location appeared twice or more  in a particular service other than with a change of direction between them it was assumed to be an error and not permitted.  It isn’t necessarily an error however for trains that take a circular route back to earlier locations.  This was queried by Daniel Gill some time ago and I promised to look at it again.  This version now allows location duplication but gives a one-off message to allow the user to check whether it’s intended or an error.

If a railway or session contains user graphics and the program can’t find them, then formerly the load would fail.  Now they are loaded without them but a message is given to inform the user.

In the last update a train that changed direction at a timetabled location had any excess route elements beyond the train removed automatically up to the next signal.  This has now been extended to trains under signaller control that change direction.

Bug fixes:

A route that finished at a trailing point leg where an existing route on the other leg looped back to this trailing leg caused an appending route to loop forever.  A new test has been added that checks and exits for this condition.  Thanks to Xeon for spotting this and notifying me by email on 13/10/20.

If a named location was copied and pasted next to another location it didn’t take the name of that location but lay next to it and remained unnamed.  This version corrects it, making the pasted location take the name of the existing location.

This is a relatively minor ‘tidy up’ release.  It adds a few features that improve usability and operation, and corrects a couple of bugs.

Functional changes:

When a train changes direction under timetable control at a location other than at buffers there is usually a redundant route left in the original direction. The program now removes these unwanted routes automatically up to the next facing signal.

All types of finish event are now permitted immediately after a new train is declared (‘Snt’) apart from Fns-sh & Frh-sh.

Facing signals can now be allowed next to bridges if the user chooses it – this is useful for working on old railways without having to change them or for new densely packed railways. A warning is given that such signals can’t be used as route truncate points, but it is now up to the user to decide whether or not that risk matters.

The distance/speed selection warning that all track lengths will be set to the specified value is now only given once.

A few timetable error messages have been clarified.

Bug fixes:

For distance/speed setting the selected track length should show in magenta for easy identification, but prior to this release it was overridden by the normal colour when set.

Track information showed when the mouse was positioned over the timetable editor, this has now been corrected.

Functional changes:

Timetable conflict analysis added. This is too complex to explain here but it is described in detail in section 5.12 of the user manual and on-screen help.

The warning that a session file hasn’t been saved when a session is ended or the application closed is now only given if the timetable clock time is 5 minutes or more later than the last session save or later than a new session start time

Signals immediately before bridges are now disallowed for new railways because the bridge prevents a route from being truncated to the signal (a bridge as a truncate point is ambiguous as it may contain two routes and is therefore not permitted). Existing railways with signals next to bridges will still work as normal, but if any changes are made to the layout then the restriction will apply.

An option has been added to ‘not show again’ the warning when changing the timetable clock.

Information is now provided for follow-on services in both the train status and timetable information windows when hovering the mouse over a train. It includes changes of direction, splits and joins, and departure times. This information helps in decision making for trains at and due to arrive at locations, especially in route setting for departures and platform selection for arrivals.

The ‘Actions Due’ panel now shows trains requiring attention before operation is resumed when a session file is loaded. This only applies for sessions saved after operating the railway, it doesn’t apply for pre-start sessions. This allows the state of play to be assessed before operation, and trains requiring the most urgent attention can be located ready for routes to be set as soon as operation begins.

The ability to right-click the first letter of text to delete it has been re-established in ‘AddText’ mode. From v2.1.0 it was overridden by the screen move routine, but now text deletion takes precedence.

In the timetable editor the selected entry following a cut or delete action is now the entry before the deleted entry rather than after it. This makes it easier to insert a new entry in place of the deleted entry.

The keyboard shortcut keys for AddMins & SubMins in the timetable editor have been removed because when these are to be used the edit box has focus and a keypress is interpreted as a text entry rather than as a command to simulate a button click.

Bug fixes:

It was noticed that the response to timetable editor keyboard shortcut keys didn’t match button click behaviour accurately in all respects. The keys worked as they should but sometimes the selected entry reverted to the top of the list making it necessary to scroll down again for long timetables. This has now been corrected.

An error discovered by Albie Vowles and reported via email on 14/08/20 was corrected. It was a fault that was present from the beginning involving locked routes, where all elements in the route normally stay locked until they time out at 2 minutes. In Albie’s case a train ran past the signal at danger (with the locked route ahead of it) and cancelled two elements, leaving it shorter than it originally was. Periodically the program rebuilds the entire railway, for example when the viewpoint changes, but in rebuilding this locked route it assumed it was longer than it was, and when it came to the end sooner than expected the program crashed and generated an error file. Fortunately it was easily fixed. The program now checks whether the actual length of the locked route is shorter than expected, and if it is then the rebuilding stops when it reaches the real endpoint.

An error discovered by JKWok and reported via discord on 9/7/20 was corrected. If separate locations were joined together by a new platform or concourse not all the earlier separate names were deleted. It was due to not ensuring that all elements had the chance to have an existing name erased, but now they do.

This is purely a bug-fix release to correct an error reported by Isglassen05 on 31/07/20. When using ‘Delete’ in the edit menu in a railway that included one or more user graphics, where the selected area for deletion didn’t include any graphics, the program would fail. It was due to the variable used to search for included graphics being set wrongly. This version corrects the error. It is surprising that it hadn’t been reported before as it was present from v2.4.0 onwards.

Changes in this version are as follows:

Text is now plotted after station platforms and concourse and non-station named locations so platform numbers can be placed over named location elements instead of being hidden by them. In fact this was added for version 2.4.0 but mention of it was overlooked.

Many more keyboard shortcut keys have been added so that most buttons now have a shortcut. The button hint (shown when the mouse hovers over a button) indicates the shortcut.

The user manual & on-screen help have been updated in line with these additions.

[Bug fix] A points check has been added in the check for a train entering a route in the wrong direction. Thanks are due to Xeon for reporting this error.

[Bug fix] A SPAD error could occur when trains entered at a continuation with zero or very low speed. This was a new fault introduced during the development of train failures and has been corrected in this release. Thanks are due to Micke (Commuterpop) for reporting this.

Version 2.4.1 Beta is a small ‘bug-fix’ update on version 2.4.0 Beta. 

The ‘Set mean time between failures’ menu option under the ‘Mode’ tag had been left in by mistake during development but did nothing.  This version removes it.  Thanks to Mark for reporting it.

Inactive track elements such as concourses couldn’t be erased in v2.4.0 due to an error in the code which this version corrects.  Thanks to Krizar for reporting it.

Mark sent in an error file generated when a train left at a continuation.  The file made it clear that just as the train left it had zero speed, which caused an arithmetic error that crashed the program.  This version ensures that the program won’t crash if the same thing happens again – but why it happened remains a mystery.

Version 2.4.0 Beta incorporates several features, some of which have required significant code modification, so it is released as a ‘Beta’ because even after a lot of testing there may well remain some teething problems that will need early attention. It has been compiled using Embarcadero’s latest C++ compiler version 10.3, which is based on Windows 10 and generates code that doesn’t need any changes to the compatibility mode, at least for normal Windows 10 settings. A very welcome and surprising outcome was that the program also works on earlier Windows versions without the need for any changes to the settings. It has been tested on an ancient notebook computer that runs Windows XP and it worked perfectly straight out of the box – that was really unexpected! It should therefore work on any Windows operating system later than XP.

New features include:

– Random train failures.

– The ability to add user-defined graphics (note that files saved with failures or user graphics won’t load in earlier versions).

– Rotation by 90 degrees.

– All pastes are now with attributes, although ‘Copy’ won’t copy location names because these can’t be duplicated.

– Timetable listings can be sorted into alphabetical order for easier service location.

– More keyboard shortcuts have been added.

– All session files should load regardless of which decimal point character was used when saved (different countries use different characters) – thanks to Micke for helping me with this.

– Platforms can now be any length equal to or greater than 20m, which is the minimum length for any track element. Formerly they were fixed at 100m to prevent unrealistic scaling, but user pressure forced a rethink, especially when Discord member Xander with an X pointed out that ERTMS requires short platfrom lengths in order to display several train locations at each platform.

– A number of error messages have been clarified.

Bug fixes:

– The ‘Submins’ (subtract minutes) box had disappeared from the timetable editor in version 2.3.1. It’s a bit too easy to move buttons and other program features inadvertently when changing the user interface, and I must have moved that button behind one of the panels without realising it so it couldn’t be used. No-one reported it so it must not have been missed, but it’s back now.

– If there was an exit signal next to a level crossing and an autosignals route was set from that signal the train crashed into the crossing. The reason was that as a train approached the crossing the single route element on the crossing was removed ahead of the train and the crossing started to close, causing the train to crash. Exit signals now can’t be placed next to a level crossing. Thanks to Krizar for reporting it.

– If the ‘Actions due’ panel was clicked before trains were listed, or a train was clicked after it had been removed by the signaller but before the panel updated then the program crashed. This has now been fixed. Thanks to Rokas and LiWinDom for reporting these errors.

– The wrong colours were displayed for underpass lengths and speed limits. These have now been fixed. Thanks to Xeon for reporting it.

– There was a lockup condition when the ‘Actions due’ panel was open and a train was in a loop. This has been fixed. Thanks again to Xeon for reporting it.

This is a relatively minor change, the main aspect of which is the addition of underpasses, also serving as surface-level foot crossings.  These function exactly the same as footbridges and are added to improve accuracy rather than functionality.  You will see that for these the track lies over the crossing rather than underneath it. The only restriction to be aware of during construction is that an underpass element won’t link to a footbridge element.  On the track build panel the new elements are located next to the existing footbridges.  Note that railways and sessions that include underpasses won’t load in program versions earlier than v2.3.1.

Some of the more obscure warning messages have been expanded to improve clarity.

The only other change is a bug fix where the program crashed when very large numbers were entered for timetable repeat values.  Thanks to Albie Vowles for finding and reporting this error.

Signals can now be displayed on the right hand side as well as the left hand side of the track. The setting is made before any railway is loaded so existing railways can be loaded with right hand signals where appropriate. Other than in appearance the signals work as before.

Timetable clock speeds have been extended to include 1/8 and 1/16 real time. This is to make operation of very large railways easier. Also the time taken for points and level crossing barrier changing and route setting have been kept at their normal values for slower clock speeds, to prevent long waiting times for slower speed operation. At higher clock speeds these durations shorten in proportion.

The ‘Actions Due’ panel has been modified to prevent track and train information from being displayed when they lie behind the panel (Thanks to Xeon for spotting and reporting this error).

An error in the user manual and help files has been corrected.  ‘Paste with attributes’ was claimed to retain preferred directions as well as track properties. In fact it doesn’t retain preferred directions as they are not stored as track properties, and keeping them would be a difficult programming task. Re-establishing them for a moved section of track is normally quite quick.

The user manual and help files have been updated in line with the above changes and the timetable error messages document has also been updated to correct a few errors and to make some explanations clearer.

Changes have been made to text and graphics handling functions to make memory usage more efficient. There had been failures when loading very large session files, especially those containing very many trains. These changes provide a bit more memory space for such files.

A new ‘actions due’ panel has been added.  This makes operation easier for railways that extend over several screens when many trains are out of sight. The panel contains a list of train headcodes with times to act in timetable minutes, in ascending time order. This panel is displayed by left clicking a new button with an hourglass icon. Left clicking a headcode brings the train selected (or the entry point for trains not yet running) to the centre of the display, with the mouse hovering over it and displaying status and timetable information when these are selected. The user manual and online help have a new section ‘Actions due’ that explains how the feature works in more detail.

A new ‘paste with attributes’ feature has been added.  This facilitates modification of the layout of a railway so that it fits better on a screen with a different resolution to that on which it was developed. When using the normal cut and paste functions all preferred directions, track lengths, speed limits and location names are lost. This new feature retains all these attributes so they don’t have to be re-entered. Any new track elements needed to link to the repositioned area will need appropriate new attributes setting, and if the cut area includes any train entry points then the timetable will need to be altered to reflect the changed element identifiers.

The ‘End’ key on the numeric keypad can now be used to toggle the zoom function on and off, providing Numlock isn’t on.

The earlier letter keys ‘w’, ‘s’, ‘a’ and ‘d’ that could be used to move the display up, down, left or right well as the keyboard arrow keys have been dropped. The arrow keys still work as before, but conflicts arose with the hotkeys introduced in the last version. No-one reported this so we assume that they weren’t generally used, and keyboard movement is much less necessary since the ability to drag the display using the right mouse button was introduced.

The need to set 256 compatibility mode for Windows 10 may have been solved – by setting solid colours instead of the default Windows colours. These defaults became transparent in Windows 10 obscuring the text that was incorporated, especially on the floating panel used for track and train information.

Performance scores for excess level crossing barrier down times weren’t being saved in session files. This omission has now been corrected.

Icons have been added to many of the menu items and buttons.

Speed and distance conversion facilities now work both ways.

‘Hotkeys’ have been added for frequently used functions.

A website link has been added to the help menu.

Presentation has been improved in terms of clarity and ease of use. 

Functional improvements:

The railway can be repositioned by dragging with the right-hand mouse button in both zoom-in and zoom-out modes.

The screen can be resized and still retain full functionality.  Xeon recently mentioned this limitation when not in full screen mode and Albert promised to add scrollbars at the next release, but full function resizing is much better than the inconvenience of scrollbars.  Interestingly he had thought that scrollbars were available but after Xeon contacted him found that v2.0.0 didn’t have them.  Further investigation revealed that they were available in v1.3.2 and earlier, but disappeared for some unknown reason in v2.0.0!

Routes can be cancelled when they are occupied by trains with a ‘route locking’ warning as given for trains approaching signals.  Albert had earlier thought that route cancellation when occupied should be disallowed as SPADs are more likely in these circumstances, but it meant that long automatic signal routes couldn’t be removed when there was heavy traffic and the route was never free of trains.  One user, Brian Clancy, commented on this back in 2016, pointing out that it is allowed in real railway operation when circumstances require it, which it has to be to avoid a no-way-out situation.  This change therefore brings operation more into line with real railway operation.

More information has been added for trains that have yet to enter at continuations, including repeat number, entry speed and timetable, to allow better planning for when the train arrives together with earlier route setting.

The help manual and on-screen help have been updated to reflect the latest changes.

Errors corrected:

The timetable screen caption now reads correctly when creating or editing timetables.  Formerly the earlier loaded timetable name remained in the caption in error.

Signal behaviour on locked automatic signal routes exiting at a continuation when a train has exited has been corrected.  Before, signals continued to clear in sequence in spite of the route being locked.  All now remain at red.

There was a potential error when pre-setting automatic signal routes, in that a pre-set route could be set across a diagonal that was fouled by an adjacent track that cut across it.  Now such situations can’t arise when pre-setting routes, though they can still be created by the user during operation if required.

Some minor changes have also been introduced as follows:

Railway file loading:  The dropdown box has been removed.  I and others found this a bit tedious so now all railways are displayed together whether .dev or .rly files, making loading quicker and easier.  Just be sure to select the one you want!

Timetable change:  ‘Fjo’ (finish join other train) has been added as an option immediately after ‘Snt’ to allow empty stock to be picked up.  Richard Gaede asked about this some time ago and I hadn’t until then realised that it wasn’t possible.

Help system:  This is now up to date using .chm files.  The earlier Windows Help system has been discontinued and wouldn’t work on newer operating systems.

Train information:  ‘Show status’ and ‘Show timetable’ are now active on startup so they don’t have to be selected.  I always keep these active during operation and I suspect others do too, so it seems sensible for them to be available immediately.  If the aren’t wanted then they can be hidden in the normal way

Fault reported by Glenn Mitchell 14/04/13.  Failure occurs when try to set automatic signal routes prior to operation if there exists a junction where there’s a preferred direction set on the through track but not on the diverging track, and where the diverging track links to a signal.  Corrected by disallowing an automatic route in these circumstances.

Found that could set a route across a fouled diagonal (i.e. where a route is already set on the diagonal track) if the route start element is adjacent to the diagonal.  This was because fouled diagonal checks were not made for first element, but these are now included.

Fault reported by Ian Walker 18/04/13.  Timetable edit screen stays up when click cancel on file open dialogue panel – should go back to base mode. Now corrected.

Fault reported by John Phillipson 09/04/15 relating to a train split.  This was traced to a program error where an area of memory could be overwritten after the new train was added following a split under some circumstances.  The functions requiring changes were quite extensive so as well as local testing they were compiled as a  pre-release beta version that John kindly tested over the following weeks without any new problems coming to light.

Fault reported by Carwyn Thomas 24/05/15.  An incorrect SPAD was given when a train passed the last signal before a continuation, and when he tried to remove the train under signaller control an error was generated.  There were two faults involved, one relating to the train removal – due to the front of the train having passed out of the continuation and the program trying to access the front element, which of course no longer existed.  Corrections were made to the relevant functions.  The SPAD error was found to be due to two trains exiting the same continuation in quick succession, when the second train passed a signal facing in the opposite direction when the last signal before the exit was still in course of changing back to green after the first train had exited. This was also corrected following investigation.

1. Letter keys (‘a’, ‘d’, ‘w’, & ‘s’) entered in distance/speed boxes were also found to move the screen viewpoint which was not required in these circumstances.
2. The miles/chains & speed conversion boxes stayed on screen after distance setting when another button was clicked in Build/Modify mode.
3. The program locked up if points were in course of changing when it was deactivated by another program becoming active. Changing points are now cancelled when the program deactivates.
4. A train’s maximum running speed is set to a joining train’s maximum speed if it is less than the current train’s maximum speed, but if the joining train is a service continuation then its maximum speed is zero until it appears on screen, and in this situation the maximum speed of the joined train is set to the minimum value which is 10km/h, which is not what is required.  This version corrects this error, which came to light during development of Ian Walker’s Chiltern Railway.  Hence when that railway is published this latest version will be required to operate that railway properly.

The faults corrected are:

1. If a train was removed by the signaller when occupying an automatic signals route then the signals stayed as they were when the train was present. This version resets the signals.
2. If a train entered the start of an automatic signals route under signaller control and stopped when occupying one or two elements, then changed direction and moved back out again, the first signal stayed at red.  This version resets the signal.
3. Train status information has been changed to show speeds in whole numbers of km/h rather than including the first decimal point.  This has been found to reduce (slightly) the flickering that occurs when this information is visible.  The flickering is due to the screen refresh processes that are part of the Windows operating system and there seems to be little that can be done in the application software – I’ve tried but with only limited success!

Other changes were made to correct a number of errors involving diagonal crossovers that I had noticed and I am sure others had too although though no-one had complained. These all relate to situations where there are crossing diagonals, i.e. diagonal track elements that cross other diagonals. There are lots of combinations of these – for example :-

The significant thing here is that routes and trains that cross at these points never occupy the same track element at the same time, as they do if they cross at a normal single-element crossover. I had taken account of these situations when setting routes – checks are made for an existing route at a crossing diagonal, but had completely overlooked related situations, i.e. that trains should crash if they meet at such a crossing; a route shouldn’t be settable through a train that is using such a crossing; and an existing route should be cancelled if a train crosses it at such a crossing. All these omissions came to light while playing with the simple Mile Oak railway that is used in the timetable tutorials. You can imagine I’m sure how I groaned when I made the discovery.

At the same time I decided to change a number of things that had been annoying me, and I’m sure you too. The first was to keep the existing train and track information settings (show or hide) when new session files are loaded. Previously they reverted to ‘hide’, and had to be reset to ‘show’ each time. Now they start off as hidden when the program is first started, then remain as set by the user until the program is terminated. The second was to allow an unrestricted route to be created into an occupied platform for a train waiting at a signal and still allow it to be called on. Previously all points into the platform had to be set manually, and any route (apart from an automatic signals route) , would prevent the call-on being offered. Now it’s much easier to create the route and have that set all the points. Third was to prevent an automatic signal route from being created from buffers – otherwise there’d be no way of allowing a train to reach the buffers! This now matches the corresponding restriction of preventing such a route being set into buffers which was present before. Why I didn’t prevent both at the same time I don’t know. I also noticed that if the ‘About’ box was displayed in pre-start mode, then when it was removed the mode reverted to paused mode. Now the mode stays the same as it was before the box is shown.

As you can see there have been many changes, and hence the ‘beta’ version. I have done a lot of testing of the changes and new functions, but as ever I can’t test exhaustively, so there may well be errors still present that I hope you will tell me about if you find them – thanks.

Firstly a fault prevented automatic or preferred direction signal routes being set in certain fairly unusual circumstances – due to an internal program test giving a false positive.  The test has now been corrected.

Secondly Matt noticed that if the window was changed while a route was being set, then on returning to railway.exe the program froze.  The deactivation detection routine in the program has now been improved to detect this situation and to cancel the route being set.

It had been noticed that level crossings displayed as always open horizontally on saved bitmap railway images regardless of track direction.  That has been corrected in this version.

Other minor changes are as follows:-

Routes may now be cancelled without route locking if the first train on the section is stopped.

It was noticed that the screen grid did not expand for resolutions higher than 1024 x 768, now it does.

Location naming functions have been tidied up – earlier, when combining two named locations the second name stayed on screen, now it is deleted; and earlier it was possible to give a timetabled location the same name as a continuation, now it isn’t.

The appearance of diagonal ground signals has been improved as the sloping top didn’t stand out well enough.

The only change from beta v0.6c is a change to the performance scoring system, after I realised that I had failed to penalise incorrect exits, unexpected exits, and missed events other than missed stops.  These are all now incorporated, so a session file loaded and then immediately resaved will be seen to give a different (and lower) performance score if any of these events had occurred during the session.

Enhancements: 1) Train headcodes are now much less restricted.  Any alphanumeric character (upper or lower case letters or digits) may appear in any of the four headcode positions.  The only condition is that repeating services that have headcode digit increases between repeats must have digits as the last two characters of the headcode.  This change is because there are increasing numbers of railways being developed that don’t use the standard British ‘digit letter digit digit’ format.  Note that timetables that use this feature will fail to load into earlier versions of railway.exe.  Note that the earlier requirement to add “;0000” after the timetable start time to allow (slightly) less restricted headcodes is no longer necessary.  2) The train status floating window now includes, for repeating services, information about the repeat number.  This takes the form of ‘First service’, or Repeat service no. 1′, Repeat service no. 2′ etc.  This has been included because trains that join must have corresponding (i.e. the same) repeat numbers, as well as the correct headcodes, and this feature allows any discrepancy to be seen.  3) Performance scoring has been added at the end of the performance log.  Points are deducted for late running based on overall lateness, and increasingly severe deductions are made for missed stops, SPAD risks, actual SPADs, derailments and crashes.  A percentage score is given along with a rating, which runs from ‘Perfect’ to ‘Abysmal’, or, if there has been a crash, to ‘Catastrophic’.

Changes: 1) Formerly when a timetable had been loaded for operation, and then a timetable was loaded into the timetable editor, the loaded timetable stayed in place.  However changes made to the editing timetable also affected the loaded timetable, which could cause problems in some cases.  Therefore, now, whenever a timetable is loaded into the timetable editor any other loaded timetable is removed, and to resume operation a timetable must be loaded again.  2) During timetable editing, when pasting entries, the current (highlighted) entry remained at the same position as before the paste.  Now the current entry changes to the pasted entry (as it does when new entries are inserted).

Corrections: 1) Glenn had reported problems with trains failing to join correctly when operating Plenwell IECC.  The reason was found to be failure on my part to update the ‘Running’ status of trains that were continuation services from earlier services.  In fact the ‘Running’ status was only correct for trains that were created using codes ‘Snt’ or ‘Snt-sh’, all other start codes continued to use ‘Not started’ as the status, which was clearly incorrect.  I fear that others will have found this error but probably blamed their timetables when they should have blamed me!  My apologies to all that have been affected by this error, and my thanks to Glenn for reporting it.  2) An error log file was sent in by Rander of the UKTrainSim forum, which occurred during timetable development.  This was traced to a failure on my part to update the current entry pointer correctly after a new entry insertion.  In most cases there would be no error, but in some cases, when the array of entries in memory becomes too big for its current location the program moves the entire array to a different area of memory.  In these cases the current pointer would point to some random place that had nothing to do with the entry array, and an error would be the result.  This has now been corrected – thanks Rander.  Again I suspect that others may well have been frustrated by this error during timetable dveleopment, so again I offer my apologies to those affected.

Corrects an error discovered by NajamUddin (my thanks again to him for reporting this) on calling a train on.  If the platform element where the train was to arrive was a set of points, then the program could fail due to a coding error.

Incorporated a variable speed timetable clock feature and the ability to increment the clock.

The user manual and help files have been updated to explain these new features.

Added a HP/KW converter to the timetable create/edit screen.

Corrected an error that could occur when a train was created on a route that was in course of building – thanks to NajamUddin for bringing this to my attention.

Corrected a rounding error in the performance log whereby hours could display one too high when near the end of the hour (e.g. 07:59 could display as 08:59).

Set a minimum track element speed limit of 10km/h, and also set the lowest value for a train’s maximum speed of 10km/h.  With lower values a ‘divide by zero’ error sometimes occurred during the train speed calculation due to approximations made in that calculation.  Note that on loading railways saved in earlier program versions any speed limit that is less than 10km/h will be set to 10km/h, and on loading earlier timetables any maximum train speed that is less than 10km/h will be set to 10km/h.

It was noticed that speed limits and track lengths for diverging point legs were ignored by the program, this version corrects those errors.

It was noticed that after a train had passed under a bridge when the top track had a route set, the route colour was redisplayed incorrectly.  This version corrects that error.

Corrected a fault that could occur when creating formatted timetables.  Hour entries could be too low in some circumstances (e.g. could read 07:00 when should read 08:00).  This was due to a failure to round correctly when converting from floating point to integer values.

Improved preferred direction and route searching to ensure that all possible directions from the starting element are searched properly.  Formerly, when there were many possible routes in one direction from a given starting element the search could fail, and other – probably better – directions would then not be searched.

Also corrects a fault where if zoom out when moving to a follow-on preferred direction element the program stops with a ‘can’t set focus’ error when click to zoom back in again.

Section 6 of user manual & help file changed slightly to add that trains will stop for trains in front if they are at a timetabled stop location.

Updated my email address to railwayfeedback@gmail.com in the quick start guide.

Information added to point 5 in section 5.11 of the help file and the user manual relating to the behaviour of signaller controlled trains.

In v0.4 when I made non-station named location (blue square) lengths 100m I overlooked the fact that these could be placed without track being present, and placing in this way then caused a fault (as did pasting areas of railway that included such locations after cutting or copying).  That fault has now been corrected.  [I wish I could correct a fault without creating a new one – or two!]

Problems had been reported where session files failed to pass the integrity check on subsequent attempts to load.  This was due to the stored temporary timetable file being incompatible with stored train information and is thought to be due to a single ‘timetable.tmp’ file being created for all timetable loads, rather than a unique timetable file for each timetable load.  The current version creates unique files of the form ‘TmpTT<n>.tmp’ where ‘<n>’ is a number, and these should be deleted automatically when the program ends.

Version 0.3 introduced an automatic cancel of routes consisting of a single element.  However another fault was discovered with this process in that if such a single element was selected for the start of a new route, and was cancelled before the new route was completed, then on the subsequent attempt to complete the new route a failure would occur.  This has now been corrected.

The zoom-out screen navigation has been changed to 60 elements from 30.  This makes for faster review of large railways in zoom-out mode.

The calling-on function has been improved in that checks are now made for any existing routes elements or conflicting routes before the call-on is offered, and when accepted an unrestricted route is set into the platform.

The route setting functions have been changed to search first in the direction of ‘set’ leading points.  This means that if there are two or more possible routes between the start and end points, or a route cannot be found by the program because the search would take too long, then one or more sets of points can be changed to link track elements along the desired route.

It was found that named location track lengths were not fixed at 100m (as platforms are), though the distance calculation treated them as though they were 100m.  These are now fixed at 100m.

The help file and user manual have been updated to reflect and explain the above changes.

A couple of errors were also found in the timetable reload function.  I had failed to update it when the normal timetable load function was modified some time earlier.

Another change is that the program automatically removes any routes that just consist of a single element – these are left when a train stops at a signal that ends a route.  This is tidier as sometimes the train changes direction and moves away, leaving the single route element isolated.

Another error was discovered in that if a complete loop of routes was attempted to be created consisting of mixed automatic signal routes and other types, then the program locked up as it went into an endless loop trying to set signals but never reaching the end of the route.  A check is now included to prevent this happening.

The help files and the user manual have also been updated to clarify a number of complex timetable functions, and also some errors have been corrected.

Also added is the ability to move the viewpoint by 2 elements at a time by holding down the control (Ctrl) key when a ‘move viewpoint’ button is clicked.  This allows much finer control of the railway position on the screen.  Corresponding changes have been made to the user manual and the help file.

More detailed checks added prior to file loading.

It had been possible to add multiple non-station named location elements at the same location (for example by a sensitive mouse that delivered two or more clicks when it should only have delivered one).  The effect was not visible on screen but it would cause subsequent railway file load failures.  This has now been corrected, and files that would not load previously because of this problem will now load, because duplicate entries are ignored.  Thanks to Michael for bringing this error to my attention.

The timetable clock now displays from 00:00:00 to 95:59:59, i.e four full days, before resetting to 00:00:00, in order to make it clearer when the time has run past midnight on the first day.  Time entries in the timetable are also now correspondingly valid from 00:00 to 95:59.

Sections 3.3 and 5 of the help file and user manual updated to add more information relating to non-station named locations and to reflect the above timetable time changes.

Help file and user manual section 6.3 updated to include a warning about running two railway.exe programs at the same time, which could cause session files to be saved incorrectly.