Prototype Operations in Trainz

Dap

Prototype Operations Guru
I have always liked the operations side of railroading - getting the freight to the customer in a safe and reliably timely manner. Trainz offers many of the tools to make this happen, but each car should have a specific destination and I have not ben able to find anything on the DLS that does this. So, I decided to create such a system. I call it the Car Movement and Traffic Management System. CMTM for short.

Think of this as a car card system on steriods. The system requires the use of at least one portal to bring cars onto and off of the route during a session. When a session begins, every freight car that was placed on the route in Surveyor is given a destination. As the session progresses, every freight car that is emitted from a portal is given a destination or series of destinations.

In Driver, the destination information is displayed in a wimdow in the upper left corner of the screen. This window is updated everytime you left-mouse-click on any traincar. When a car is delivered to it's destination, it is so noted with a mouse-click in the window. After a preset amount of time has passed, a new destination will be displayed.

Not sure if this is anything that others would be interested in, but for me, it makes Trainz much more prototypically operational, especially if you love switching. Classifying a string of cars in the yard or making switching moves at industries now can be with a purpose. No hand written lists or external car card programs are needed.

Here is a description of an operating session on my test route. I call it Austin Subdivision. It is an East-West mainline with a southern branch line that continues beyond the subdivision. It interchanges with two foreign roads. There is a small yard in Austin that is the center of operations. Some thru trains stop in Austin to drop off and/or pick up freight cars. These cars are then classified in the yard. They are then sent on their way, either in a different thru train or to one of the interchange tracks or to an industry.

The session mission is to plan and execute operations for the subdivision yard and run the local trains. As the day begins at 6:45am, there is a string of cars in the yard that need to be classified.

Classification Operations: there are five classification tracks and one stub end empty car storage track. Classification Catagories are:

Track 1 - local traffic for Austin, Maxwell and CGW interchange
Track 2 - local traffic for Kelly, Huxley and CNW interchange
Track 3 - eastbound thru traffic.
Track 4 - southbound thru traffic
Track 5 - westbound thru traffic

Watching your message board, at about 6:50am you will see that the CGW has dropped off a string of cars at the interchange on the east side of town. Retrieve these cars from the interchange and classify them also.

The first train to arrive is #101 from the west at about 7:00am. Pull all the cars from this train. Put the engine on the engine track and the caboose on the caboose track and classify the cars you have just pulled.

The second train to arrive is #401 from the South at about 7:20am. Pull from it the cars for local service. Then pull half of the westbound cars you may have from the yard, put them in this train and send it on its way West. Classify the cars from #401

Next to arrive is train #201 from the east at about 7:45am. Pull from it any local cars, and add to it the remaining westbound cars and send it on it's way west. Classify the cars from #201.

The last train to arrive for the morning is #301 from the west at about 7:10am. Pull from it any local cars and add to it all the southbound cars from the yard and send it south. Classify the cars from #301 and then remake train #101 with all the eastbound cars from the yard and send it east.

Make up the Huxley Turn using all the cars bound for Kelly and Huxley and the CNW interchange. Send the Huxley turn east to Kelly (using AI) and classify the remaining cars for the Austin Local and the Maxwell Turn.

Your first local train is the Huxley Turn to service the industries in Kelly and Huxley as well as the CNW Interchange in Huxley. Service only trailing point sidings at Kelly - which means some industries on the outbound trip and some on the inbound trip. At Huxley, deliver the livestock to the packing plant first, Then pull refers as needed from the storage track and deliver to the ice house. Then, pull the cars from the CNW interchange. Next work the industry tracks, including any cars from the CNW. Before you leave town, deliver your CNW cars to the interchange track, pull the livestock empties from the packing plant and make up your train for departure to Kelly and Austin. Your last move at Huxley is to transfer the refers from the ice house to the packing plant.

On your trip back to Austin, work the trailing point industries at Kelley.

Back in Austin, classify the Huxley Turn that has just arrived. Then switch the Austin industries and classify any cars brought back to the yard.

