Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Operating like the propotype does.
- Thread starter mjolnir
- Start date
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
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
New member
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?
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.
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 )
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
ns
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
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!
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.
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.
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.
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
ns
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
Bob Pearson
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
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
Last edited:
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.
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
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
...
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.
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.
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.
Last edited:
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
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
Similar threads
- Replies
- 0
- Views
- 677
- Replies
- 6
- Views
- 2K