Tutorial Making A Scenario (basics)

Lots of images in this, so it's going to take a few posts... if anyone posts in the mean time i'll delete it, and apologise now, just so that it keeps the flow.

I'm going to write a scenario for the East Coastway route, so let's start by getting the map loaded. Find the BrightonEastbourne folder and inside it the Map folder, and double click on East Coastway Map.


Once the map is loaded, let's get started.

For this scenario i'm just sticking to the basics, and we won't be looking at how it is in the UI yet either - the goal is to show you how you get get a scenario going and test it within the editor itself. I'll be covering the Objective system in another tutorial as well, this is a kind of bootstrap tutorial really.

Make yourself a plugin - i'm calling mine MattsScenarios - follow the plugin creation tutorial if you aren't sure how or haven't done it yet.

In the folder, let's create a folder of our own to put Scenario 1 in.


Go into the Scenario1 folder and let's make three files to get started.

The first is the Scenario Definition - right click in the content browser, select Miscellaneous and then Data Asset.


From the window that pops up, type "ScenarioDefinition" into the search field, select it from the list of results once it appears and then click Select. Let's go ahead and call that Scenario1_Definition


Continued...

 

Here's what our Scenario Definition looks like:


Let's make the second file, that will be the timetable itself. Not quite the same procedure, right click in the content browser, select Miscellaneous and then Route Timetable. Let's name that Scenario1_Timetable


Final file is the Objective Manager. Right click on the content browser and select Blueprint Class. In the bottom of this, you'll find an expandable element called "All Classes", expand this and in the search field, type ScenarioManager_BP - select it from the list of results and click Select. We'll name it Scenario1_Objectives.




Note that a little asterisk on a file means it isn't saved yet - let's go ahead and make sure everything is saved by clicking on it and pressing CTRL+S (or right click on it and select Save).




Continued! (this is gonna take a while...)

 

Ok the first file we're going to set up is the Scenario Definition file, this is what sets up the basic attributes of the scenario. Double click on it and let's take a look.

There's lots of information in here and honestly lots of it you won't worry about for a bit and some of it is even deprecated these days, so don't be concerned about how much there is.

Let's start by populating some data.

Display Name - "Matts Scenario #1", this is what will be displayed in the UI.
Mandatory Tutorial - nobody likes this, don't tick this.
Show in Training Centre Fundamentals - aside from someone not getting the memo about spelling of "Center" for TSW3, ticking this is what will put it in the list of fundamental training tutorials, if you feel that's a suitable place for what you're making.
Plaintext Name - "MattsScenario1", this should be the name of the scenario without any funky characters or spaces etc, must be unique to you, is not displayed anywhere and is just used for internal stat tracking and the like.
Scenario Type - If it's a standard scenario then set it to "Mission" and if it's a Tutorial set it to "Tutorial".
Order Number - influences where it will appear on the menu.
Description - I feel like this doesn't need much explanation.
Difficulty Rating - select 1 to 5, 5 being very hard.
Difficulty Tags - not currently used but will be soon - i'll add a tutorial on that later. Leave it empty for now.
Minutes to Complete - again, feels fairly self explanatory.
Start Location Tag - a little tricky because you need to know the exact names of the stations used in the map, which you can't load. Fortunately you CAN load other scenario definitions so you can see what they look like in some of those and perhaps get a feel for an educated guess about what it might be. It's pretty predictable - for me, i'm going with "Brighton". This is purely used to highlight on the map and should be considered to show the player what extent of the route will be covered, it's less about where it actually starts and ends and more about "you'll be in this bit" so don't over think when it comes to "but i'm going from Brighton, to Lewes and back to Brighton again!".
End Location Tag - same deal as Start, but, where it ends! I'm going with "Lewes", because, i'm going from Brighton, to Lewes and back to Brighton again, and I promised I wouldn't overthink it.
Map Waypoints are just more location tags and mostly you won't need them, but they come in handy on a route like Rhein Ruhr Osten where there's two ways to get from Wuppertal to Hagen - you'd put a tag for a station on one line or the other in here to influence which map routing is shown on the simple 2D map. Let's leave that for now.

