Timetable Descriptions

Introduction

Apart from the obvious schedule data, train types, and rules covered elsewhere, there are a few things to remember when preparing timetables for distribution via the SimSig website.

Timetable Name

This is a one-line brief summary of the timetable. This should be in the format .wtt - for example, "Nowhereville 10-Apr-2012.wtt". If you're going to write a date, don't forget that not everybody uses DD-MM-YY or YY-MM-DD, so make it unambiguous as to which is which - for example, a 4-digit year, and the month as letters or spelt in full.

This is will automatically become the file name when you save the timetable and you are advised to accept that default.

Do not include the version number in the name.

Timetable Description

This is a free text field you can use to firstly describe the timetable, and secondly add any notes pertaining to the running of trains. You can pretty much enter any text you like here but please get somebody else to proof read it before release. We all read what we expect to read, rather than read what we actually wrote!

This text will be viewable when the timetable is selected during the launch process.

Do not include the version number in the description. If the timetable requires a specific version of the simulation, write this as a line on its own, such as "This timetable requires the simulation version 1.2.3 or greater".

Version

This is the version number of the timetable, not of the simulation (and any resemblance to the simulation version should be entirely coincidental rather than intentional). It can be whatever you like but the overall number must always go upwards. The Build number should be zero for release versions. The very first release version should be 1.0.0 (major.minor.build). Each of the numbers can range from 0 to 65535.

Once you have released version 1.0, what happens if you want to make some edits and release a new version? Firstly, increment the build number - for example, to 1.0.1 in this case. Make your edits and release to your testers. You might need to make some more edits based on feedback from your testers. In this case, increment the build number again (eg 1.0.2) and re-release to your testers. Once everybody's happy that the timetable is good enough for release, set the major and minor values to appropriate numbers, and build to zero - so in this case, we could go to 1.1.0 if the changes were relatively simple, or 2.0.0 if the changes were major.

What determines whether it's a major change or a minor change? To a large extent it's up to you. If you just tweak the timings or platforms of a couple of trains then that's probably minor. If you re-platform an entire station through the day then that's probably major. The dividing line is quite subjective.

Filename

This will default to the Timetable name as above and if you follow the naming convention this should not need amending.

Do not include the version number in the filename.

Conventions

Why stick to the above guidelines? Twofold: firstly, if everybody follows a convention, it makes it easier for the end user to sort and use your timetables. Secondly, the SimSig software is geared up to look at version numbers. While user-supplied timetable updating is not yet supported in the SimSig Updater, it may soon be, so the sooner you follow this convention, the more likely it can be included in the library automatically and sooner. The version number increment is required by the software to compare your local copy against the server version: if the (newer) server version says 1.2.99 and the local copy says 1.3.0 then it assumes the local copy is newer as it is a higher number.

Last edited by Peter Bennet on 11/05/2019 at 20:10