Your last run for the morning is the Maxwell Turn which includes delivering the appropriate cars to the CGW Interchange.

When you arrive back in Austin, classify the Maxwell turn.

The scenario could go on all day long, but this is over 4 hours of operations. The next time you run this session, you can choose another day of the week. Car Movements and Traffic patterns will be different.

I'm currious how much interest there is for an asset like the CMTM system.


PS: You can find the users manual at CMTM User's Manual 0408 Release
 
Last edited:
Very timely.

I too, am interested in a more prototypical type of operation than TRS / TS is set up to provide, and have started my first route in earnest, partly to serve as a experimental testbed, and partly for realistic operation. The mythical Oxbow Railroad serves one shipper, a grain company, and interchanges with one connection at Three Forks. Empties get spotted for loading, and any loads available on the day are pulled, and placed on the interchange track.

System map:
System.png



[NB: Color coding added with GIMP; the track roads are complete, and some of the structures are in place, but the route is not ready to unveil at this point.]

I'm not much interested in Car-card operation, though. I plan to use spreadsheets instead. I've already created a car fleet, of thirty covered hopper cars, each with an individual number and expect that there will be some number of "assigned" cars, as well, each of which will have an individual number.

In my method, each of the cars owned by the OXB, and each assigned car has a line on the car accounting sheet, which lists where the car is, it's status (L/E) where it's headed, anticipated arrival date, and approximate return date. The cars will show up in interchange around (meaning occasionally a day or two before, more often somewhat later, but usually on the expected return date.


I'm envisioning two different operating schemes based upon this route: 1940's, where the BCRR (or a predecessor) does the operations at 3 Forks junction, and OXB only handles its own traffic. In this scheme, interchange traffic is delivered to, and pulled from an interchange track, empties are run to the grain company, and loads pulled and brought back to the interchange. The more interesting job here will be the local BCRR switcher at 3 Forks, which classifies cars dropped off, and generally handles local switching duties. The OXB will simply make a trip a day to the grain elevator (or maybe two during the busy season), switching in empties, and pulling loads to bring back to the interchange. In this scheme, power for OXB is probably a 44 tonner (or perhaps 2), and equipment to be loaded is 40 foot boxcars. OXB has a modest supply of its own, but also gets cars from BCRR, who supplies some of it's own, and some from other sources.

The other scheme is based upon this route in the 1990's. In this scheme, BCRR no longer maintains a local switcher at 3 Forks. There are three locals which visit town, one from each direction, and they do occasionally have business to be set out and switched, but OXB handles the local switching here under contract to BCRR. In this scheme, OXB has the covered hoppers mentioned earlier; motive power is a pair of SW's. There is presently a proposal by the marketing department of BCRR to handle three dedicated trains from the grain company to a consignee some distance away, so there might be a need for some larger power, too, perhaps a GP38.

My dissatisfaction with the car card system is that to my way of thinking it is based upon a premise which is fine for simulating traffic on a wood/plastic/metal model railroad, where assets are expensive, and space is at a premium. But it's also based upon a particular phenomenon which was not all that common 50 years ago: reloading cars. Yes, cars did get reloaded, but already in the 1950's, the issue of car supply was becoming an issue, as more shippers began demanding specialized equipment, and more equipment began being returned empty via reverse route, instead of reloaded. By contrast, in virtual modeling, railcars are very inexpensive to make, and don't require much space to store: I can store about 500 cars on a CD-R, and about half again as many on a 1 GB thumb drive.

But I am interested in TRS as a platform for prototypical railroad simulation, and had contemplated seeing if there were any others who might be interested in forming an informal sig.

ns
 
How would this differ from the current LARS system?
(LARS is not on the DLS)

LARS deals with Commodities - loading and unloading. Once a car is loaded, there is no way to tell where that specific car should be routed. The CMTM does not deal with commodities other than to load or unload a car based on the data you have created for car movements.

I believe LARS did write a limited Car Destination Library, but with his system, a car destination must be entered in Driver one car at a time rather than having them assigned automatically. And the system does not support multiple destinations.
 
Very timely. . . . . . My dissatisfaction with the car card system is that to my way of thinking it is based upon a premise which is fine for simulating traffic on a wood/plastic/metal model railroad, where assets are expensive, and space is at a premium. But it's also based upon a particular phenomenon which was not all that common 50 years ago: reloading cars. Yes, cars did get reloaded, but already in the 1950's, the issue of car supply was becoming an issue, as more shippers began demanding specialized equipment, and more equipment began being returned empty via reverse route, instead of reloaded. By contrast, in virtual modeling, railcars are very inexpensive to make, and don't require much space to store: I can store about 500 cars on a CD-R, and about half again as many on a 1 GB thumb drive.

But I am interested in TRS as a platform for prototypical railroad simulation, and had contemplated seeing if there were any others who might be interested in forming an informal sig.

ns

Forget about any limitations you may think a typical car card system may have. In my system, I use the term "record" to refer to the data that defines a series of moves. This record can be attached to any freight car. Sometimes the it needs to be attached to a specific type of car. Sometimes it needs to be attached to a specific type of freight car owned by a specific railroad. All this is done automatically.

To service your grain company, the first move would be to pull a car from the empty car storage track. This track could be located at your yard or at the grain company.

Click on a car and then Click on the add record option and you will be presented the current requirements for the type of car you have identified. Click on the a record and it will be attached to that car.

The frist destination for this car would be the loading track. When the precribed loading time has elapsed, the next destination would be the portal (or maybe the scale track first?). When you create the record for this move, you also create a companion record that brings the car back on the route several days later with it's first destination being the empty car storage track, or maybe a stop at the car cleaning track first. When the car arrives at the empty car storage track, and the delivery is noted by a click in the window, the record is automatically removed and the car is available for another cycle when it is needed.

I not sure you will need to use a spread sheet on a separate computer. I have tried to build in all that functionality into the system.

And I'd love to get a discussion going about TrainzOps. I have started a discussion over on GUARC General Discussions
 
Last edited:
Destination of cars on a lars layout

I have been running 06 for about 3 years now and am still developing a system of pickup and delivery on a layout regardless of how large. The problem seems to be keeping track of individual cars which have a specific set of loads they can carry.
I have found cars of various types and load designations available with an autonumbering system which allows more cars of the same name,same color,
but a different number assigned to it, to keep track of it with.
I am presently developing a large layout of about 7 different individual layouts and all kinds of lars commodities to use. At the present time I am also trying to judge the max capabilities of the computer graphics to allow the most smooth operation Possible.
Here is the real catch 22 for any layout, if you have say 300 lars setups and some of them are duplicated in different areas of the layout, you also have to have BOTH pickup and delivery for every item or you do not get them all unloaded.
Now relating to the car listing: you need to set up a database of all the different commodities and what cars can load/unload each with the number of the car and its very location at any start or stop of destination.
In the switch yard you need to know each track location and a listing of cars start to finish in a specific direction to easily locate and switch them on new consists, but some computers can't handle large switch yards so you use designated sidings you create by isolating double tracks to singles.
Some of the items i have pointed out are still in design and I have a long way to go, but it is promising at the least.
I have a consist listing showing individual and sets of consists with each complete set and some of those are autonumbering, so when i duplicate the set I have twice as many cars with all new numbers, Engines also have the same system allowing the same engines and no duplicate numbers.
This design give me manuverability and duplication of regardless how large my layout may get because I alwas find new yard designs and layouts to add all the time. WORK SEEMS NEVER DONE just continues forward.
I just wish the FLightSim Game worked with pickup and delivery you could see huh. Hope this give the gamers something to think about.
 
The CMTM System is designed to simulate prototype operations and as such, completely disregards anything that LARS and waybills may be doing. The built-in so called "WayBill" system has nothing to do with prototype operations. Shippers drive the traffic in a prototype system. The power plant never calls the railroad and says "Bring me some coal". In the real world, the shipper calls the railroad and says "I need x number of empty cars. They will be ready for pick-up Y hours after you deliver them. These cars may or may not all go to the same destination. I'll have bills of lading for you when you pick up the loaded cars."

The Trainz community is a wonderful and diverse community with interests in all the many aspects of railroading. Some like to run trains in circles on small routes, some like to do switching operations, some like to drive that steam loco in cab mode across a 50 mile route. Some love to build assets for all to use. Some like to run trains on routes that others have made. Some like the game aspect of Trainz. Others, including myself, use Trainz as a modeling medium to create a realistic and detailed platform on which we can run a railroad in a very prototype manner. This is what has prompted me to create this system. Sorry if it ignores LARS and WayBills.
 
Dave, . . . When you say "assign a destination to a car or cars". Does that mean they are then automatically removed from the route ?

regards,
Mike.

The only way to remove a car from the route is to drive it to a portal. Cars that are setting on the Empty Car Track have no destinations. They are just setting there waiting for you to use them. Let's say you are working the yard and making up a train to service industries in town A. One task you need to do is click in the window to see if there are any records for industries in town A. If there are, attach those records to an appropriate type car and pull them from the storage track. Cars are not moved by this system. It only presents the data so you can plan and impliment the moves necessary to get the cars to their proper destinations.

I hope this helps your understanding. If you want to read the User's Manual, I have posted it on the TrainzDev website. CMTM User's Manual 0408 Release
 
Last edited:
I have looked into making a utility that would edit a session that had been saved from Driver. I know it is possible, but will take a bit more detective work to find out exactly what needs to be done. In the meantime, I have devised a work-around.

Create a session based upon a route, placing cars and other assets where you want them.

Open the session in Driver, and run it. When you are done running it, do a visual yard check of all essential content: what cars are at what shipper, &c. In another thread on this general topic from a number of months ago, someone opined that a rule could be created that would perform a yard check, but I don't know if such a rule was ever written, or not.

When done, whether or not you save the session, go back into Surveyor, and reload the session. Move the cars around to reflect the status at the end of the session in Driver.

Save this as a new session.

There are two utilities that would make TRS / TS much more enjoyable for me: one would edit allow editing of a driver session; the other would rotate a route by 90 degrees. I am convinced that both of these utilities would be trivial for someone with access to file format information, but apparently I'm the only one to think so.

ns
 
Hi all,

I've tested David's system and it is a brilliant piece of programming. It is at its simplest a built-in card order system for trainz. If you have never operated a model railroad using a traffic management system like Car Cards and Waybills or software like Ship-it then you may have trouble understanding what this system does. Here is a good introduction to operations:

http://www.opsig.org/primer/guide/

The difference is instead of making paper waybills the same data is entered into a spreadsheet which is exported as a text file and then copied into Dave's control object on your route. Once the system is setup, it acts as a shipping clerk assigning destinations to the correct type of car for each of your industries' needs. Just clicking on the car tells you where the car needs to go. Getting it there is your job.

I suggest you get Dave's demo route to see how it works. Once you see it in action it makes perfect sense.

William
 
Last edited:
I have always liked the operations side of railroading - getting the freight to the customer in a safe and reliably timely manner.

Not sure if this is anything that others would be interested in, I'm currious how much interest there is for an asset like the CMTM system.

When 2009 version was being beta tested, I ask if there was going to be Way Bills, I was told yes, as there is. But the Way Bills in the game was not what I was thinking, your idea is.

Yes, a thousand times yes, do this, this would make Trainz what it should be.
 
Others, including myself, use Trainz as a modeling medium to create a realistic and detailed platform on which we can run a railroad in a very prototype manner. This is what has prompted me to create this system. Sorry if it ignores LARS and Waybills.

That's what I use Trainz for, since the real hobby of Model Railroading is out side of my price range today. Trainz, take's it's place.
 
Back
Top