Single line operations.

[dimgdogos]

Hello, i am a NEW member. I have a question for you, how can i make a single Line meet? I tried using a portal for the exit point of the ai train and instead of the dispatcher to send Player tain or ai to a siding it permited the ai train to proceed and finaly crash in Player train.
What am i doing wrong?
Thanks in advance, Dimitris.

[BoostedFridge]

Hi Dimitris,

In my experience, getting meets to work on a single track line involves some careful train placement, timing, and trial and error. Some of these steps may be unnecessary, but I found that following them helps the AI 'dispatcher' make the AI trains perform as you want them to. Any scenario pros should chime in with any pointers I may have missed.

I am going to use a scenario I made a while ago for an example, and visual cues.

In this scenario, set on Stevens Pass, the player is controlling an eastbound manifest train, #82. The first meet I am arranging is at Gold Bar siding with the westbound train #3.

First, I place the player train on the main tracks, at least one full signal block away from the approach signal at the west end of the siding. In this example I have placed the train two full blocks away. (see below)

Single Track 1.jpg

I am setting the players train priority to "Standard Freight". I am doing this so the player will be held for higher priority trains.

Next I place the opposing train (#3) that our player train will be meeting at Gold Bar. Again, I place the train at least one signal block away from the approach signal, this time the one at the east end of the siding. (See below)

Single Track 2.jpg

I set the priority for the AI train, #3, to 'Express Freight'.

Now, its time to give the player train its instructions to proceed and take the siding at Gold Bar. Making these instructions is very easy on Stevens Pass because the route builder laid out destination markers at each end of every passing siding, and main track on the route. Thanks Michael! (see below)

Single Track 3.jpg

If the route you are making your scenario for does not have these markers, you can add them specifically for your scenario so they will not affect the route itself.

I am instructing #82 to go via Gold Bar Siding W using the 'Stop at destination' instruction. I used this instruction instead of a the 'waypoint' instruction because it allows me to edit the speed, and therefore time that the train is projected to complete the instruction. This timing can be crucial for getting the opposing AI train to pass ours.

Single Track 4.jpg

Then, I instruct #82 to go via Gold Bar Siding E, again using the 'Stop at destination' instruction. In this example I have again set the duration of the instruction to 00:00:00 by inputting a speed value for the instruction. This allows for the potential of a 'rolling meet' where neither train comes to a stop. This is mainly possible because this siding is almost 2 miles long. If you want the player train to be forced to stop at the east end of the siding, you can input a duration value in this instruction in hours:minutes:seconds, and the player will have to stop to successfully complete the instruction.

Because train #3 has a higher priority than ours, #82 will get a red signal at the east end of the siding if it arrives before #3 has cleared the block. If #82 arrives after #3 has cleared the block, it will have a green signal, and can continue on without stopping.

Single Track 5.jpg

Next we go through the instructions for train #3.

[continued below]

[BoostedFridge]

Next we will give the AI train, #3, its instructions.

I have instructed the train to proceed down the main track through Gold Bar Main E, and W, using the 'stop at destination' instructions. I have overlayed both instructions in the picture below to save space and avoid redundancy.

Note the speed values. I have slowed the AI train down between Gold Bar Main E, and W. This is to prevent the AI train from getting to the west switch (and signal block) at Gold Bar before our player train, #82 does. If that were to happen, #82 would get a red signal at Gold Bar W and potentially have the AI crash into #82.

single track 6.jpg

The real keys to making the meet work is the timing. In the diagram below, I have laid out both the AI and player trains instruction schedules side by side. As noted, the key is making sure that the lower priority train (#82) arrives at Gold Bar West before the AI train enters the signal block between East and West Gold Bar.

Single Track 7.jpg

Because this siding is so long, it is pretty easy to coordinate meets here. If the siding you are planning your meet at is very short, you will likely need to instruct one of the trains to come to a stop, and wait on either the main track or siding for the other train to arrive.

Single Track 8.jpg

Single Track 9.jpg

I hope this was of assistance.

[dimgdogos]

Hello and 1000 thanks for your help. Sadly nothing worked and i did as you instructed in the messages. The problem is that i can't change the priority of the trains and i don't know if is responsible that the siding has a switch and another dead end track. the switch is manual and this happens in the 3 sidings i tried to make the meeting to happen. The route is located in GREECE (Leivadia to Domokos).
Below are the images i was trying to make the meet to happen.
http://prntscr.com/e7vszb http://prntscr.com/e7vtbc http://prntscr.com/e7vtro

Hope you can understand my rusty english

[OldProf]

Thanks for your thorough and well-illustrated tutorial, but it does leave me with questions:

1) In my experience, the marker arrival times listed in the player train's timetable view box are based on ideal conditions as calculated by the game engine (what many of us refer to as "the dispatcher", but as scenario writers the one variable that we cannot control is the player. I doubt that any two players will accelerate to full line speed at the same rate; in fact, some players will never drive at that speed and many will at least occasionally speed above it; uneven terrain will add to this problem. So, how can any scenario writer ever feel certain that a meet such as the one you've so thoroughly illustrated will happen?

2) Again in my experience, the player engine usually (but not always) is given the right of way over an AI train with the same priority and sometimes even over one with a higher priority, which also places a meet -- or an overtake, for that matter, at risk. Have you encountered this and, if so, how do you deal with it?

