Timetable Challenge

[segy]

Hi All Timetablers and running to Schedulers

I offer a friendly challenge to implement a timetable for the running of trains to a prepared schedule.

There has been some discussion about what can and can't be done using the various time and portal rules. Why don't we pool our efforts to help ourselves and other members of the community understand these various options?

With your agreement and guidance I propose to design a simple route and a simple schedule, post the route on the DLS, then let each person design a scenario/session that implements the schedule using whatever method they wish. They would post this to the DLS, suitably documented if required, so everyone could understand and experience the joys and pitfalls of timetabling using TRS2006.

I propose the following:

• I would design a simple route (or someone could donate/suggest one ) with a few junctions/switches, portals at the extremities, lots of trackmarks for the unportal users, a separate track for trigger users etc. This would be posted on the DLS.
• Suggestions for design of route to be posted by end of September 30.
• Suggestions for design of schedule to be posted by end of September 30.
• No more than one industry (if any) and 2 platforms.
• Scenic simplicity
• All communications through this thread
• Schedule to involve train arrival, departure, locomotive change, shunting, random delays and any other element suggested before September 30
• For TRS2006 SP1 only!
• Possibly one user controlled train, all others to be controlled by the timetabling system
• A plus point of your timetable proposals would be whether the session could be saved and restarted correctly at any time

What do you think?

Segy

My initial list of timetable schedule features, please suggest others:

• Passenger train arrives at station at specific time
• Passenger train loads at station, waits until a specific time of day until departing
• Passenger train arrives at station, waits for a specific elapsed time until departing
• Train held at signals, or in other location until another train has completed a movement
• Train enters route at specific time
• At least 10 trains are scheduled
• Loco detaches from train, another couples, journey proceeds - all at specific times of day
• Allowance for user controlled train throughout
• Allow user to take over a train already running to a schedule, drive it, then relinquish control back to schedule

I expect the schedule would look something like:

• 8.00 Train1 arrives platform1 from north(up)
• 8.01 Train2 arrives platform2 from south (down)
• 8.02 Train1 departs to south
• 8.03 Train3 through from north to south
• 8.04 Train2 departs to north
• etc

However there would be some random delays built-in which might cause trains to move in different orders on different sessions.

========================================================================================================
Here is my first suggestion for a route. This is schematic of course and covers 3 x 1 boards

TM--TM--TM--TM--TM--TM--TM-\
...............................................\
------Portal.Basic------------------\....................................................../---TM--TM--TM--TM--TM--TM--TM---
...................................................\.............../--Platform2--\.............../
------Portal--------------------------\---\-/---/---------------\............/-----Portal.Basic-----------------
...........................................................x.............................\........./
------Portal--------------------------/---/-\---\----Platform.1----\----/-------Portal-----------------------
.................................................../...............\
------Portal.Basic------------------/..................\-----------------\
................................................/....................\-Multiple.Industry-\---
TM--TM--TM--TM--TM--TM--TM-/

--TM--TR--TM--TR--TM--TR--------- Separate timing track ----TM--TR--TM--TR--TM--TR-------------

Please read . (periods) as spaces - the forum wont allow me to put in leading spaces, nor to use a fixed width font on an edit

1. I have kept it relatively simple although there are plenty scenarios where contention for a path may arise
2. If your timetabling method of creating trains requires other facilities please let me know
3. There will be lots of other track marks and triggers, if your method requires these to be in specific locations please let me know
4. I propose that signaling will be 'route setting' configuration for simplicity
5. Only built-in content used for route
6. Clone the base scenario then use whatever rules you need for your scenario/session
7. Use only built-in vehicles

 

[Dap]

Hi All Timetablers and running to Schedulers

Suggestions for design of route to be posted by end of September 30.
Suggestions for design of schedule to be posted by end of September 30.

Segy

Segy,

great idea, but maybe we should have the route designed first - say by Sept 30 , then design the schedule sessions by Oct 31.

Dap

 

[segy]

Segy,

great idea, but maybe we should have the route designed first - say by Sept 30 , then design the schedule sessions by Oct 31.

Dap