So far:



Trains Involved - i'm going to be using a Class 101 DMU from Tees Valley Line as my player train. This setting is not determining the player train, it's simply populating the UI for the player that will see it when they select it. You can literaly put anything here, or nothing, i'd suggest this is a good opportunity to be helpful instead though This setting should contain the RVD (Rail Vehicle Definition) so in my case i'm going to set it to the RVD_DSN_BR_Class101_DMBS. As I say, it doesnt matter if you dont have exactly the right vehicle as this will not affect the scenario itself, just the UI. If you actually end up driving the DMCL... you can live with that shame privately.
Icon - the image for the UI, i'll cover what these are and specs in another tutorial.
Next Scenario - you know at the end of a scenario and it says "Next scenario?" - this is where you specify what that next scenario will be, so if you make a pack of 5 scenarios, in the first scenario you can put the scenario definition for scenario 2 in this slot and then players will be naturally taken to that scenario.
Recommended Tutorials - a list of tutorials that you'd recommend they play first, again these are scenario definition files. You'll need to find the relevant ones from the various DLC and link them in here - or not - up to you, it's optional. If set, and the player is missing completion of any of the indicated items, it will pop up and say "you should do these first!" and the player can do that, or not, up to them.
Next up we have the timetable entries - let's just put our Scenario1_Timetable into all of them (ignoring the "Timetables" one at the bottom, note the plural in the name). This tells it what timetable to use and allows Xbox 1 and PS4 to use a different timetable if you want to do that.

Let's just check what that looks like:



Ok - Now things start to get a little more interesting, but we'll come back for most of this in future tutorials, for now, we'll just set up a couple of things.

Player Only services - click the Plus sign and add "PlayerService" as the name. Any named services in this list will never be taken over by an AI driver.
Date and Time - Let's set this to 2023.09.10-18.30.00 +0100 so our scenario is at an interesting date/time. This will mean the scenario is 17:30 - note that it has a plus 1 hour summer time offset on it.



Weather Scenario - when you drop this down you'll see all weather scenarios in the DLC library, i'd strongly recommend that you stick to weather scenarios that are on the route you're using (unless you're making your own ofcourse... future tutorial...) you can use the three letter abbreviation for a route to help filter the list - for East Coastway that's ECW. For now, let's set it to WS-ECW-Preset-LightCloud so the sky is at least interesting.




Continued...

 

It's crucial you now set these ones and never forget in the future!

Scenario Manager Actor Class - this needs to be the new objective manager file we made, Scenario1_Objectives. Drop down the list and search for it to find it and select it.

Tick the "Auto Generate Objectives From a Service" tickbox, this will mean that your general "go to", "go via" etc instructions in the timetable will just get automatically made into objectives for the player which is a time saver. Later for more advanced scenarios you may prefer to not have this and manage it all yourself in the objective blueprint but you're a way off that yet (we usually leave it on in ours too)!

Once you tick that, the Objective Composer Class option becomes selectable, we'll use the one built into the route - so expand it and type "ECW" and select ObjectiveComposer_ECW. All routes should have one just use the one that it comes with to keep things simple.


You're probably thinking... hey! Matt! but i'm making a route of my own - how do I make an Objective Composer?! - Future tutorial. :-D

Leaving this section looking as follows:


I'm going to leave everything else as it is at this point, there are some other fun things in here to play with and we'll be back here later to do that - but for now I kinda want to get you the rest of the way to your first train doing a thing so you can see some results before we start digging deeper.

Continued...

 

Save that, and let's open the Timetable, this is where the fun starts.

There are a few things to note here before we get stuck in.

