Atomic Systems

This is prompted by the contrast that whereas some very interesting scenarios are being published (most of them payware), the Scenario Creation subforum has the least number of posts in the whole Rail Simulator forum on UK TrainSim.This suggests a very low level of activity, but does it indicate a low level of interest? By comparison, Activity Creation has the 5th highest number of posts in the MSTS forum.

This is also the reason for posting this under General, rather than in its <right> place, where it probably won't be read.

The idea is to get more people involved in building scenarios, especially those who have tried and were badly frustrated in the attempt.

For most of us who have tried, if we ever get the scenario to work, by that time we never want to see the scenario or Rail Simulator ever again. Fortunately this feeling usually wears off.

A typical experience goes like this: start a new scenario, place player train, add pickups, and run. Add 2nd train and use preview to check likely passing place. Reset, and 2nd train has disappeared. Decide to change start time of scenario, add 2nd and 3rd train and preview. Player train doesn't move. Change its start time and nothing moves. Check and find train start times are now like 30:45, etc. Abandon and pour stiff whisky.

So how are those people who are making working scenarios doing it? Well, I suspect they have made a map of the minefield and rigorously avoid the mines by working in a disciplined way, something like this.

(A TRAP is something that if you do not do correctly, the scenario will break. A TRICK is a way of doing something that is not obvious. A TIP is a suggestion intended to make scenario building easier, safer, faster and more fun.)

* TIP * When you start a new scenario, before you place the scenario marker, move to the approximate location where you are going put the player train in its start position.

* TRAP* If you need to change the start time of a scenario (after you have placed any trains), do NOT use the Scenario Editor to do this: use Mike Simpson's Kickstart instead.

* TRICK * If you need to change the driver locomotive of a train (the one with the Driver and any other discs on), you can only do this with KickStart, if you don't want to redo all the instructions for this train.

* TIP * Do your Player Service first and note its timetable to use in setting location and start time of AI trains.

* TRICK * Use the Performance Percentage (on all PickUp and StopAt instructions) to slow down or speed up AI trains.

* TRAP * If you use the Preview mode, you must Save the scenario beforehand, and reset the time afterwards, and do nothing but run in preview mode in between.

* TIP * Add AI trains one at a time, and (Save, then) Preview the scenario (then Reset the time) after adding each new train, to see how it affects the overall scenario.

