A scenario is defined as a series of events which are depicted in the simulator. Generally scenarios rely on player input.

Scenarios can be based on real workings or can be fictional. In both cases the scenario should be immersive and require a reasonable degree of interaction from the player.

A subscription scenario must adhere to the following;

Timetables
– The correct workings must be used. This data can be obtained from sites such as Realtime Trains or Open Train Times. A small deviation from this is acceptable if necessary to overcome pathing’ or signal issues with the simulator. This deviation should not be significant.

– Arrival and departure times should be as accurate as possible. Remember that services rarely stand at stations for exactly the allocated time so some variation should be considered.

– AI (computer trains) should be accurate to the timetable. If constructing a scenario set in the past it is appropriate to include any delays where possible.


Rolling Stock
– Rolling stock used must as accurately as possible reflect the workings of the day. Where an element of stock is not available for the simulator a suitable alternative should be used.

– The correct livery should be used. This means that as far as possible, the correct liveried train must be used in the scenario. For ‘special’ liveries applied to some trains (such as the LNER HST/225 fleet) we understand that accurate information regarding these is difficult to come by. Therefore a ‘best guess’ is acceptable. No ‘special’ livery should be repeated in a scenario unless it genuinely does pass the player more than once in reality.

– Reskins should all be available. You must not use a reskin or stock that cannot be obtained. A list of requirements and links to the site where they are available is required.

– Train numbers should be accurate for special services. For example, if a specific number is known for working a specific service then this should be replicated. There is a greater need to accurately number the player service than AI. Where numbers cannot be researched then the default game numbering is acceptable.

– Excessive stock should not be placed in yards. This impacts the performance of the scenario unnecessarily. It is appropriate to place just the ‘perimeter’ stock in a yard. This means that where there are many trains stood in a yard, just those on the outside of the group should be placed leaving a ‘gap’ in the middle.

– Freight workings should be as accurate as possible. The use of Google and image sites such as Flickr will help in identifying freight services.

Functionality
– Train scripts must be functional. There must be time for the player to set up their service at the start of the scenario and time for them to interact with the stock where required. This includes things such as setting up the cab, setting a destination, setting the GSMR and other systems which may be functional on the train used.

– The scenario must run end to end without requiring that the player save and reload or TAB past an excessive number of signals. Where a TAB is required to pass a red signal a message to the driver should be present.*

*TAB is a way of passing a signal at danger in Train Simulator.

Route
– There are no specific requirements to the use of route in a scenario. It is recommended to avoid routes which have been used a lot recently. Duplicate or very similar scenarios are unlikely to be approved at the same time.

A route is a depiction of a geographical area of the world and built for the simulator by a user or series of users using placement of various assets in the game world.

Routes can be any length and depict any part of the world.

A route released on the subscription part of the site must;

– Be to a reasonable standard, this means it must be;
-complete to the point that it can be driven with all major scenic assets placed and no significant gaps in scenery exist
– Correct and functional signalling exists
– Track and associated properties are complete
– A minimum of three functional scenarios are included. These do not necessarily need to be subscription quality but they should demonstrate the route well.

– Routes must be correctly and appropriately named.

– Routes should keep asset requirements to a minimum.

– Work in progress routes are acceptable providing a reasonable section is completed to a reasonable standard as detailed above.

Rolling stock is a train, carriage, locomotive or wagon which can be moved around the track by the player or AI (computer driven)

All subscription rolling stock must adhere to the following;

– The content must be functional. This means it can be driven (if appropriate) or hauled.

– The creation must be a reasonable representation of the real thing

– At least one livery must be included

– Physics and sounds should be as accurate as reasonably possible.

A reskin is a change or modification to the texturing of an asset within the game. Commonly these are the change an item of stock into another livery but they can apply to scenic assets as well.

A subscription reskin should adhere to the following;

– The updated files should be a reasonable representation of the real thing

– The asset on which it is based must be available

– A similar or identical reskin must not already exist.

– No brands can be included (these should be available separately)

– The reskin must be complete and not a ‘work in progress’

All content is subject to review and will need to be checked before it is approved. This will take longer than non-subscription submissions so please be patient.

All content must clearly be marked as SUBSCRIPTION ONLY in the title. This is so the moderation team can identify it and review it. Failure to do this will result in it being approved as non-subscription content.

No submission will be approved if it contains;
– Illegal content (i.e. pirated content or includes files which you do not have permission to use)
– Banned workings (depictions of fatalities, suicide, crashes etc). The recovery of the network after such events may be considered on a case by case basis for approval but our decision is final.
– Please make sure all requirements are listed and a link is provided to where they can be obtained from.
– Please make sure you have the required permission to use the product as a requirement. Thomson Interactive products must not be used.
– You must have the right to submit the file to us. This means if the content is generates by a collaboration of users then we would need the consent of all users in that collaboration in order to approve it.

Please note that we may from time to time delay the release of some content if it conflicts with other content or if we have another good reason for doing so. We will discuss this with you should we need to do this.