First and foremost, the 3D view window (the one titled "EastCoastwayMap" if you have also got the East Coastway route open), it's the one that is the main UE4 window, MUST ALWAYS BE VISIBLE. It can't be minimised, it can't be a tab in the background. You CAN put other windows over the top of it but as far as *it* is concerned it must be on the top. Why? Things stop rendering properly and everything gets super frustrating trying to figure out why stuff isn't working. Totally not made this mistake a few times and banged my head on the desk once I realised what i'd done. Say it again with me - Keep the main window "visible".

Second, if you have multiple monitors this is a good time to start using them well - if you don't, think about investing in multiple monitors, your sanity will thank you.

So we have the timetable window open and we can get the route map open at the same time - Window, TSW Tools, Route Map.
Once open, scroll the mousewheel back to zoom out on the map and you'll see the map is there it was just off the bottom a bit - move and zoom to get it so you can see Brighton and Lewes.



Now you have context, let's get our little DMU placed in Brighton somewhere. Zoom into Brighton.

Before we get started, let's get some basics set up in the timetable defaults.

Name and Description you dont need to worry about until you're making service mode timetables later on. Leave them blank for now.
Route must be set to point to the route definition for the route you're using.


Skip down a few, set the simulation start time to the same as the start time of the scenario from earlier - which was 2023.09.10-18.30.00 +0100

Now set the simulation time limit to more than the length of the scenario - I have no idea yet, and we can come back to this if needed, so i'm just going to set it to an hour.

These simulation constraints aren't used at runtime, but you can use the timetable simulator (normally used for service mode timetables) to run a high speed test on your scenario, which can be a massive time saving when checking out dependencies and such to make sure that all the trains get to where they are supposed to. It will also then give you the data tracks needed to use the playback tool, but, spoilers. We'll set them up for now but we won't use this until later as it's a bit more advanced.

On the Timetable designer, right click on the main canvas and select Create a New Formation. This is slightly misleading because this is not going to actually create a new string of vehicles where you can pick the vehicles - it's going to let you place a predesigned formation into the timable. Don't worry you can make your own formations... that'll come later.

