Portal weirdness

chili46

Member
First disclaimer: I am not a fan of the portals so my comments may be a bit biased.

I'm working on a map that has portals at multiple exit points. Normally I set up holding yards that loop around so the consists never, ever leaves the map. The current map came with portals so I'm trying to use them - but not very successfully.

Here's the scenario. A grain consist with 28 cars goes to 7 different silos to pick up wheat. Each silo is assigned specific hoppers in the consist. When the train returns from a portal all the car names/numbers are messed up. A test train came back with two boxcars having the same, identical name!

Has anyone else noticed this or am I just being to picky?
 
Portals are weird, awkward, and quite quirky.

This, unfortunately, is one of the quirks. If you setup a consist with randomly generated car numbers, the numbers are no longer random for every consist that is spat out by the portal and are the same numbers you entered originally. I discovered this ages ago and mentioned it here in the forums. I was then informed that was the case with a statement by someone I can't remember that I should basically get over it and suck it up as a "feature".
 
You could try the new asset <kuid:121843:100602> InstantMoveTrain. The train moves to the track mark and then instantly appears at another track mark.

Carl
 
Portals are weird, awkward, and quite quirky.

This, unfortunately, is one of the quirks. If you setup a consist with randomly generated car numbers, the numbers are no longer random for every consist that is spat out by the portal and are the same numbers you entered originally. I discovered this ages ago and mentioned it here in the forums. I was then informed that was the case with a statement by someone I can't remember that I should basically get over it and suck it up as a "feature".

Yes, that's some "feature" isn't it. :eek:
 
You could try the new asset <kuid:121843:100602> InstantMoveTrain. The train moves to the track mark and then instantly appears at another track mark.

Carl

Sounds interesting, but not sure that's what I'm looking for. I have AIs running from one end of the map to the other end and then back again (infinite loop). Like I mentioned, I have some maps with holding tracks at the "exit" points. They drive to a track marker and wait for some specified amount of time or wait for a trigger. Then they loop around and traverse the map in the opposite direction. This is a little time consuming to setup, but hey, don't most of us play trainz to kill time?

I could create a holding yard map and then merge that into any route I want to use it on. Yeah, I'll work on that.
 
Yup. I've done the loop thing myself. It wasn't so bad once I got it done. I put signals, track markers, and direction markers to prevent the AI from trying to circumvent the loop and stuff the works up. With that worked out, the AI did what they were supposed to. The issue I had was the extra set of commands I had to create, but using the Schedule Library was my savior for this.

Yeah... not-so-random consists, that are supposed to be random but not is a nice "feature". This is also the same with pre-created consists. If we setup and save consists, the freight cars all have the same numbers given at the beginning, but anyway, I think the loop will work for what you want in this case. You could use a combination of loop and portals. Portals for the truly through trains and loops for those captive consists.
 
You can add another item to the portal "weirdness" list. This "feature" would only be noticeable under some special and probably rare conditions and only came to my notice after using the new UDS feature found in TRS19 Platinum Edition and Trainz Plus.

A train that is driven into a portal and later returned to the layout will be returned in the same layer as the portal and not in the trains originally assigned layer. Trains that are produced by a portal will be assigned to the same layer as the portal.

This could become an issue if you use the UDS to make the switch from Driver to Surveyor after a train has been returned to the layout from a portal. For example, if a train is originally in a Session Layer then it is part of a Session. If it is returned from a portal then it will now be in a Route Layer and will be part of the Route. If you then switch from Driver to Surveyor and save the Route then the train will be saved in the Route not in the Session. If this is an issue then the remedy is to open the property dialogue window of any wagon in the train after it has left the portal and change its assigned layer to the correct one. This will set all vehicles in that train to the same correct layer.
 
I've been gradually removing portals and replacing them with semi-hidden loops in the landscape very much in the same way that I would do if I was building a large real world model railway layout. Most of the passenger trains on my Norfolk layout have a set make up so they might as well sit in their own dedicated loop sidings instead of running the risk of them being messed up by being created by a portal. I only really have some goods trains and two branch line passenger trains working from a portal at the moment and since they seem to be behaving themselves I've left them alone for now. Trains running off the end of portal tracks instead of being consumed is still an annoying intermittent problem. I'm considering using a trackmark and the remove train command instead to get rid of the problem for good.

I've been building up a nice schedule library for all the various service runs on the layout. This has the advantage that should I decide to run an extra relief service I can go ahead and shunt the train into the right formation using the yard pilot loco and once an appropriate train engine is coupled up I can give the driver their schedule without any further fuss or bother.
 
Last edited:
Another thing I forgot to mention is if you save a session to continue playing it at a later date, any trains in a portal when the session is saved will be gone. Another nice "feature". :confused:
 
You could try the new asset <kuid:121843:100602> InstantMoveTrain. The train moves to the track mark and then instantly appears at another track mark.

Carl

And it works perfectly too. I used it to do away with a portal just this evening when I was working on my layout. The only thing to watch is that the train will be oriented in the direction of the track that it's being sent to.
 
I have been using iPortals to go between routes as you can set them up for "with in this computer". The disadvantage is you can only send 2 at a time then they start to get lost.
 
And it works perfectly too. I used it to do away with a portal just this evening when I was working on my layout. The only thing to watch is that the train will be oriented in the direction of the track that it's being sent to.

Lewiscc65 Great asset. I decided to try it and it works great. I can have 3 or 4 sidings that the trains stop at and wait for some amount of time then warp to the MOVETRAIN_# and continue.

KotangaGirl, the plus is that the trains do change direction if you have direction markers on the track thereby eliminating the need for a long loop to get turned around.

Now the question is, if I have multiple trains going to the same TM, what happens if there's a train there already? Seems like it could get messy. So, to avoid that, I may put the same number of sidings in the opposite direction. That too presents a problem since there seems to be only 21 TMs available (the driver command is hardcoded for MOVETRAIN_#'s 0 through 20) and on a very large map with many entry/exit points I think 21 TMs might be used up quickly. But that could just be me over-thinking the issue.

On the other hand, if I had multiple sidings in the opposite direction and the MOVETRAIN_# at the beginning of the sidings, then I could have the train go to the MOVETRAIN TM and then to a specific siding before continuing the schedule. More setup and more AI programming, but sometimes that's half the fun of creating a layout.
 
Lewiscc65 Great asset. I decided to try it and it works great. I can have 3 or 4 sidings that the trains stop at and wait for some amount of time then warp to the MOVETRAIN_# and continue.

KotangaGirl, the plus is that the trains do change direction if you have direction markers on the track thereby eliminating the need for a long loop to get turned around.

Now the question is, if I have multiple trains going to the same TM, what happens if there's a train there already? Seems like it could get messy. So, to avoid that, I may put the same number of sidings in the opposite direction. That too presents a problem since there seems to be only 21 TMs available (the driver command is hardcoded for MOVETRAIN_#'s 0 through 20) and on a very large map with many entry/exit points I think 21 TMs might be used up quickly. But that could just be me over-thinking the issue.

On the other hand, if I had multiple sidings in the opposite direction and the MOVETRAIN_# at the beginning of the sidings, then I could have the train go to the MOVETRAIN TM and then to a specific siding before continuing the schedule. More setup and more AI programming, but sometimes that's half the fun of creating a layout.

I will have try that with using direction markers. It certainly would make setting things up a lot simpler. Thanks for that.
My layout is only a 40 mile long patch of Norfolk (Uk) so I don't think I would ever run out of coded TM's, but I could see that being a problem on longer routes.
 
Back
Top