Thanks Dap. I was hoping the schedule design would be relatively simple and therefore not take a month. When I mentioned September 30 I was putting a limit on suggestions about what timetabling features should be in the schedule (e.g. arrivals at a certain time, departures at a certain time, one train to wait until another had passed etc).

I will put up a list of these features to stimulate discussion and hope you can point out to me if there are any features you would like to see as I am only concentrating on passenger train scheduling for a large station (Crewe) right now so know little about what timetabling might be required for other types of routes.

Thanks
Segy

 

[davidbird]

Hi All Timetablers and running to Schedulers

...

I propose the following:

• I would design a simple route (or someone could donate/suggest one ) with a few junctions/switches, portals at the extremities, lots of trackmarks for the unportal users, a separate track for trigger users etc. This would be posted on the DLS.
  ...

• 
  
  How about using Hawes Junction? It has portals, lots of trackmarks and triggers. I know its not a simple route, but its already built-in to TRS2006.

 

[Paulsw2]

I think this is an excellent challenge and I hope people will join in.

I do hope that, whatever approach seems to work best, we get a good, blow by blow tutorial/explanation that's easy to follow and use.

Just a restatement of my success criteria when I posted my original thread on timetabling in Trainz:

1. ability to schedule all train movements by the hour and minute in the trainz world;
2. ability to emit trains from portals by the hour and minute according to timetable;
3. ability to manually take over trains then leave them again whereupon their previously determined schedule is restored.

If we can find the best way of achieving these objectives, I will be well pleased!

 

[segy]

Thanks Paulsw2

I have modified my first post and hope it covers all your requirements (I think that last one could be quite a challange) Please keep the feedback coming about the details.

Segy

 

[segy]

How about using Hawes Junction? It has portals, lots of trackmarks and triggers. I know its not a simple route, but its already built-in to TRS2006.

It would be my preference too to use an existing built-in route and I will look into your suggestion - thanks

Edit: Having thought about this perhaps not the right way to go. This challenge is about scheduling.
1. In order to do that the route must have several different methods of making trains appear and disappear. e.g. portal, portal basic, track marks etc. and existing routes don't tend to have all the possibilities implemented at once.
2. Getting scheduling right involves a certain amount of trial and error. Better that the route is relatively short e.g. 5 x 1 boards so can test the timing without having to wait while trains cover large distances.
3. The route needs to be relatively simple and I could probably do it in a couple of hours once we have decided what features it should have. It doesn't have to be scenically stunning or anything in fact it could just be tracks, portals, signals, track marks and triggers.

Segy

 

[mjolnir]

Friends,

I'll state at the beginning that I am fairly new to gaming in general, and to TRAINZ in particular, and beg you to take those considerations to account in the comments which follow. And while I have no particular interest in timetable operation, there are a couple of points where interests have requirements which are parallel, particularly

... train arrives at station at specific time ...

and

... some random delays built-in ...

,

To take the second item first, and to ask a blatantly newby question, is there any capability in the scripting language for generating a random number? I've just begun looking for the answer to this question, but not yet seriously.

With respect to the first question, I know that there is capability in TRAINZ to reference the "game clock" (that is, the time internal to the game); is there capability to refernce the "system clock" (time external to the game)?

ns

 

[segy]

Friends,
is there any capability in the scripting language for generating a random number? is there capability to refernce the "system clock" (time external to the game)? ns

Both goods questions but please post them in a new thread as this one is about how to implement schedules and timetables.
Thanks
Segy

 

[stagecoach]

1. In order to do that the route must have several different methods of making trains appear and disappear. e.g. portal, portal basic, track marks etc. and existing routes don't tend to have all the possibilities implemented at once.
2. Getting scheduling right involves a certain amount of trial and error. Better that the route is relatively short e.g. 5 x 1 boards so can test the timing without having to wait while trains cover large distances.
3. The route needs to be relatively simple and I could probably do it in a couple of hours once we have decided what features it should have. It doesn't have to be scenically stunning or anything in fact it could just be tracks, portals, signals, track marks and triggers.
Segy

I assume the route would be an end to end with two or three stations. You might also consider a branch line going off to a station terminus on the side that uses single line operations. Swapping engines for return journey cause some a lot of problems.

 