It'll ask you to name it, let's call it PlayerFormation (doesnt matter really what you name it, you can scold yourself later when you're trying to figure out what Formation_44 is though ).


Quick note: If auto save is enabled, you're going to get pop ups periodically warning that your timetable is out of date and needs compiling, this is a safety warning just reminding you - if you're still busily working you can just accept it and let it get on with it. The time to worry is when you're actually saving it and it pops up because you probably HAVE forgotten something then, but at this point in time you dont know what, so... press ok and move on.

We need to tell the formation entry what actual train formation to use, so let's set that next.



Ok a few settings to explain:

Spawn In Vault - if ticked, this will spawn the train "off-world" so that you can bring it onto the world via a portal later. Ignore this for now, we havent covered portals yet.

Spawn Configuration - again, voodoo. leave it at the default for now. Later on you can use this on some trains to say if they spawn in Vacuum or Air brake mode by default for example.

Spawn Type - How do you want the train to be set up at the start, Parked Preset means cold and dark, Running Stopped is usually for a train that you're taking over from an intermediate position (so expect switches to be off etc but engine running brakes charged etc). Finally, Running Active is a train that's mid-service usually and is the easiest for a player to get moving, almost always should end up with "release brakes set to forwards apply power". I'm going to go with Running Active.

Let's skip Spawn Facing and come back to it. We need to get the train placed on the map. Click "Pick Location" next to "Spawn Location" and then click on the track in the route map.

Nothing happened - well, except for some wierd numbers appearing. (tech note: these are the unique of the track ribbon you selected, and the position along the ribbon... you dont need to care about this particularly though )


We need to tell the editor that the scenario we're making is our "Play In Editor" scenario - and we can do that for now just on the timetable itself - at the top you'll see a button "Set As PIE Timetable", click it.

Continued, darn it.

 

Before I was so rudely interrupted. *clears throat*

We need to tell the editor that the scenario we're making is our "Play In Editor" scenario - and we can do that for now just on the timetable itself - at the top you'll see a button "Set As PIE Timetable", click it.



If all has gone well... the train should now appear on the route map.



If it didn't - check the following:
- The "Route" entry on the timetable defaults page must be set correctly
- The route must be loaded of course
- The 3D view window MUST BE VISIBLE (the route map is the biggest thing that doesnt get updated if your 3D view isn't visible).

Now, my train is clearly not in the right place - I clicked where the bottom of it is so we need to flip.

Experiment with "Spawn Facing" and finding new positions until you have the train right where you want it.


This is good, we now have our train in the world, we need to give it some instructions.

Drag a link off the formation node and create a "Create New Service" node. Name it PlayerService - this time the name is a little important because we set it in the Scenario Definition, if you remember. Other than that however, you can call it what you want.

Tons of parameters here, let's just set the Start Time to the beginning of the scenario - so 17:30. This one is LOCAL TIME which means it doesn't have any offsets on it.



Next, let's make a run to Lewes non stop. Drag a node off the right of the service node and make a Go to. Select it, and let's set its destination by clcking on Destination/Location/Pick Location. Pan the map around and click on Lewes Platform 5 somewhere on the right hand side, this represents where you want the marker to appear in world that the player stops at - usually the front of the train, for some people it'll end up being the back, and if you're me, probably miss it altogether. Some players can't be helped.

Nothing has appeared on the map yet - so click OFF the go-to node, and click Compile Timetable. Then click back on the go-to node - and notice the train is now there. If you pan around, you can also see the exact path the train will take. Does it look ok?



Continued...

 

Now we can see it:



Interesting to note that the actual stopping point the train will have is based on the stopping boards on the platform not necessarily where you click. You can override this with "force exact stop" which will then always go exactly where you click.

Ok we need passengers. Drag a new node, this time "Load Unload". Expand Loading Criteria, and the first entry, tick the "Specific Cargo Type" box and set the Cargo Type to Passenger (I mean in your heart you always knew you were cargo really, and this will just reinforce that belief). Again there's tons of things that can be set here including the dwell time but let's just leave them as they are for now and move on.



(Is that Auto Save bugging you enough yet? Go to Edit, Editor Preferences, type Enable AutoSave in the search field and untick it to stop it. However, you are now responsible for all saves and can blame nobody, including me, if you fail to do so and lose work. You may however fully credit me for time and sanity saved).



As you're making changes to a timetable, hit compile and then save periodically for a smoother experience and just to keep things saved.

Ok let's bring this train back to Brighton. One thing that you had to have done right for this to work is made sure the BACK end of the train has cleared the intended departure signal for the return trip and you can achieve this by ensuring you've set the marker far enough away that even when a fool like me plays it they can't get it wrong.

This is a good stop ready for the return journey.


This is a bad stop, the return journey simply won't work because the westbound starter signal is needed to change the points at the junction and since you will start beyond it, that won't happen.


Continued...

 

Ok let's drag off a stop-at and a load-unload in London Road and then Brighton. You could just copy-paste the two we used for Lewes and update the stop-at location for that instruction, once you start setting more parameters on your objectives you'll find this is a big timesaver.



Here's what it looks like with that done, so we can cap it all off with an end service node.



Now when you press Compile you will gain the coveted tick of success and feel that brief shot of dopamine.



If you click on some of the stop at's you should see the train and its stopping points and follow the path it's taking too. Check you're happy with everything. It's time to give this thing a run!

Make sure you're compiled and saved, and close the timetable view. On the map view you can right click on it and select Jupmp 3D world to here. Use this to jump the 3d world to where you train starts. Once you click that give it a moment, it's busy.



Once it's finished loading into the 3D view, move the camera around abit just as normal for a camera and find the surface of the ground and let's see what the player train looks like in the editor.

 

Couple of tips:

• Mouse wheel will allow you to speed up and slow down movement within some limits - there is a control on the top of the 3D view to make bigger changes to this.
• Holding both buttons down and moving the mouse around will slide you left right and raise and lower your height.
• Hold right button down and move mouse to look up down, left right.
• WSAD keys to move around.

See these blue boxes on the track? that's a train model. The boxes are the bounding boxes for each vehicle. Move the camera so that you're above the ground nearby the front of the train.

Before we go any further, right click on the scenario definition file (Scenario1_Definition) and set it as the play in editor scenario. When we hit play, it will run this scenario now.


On the top button bar there's a - DONT click it yet - Play button. Carefully click the down arrow next to it for settings. In here I want us to click the "Current Camera Location". Later when you're further on you'll want this to be "Default Player Start" but as we haven't added a Player Start yet...



Ok, we should be ready to go. Make sure your camera is somewhere sensible ready to spawn in as the player on foot and press PLAY.

It's going to take a few minutes to boot the game up, but once it does, here it is !



Notice how the objective is already live and everything's good to - get in the train and test your scenario and see if it works!

If you have the timetable open as you do it, you can see things being ticked off as you go with time markings going in etc. You can use this to debug AI trains as well later on, all trains will update on the timetable view in real time.



Couple of tips:

• When playing in editor you can press F11 to boost it to fill the entire UE4 window.
• Drop down the play button again and you'll see there's other options - the other one of common use is "New Editor Window (PIE)". This will open it in a new window which you might find easier paticularly if you followed earlier advice re: multiple monitors perhaps.
• When you're done, the play button has changed into a STOP button. I'll leave that one for you to discover.

There's lots more we can cover later:

• Setting up the UI so it shows up and looks good in the menu
• Adding scenario specific objects
• Adding a player spawn on foot start point
• Making the player spawn straight into the train
• Adding some objectives for subtitles and control movements etc
• More advanced timetable shenanigans such as shunting *sooo much fun*

Lots more. But, I wanted to get this basic grounding covered first.

That's it for now - we'll come back and play with other things in future tutorials.

AND we're done. Finished. If you wish to reply, now's the time, thank you for waiting

Let me have any feedback on the style and format and i'll try and incorporate into subsequent tutorials.

 

If you run via a scenario definition, it will set it up automatically to the start time in the scenario, so you dont need the set local date time.

If you run via the timetable, you will need to set the time yourself, yes.

Matt.

 

For the first part of our question - you can load the scenario definitions for existing routes, so find a scenario on the route in question and copy how they did it.

Matt.

 

Even when you run via the scenario definition? I'm sure I tested it and it set the time for me... i'll re-look at that.

Matt.

 

yes that is correct, you must run it via the scenario definition if you want the time, weather and other things to take effect. If you run it via the timetable they won't, and you must set the local time yourself.

 

That never improves i'm afraid

 

No there isn't i'm afraid.

Matt.

 

Yep, East Coastway.

Matt.

 

It is not currently possible to package the content into a pak file, as soon as we have that in an update i'll show how to do it.

Matt.

 

Currently. Hopefully won't be long to get the packaging sorted. Use the time to continue to add more to your scenario

Matt.

 

Ok so YorksAndy issue is an excellent learning example - he's got something quite interesting going on but it falls over a number of things (not a criticism at all btw - none of this has been explained anywhere ).

So - the idea is that a 40 and BG's is coming in from red bank sidings to Manchester, dropping them off and heading back to Red Bank. Meanwhile, a 45 leaves shortly after from Red Bank to couple to the BG's and bring them east. Nice little bit of hand off and interplay between player and AI.

The symptoms were trains basically getting stuck. The 40 wouldn't move back to the yard and the 45 wouldn't approach the BG's.

First issue - whenever you change direction you MUST go via a SIGNAL before you get to a POINT. Signals Change Points. Because inherently the system is akin to NX (Entry Exit) control, you can only change a point if a route is set between two signals. This wasn't happening here, the 40 was pulling forwards just past the point and then trying to change it and take the other exit - but it can't.

Unfortunately, this falls onto a limitation you're going to potentially find in some routes - if the signalling isn't set up to support it you'll have to change your goals because you can't adjust the signalling nor can you tell it to ignore it.



You can see that if the loco now reverses, it can't change the point - there's no signal. So what happens now is the loco is sat indefinitely complaining in the log that it can't move because it's waiting for a junction to be set.

The only solution here given there's just no signals now facing east on this western end of Manchester station is to change the plan.

Now, I bring the coaches into the platform - not quite right, but it'll work for our purposes.



Notice how i've left plenty of room for the loco coming in to couple up to the back of the train too and remain clear of its starter signal heading east.

I can now pull the loco now forwards into the other platform because it has an eastbound starter on the right end (notice the green flags - they are signals)



If you now follow the intended path of the loco next, going to the right and taking the first junction over to the diverging direction, there's a signal first, the flag points in the direction of travel that it represents (NOT the direction the signal is *facing*) - this is now a working situation.

Next up was to look at the 45. It's already a lot happier because the 40 is now getting properly out of the way.

First thing I noticed was that the 45 departs the yard exactly one minute after the player train - which means that if the player spends time in their loco setting up or otherwise stargazing, the 45 will get out first and... bad things. We can use a dependency to fix this. I've added an intermediate waypoint on the way out for the 40 so that it's clear of the yard and then use that to release the 45:



It's just a go-via but comfortably ahead so that now, no matter how long the player waits, the 45 will just sit there until you trigger that go-via before it can proceed.

Continued...

 

So how's the dependency actually set up?



The white marks. The go-via at the top is the departing 40 and its way point, the stop-at at the bottom is the instruction for the 45 for its first destination. The white line is the dependency. The flow is as follows - when a given instruction completes, a signal is sent down the RIGHT hand side white departing link into the LEFT hand side of wherever it gets to. If a node has inputs on its LEFT dependency node then it will NOT start them until that link goes active.

We've got another dependency to add later too, so we'll see it again.

Back to the 45 - it was set to go right up to the platform before, but that won't really work because there is a train there and unless you set up a call-on dependency (i'll cover that another time, it's a bit more complicated to explain) then the only way into an occupied section is with a couple-to instruction. To be clear - a call-on dependency is probably the best way to do it... but let's keep this simple old school for now.

What i'm going to do is bring the 45 up to the final home signal before getting into Manchester's junctions - that's the first stop-at you can see above. I'll bring the train to a stop, then the player will need to contact the dispatcher and this will grant them permission to proceed to the coaches.



The next issue is another one that will cause great confusion until you get used to figuring it out so i'll try and explain how you do that.

The couple-to instruction has two settings relevant to this discussion:


These can be seen in the node itself too:



It is CRITICAL that these are right. Even if they make no sense and its obvious what you *mean* if you get these wrong things just dont work.

As specified originally they were the wrong way around - but let's explain how you figure the right way.

Let's think about what we're trying to do. The 45 is coming down to the coaches, and we know the "front" of it is the one that's going westbound. For locos it's easier to tell because the graphic or a loco has a round end and a square end. NOTE: Confusingly... there are cases where this will get reversed... so... you're going to find some wrinkles that cause confusion, usually related to things spawning in reverse out of portals or where other coupling operations have taken place. For this case though, it's straight forward.

"This Formation" is going to be FRONT as we want the front of our loco to couple up to the coaches.

For the coaches, i'll click on the final instruction before the train uncoupled so that we can see it in the map at that moment:


If you hover your mouse over the vehicles you can see at the top it tells you the name of the formation and which vehicle you're on - in this case, the one that we want to couple to is vehicle 7 of 7 - otherwise known as the BACK of the train. We have our answer.

This - Front
Other - Back

Fronts and Backs can change, they have no resemblance to what is logically and sensibly the front or back of a train either - if you have multiple coupling operations you need to figure out what is what, and the trick above will often help you. It gets very confusing though if you are coupling to a single wagon because... front and back are the same wagon but different ends and you might need to use trial and error to find the right way to do it if you can't figure it out.

Continued...

 

Let's take a look at what we've ended up with after the couple operation, which will also visually confirm if we got it right:


(if you find the loco is at the wrong end or other bonkers things that dont look right - thats usually because front and backs are not set right!

Notice that i'm hovering over it and it's showing as 7 of 7. Yep, this is still the REAR of the train and to run to leeds we'll be essentially driving REAR first. That means nothing for players, it's for you to keep track of only. For example, if you were to do an UNCOUPLE operation later on to uncouple the 6 BG's, you'd need to do an UNCOUPLE FROM FRONT because the coaches are on the front of the loco... not the rear... where it kinda logically is at that point.

Another way you can see this is in the rail vehicle list on the instruction - if you click the COUPLE TO node and look at the bottom of the properties:



Notice that the 45 is at the BACK of the list, again, confirming it is at the REAR of the formation.

Things get more confusing if you couple the BACK of a train to the BACK of a formation - because then the fronts and backs all change... but i'll go into that in more detail in a proper tutorial.

Ok, so we've got the 40 holding in the siding behind us, the 45 is ready to. The 40 wants to get back to the yard and the 45 i'm just going to get out of the way into Miles Platting for now. I'm going to get the 45 going first because with the original routing Andy put in, the 40 wants to go back into the platform before running to the yard - I could optimise that out at this point as the junctions/signals support going direct, but I thought it added an extra wrinkle so I kept it in.

Let's get the 45 moving, and i'll use another interim waypoint to trigger a dependency so that no matter how long things take the 40 will stay out of the way and prevent a deadlock.

I've set the waypoint here:



It's a typical go-via for the 45 and then it's straight onto its "final" destination at Miles Platting via a stop-at, nothing fancy there.

For the 40, i'm going to route it via the middle route, out to a reversing signal (as per original timetable) and back into the platform, before routing it up to the yard.



From here it goes back to the platform and up to the yard.

Let's check the dependency though.



So the go-via at the bottom is the 45's waypoint after it gets moving out of the platform. The stop-at at the top is the first way point routing the 40 back out of where it's at - you could make this a go-via also but having it as a "no-despatch-beyond-stop-at" also means it might get held up by another AI service if one was there, adding to the interest perhaps.

So the 40 is not going to begin its move out of the platform until the 45 has reached that way point, guaranteeing no problems of things getting out of order.

Again, follow the "right hand side of a node" emitting the signal to the "left hand side of a node" over the white line.

That's sorted that and it all works in the editor when I run it, looks pretty cool too.

Continued...

 

The last thing I wanted to raise is that in the final yard move there is what I call a "compound movement". In that there is a change of direction implicit in the instruction - it's going from manchester to carriage siding 9 and to do that it has to route you up to the north end of red back and then back in to carriage siding 9. Technically, it works. For the player it's less obvious what they're doing, and it means there's an expected path that the dispatcher wants them to take that they might not take which can also sometimes cause issues. As a general rule, I find everything is much simpler if you always stick to ONE direction for ONE instruction, if you want to change direction then add it as another stop-at instruction.

There's a couple of strong guidelines here then really:

If you want the player to change direction, always use a stop-at so they are naturally stopping, checking the map and then proceeding (they'll need to set some junctions potentially afterall). I've seen this done with go-via's by some earlier on and nobody expects a direction change at a go-via - so you run through it at whatever line speed, find the new destination is behind you, curse, stop, and change directions - and heaven help you if you passed a signal or something.

Never use compound movements, while they technically work they are a BadThing. As a general rule, any time you need to click "Allow Reversing" you have something wrong. I use that tickbox to help diagnose an issue, e.g. without it it says "can tget there", but with it it can get there but goes all over the place - oh, i clicked the wrong platform... etc.

Anyway, hope that's all been useful exploration and thanks to Andy for sending me his work to look over.

 

This is all done via the objective system - i'll be covering that in a future tutorial (it's not a 5 minute job to explain )

Matt.