Portal Exit
Portal Exit: Exits for items leaving Subsystems
When an Item has to leave a subsystem to go to the screen above, it needs a place to leave inside the portal.
The Portal Exit provides passage to the screen above, where the item will appear at the Portal object. A Portal Exit is created automatically for every sub system screen, which in turn is created when a Portal object is added to a model.
The Portal Exit is much like a normal Exit, but instead of it destroying items it returns them to the screen containing the Portal object associated with the sub system screen it is on.
Portal Entries are for items entering Subsystems.
All subsystems must have at least one Portal Entry and one Portal Exit.
No interaction editing is necessary for Portal Entries and Portal Exits.
Portal Exit States
Idle Portal Exits always appear as idle.
They can however have different icons selected for them.
Portal Exit Object Editing
The following object menu options are available in a Portal Exit.
Menu Item
Description
Up To Portal
Enables the user to switch the screen display "up" to the Sub-system screen containing the Portal Object that owns the current subsystem.
Attributes
Attributes can be added to a Portal.
Click on the Attributes option brings up a list of Attribute names for editing, or enables you to name a new attribute.
(This option is also at the Portal Entry and the Portal itself).
Connect To
This option lets you select from a list of objects the one you want to assign to this Portal Exit.
Items entering th portal from this object will now appear always at this Portal Exit.
When you assign an object to a Portal Exit, its name appears above the Portal Exit. Note that an outside object with a leading underscore in its name will not be displayed.
Many Portal Exits can be linked to "Any".
When there are numerous paths of the same class leaving a portal, Portal Exits set to "Any" (i.e. no specific target object) will send items out of the subsystem along the first flow (lowest numbered path) or first-created appropriate track leaving the Portal, that will accept the item.
Portal Exits that are connected to a specific object will NOT allow an item to take alternate paths, or objects when the connected object is blocked.
Add Alternate Exit
Places a new Portal Exit on the screen for you to use.
Each can be assigned as the link to a specific object outside the subsystem, using the "Connect To" menu option.
Naming Portal Entries and Portal Exits
Each Portal Entry and Portal Exit can be named independently.
However if you rename the owning Portal (the Object containing this subsystem), then all of the Portal Entires and Exits are automatically renamed according to a special renaming/numbering system.
All links to specific named objects are retained if you copy and paste the subsystem.
This enables you to perform Ctrl-Pastes, without having to re-assign the Entries and Exits.
If a specified object is not linked, or not present when the portal with multi entries is pasted, then the system will complain about:
- Being unable to form a link, when there is no object of that name present, or
- The absence of a link, (either Path or Track) where the object is present.
Hiding Portal Entries and Portal Exits
The Portal’s Object Edit Menu Options dialog contains an option called “Hide P-Entry/P-Exit”.
When selected, this option disables and hides the sub-system Entry and Exit.
The sub-system entry and exit icons become blank and do not respond to clicking.
To re-enable the sub-system entry and exit, unselect the "Hide P-Entry/P-Exit" option in the Portal Object Edit Options Menu.
Multiple Portal Entries and Portal Exits
Multiple Portal Entries and Exits enable items to enter from the left, and depart to the right, and at the same time enter from the right and depart to the left, and enter from the top and depart to the bottom, and so on. This also makes logical constructs easier to build and follow.
You can create as many alternate Portal Entry Objects, and Portal Exit Objects in a Subsystem as you wish.
Multiple Portal Entries and Exits also enable the following:
- a) Direct control over incoming flows from specific objects located outside a Subsystem.
- b) Direct control over outgoing flows to specific objects located outside a Subsystem.
- c) An different approach to handling item flows into a subsystem
- You don’t have to use switches to direct an item when its path into the subsystem depends upon the object from which it came into the subsystem.
- d) An alternative approach to handling item flows out from a subsystem.
- You don’t have to place switches immediately outside a Portal to direct an item when its path away from a Portal depends upon how it was processed inside the Subsystem. This switching is now done within the Portal, and the Portal Exit chosen determines the path branch taken outside the Portal as the item leaves.
- e) Improved handling of challenging train control logic, and capacity management issues across subsystems.
- f) the chance to construct a more congruent representation of incoming, outgoing and crossover schematics within subsystems.
Connecting to External Objects
A link created between a Specific Object and a Specific Portal Entry applies to ALL ITEM CLASSES' with a path from the Object to the Portal.
All items, regardless of Class, leaving the Specified Object and entering the Portal, will arrive at the Specified Portal Entry. As usual, you can have different paths for the different classes leaving the specified portal entry.
A link created between a Specific Portal Exit and a Specific Object applies to ALL ITEM CLASSES' leading to this Portal Exit. All items, regardless of Class, passing through this Exit, will go to the Specified Object.
The software doesn't complain if 2 Portal Entries are assigned to the same object. Only the earliest created (NOT earliest assigned to the object) Portal Entry will accept items. (2 exits can point to the same object - this makes sense).
The software currently provides no warnings if an object connected to the Portal is "left out" of the specifications, and there is no Portal Entry in the subsystem with the assignment of "Any". This object will simply become, and remain blocked. You cannot leave the earliest-created Portal Entry with an unconnected flow, even if all other Portal Entries are connected, and set to receive items from any object.
Connecting to Track Objects
You can connect Portal Entries and Exits to Track Objects.
To properly connect up a Track object and enable bi-directional travel, you need to assign both a Portal Entry, and a Portal Exit to it. This will enable two way flow.
If your track is only uni-directional, then you need only assign an Entry or Exit, depending on the Track's direction.
Note that if you connect a Portal Entry/Exit to a Double Track Object, then you will get traffic coming in from either of the two individual tracks, (Portal Entry) or departing on to either of the two individual tracks (Portal Exit).
You may get more flexibility options by using two single tracks, rather than one double track - this will become clearer with further testing.
Ctrl-Paste Issues
Ctrl-Pasting of Subsystems assigned specific connections in a track network will probably give link warnings since the connections made are so specific to each subsystem, and a great deal of re-connection maintenance will be required if you think you will be making changes that you will have to replicate many times if the subsystem flow structure must change for some reason.
Either use Ctrl-Paste only on single objects inside the subsystem, or build logic into Portals within the Portal linked into the network infrastructure, (if you think that flow editing may be required as the model progresses).