EITower-Instructions?

Rater than just fiddle around until having some success I decided to try following the Wiki instructions. There were three rules specified to download from the database. All three are builtin. When I installed them into the rule handler in TRS19 This is the result:



Appears to be a problem? Are there alternate rules somewhere?

Maybe the game can’t read the red text, just like I can’t read it.

Hi.

this display means only that the rules do not have all their needed parameters set to valid values ...

you need just to edit each rule and enter the missing parameters with valid values and the rules will be displayed with their normal aspect and will become operational.

Regards.
Pierre.

Two out of three need information so they display a fault condition - ODD.

I have successfully used this program in the past. It managed the flow of trains ok. However, I never understood the Mission thing until you explained it. While I can lay down a golden trail I see no way to assign a train. The rule that appears for that purpose is much like the rule below. It has no reference to a train.

Since people much more talented than I are using the program with great success, my abilities, and/or some software glitch, prevents the program from operating in any manner I can understand. Therefore, I will revert to the newly discovered Game Time rule and keep a window of Notepad open with the "written schedule". After all, the "paper" sked is traditional and its implementation in Trainz suffers from any modern glitches, not too unlike the unpredictable old-fashioned things that plagued railroads in the not too distant past.

boleyd said:

Click to expand...

IIRC, this one causes a pop up screen in driver that asks you to assign an upcoming path on the fly based on how you config'd the tower.

Hi.

when you use mission codes manger to manage path assignment for trains, you no longer need the interlocking tower path selection UI rule as MCM will take care of all path assignments.

So when you add MCM rule to a session, just remove the Standard IT path selection UI rule which is no longer needed, and everything will run fine.

regards.
pierre.

WOW __ That is a major difference from the way I see the presentation of the program. I could never grasp the need for the Paths in a scheduler. I was always searching for that when I attempted to use the program. The other thing I was not clear on was which functions require Driver Mode versus Editor mode. Thus on some occasions I was in a mode where the program's features might not work. Things that are fully understood by some may not be understood by all without structured instructions. Narrative explanations can mask the objective.

So, I will definitely try again. While my alternative approach works well, it has a significant liability. If a train has a complex schedule the size/length of the instruction set is quite cumbersome.

I am afraid that the Interlocking Tower and its Mission Code component will not do what I want. I setup a path, and attached a mission code to the path to stop at a station. Assigned a train etc... But, I could find no process to execute the routines at specific times within a traditional railroad schedule format. That is, leave the yard, or station at a specific time for a predictable arrival at a station. I did not see the technique for leaving a station by the clock in plain language or computer style language. In fact time seemed to not be involved at all in the Mission Control system. It appears directed more to high traffic areas where the overall system is managed with no specific regard to clock time. In that state it looks to be a very good tool and allows very complex routes with a variety of trains to operate in a managed and integrated fashion.

I see the simulated railroad, not as a complex integrated function, but as a traditional railroad governed by time (schedule). As an example, if a train leaves a station earlier than scheduled, it runs the risk of an early arrival at the next, and subsequent stations. The time-at-station is based upon the time consumed by software-exchanging passengers thus the train may leave the station ahead of schedule. Any passenger arriving on-time at the station runs the risk of the train being long gone despite the scheduled times. This guy ain't going to be happy. However, the boarded passengers will be happy with the early arrival at their destinations.

Transportation satisfies a demonstration of best effort by leaving on time. After that the arrival time is a variable. I bet that there is a "Best Effort" clause on the ticket or posted for easy notice.

To guard against the schedule being impacted by computer load, departure clock times are critical at each station. Perhaps you have seen a train set at a station after loading and wondered why it did not leave the station. It was probably waiting for the clock to tell it that it was time to leave or it was awaiting the arrival of a V.I.P whose limo was stuck in traffic.

A simulated railroad may be managed by an overall computer control of the system dynamics. This will keep a large number of trains running without incident. While it is a notable task, it ignores the clock upon which railroads, and almost all transportation activities, rely.

Hi Dick
MCM does allow timed departures as you need. All it does is allocate paths to a train.
By using DriverCommands Active autopilot/Stop at trackmark - Wait until time - Autopilot to trackmark - Wait until time....
Does that make sense?

Hi Dick.

I think you have forogtten the third level which is the Stops and TimeTables Manager ( <kuid2:61392:8300:63> ) which works with the MCPathStop ( <kuid2:61392:8311:58> ) to define where trains will stop, and driver command AutoDriveWithMCTimeTable ( <kuid2:61392:8322:60> ) to drive a train following a timetable previously defined in the Stops And TimeTables Manager.

The MCPathStop is in fact a customisable trackmark, that you can put anywhere you want a train to stop, and by clicking on its properties you can give it a logical stop name. You can have several MCPathStop configured with the same logical stop name. By default if a MCPathStop is put in a station or industry area, it will have a default logical stop name identical to the station or industry area, but you may change its logical stop name if it is not convenient.

When defining a named schedule in Stop And TimeTables Manager (STT), you enter the list of successive logical stop name for your train with arrival and departure time (no arrival time for the start logical stop and no departure time for the last logical stop) and you enter one or several mission codes to use to driver between stops.

When a train executes the AutoDriveWithMCTimeTable driver command you enter the named schedule to follow : the driver command will retrieve the named schedule and will follow the schedule stopping at the first matching MCPathStop encoutered with a logical stop name included in the schedule, waiting for the departure time defined in the named schedule.

So to resume, the full system :

- first level : EITs, in charge of defining the paths that can be used and managing conflicting paths request
- second level : MCM, in charge of choosing at each entry signal the correct path follow based on the mission code
- third level : STT, in charge of defining the named schedules with their timetables (list of stops and time to follow, mission code to use, … )

and then with only driver command, your train will follow the named schedule selected, using the timetable mission codes to go from one stop to the next, with mcm choosing the paths to follow based on the timetable mission code …

May be you need some time to be familiar with this three levels of management (paths, mission codes route, timetables) but when you understand how all this is embedded the system is very efficient to make trains follow a precise timetable for operations …

Regards.
Pierre.