[davidbird]

Originally Posted by segy
1. In order to do that the route must have several different methods of making trains appear and disappear. e.g. portal, portal basic, track marks etc. and existing routes don't tend to have all the possibilities implemented at once.
2. Getting scheduling right involves a certain amount of trial and error. Better that the route is relatively short e.g. 5 x 1 boards so can test the timing without having to wait while trains cover large distances.
3. The route needs to be relatively simple and I could probably do it in a couple of hours once we have decided what features it should have. It doesn't have to be scenically stunning or anything in fact it could just be tracks, portals, signals, track marks and triggers.
Segy

I assume the route would be an end to end with two or three stations. You might also consider a branch line going off to a station terminus on the side that uses single line operations. Swapping engines for return journey cause some a lot of problems.

This is beginning to look like a typical "real" model railway!:hehe:

 

[mjolnir]

Both goods questions but please post them in a new thread as this one is about how to implement schedules and timetables.
Thanks
Segy

With all due respect, it seems to me that these are fundamental issues to address, perhaps before starting work on implementing the timetable, because the issues have significant impact on the implementation. For example, consider this: you devise the timetable for your station, and you use the arrival of the first train as the trigger event for everything that follows. Then at a later stage, you decide to introduce an uncertainty factor, and this uncertainty factor acts to delay the first train due to some factor at a previous station. Now nothing else will happen, because of the delay to the primary trigger event. The obvious solution to this particular pitfall is to use something other than the arrival of the first train as the triggering event (my nomination for an initial trigger reference point: assign one of the drivers to impersonate the stationmaster, and open the ticket office at a designated point, and derive all the other times from that; when the ticket office is opened, the driver reverts to being a driver.).

A similar issue will arise any time an arrival is based upon the arrival of some prior train. If the second train is dependent upon the first (that is, train B cannot leave until train A arrives, because it is going to use the locomotive which arrives on A) this is not an issue; if however, the two trains are not supposed to have a direct dependency link, then it might be advisable to have the second train refer back to the original trigger event (e.g., opening the ticket office). This presents the problem of a dependable means of keeping track of elapsed game time, which, if I understand correctly, seems presently to be a weakness of TRS. If this is true, I may have devised a workaround for this, too.

Now, in the real world, timetables are the ideal, which is not met a small but significant part of the time. And an essential part of failure to meet the timetable is the principle uncertainty. A tree falling across the tracks will create a timetable problem because it is unpredictable. If the operations personnel knew in advance that the tree was going to fall, they would change the schedule for the day, so that the train ran at a different time and was not affected. In the challenge you have set to meet, I expect that it will be trivial to get the scenarios and sessions running perfectly. The real challenge will be in introducing the uncertainty.

I don't expect to be a big contributor of this thread, as I'm not especially interested in timetable operation. However, the issues of keeping track of initialization, elapsed time, and providing uncertainty are as important in my particular area of operational interest as I perceive they are in timetables, so I do plan to monitor this (and daughter) treads pretty closely.

ns

 

[stagecoach]

mjolnir
Yes you do have some valid points but you seem to be refering to triggers for all actions. A list of events can be carried out without a single trigger being used. I use a lot a commands that carry out action on command, but if a train misses or fails to arrive then then the next train that needs this action will start the event. I dont use consist/driver names as these may vary, but use the commands that only refer to a message or trackmark.
for instance train A arrives another engine B connects for return journey and train A moves to waits for train C. Train C fails to arrive, train D arrives but does not need to return, Train E arrives and train A connects for return. This is all done with using message rules and trackmark commands. If train C did arrive then train A would have connected for the return and train C would wait for train E. vbmenu_register("postmenu_173638", true);

 

[mjolnir]

... you seem to be refering to triggers for all actions. ...

I did in this case. Even when I wrote the post, I was sure that there were other techniques that can could be used instead of triggers, though I am new enough not to know for certain what they were. However, I chose to use triggers in the example I used in rebuttal of Segy's assertion that my questions had so little bearing on the thread as to be off topic here. If event B needs to happen at the same time in the timetable without respect to what happens with prior event A, then B needs to have an independent point of reference of time from the reference of A. Or to state it differently, B and A can both use prior event C as a point of reference, but in this case for B to use A as a reference point creates a false dependency.

