Portal - Route or Session?

Is a portal a route or session element? Or, either?

It's in both.

The hardware is placed in the route, but the software i.e., the setup is done in the session.

Now, if you look at a portal's properties in the route, you'll see the driver setup from the session, but editing those properties in the route messes up what's in the session. With that said, keep things consistent so put the portal down during the route setup the parameters and name it what you want. When you create your operating session, edit the properties again and add in your drivers and command.

Hint: When setting up the portals in the session, I highly recommend using the Schedule Library and Copy Commands from related driver command, as well as using saved consists. This saves a lot of time when setting up the drivers even for simple operations.

Thanks - I was getting sessions labeled with default when they were user defined sessions with driver instructions. I have only had this in TRS22. Sessioning the same route in TRS19 does not cause a Default to attach to some driver command lists. I am guessing that this is unique to my setup. Once I finish adding sessions in TRS19 I will go back to TRS22 with your "hinted" strategy.

JCitron said:

It's in both.

The hardware is placed in the route, but the software i.e., the setup is done in the session.

…….

Hint: When setting up the portals in the session, I highly recommend using the Schedule Library and Copy Commands from related driver command, as well as using saved consists. This saves a lot of time when setting up the drivers even for simple operations.

Click to expand...

The hardware can also be placed in the session. In this case don‘t move any existing track-splines, otherwise not the session is saved but the route.

Regards

Swordfish

Swordfish said:

The hardware can also be placed in the session. In this case don‘t move any existing track-splines, otherwise not the session is saved but the route.

Regards

Swordfish

Click to expand...

I've had sketchy results doing it that way, therefore I go to the tried-and-true hardware in the route and programming in the session. This has proven even more true as the Trainz versions have changed. What used to work fine in TRS2009 and TS12 doesn't work the same in TANE and TRS19, and I've had things break between service packs too like the old ATLS crossing which vary between versions so much I can't remember where to place them.