* TIP * Use the Drivers disc (click on any train's Driver disc and click on the Drivers button in the flyout on the right to get a list of all trains) to check that all trains have the status Successful.

* TRAP * Each train should have a PickUp or StopAt disc as well as a Final Destination on the Driver Disc and these should be achievable (Final Destination NOT before the last PickUp/StopAt point).

* TRICK * You can start an AI train (as many as you like) from inside a portal. Pace the train near the portal and complete all its instructions. Now double-click on the portal pillar, click on Add, and click on the train's driver loco. If you want to alter the train's instructions or remove it from the portal, just double-click on the portal pillar again and select Remove, and click on the train in the list. Place the train gently back on the track again (it's attached to your mouse pointer).

* TIP * Freight train instructions will normally have StopAt instructions, whereas Passenger trains will have PickUp instructions. You don't need both for a Passenger train to stop.

* TIP * Make AI paths as short as possible, such that the Player train will (within reason) always see them and only make PickUp instructions at stations where the Player Train's path is likely to intersect.

* TRAP * Do not have more than one AI train shuttling between 2 portals: one will crash into the other after the first cycle. If you send an AI train into a portal and have further instructions afterwards, check that scenario <plays> (the preview tends to be too optimistic) successfully before relaxing

* TRAP * Do not use a portal as the starting point or destination for the Player train: as a destination, the player train treats the portal the same as buffers: ouch!

* TIP * You can use Portals as both source and destination for AI trains. But do not send too many trains into the same portal. How many is too many? As above, play the scenario to check.

* TIP * Avoid conflicting paths (eg trains crossing or using the same track in opposite directions) as far as pssioble, and if unavoidable or you are determined to do this, once more, <play> the scenario to check that it works.

* TIP * By all means, use Destination Markers (orange, where sidings are yellow, and platforms are green, these are sometimes known as Gates) to try and force your (player or AI) train to take a specific path. But when you Preview the scenario, do not be surprised if the despatcher outwits you and still manages to send the train a way you did not expect!

* TIP * Keep the 3D viewpoint on the current train you are editing. Select and lock the right flyout window (Driver, PickUp, StopAt, etc) , and use the 2D map to move to the desired location. Zoom in on the centre of the marker you want to select as the location. Now click on the location selector in the flyout and click on the track near the centre-point of the marker's extent (and/or the centre of its name). The marker name should be inserted into the location name. You should never have to move your viewpoint on the 3D map except to relocate to where you want to place the next consist or whatever. For this you can usually use the GoTo list (qv).

I look forward to hearing what I have got wrong, what I have left out, and what can be done more easily! If only it helps us just to <enjoy> RS a bit more.

Russell Westwood

Hi Russell

Very good advice and spot on with your observations.

I would like to add that since uploading The Big Layout, I have realised that although I added in a large number of extra markers as waypoints and a few portals, I should have added in many more of these as they help enormously in the writing of scenarios to guide both player and AI traffic through quite complex paths. In particular, markers in passing loops and next to passing loops will help on single track.

Anyone writing their own scenarios for The Big Layout or any other route for their own enjoyment can add in as many markers and portals as they like and as long as the track or signalling is not changed, they can still run published scenarios for that route, but writing scenarios for the basic routes is limited. I will not be publishing an updated version of The Big Layout to avoid messing up any scenarios people have written and want to upload, but I will take more care about this in my next route.

A message to all route builders is, therefore, add in many additional markers as waypoints and lots of portals all over the route, not just at the ends of lines, before publishing your final route.

In checking if a scenario works, I would highlight the help that the drivers facility gives. If you add in a new AI train for example, clicking on the 'Show Driver' box and then on Apply will start the scenario running quietly to itself and then a few seconds later clicking on refresh will indicate the success it it having with the different trains with some showing as Succeeded, Pending or Failed, and keep refreshing until finished where the final listing will show if any of the trains fails. This only takes a few moments to run and helps to identify failed paths. If, for example the player train succeeds before the addition of a new AI train but fails afterwards, then you know that the new AI train needs re-pathing.

Very good, really appreciate that!

Matt.

Some excellent stuff there, nice post.

Can I just check one thing mentioned though

Russell wrote:* TRAP* If you need to change the start time of a scenario (after you have placed any trains), do NOT use the Scenario Editor to do this: use Mike Simpson's Kickstart instead.

Why can't people use the Scenario Editor? I can understand that Kickstart may make changing the start time a faster process, but I cannot see why people are not to use the tools provided.

RSAdam wrote:Some excellent stuff there, nice post.

Can I just check one thing mentioned though

Russell wrote:* TRAP* If you need to change the start time of a scenario (after you have placed any trains), do NOT use the Scenario Editor to do this: use Mike Simpson's Kickstart instead.

Why can't people use the Scenario Editor? I can understand that Kickstart may make changing the start time a faster process, but I cannot see why people are not to use the tools provided.

On this particular point Adam, I think you have alredy answered your own question - Kickstart achieves the result far faster. The RS process in the current scenario tools would be some 10-15 seconds per train slower, unless, of course, you know better.

Hi

It may be just my set-up but when changing the start time of the scenario on the marker icon, the times of the player and AI traffic are not also updated.
With Kickstart, the starting times of all traffic in the scenario are updated.
Is this right?

The same situation applies to mine also Acorn

Fair, so my point was that Russell advises against the use of the provided tools, where as really he means its faster to use 3rd party tools. This would result in the point being a tip and not a trap

haha, nice response Adam.

Good parry Adam!

I think this may be one for the Mk3 wishlist.

RSAdam wrote:Fair, so my point was that Russell advises against the use of the provided tools, where as really he means its faster to use 3rd party tools. This would result in the point being a tip and not a trap

Haha, well "Touche"'d!

To answer Adam, the first reason I call changing the scenario start time using the Scenario Editor a trap is this: some time ago I created a scenario with a player train and 50-odd AI trains. I then decided it would be more fun if the scenario started an hour later (or earlier). So I changed the start time. At this point the scenario <broke> - none of the AI trains would move. It was some time later, after I had deleted the scenario, that I realised that changing the scenario start had no effect on the AI trains' start times (you can drive the player train anyway as soon as the scenario starts).

The second reason is as indicated in my initial post, where start times can become corrupted: I cannot recall this happening if I <haven't> changed the scenario start time in Scenario Editor, so as a precaution, I avoid this. Changing the start time of an individual AI train for a better interaction is OK. There are combinations of changing the time and using Preview mode which seem to corrupt scenarios.

I would like to suggest that Preview mode has a safety belt built around it. When you initiate a Preview (by selecting Run), the program should (check with the user, then) <automatically> save the scenario before starting the Preview. On exiting from Preview mode (by any selection other than Pause, Run, Change view (2D/3D) or Change speed, the program should (check with the user, then) <automatically> reset the time to the scenario start time. If the automatic time reset is found to be totally reliable, then the Save beforehand could be dispensed with. The Preview mode is a superb feature (although not perfect) which is being avoided because it is <known> to cause broken scenarios.

I have remembered a few more TTTs.

* TRAP * Do not allow other trains near a portal when a train is due to emarge from that portal: the emerging train needs a clear track.

* TRICK * The biggest delay in working up a scenario can be in switching from edit to run and back to edit, via the menu. But there is a quicker way - from Run mode, you can switch back to Scenario Edit mode via the World Editor: In Run, press Ctl-E then select the Scenario Edit icon (rightmost of top row in top left flyout). You are back in your scenario for more editing much faster (and the fact you lose the runtime session is not usually an issue - if it is, Save before pressing Ctl-E)

* TIP * (This can also be a trap) Whilst it is possible to develop a scenario which involves using a turntable (or a traverser), you are on your own and will have to run the scenario to check whether it works. Try putting the turntable movement at the end of the scenario, when the loco comes back on shed.

* TIP * Preview mode has some limitations: it does not "know about" turntables (see above) or loose consists, so coupling and dropping off instructions result in the player locomotive running through the consist to the end of the marker extent (to make sure of finding its consist?) It also tends to be optimistic, for example Preview will show trains shutling between portals all day, but in reality they don't. In general use Preview as a first stage test, but always run the scenario to the end to ensure that it does work.

Hi Russell, very informative post. If the user incorporates all these suggestions does it prevent the crawling al problem?

BP

My understanding of crawling AI is that this happens when the despatcher "forgets" about that train. And once forgotten, it is the same as a loose consist sitting on the main line: invisible to other AI trains and so sooner or later it will probably be crashed into! I do not know what causes the despatcher to "forget" about a train though, so cannot with any certainty predict the effect on their occurrence of the adoption of these ideas. It is for this and other reasons that you must run the scenario as a final check, and not rely on the Preview (where trains <never> crawl).

All I know is that my whisky consumption has gone down dramatically!

Perhaps someone else can shed some light on what causes this despatcher's amnesia?

Hiya,

The crawling AI is not forgotten by the dispatcher, but a train that has lost its instructions. For reasons that are still to be resolved, it is possible for the Dispatcher while holding bits of paper with instructions for each AI train, to drop one of those bits of paper. At this point the Dispatcher doesnt know what to do with the train, so brings it to a 0.5mph crawl for safety reasons. The signals will still act accordingly so all that happens is you get a blockage on the line.

You could treat it as a 'failed' train in prototypical terms, as the net result of this is the network slowly grinding to a halt in a jam.