I have discovered partial solutions to situation 1: a) assign departure times to the player train's tasks when possible: for example, when entering or leaving a yard or interchange; b) have an AI train overtake the PT while the latter is stopped on a marker just before a signal, causing the signal to show red for the PT until the AI passes through another one or two (depending on the route) signals. I usually accompany this with a message explaining the delay in some way, to keep the player from seeing the red signal as an error.

Again, your tutorial is very good -- I'll bookmark it for future reference.

[_o_OOOO_oo-Kanawha]

Thanks for this clear tutorial from me also.

Does this technique also work for Quick Drive scenarios? I am still struggling with writing QD for Tehachapi Pass, and would love to have meets on the single track portion.

AFAIK, QD's are just a template, and DTG haven't provided service classes for the player and AI trains.

[BoostedFridge]

The problem is that i can't change the priority of the trains

Priority.jpg

and i don't know if is responsible that the siding has a switch and another dead end track. the switch is manual and this happens in the

The dead end track which connects to the siding will not make a difference.

The manual switches may be forced by the AI dispatcher based on the priority of each train. I am going to to look into this tonight.

Below are the images i was trying to make the meet to happen.
http://prntscr.com/e7vtbc http://prntscr.com/e7vtro

The siding in the first picture looks fine for its signal layout for meets. I can't zoom in though, and see if there are destination markers on the siding and main tracks, as I showed in the third picture in my instructional post.

The sidings shown in the other two pictures do no have approach signals protecting the main track at each end of the siding, or indicating for a train on the main track to take the siding. That would cause issues with meets or the AI dispatcher.

Does this technique also work for Quick Drive scenarios? I am still struggling with writing QD for Tehachapi Pass, and would love to have meets on the single track portion.

To be honest, I have zero experience making QD scenarios, so I'm not of much use on this subject.

[dimgdogos]

This is what happens every time i try to change priority of trains.
http://prntscr.com/e8pasn http://prntscr.com/e8pb2j

[jalsina]

Thanks for this clear tutorial from me also.

Does this technique also work for Quick Drive scenarios? I am still struggling with writing QD for Tehachapi Pass, and would love to have meets on the single track portion.

AFAIK, QD's are just a template, and DTG haven't provided service classes for the player and AI trains.

In QD you can only program via's and final destination for AI. I haven't been able to program delays. The behavior of AI trains when going into the player's track is stopping in switches (no need of lights) to wait and let pass the player's train. So in fact there is a meet.
If the AI is a few miles beyond the player's, it will take the single track and proceed in that same direction of player but as I said before, a few miles far away. I believe the AI train behaves considering the quantity of lights between player an AI as an empty block in between. There won't be a meet. You can see the AI moving far away or using the map.
Placing an AI against the player's direction at a certain distance and later go into the danger of a frontal meeting, will produce a QD session crash.

[OldProf]

This is in reference to a JPG image included in one of Boosted Fridge's posts. The image is "single track 6.jpg", which for some reason I cannot quote in this reply.

The image shows a Stop At instruction open in the timetable editor, in which a specific speed -- 20 mph -- has been entered. In my experience, this is a great way to ask for trouble. Only two numbers should ever be entered in this box: "0", the default, which will cause a train to stop at the designated marker, or "1", which will cause or allow it to pass through the marker, thus changing the Stop At instruction to a Go Via. To attempt to control an AI train's speed, vary the number in the text box labeled "%". The default is 75%; increasing that number will make the train run faster, while decreasing it makes the train run slower, but setting an exact speed with these percentages is impossible. If the train being edited is the player train, entering a percentage will make no difference, since the player controls the train's speed, not the game engine. In this case, entering anything other than a 1 or a 0 in the "speed" text box really invites disaster.

As I think I wrote in an earlier post to this thread, the player engine's speed can only be controlled by the player/driver. Again, this is based on my scenario writing experience, which is considerable.

