View Full Version : Operating like the propotype does.
mjolnir
September 27th, 2007, 02:04 PM
Friends,
Because I am disenchanted with the way that Auran implements simulation of load management and generationin TRAINZ, I have begun to devise a system that more closely reflects the actual prototype, than either Auran's system, or the more generally accepted "car-card" systems devised in the dummy coupler era by tangible model railroaders. I suspect there is a great deal of similarity in the way these things are handled in various areas in the world, so the discussion I hope will be carried out may be of general interest. However, since I know the details of the system in North America better than the details of the implementation of the system in other other areas of the world, my efforts are devoted to that area.
ns
mjolnir
September 27th, 2007, 03:40 PM
To have a common frame of reference for discussions in this thread, I have created a map for a small route, viewable at
<http://users.waymark.net/~mjolnir/AURN_op.jpg>
[NB: both this and the other link listed below are deliberately not set to automatically load, so that the bandwidth of those users who have no interest in viewing the maps is not wasted.]
The exact location and orientation of this route has not been determined; beyond that it is in the U.S., though at the moment I am inclined towards, The physical layout is dictated by the topography of the area, which can be seen at
<http://users.waymark.net/~mjolnir/topo_map.jpg>
At present, though it probably is a violation of mapmaking conventions, the contour lines in the map are not spaced at uniform intervals. The rail lines depicted are relatively level, high enough above water level that flooding is not a concern; the hill is at least several tens of meters high, and perhaps higher, depending upon my whim.
Layout of the North being up. The green colored lines in the lower part of the map represent the connection to the outside world; the blue colored lines represent the line I am using as the test bed for my proposed operating schemes and devices. As development progresses, I expect to actually create this three board route, and upload it. This route has one industry, a contract packaging facility, located at 11 on the map. Inbound shipments are received in covered hoppers on track 8, inbound bulk liquid shipments are received in tank cars on the track immediately above the number 7. The power house for the plant is located at number 4, and receives inbound loads of LP gas on the track at number 5. Loads of inbound empty containers are received in box cars on the track to the left of the number 9. Packaged products are loaded into boxcars on the two tracks nearest the number 10. The three tracks immediately below the number 7 (except the receiving track for gas loads) are the yard, where inbound loads and empties are held for loading.
Interchange is made on the two blue tracks to the right of the number 3. The interchange agreement provides that the railroad identified in green delivers and pulls from the interchange, and may operate on the green track, and the part of the blue line to the right of the switch just to the left of the numeral 3. Blue line locomotives may not operate on any green line trackage. Further, under the terms of the interchange agreement, traffic delivered to the green line, both outbound loads, and outbound empties, is to be delivered in specific order, based upon whether the destination of the cars means they leave on the green line to the right, or to the left.
The blue line railroad owns, besides the needed locomotives, a modest quantity (actual number not yet determined, probably more than 20 but less than 50) of 50 foot boxcars for outbound shipping; the connecting railroad also supplies cars for loading. some of these are stored for short terms on the green track below the number 3. There may also be a pool of foreign cars assigned for loading at this facility.
Car loading and unloading is governed by simplified versions of the Car service rules used by Prototype railroads in the U.S.
Because I intend it as a test bed, and because I hope to develop an operating scheme which can interface not only with all versions of TRAINZ, but with any other other virtual and tangible model railroads, I am placing this map in the public domain. Anyone is welcome to build this route in any version of model railroad software, or hardware of their choice of platform or gauge. As it is shown here the map has been simplified by omitting some trackage which will appear in my implementation of the final route, but which has no direct bearing on creating operating schemes and software.
ns
mjolnir
September 27th, 2007, 03:52 PM
I botched the editing, and failed to adequately proofread the paragraph which begins
The exact location and orientation of this route has not been determined; beyond that it is in the U.S., though at the moment I am inclined towards, The physical layout is dictated by the topography of the area,
Please read the second line as if the words "defining the upper long end of the map as North." were inserted after the word "towards" at the end of the second line.
ns
sethmcs
September 27th, 2007, 06:03 PM
NS,
What is Car Card Sysyem and How Does It Work in standard Railroad Practice?:o
Good luck in your efforts.:)
mjolnir
September 27th, 2007, 08:35 PM
Sethmcs:
The car card system is detailed in some detail on the Operations special interest group website (<http://www.opsig.org/>, and in the article on page 26 of <http://www.virtualrailroader.com/VR-0804.pdf>.
Actually, for a good percentage of movements on a modern railroad, the car-card system works quite well, as a significant amount of traffic in the U.S. is loaded at a particular place with a shipment to a particular destination, and when the shipment is unloaded, the car is returned empty to the point of origin. For other shipments it is not quite as good, but a complete description of why is best suited to another forum.
ns
Dap
September 27th, 2007, 09:04 PM
mjolnir,
Let me know if there is anything that I can do to help.
In a previous thead, you nemtioned that your favorate railroad, the Rock Island interchanged with the Ft Dodge, Des Moines & Southern at several locations. Do you recall which locations those were?
Dap
mjolnir
September 28th, 2007, 08:21 AM
Apparently, I did not remember where the locations were correctly. Reviewing the route map available on line through the auspices of the Ames Historical Society <http://www.ameshistoricalsociety.org/exhibits/fd_dm_s_rr2.htm>, it appears the only place there was direct interchange was at Des Moines. I'll have to check this furtther though.
ns
Dymond
October 3rd, 2007, 10:16 PM
I guess my first question would be.. Are you modelling it more like the industry system already in place (I need X amount of LP Gas and will be out in 30 minutes) or are you modeling like I need 8 cars of LP gas delivered to this siding once every 48 hours?
mjolnir
October 3rd, 2007, 11:11 PM
Not exactly like either, but closer to the second. The way I perceive it, when you start a session, there will be cars in the yard, and cars at various industries. Instead of a waybill, the instruction will be to take particular cars from the yard, and place them at particular industries, and take particular cars from various industries, and bring them to the yard.
In some manner, the system will keep track of which industries get LP gas, from where and how much, and how long it generally takes for them to unload a car, but as far as the driver / operator is concerned, all that matters is three questions. What car? Where? and When.
ns
philskene
October 4th, 2007, 01:28 AM
Hi ns --
"The way I perceive it, when you start a session, there will be cars in the yard, and cars at various industries. Instead of a waybill, the instruction will be to take particular cars from the yard, and place them at particular industries, and take particular cars from various industries, and bring them to the yard."
Hmmm - maybe I've been doing this without realizing it? Have you seen some of my sessions?
For example:
__________
Chuck and Joe, Dispatcher here.
Now that you are familiar with our operations during day time I have given you the midnight oil run.
Refuel your GP60, attach those nine white Procor tankers in the Transfer Yard and load them at Conoco PetroChem.
As you head north, exchange the full Procors for the empty JAP tank cars.
You will find three at Fingers Foundry, two and one at Armour, and three at AgriBusiness.
Leave the empties at the Conoco terminal at Diaspar.
Go to Loco and contact me for your next assignment.
Mainline trains will be running at 4 minute intervals; you must give them priority.
You are authorised to travel at up to 50mph except in yard areas where normal limits apply.
__________
Charlie, Harry - thanks for standing in on this wet and wild night for the rostered crew who called in sick. Charlie, the heater in the cab of your Class 37 has been repaired so at least you should stay warm. Harry, you will certainly need your oilskin when coupling and throwing points.
An urgent task - take those loaded container flats down to the Container Wharf and unload them at the two unloading points (both ProtoLARS).
For some reason there are two flats with pipes mixed in with the containers - unload them at the gantry at the south end of HeavyTech (LARS).
Reload all the flats with tank containers at the Container Depot (ProtoLARS or LARS), and leave the flats in the upper level Transfer Yard.
Fuel up the locomotive before you start.
Main line trains will be running at 3 minute intervals at the upper level. Always give them priority.
Once again, thanks for your help. Do try to stay dry and warm. Train Control out.
__________
Achtung Kurt und Steffen, your orders.
Coal and water your locomotive.
In West Transfer Yard you will find MAV Rgs flat wagons loaded with logs, DB Sss-y wagons loaded with lorry trailers and SBB Uaikks well wagons loaded with transformers.
You can perform the following tasks in any order.
Take the Rgs wagons to the Dry Sort Yard and unload the logs on the south side of the Dry Sort Yard. Reload with sorted loads on the northern side of the yard and unload these logs at the log dump at Matchless Timber Products.
Unload the Uaikks at the gantry crane and ramp in the north western corner of the container yard. The transformers will unload in sequence when one well wagon has been stationary between the double yellow markers for one minute.
Unload the Sss-y wagons at the yellow mobile crane in the container yard. The trailers will unload when the wagons are stationary between the triple yellow markers.
Load the Uaikks with round stock at the overhead crane at the western end of Diaspar station.
Load all the Rgs and Sss-y wagons with tank containers on the northern most siding in the container yard. Fill the tank cars with benzene at Conoco Chemicals (note: they will not actually load).
Assemble the train in the West Transfer Yard.
Report for further instructions.
__________
Is this the type of operations you mean?
Phil
mjolnir
October 4th, 2007, 04:04 PM
Hmmm - maybe I've been doing this without realizing it? Have you seen some of my sessions?
Truth to tell, no, I haven't. But examining these I note examples of the three very, very large related differences between most of the operating I see in TRS, and the prototype in North America [NB: My comments may reflect operations in other areas of the world, too, but I have no particular basis for knowing for sure whether they do or do not]. First, it takes a considerable amount of time to load and unload a car--an hour per car is a good starting point, and it is often longer than that, sometimes much longer. I have recently seen a car which took six _weeks_ to unload! The second difference is a predicate to the amount of time required to load and unload: "live loading" is extremely rare. I can think of a single class of examples in the U.S.: unit coal trains are "live loaded", but they are not operated by railroad personnel, but by employees of the mine. The third difference is that with a few exceptions, shippers and consignees are considerably further apart than they are in most TRS. So, in the first session, the "nine [empty] white Procor tank cars" would be dropped for loading on one day, and in a later session, when loaded, be picked up land distributed. Further the rail crew has no discretion of over which car goes to which consignee, so instead of "three at fingers foundry", (assuming for the sake of discussion that the cars are PROX 1-9) the crew will be directed to leave PROX 1, 3, and 7 at the foundry. Similary, the cars to be pulled from each industry would be specifically identified by proper initials and car number.
An additional note, about the first session you cite: in the U.S. because of a number of spectacular, but tragic accidents involving certain types of commodities, there are specific laws regarding the handling of many types of commodities. You don't specify in the session dialog exactly what commodity is being loaded in the tank cars, but odds are very high that the commodity being loaded at a Petrochem plant, is one which the regulations require be placed in a train no closer than six cars from the locomotive.
Charlie and Harry might well take the flats loaded with pipes, and the intermodal equipment to the specified locations, but rather than being instructed to unload the equipment, they would be instructed to drop the equipment for unloading, and to pick up equipment they (or another crew) had dropped at those facilities earlier that was already loaded (or empty) and set to go.
My comments may or may not apply to Kurt and Steffan, the "Achtung" suggests to me that they are operating in Germany in prior years, and I am not sufficiently familiar with their environment to comment on that session.
My comments here should not be interpreted as meaning that there is anything wrong, or defective with your sessions, or with the operations model used by most model railroaders, both virtual and tangible. Not only is it the way model railroaders have been operating for many years, and so is validated by the culture of model railroading, but more importantly, your model railroad is in your world, of which you are the master. You can operate it any way you choose, and I won't criticize. However, my preference is to operate my railroad in a manner which more closely reflects how things generally happen in the real world.
I have devised my first TRS route, a map of which is at
http://users.waymark.net/~mjolnir/AURN_op.jpg (http://users.waymark.net/%7Emjolnir/AURN_op.jpg)
At the beginning of a session, there will be cars received in interchange on the interchange tracks (the tracks to the right of the numeral 3); there may be loads and empties in the yard (the three tracks above and to the right of the numeral 6). Track 5 serves the powerhouse (4), and is where carloads of LP gas are unloaded. The sole customer (located at 11) on the route is a business which receives inbound product in bulk, blends and packages the product into consumer sized packaging. Inbound empty packaging is is received on track to the left of the numeral 9. Inbound loaded tank cars are unloaded on the track just above and to the left of the numeral 7. Inbound hoppers on the track numbered 8. Boxcars are loaded on the two tracks at the top, to the left of the numeral 10.
At the start of a session, there will probably be partially unloaded cars on tracks 5, 7, 8, and 9; there will be loads and empties in the yard, and there may be loads and empties on the interchange tracks. At the beginning of a session, there will be orders from the shipper as to which loads are to be pulled from 10, and which empties are to pulled from 7 and 8, and which cars are to be moved from the yard to the various loading and unloading tracks. Sometimes it will be necessary to move a partially unloaded car to pull the empty behind it, in which case the unloaded car needs to go back to the place it was originally spotted. The order in which cars are delivered to the interchange tracks is important. For interchange deliveries, cars destined to points on the connecting line (in green) to the right need to be grouped separately from cars destined to points on the connecting line to the left, so cars need to be in the proper order.
In the sessions on this route, the instructions will be to pull loads and empties from the plant, to spot empties for loading, and loads for processing, and to pick up and deliver the interchanges. Specific inbound loads will have to be delivered to specific spots. On occasion a car may be delayed, and warrant a special trip to the interchange to get the car as soon as it is delivered, and spot it to the plant.
Now, imagine that this route is included as a subset of a route of the railroad which is represented in green, so that one operates the interchange from the opposite direction. Here, one would only be concerned with pulling loads and empties from the interchange track (3). In this case, your train might have a block of cars in it which get delivered to the interchange, and there might be cars at the interchange which were delivered a couple of days ago (or longer) for you to pull.
ns
philskene
October 4th, 2007, 05:34 PM
Hi ns --
Your comments about prototypical operations are very valid. It always amazes me, for example, the time it actually takes to do simple switching operations in real life. And you are quite correct about the time taken to load freight cars.
Most of us, though, do have another life to live, and spending eight hours shuffling a couple of freight cars around a yard may not appeal to some Trainzers.
Rather than start from scratch you might like to consider this route as the basis for prototypical operations:
http://i23.photobucket.com/albums/b392/nineercharlie/PSC%201/PortSwitchingCo_map1.jpg
http://i23.photobucket.com/albums/b392/nineercharlie/PSC%201/PortSwitchingCo_map2.jpg
http://i23.photobucket.com/albums/b392/nineercharlie/PSC%201/PortSwitchingCo_map3.jpg
The transfer yard with the Class 1 railroad is at the southern end where cars are picked up and left. There are a large number of interactive industries to cater for a very broad range of rolling stock.
You are more than welcome to construct sessions for this route. Look for "PortSwitchingCo" on the Download Station. All the assets needed by the route are on the Download Station.
More details can be found here:
http://forums.auran.com/trainz/showthread.php?t=11631
Another route that might interest you with a similar theme of a short line interfacing with a larger railroad is YardSwitchingCo:
http://forums.auran.com/trainz/showthread.php?t=7362
Cheers,
Phil
wreeder
October 5th, 2007, 05:56 AM
Hi ns,
I am very much interested in your project. My Trainz use goes back to the original retail version which did not have interactive industries. I enjoyed running sessions much as you have described on routes from trainzproroutes.com. I used a simple car forwarding system done on index cards. The system was based on one described by Bruce Chubb in his book on operating your model railroad. When TRS2004 came out, I found the interactive loading and unloading to be too toy like. In fact, my interest in Trainz wained because of my belief that Trainz was becoming too much of a game and no longer a simulation of a railroad. I became more of an arm chair virtual railroader. Reading the forum or maybe starting UTC for a quick session but the fire was gone. I did buy TRS2006 in hope that it would be an improvement and in some ways it is. The easy session creation system and wonderful routes like NorthBay County got my interest up again. Also I discovered the Razorback Railway online and began to run their sessions. I suggest you check them out at razorbackrailway.com. Another thing you should look at is the ProtoLARS system at trainzproroutes.com It offers the many of the features you want in your sessions. You can set up an industry to require a car or cars be spotted and left by the train crew. Then it can take a preset period of time for the cars to be loaded or unloaded either one at a time of all at once. So the following would be possible, a crew with orders to pick up four loaded boxcars would find that only three are finished and one is half done. The half loaded car is blocking access so it must be moved and returned to its spot to complete the loading process. It is a very powerful system. They also have a database system for car movement in their download depot that I have not had a chance to try out. From the description, it sounds like something that would interest you.
William
mjolnir
October 5th, 2007, 08:18 PM
There are a couple of is at least one route, with a couple of sessions by the RBR people included in the US commercial distribution of TRS, which is a good implementation of the work of what would be called in North American parlance a "way freight", or "local freight". As to ProtoLars, I have looked at it briefly, but my impression is that too much regularity. While I don't want to reinvent the wheel unnecessarily, I want a system which would provide for a bit of "randomness". When a machine in a plant breaks down, the railroad may or may not know exactly what happens, but the plant which normally loads two cars a day will have a day when one car, or just a part of one car, is loaded, and nothing is loaded the next day, or few days. Then the first day or days after the machine is repaired, there will be extra shifts and extra production to catch up with back orders. The employees of the railroad may or may not know exactly what happened with the plant, but they will know that today and tomorrow there is no switch required, and the next two days after that, two switches per day will be required instead of one.
The prototype railroads in the U.S. participate in agreements called "Car service rules" which provide how railcars are to be handled. I do expect to try to implement a database which would permit simulation of Car service rules. [NB: for the sake of interest of those who might be interested in Car Service rules, I am in the process of trying to acquire a current copy (the one I have is nearly 30 years old), at which point I plan to post on-line a tutorial bit about how real railroads use equipment]. MOre about the database later, and probably in another forum, as I judge it a bit off topic in this one.
ns
nwhitney
October 5th, 2007, 08:22 PM
Another thing Lars has is the interchange track (can't find the kuid right now), where you leave loaded cars, and a set time later, they're replaced with empty cars.
Norm
philskene
October 5th, 2007, 11:59 PM
ns --
You may be seeking just a little too much.
Good luck anyway.
Phil
mjolnir
October 6th, 2007, 02:34 AM
ns -- You may be seeking just a little too much.
If so, it won't be the first time, but there has been a time or two, when I thought I was seeking too much, and it turned out I wasn't.
ns
mjolnir
October 6th, 2007, 02:36 AM
Another thing Lars has is the interchange track (can't find the kuid right now), where you leave loaded cars, and a set time later, they're replaced with empty cars.
Well, I hope to configure the interchange track a little differently, where there is no specific link between the cars delivered and cars received. That is, a car might appear on the interchange track that will eventually be spotted to the industry, and when empty the car will be delivered back to the interchange track, and disappear from the railroad. On the other hand, other car might be delivered loaded at the interchange, and return empty (or possibly loaded) at some future date.
ns
nwhitney
October 6th, 2007, 06:33 AM
Well, I hope to configure the interchange track a little differently, where there is no specific link between the cars delivered and cars received. That is, a car might appear on the interchange track that will eventually be spotted to the industry, and when empty the car will be delivered back to the interchange track, and disappear from the railroad. On the other hand, other car might be delivered loaded at the interchange, and return empty (or possibly loaded) at some future date.
ns
I would imagine you could introduce randomization into the script, but as I can't write script to save my life, I have no idea how to properly go about it.
Norm
mjolnir
October 6th, 2007, 01:48 PM
I would imagine you could introduce randomization into the script, but as I can't write script to save my life, I have no idea how to properly go about it.
I"ve not get gotten to the point where I've studied the scripting language in any detail. I will be mildly surprised if there is an implementation of "random" capabilities built into the scripting language, though, as some time back I posted as suggestion about it in the suggestion forum, and no one responded with anything close to "Hey, Noobie, read the manual; it's already there!."
ns
Jenolan
October 6th, 2007, 06:22 PM
Using Math.Rand() and if{}else{} doing a random widget is simply a matter of coding it.
You could even do things like do something randomly based on speeding breaches or anything else you can think of.
Dymond
October 6th, 2007, 06:34 PM
I kind of agree with Phil IF you are expecting Trainz to do all the thinking for you. However there are alot of 3rd party Switchlist and Waybill programs created for running model railroad sessions that can do exactly what your looking for.
mjolnir
October 6th, 2007, 07:43 PM
At the moment I am inclined to keep as much of the "logic" as possible out of TRS, and put it in a "helper application". One reason for this is that what I am proposing to develop is an additional means of controlling operations, so that there is a choice of operating schemes, just as one can choose between DCC and cab control mode when playing as driver / engineer. Another reason is that some of what I want to accomplish may require data structures that are not supported by TRS. For example, consider a modeled industry which has a dedicated car supply. Two cars of this supply are loaded, one to a destination which is three times as far away as the other. Both cars are delivered in interchange on the same day. Now, the car going three times as far away should not re-appear on the route for at least twice as long as the other car delivered the same day.
Another reason for keeping the logic out of TRS is allowing for the possibility of using the software with other platforms. If an individual on another platform, whether another simulator, or even with a tangible model railroad, finds out about the package, and begs eloquently enough ["I'll pay ..." might be eloquent in the right circumstances?] that I am persuaded to implement the software for that platform (tangible modeling, for example) if the logic is external to TRS, then I may have to change some read and write routines, and create some data structures, but this would be easier than duplicating logic.
I don't claim to have done an exhaustive survey of the available software programs for generating switchlists and waybills, but I every one I have looked at thus far seems hopelessly mired in the 1950's model railroad mindset. For tangible model railroaders, there is are limits that do not confront virtual modelers. For one thing, there is not much "freeware". In the arena of tangible modeling, this mostly involves two things: going to an auction, seeing a box of modeling equipment no one wanted, and buying a couple of hundred dollars worth of equipment for a token fee is one, and an idea I remember reading probably 25 years ago, taking an "ordinary" car and painting one side of it with one car number, and the other with another, was a second. So a tangible model railroader is has a need for an operating scheme that simulates realistic operation with a few dozens of models in a finite space. By contrast, virtual modelers do not have these constraints. 10 x 20 yards / meters would be a very generous layout space in tangible modeling; in virtual modeling it is two grid squares of a single board. In like manner, while there is no way for a tangible modeler to run a car he doesn't actually have possession of, this is a trivial matter for virtual modelers, where the physical space required for a fleet of Goodpasture, Inc. as listed in the January 1980 Official Railway Equipment Register--4 cars, two each of two types--takes the same physical space as the entire fleet for Conrail (120747 cars, in a number of classes and subclasses) reported in the same source.
Finally, the various waybill and switchlist operating schemes were state of the art when they were developed in the 1950's, but has remained more or less static and ignored advances in the state of the art of gaming control. The computational capabilities each of us has are not used as well as they could be when our hardware is used only for input, data maintenance, and output capabilities. What I want to do is to create a program (or suite of programs) which would allow interested parties to choose to model on a more prototypical basis, a wider range of the overall operations of a railroad, rather than just those bits related to the operation of trains and engines.
ns
Sylvicolus
October 6th, 2007, 09:17 PM
Something that would help this endeavor is the creation of rolling stock that can be given various running codes and numbers, such as GATX 12945 or PFE 78345. I think I read about passenger cars that could be given different names in Surveyor by clicking the edit icon (?) and clicking on the car to change the name (as done with other objects) and the name shows up on the side of the car. As someone done this with freight cars?
Dymond
October 7th, 2007, 01:09 AM
I believe there is something called the ARN that can number rolling stock that have been customized to do so. I'm curious MJ if you have looked at Pro-Trak and RailOp. These are some EXHAUSTIVELY deep programs. I believe one can even tell you if your railroad is profitable or not.
Kelly88
October 7th, 2007, 03:05 AM
Something that would help this endeavor is the creation of rolling stock that can be given various running codes and numbers, such as GATX 12945 or PFE 78345. I think I read about passenger cars that could be given different names in Surveyor by clicking the edit icon (?) and clicking on the car to change the name (as done with other objects) and the name shows up on the side of the car. As someone done this with freight cars?
there are ways to give individual units different names or numbers
but then do not use portals of any kind as when they come back out the names numbers revert back to the original and if you have say 3 locos the same and name them loco1...2..3
if loco 1 goes into a portal it will come out as Loco4
be warned I spent hours once renaming locos and wagons to make a session more easy to control, and then when run every thing was OK untill they started to come out of portals ( what a mess )
mjolnir
October 7th, 2007, 04:26 AM
Pro Trak has some features that are close to what I have in mind, but there are some things that I want to do differently than they are doing them. As to portals, while nothing is definite at this point, there is a good possibility that the software will function "outside" of TRS, and that it will not make direct use of portals.
ns
Dap
October 7th, 2007, 12:33 PM
Pro Trak has some features that are close to what I have in mind, but there are some things that I want to do differently than they are doing them. As to portals, while nothing is definite at this point, there is a good possibility that the software will function "outside" of TRS, and that it will not make direct use of portals.
ns
Ah, but just imagine if we did use portals. Inbound interchange consists would be automatically generated by the "Opererations Software" ( we could call it OPSOFT ). I see this as a very desirable feature.
Dap
Dymond
October 7th, 2007, 04:29 PM
Ah, but just imagine if we did use portals. Inbound interchange consists would be automatically generated by the "Opererations Software" ( we could call it OPSOFT ). I see this as a very desirable feature.
Dap
I 100% agree with that. It really would add an 'interactive' feature to Trainz. Personally I would love to write something that was web based that could do 3 things.
1)Allow users to create their own switchlist for their layouts. There is nothing better than having car movements for a reason. I wish there was a way to send something to the software to 'spot' these cars where they need to be when a session starts.
2)Create these 'offline industries' to be able to send cars to these sessions via a portal. If your session says your going to recieve XX cars of empties and loads then they will roll in when their are scheduled to.
AND
3) Allow users to be each others 'offline industries'. Wouldn't it be great to tie your layout to another users? When your consignee needs a product from their shipper, they get the switchlist to roll out the empties, fill them and ship them off via a portal. When they hit the portal they will show up on the next schedule to your yard to be broken out and sent where they are needed.
I know alot of this is a pipe dream on my part but I know there were some pretty decent dos based switchlists programs that I know I could convert to PHP if I had the dang source code!
dlevine99
October 9th, 2007, 08:53 AM
Sethmcs:
... and when the shipment is unloaded, the car is returned empty to the point of origin. ...
ns
In the 1950's the car service rules (in the USA) required railroads to try to load empty cars from other railroads with shipments going in their direction.
An article in Model Railroader magazine a few years back (I'm tyring to find the issue so I can give more details later) gave an abreviated version of these rules and showed how to modify a car card system to use them.
mjolnir
October 10th, 2007, 04:36 AM
The situation with empty railcars in the US was a bit more complicated than you cite. A freight car owned by another railroad than the one it was on, empty at a junction with the owner, was to be loaded to a point on, or via the owners rails, or returned empty to the owner at the junction, with the exception of cars which were covered by an order that they were to be returned empty via reverse route.
I have a copy of the Code of Car Service Rules effective 1 January, 1980, and expect to have a current copy shortly.
When I say that the helper application I propose may not use portals, it is because I want to allow the possibility of use of the application on other software and even tangible platforms, where the portal may not exist, or where it may function differently than it does in TRS.
With respect to off-line industries, I intend to provide for these with a great deal of flexibility. Suppose an industry on your route processes five cars of widgets per day. One option would be to merely say that the industry gets five carloads of widgets per day, and have five cars show up on the interchange track. At the other extreme, I intend for the user to have the capability of specifying the origin point for each carload of widgets. In a similar manner, the user could choose at one extreme just to deliver five cars of finished product to interchange, without worrying about where the loads are going, or to specify the not only the destination city, but the complete route.
Dymond
October 10th, 2007, 09:52 PM
Well MJ then I say start writing! If you need alpha and beta testers I'm your man.. Do you have an idea of what your going to write this in?
mjolnir
October 11th, 2007, 04:24 AM
Besides the Auran Scripting language (for the actual interface to Auran's version) I don't know yet what language I'm going to use, though there is some likelihood that it will be a dialect of C. For one thing, there's a lot of work to be done before even thinking about starting to write the code.
ns
RPearson
October 11th, 2007, 06:17 PM
Not to be too pesimistic but interfacing 3rd party utilities with the game in progress is afaik not possible. That is to say I know of no way your utility program written in C or whatever can commicate with a script program run by the game engine. If an interface into the game is necessary I'd suggest you find out what if anything is possible before going too far.
Bob Pearson
mjolnir
October 11th, 2007, 09:06 PM
Wise advice, indeed, Bob. It is premature at this point to talk about interfacing with the game in progress. My present working hypothesis is that one might have a multi-part session, and that certain railcar assets in the session might be managed by an external module. Thus, for example, the module would maintain and process a data object which is a list of designated home road cars, so that after being delivereda as a load to a connection in interchange, without any input from the operator they are off line for a period, during which at some point the status is changed to empty, and then later they reappear empty at the interchange. Or as another example, that the load / empty status of cars spotted today at a particular industry is managed so that the cars spotted today are probably unloaded by day after tomorrow, but might be unloaded sooner or later. This type of management can be done "outside" the session, that is, before the session is resumed.
However, I am encouraged to see that the TRS scripting language defintion provides a keyword "native", defined as "a method specifier that indicates the method is implemented with native code (i.e. not script code)." I am not yet sufficiently knowledgeable about TRS and the scripting language, but this seems to imply that I can call a method from within a TRS script written in native code which is capable of doing functions which may not be possible from within the TRS scripting language itself, for example, obtaining the system time.
Finally, keep in mind that what I am wanting to do here is, at this point, a "wish list", and I am fully aware that it may not be possible. But imagine the possibilities if it is!
ns
Dymond
October 12th, 2007, 12:29 AM
I know it can be managed somehow. See what Lars has done with his E-Portal. You may not be able to interact with it live but even the ability to create a session that could be imported, ran then exported out to show where you left your cars would be better than what is in place now.
Dap
October 12th, 2007, 03:06 PM
mjolnir,
I have been investigating what software is available now and have discovered Ship-It by Albion Software. Are you familiar with this package? It seems to do most of what you are looking for except the Trainz interface. It is not a card card system, but a very realistic freight handling simulation. I especially like optiona for handling empties. Although a bit pricey, I am considering getting it to enhance my Trainz experience. Does anyone out there have any experience with this softwware?
Dap
dlevine99
October 22nd, 2007, 03:23 AM
...
However, I am encouraged to see that the TRS scripting language defintion provides a keyword "native", defined as "a method specifier that indicates the method is implemented with native code (i.e. not script code)." I am not yet sufficiently knowledgeable about TRS and the scripting language, but this seems to imply that I can call a method from within a TRS script written in native code which is capable of doing functions which may not be possible from within the TRS scripting language itself, for example, obtaining the system time.
...
Unfortunately that is not what "native" means in gamescript. It means that the implementation is built into the game code and the GS compiler knows how to generate a call to it.
I seems to me that GS is based somewhat on JAVA and can't read or write to ordinary files to avoid the possibility of viruses and other malice-ware. It can read the stringtables of the config.txt files of assets and write to the JetLog.txt file. But Trainz only reads the config.txt files on startup and only writes (or at least only closes) the log file on exit.
These are the files that Lars uses to get data in and out of eportal. The etrainZ external program creates a config.txt file in <Tranzroot>\world\custom \eportaldata\<eroutename> this is of kind mesh with an empty meshtable. and a stringtable with the train data. When a train enters an eportal the data is written to a log file (not sure if it's JetLog or ResultLog) which etrain can parse to recover the data.
TRS2006 however, has iportals which can transfer data over the internet. I haven't used '06 very much and have never tried iportals. But it seems to me - based on general internet principals - that one could configure an iportal to talk to localhost and, if you can figure out the transfer protocols, write a local server to manipulate the iportals programmatically.
dlevine99
October 22nd, 2007, 04:18 AM
Car card vs. waybill-on-car.
About 30 years ago model railroaders were experimenting with what were called waybill-on-car systems as an alternative to car cards. The idea was to affix some sort of small tag to the top of each (non-empty) car that would show (either with text or color codes) the type of car required and shipper on one side and the consignee on the other.
You would make up a bunch of these tags (perhaps adjusting the number of each kind to the traffic flow for each industry) and a few special tags for shipments "originating" at interchanges. At the beginning of a session you pull a handful of tags and look for appropriate empty (i.e. tagless) cars for each shipment.
These systems fell into disuse mainly because of two objections. First most cars had to be modified at least slightly to hold the tags securely. While for some systems this was only a pinhole, someone who had spent hours scratchbuilding a car probably wouldn't want even that. Secondly most people thought that the tags looked ugly and unprototypical. Neither of these objections applies to Trainz.
The TPR Freightcar Destination System (also known as the Destination Database) comes very close to implementing such a system. It only provides for a single movement of each car and the destinations have to be chosen and set manually in driver mode. But I think that it is a good starting point for designing a "waybill-on car" system.
Dap
October 22nd, 2007, 09:29 PM
I downloaded the TPR Freight Car Destination System and manual and was very disapointed in its limitations. I think a paper system would be more user friendly. And when I am in driver mode, I don't want to be doing set-up stuff. What would it take to make the set-up mode work in Surveyor?
And then it will need at least two moves capability. This would be a good start.
The ultimate goal is to have the capabilities of Ship-It and be interactive in realtime with train movements.
My only experience with virtual railroading prior to Trainz was Train Dispatcher. Their system will handle perpetual operations. One of my favorite territories would run seven days of operation before repeating, each day of operations being different in number of cars on the road and number of trains running. Maybe someday, Trainz will have this capability.
Dap
vBulletin® v3.6.3, Copyright ©2000-2009, Jelsoft Enterprises Ltd.