Hi all,
I have been experimenting with using model railroad operating ideas in Trainz for a while now. So I will share my thoughts on the subject.
I have been using the name space inside a piece of rolling stock's property window to add routing information. This is done in surveyor by using the ? to click on the car and editing the name at the top of the panel that opens. I use a system similar to the colored coded tack system. Let's say that I have a box car and I want it to go to Town A and Industry A for loading then it should be taken to Town B and delivered to Industry C. I would change the name to be:
Town A/Ind. A -->Town B/Ind. C
When the car is empty it is picked up and returned to the home yard and the cycle begins again. The routing information survives driver session save so continuous play is possible.
One problem is the limit of the space available for the routing information. I don't think Auran ever envisioned this use. If the space was larger then more cycles could be done and more detailed information could be used.
Also, the routing information does not survive a trip through a portal so staging yards are need.
This system works and is quite fun but I agree it should be more a part of the game. Here are my thoughts on the current topic.
Don't overlook what is available in the game now. We have the basis of a system with the current products system. Think about it. What is a waybill but a product with a destination listed on it. You have the ability in surveyor to add products to rolling stock so what is needed is to assign a destination to the product for delivery. At any point in Driver you can right click and see this information. Let's call this new type of product: Product 2.0. Industries could be modified to load and unload these new products within the current system. Perhaps the coal mine could produce three types of coal products: one for the Power Station, one for the Loco Service Station and one for the loading bins down at the docks. I'm not sure if it would be possible to assign destinations at the time of loading or if the products would have to be pre-assigned for a certain destination. Maybe it would be possible to have a list of destinations on the route stored in an object like the TPR Destination Database and have the list available in a drop down gadget on the Product 2.0 property screen. This is where a clever programmer is needed.
The current waybill system should be changed to a request for empty cars system based on production rather than consumption. When an industry has enough product to ship than a request for an empty car would be generated and a suitable car would be found and routed to that industry for loading. It would be loaded with a Product 2.0 that lists the destination for the load.
Except for the in game waybill system changes which would require changes to the game code. Most of these ideas could be done by content creators.
William
William,
I salute your creativity in finding a partial solution to this problem. We need clever minds like yours to help formulate the next step.
I don't think that any solution that requires changes to the game code such as changing the exisisting "Way Bill" system are feasible. I have never cared for this system anyway. It works backward from the real world. Railroads don't get messages from their customers that say - "Bring me more coal, and I'm not telling you where to get it from". In the real world, which Trainz is supposed to simulate, the shipper, not the receiving customer initiates the process and gives specific delivery instructions.
You say that "a way bill is nothing but a product with a destination". I disagree. A waybill specifies a vehicle with a destination that just happens to be carrying a certain product. The contents of the vehicle are only secondary to the delivery process, such as: Is it a hazardous material? Where should I put it in the train makeup? The most important information the way bill carries is where does the vehicle get loaded and where does it get unloaded.
Using just those two bits of data will keep this project as simple as possible yet give us a tool that will greatly enhance the simulation of prototype operations.
As I envision that the current "Way Bill" system would not be used. I am working on a railroad that has 138 industries with a total of 206 places to spot a car. Creating a Protolars or other interactive interface for each is a very daunting task. I find the system overly complex and difficult to fully understand. Production rate per hour? Who cares. Just tell me how many empty cars of what type are needed on a daily basis - much less information and much more relavant to the railroads operations. Now if I were a manufacturing engineer(which I was in past years) I would be interested in such trivial data as production rate per hour, but to run a railroad, this I do not need to know.
I would keep the animated industries. It is fun to watch the coal dust billow when a car is loaded, but there would be no drive thru loading or unloading.
A year ago we had a thread discussing this topic. mjolnir mentioned several things that I think bear repeating here.
"1) Routes upon which it is to be implemented must have at least one modeled interchange with the outside world, and it must be decided where in the outside world the connection is made. Note that in this case, by "outside world" I mean only someplace not modeled on the route; it may or may not be a real or virtual point on the existing rail network. Just as most real railroads have multiple points at which they interchange traffic, a large route may have multiple connections, and even if there is only one physical connection, this may represent multiple interchange points.
2) More consideration is going to need to be given to the industries on the route. For each industry, one will need to plan where its suppliers are located, how much of the raw material is purchased from the supplier in any given time frame, by what route the raw materials it requires are shipped from the supplier to the industry, and the typical transit time from the origin. Similarly, one will need to determine where the industry's customers are, how much they purchase, and by what route the product is shipped, and the transit time to the destination.
3) One will need to prepare a detailed industry list, listing each industry, the number of cars per day of inbound material from each supplier, the number of cars per day of outbound product to each customer"
And keep in mind that in the real world, very few railroads served both shipper and reciever. That makes interchange portals an important component.