[BoostedFridge]

1) In my experience, the marker arrival times listed in the player train's timetable view box are based on ideal conditions as calculated by the game engine (what many of us refer to as "the dispatcher", but as scenario writers the one variable that we cannot control is the player. I doubt that any two players will accelerate to full line speed at the same rate; in fact, some players will never drive at that speed and many will at least occasionally speed above it; uneven terrain will add to this problem. So, how can any scenario writer ever feel certain that a meet such as the one you've so thoroughly illustrated will happen?

You are absolutely right. The player is the wild card, with every game player, and every session being different.

A trick I employ to prevent the player train from falling too far 'behind schedule' and throwing off meets and events based primarily on timing, is to put a 'stop at destination' instruction with a time duration at the junction, or siding where a meet is occuring. I will then run a few test sessions with the player train first going as quickly as I can (run 8 with sand right away, and slight speeding if possible) and note the arrival time at the 'stop at destination' marker. Next I will retest using the player train, but running very slowly (taking the slack out of the couplers before notching up, etc...) and again note the arrival time at the 'stop at destination' marker. I will then adjust the duration of the 'stop at' instruction so that the faster players are held for a minute or so by the instruction. I like to put these 'catch up' type of meets in situations where the player train is meeting a higher priority train. I'll place the higher priority train a block away, but set its speed or % quite low. Then I set its 'start time' to be about the earliest that a 'fast player' train would be arriving at the siding for the meet. That way, the opposing AI train rolls into the main block and throws up a red signal for our opposing player train on the siding. The fast players will sit through the duration of the 'stop at' instruction, then have to wait for our slow moving AI train to clear the block before it gets a clear signal. A slow player will likely arrive at the stop instruction while the AI train is passing, and will only have to wait for the duration of the 'stop at' instruction before proceeding. I don't like making players wait at green signals just for an instruction to time out, so the AI train is a great way of letting the 'slow' players catch up to the 'instruction schedule' for the remainder of the scenario.

To take the worry about timing out of a meet, you can simply set the AI train to have a lower priority than the player train. That way, the worst thing that can happen is that slower players will miss the AI train in motion, and will simply meet a stationary AI train waiting for their arrival.

2) Again in my experience, the player engine usually (but not always) is given the right of way over an AI train with the same priority and sometimes even over one with a higher priority, which also places a meet -- or an overtake, for that matter, at risk. Have you encountered this and, if so, how do you deal with it?

I agree, when the player train and AI train are of the same priority, the AI or dispatcher will sometimes behave differently in the scenario than they did in the 'trial run' in the scenario editor.

It is for this reason that I always make the player train (in freight scenarios) a 'standard freight' priority. This way you have higher and lower priorities available for AI trains to help force the AI dispatcher in routing its trains as you want around the player train. The AI trains are certainly fickle sometimes, but I have yet to have an instance where a lower priority AI train will enter a block routed for a higher priority player train.

The image shows a Stop At instruction open in the timetable editor, in which a specific speed -- 20 mph -- has been entered. In my experience, this is a great way to ask for trouble. Only two numbers should ever be entered in this box: "0", the default, which will cause a train to stop at the designated marker, or "1", which will cause or allow it to pass through the marker, thus changing the Stop At instruction to a Go Via. To attempt to control an AI train's speed, vary the number in the text box labeled "%". The default is 75%; increasing that number will make the train run faster, while decreasing it makes the train run slower, but setting an exact speed with these percentages is impossible. If the train being edited is the player train, entering a percentage will make no difference, since the player controls the train's speed, not the game engine. In this case, entering anything other than a 1 or a 0 in the "speed" text box really invites disaster.

As I think I wrote in an earlier post to this thread, the player engine's speed can only be controlled by the player/driver. Again, this is based on my scenario writing experience, which is considerable.

I haven't experienced any issues with entering a specific speed in the 'speed' box. After reading your post though, I have been playing around in the editor and it doesn't seem to make much, if any of a time difference in the 'instruction timetable' whether I input a specific speed, or the 1mph that you suggest. What 'trouble' have you noticed with using a value other than 1?

When changing the '%' or 'speed' inputs for the player train for an instruction, all it seems to do is run the player trains 'expected' schedule past the AI dispatcher, and see if it triggers an error or fault with the pathing of the AI trains around it. Once the scenario 'test runs' cleanly in the scenario editor, it doesn't seem to matter to the dispatcher if the actual player deviates from their projected schedule in the scenario. Much of what I have learned about scenario writing is from trial and error, so I will definitely defer to any one else's firsthand experience.