I have discovered portal-generated trains.

JonMyrlennBailey

Active member
Yesterday, I discovered how to generate AI trains from the portals and now I am experimenting with them on my route. There are seven portals on my Mojave Sub route as follows:

at the southeast end there are:

Palmdale
Barstow
Sealres Turn


at the northwest end there are:

ATSF to Fresno
ATSF from Fresno
SP to Fresno
SP from Fresno

I set up 5 portal trains set to be emitted hourly and immediately when session starts.

3 trains are set to come from the east end to various west end portals (a passenger, a short freight, a medium-length freight)
2 trains are set up to come from the west from various west end portals (a passenger, a long heavy freight)

The Mojave Sub has a double-track system in some parts and a single-track system in other parts: mainly over the Tehachapi Mountains with some intermittent sections of double track. My concern is there might be conflicts between AI trains moving in opposite directions at junctions where tracks merge from double to single. Trains might get in each other's way. There is also a feature to assign priority numbers to AI trains, 1, 2 and 3.

My questions are:

Should the longer heavier trains get the higher priority numbers (1)?
Should medium trains get a 2?
Should short, light passenger trains get a 3?

What about setting priorities when making schedules?
Should the priority be the first item on the drive schedule line?


Central Portal Control lets me assign priority numbers to each created train.

What about my timing for portal release of trains. Is it BAD to have trains
released from all the portals on the entire route at the SAME time or should I stagger portal
release times considerably? Should portal generation of trains be sequential or random?

Is hourly too frequent to release trains on the Mojave Sub?

What I want portal-produced AI trains to do is continuously REPEAT their respective assigned schedules: I want the same portal trains to re-emerge from their original portals after they complete their drive schedules over and over again. When configuring schedules, I have "Enable Repeat" as the last command issued to drivers of portal-generated A1 trains (if this even necessary).
 
Last edited:
You've asked a lot of stuff here, and rather then attempting to answer everything, I'll give you some overall hints with portals which I have found with experience.

The time interval should not be too close as that will clog the route with traffic. How close is too close? I find 60-90 minutes to be comfortable with a route this size. So yes, 1 hour is good. If you find that there's a bit more traffic than the route can handle, increase the interval. On my very, very long personal route, I've actually increased the time numerous times and staggered the time for various portals so that they don't all start putting trains out on the lines at once as this can cause a sudden bog down of performance, and this drop in performance can cause the already AI drivers to become dumber than they already are.

Priority can be tricky. Overall, priority is done by changing the weighting of the consist and by the weight value of the route as set by a priority marker. Having said that, I'm not sure how the portal control works, but I'm sure it is done in a similar fashion. I can't remember if the weighting is 1 for high or 3 is for high priority so I can't help you with that.

To have trains repeat their schedule, always the same schedule, do not set the portal to random consists. Let the trains run in the order they are placed in the portal setup.

I think what I've said here will get you going in the right direction. I'm glad you are having so much fun puzzling your way through Trainz. :)

John
 
I ain't never figured out how to use Portals, so on my routes, I just have AI trains running back and forth with loops on each end of the route and just program them to go around and back and forth.
 
Track Priority Markers

The priority feature in Trainz is poorly named. Trains are not given priority one-over-another. The user assigns a priority to certain tracks by adding a "Track Priority marker" (V key on "Tracks" tab), and placing a marker on the track. Default track priority is 2, if I'm not mistaken

When a train is assigned a priority number, it uses this number to evaluate which paths contain a matching priority marker, and will choose those paths in preference to other paths. If the preferred path is blocked then the train will choose another path, even though the priority of the new does not match the priority if the train.

The direction of the marker is significant and it will be ignored if facing towards the train.

The priority of a train can be changed at any time ("Priorityz" driver command) and the new setting will apply the next time the AI makes a path decision.

Regards - Trevor
 
Last edited:
The timing of trains emitted from portals

A train that is emitted from a portal may be consumed by another portal at the end of its journey. When trains are consumed by a portal then they can either be made to disappear forever or they could be re-emitted from any portal.

If the first option is selected then the portal manager will emit another train when its scheduled time arrives. Repeating the schedule does not have a bearing here.

When the second alternative is chosen then the time of re-emission depends on a) the length of the original journey; b) the delay time specified by the portal manager; c) by the amount of traffic at the emitting portal.

There is another problem to be overcome: The scheduled commands, up until the train enters the consuming portal, are used up. Any commands after the <drive to portal> command are carried through and executed when the train is re-emitted. This makes the second option more difficult to manage in the long term. There are ways of dealing with this - lets wait until you are ready for more bravery.

That said, when a number of trains are repeatedly emitted from portals they are likely to clash when it comes to passing over single track lines. Once again, advanced techniques can be used to overcome log jams.

Regards

Trevor
 
Thank you Trevor for the portal details.

I keep things simple and run trains from Portal A to Portal B. I never played with the other options. :)

John
 
Portals transmit trains on one route ... iPortals can send a train from your 1 route, to another route on your own PC, or to another PC in your own house, or to someone worldwide ... and the train will appear when you open the other route.

http://i525.photobucket.com/albums/cc339/cascaderailroad/110430WestStaging.jpg

http://i920.photobucket.com/albums/ad47/mpeterll/Wyefield Junction Stage Two/WFJ120401.jpg

To avoid Portals and iPortals, you can also send a train on a long route looping, run-on trackage, on extra baseboards, to simulate a long distance route
 
Last edited:
Back
Top