Likewise, the question I raised about uncertainty. It can be introduced into the session in a number of ways. One of these would be session master intervention, where at the beginning of the session someone "manually" introduces uncertainty, e.g., "OK, let's see what happens if I delay the arrival of train X by 15 minutes this time." It might be more interesting, though, if the uncertainty is automatic so that the arrival of train X is as scheduled for thirty five straight sessions, and again in sessions 37 and 40, but in session 36 it is three minutes early, in session 38 it is ten minutes late, and in session 39 it never arrives during the session.

While my own personal interests in timetables is not very high, I am very interested in how (or if) the techniques could be implemented to have the computer itself generate the uncertainty factors, as that bears directly impact my own operation interests.

ns

 

[stagecoach]

It is possible for the uncertainty you describe to be done with commands. If a train schedule was for trains to arrive, change engines and depart hourly (not on the hour) then it is simple. Using the post message commands the engine change will only take place when the train has arrived and sends the message, it wont matter if the train is early or late. the second engine will couple after arrival and using the wait until minute will depart on or after the set time. Train 39 fails to arrive then the engine sits in the spare track until engine 40 arrives and carries out the task. it all relies on the sending and recieving the message and not on time.

 

[mjolnir]

... If a train schedule was for trains to arrive, change engines and depart hourly (not on the hour) then it is simple. Using the post message commands the engine change will only take place when the train has arrived and sends the message, it wont matter if the train is early or late. ...

The part of this description of greatest interest to me, is the mechanism by which in a particular session, the train might arrive on time, be early, or be late. Suppose the timetable provides that a particular train is due to arrive at a particular time, after which it sends out messages, you describe. Now, in the real world, that train will be late by some amount of time, on some occasion which cannot be predicted in advance. For example, let's assume that train 37 is due to arrive at 12:10, and that it does so most of the time, but on one occasion, it is delayed for 37 minutes because of replacement of a broken rail took longer than anticipated. I don't yet perceive how the post message commands can be used to cause this train to be late by some random amount of time on one day of 40 chosen at random.

ns

 

[stagecoach]

The post message is a command that is placed in the drivers instructions like any other. It will activate in rotation the same as all other driver commands. This means if you place the command after uncouple, the message cant be sent until the early/late engine has arrived and uncoupled. The second engine will only activate once it recieves the message from the incoming train. If that train is missing it will sit there until the message it is waiting for has been recieved. portal created trains use the same post message each time and the same wait for message is used for the returning engine.
The post message wont delay the arrival of the train, but will allow for an engine that is waiting to couple to it for the return journey to do so, only at the time of its arrival or the next trains arrival will it carry out its commands.

see thread Coupling a Loco to Passanger Train

 

[mjolnir]

... The post message wont delay the arrival of the train, ...

Which leaves the original question: can a method be devised which eliminates user intervention and provides for a particular train in the timetable arriving late in a randomly occuring session, and by some random amount of time? It happens in the real world, and it would seem to me that some planning needs to be done so that it can be provided for in the sessions on the proposed route. In some cases, an event which follows another will depend upon a prior event (to use your example, you can't change out the locomotives in a train which isn't there, though if the reason the train isn't there is engine failure, it may well be that one option for solving the problem is to take the loco that is supposed to couple to the train to where the train is, and drag the train in, and then set out the defective locomotive.). In other cases, even though event b is scheduled to occur later than event a is a mere happenstance, and unaffected by issues relating to train A.

ns

 

[segy]

Progress Report

The design of the timetable challenge is near completion.

Features:

• 9 trains arrive and depart according to schedule where possible.
• Paths to be kept clear for through express.
• Express delayed up to 6 minutes depending on player selection.
• Trains automatically held until express has cleared then released in order of priority.
• Load at industry, run around train, depart when other traffic clear.
• Path to alternate platform if scheduled platform still occupied due to departure delay caused by express running late
• Contention for through track, cross-over and platforms

Segy