Portals

Travlar

Member
Does anyone have a work around to get the portals to work?

My train runs onto the portal track, reaches its mark and just shuts down. I have to manually drive it off the edge to derail it so the next train can come up to be manually driven off the edge to keep traffic moving.

I have tried each of the portals and none work as expected. Also, is there somewhere we can go to see what bugs have been submitted so I can research this before bothering the community?
 
Well I have just tried the portals on my TRS19 layout and they are working perfectly - both in emitting trains to a schedule of driver commands and accepting trains which are then removed from the session.

The portal I am using is <kuid2:30501:22006:3> Portal Basic.

A question if I may to clarify your description of the problem.

"Reaches its mark and just shuts down" - what mark? I am assuming you are using a Navigate To <Name of Portal> command and that the portal is configured to accept all trains.
 
I can confirm that the portals are randomly failing to remove all or part of a consist entering it. It also has a random problem with some consists on production of loading the first part and then stopping in the portal.
 
... i did my 1st portal-configuration (.. ever ..) in trs19 (early access) ... just simple and basic ... in diorama: blast down under:
- everything runs fine: 2 tracks from right to left and 1 track from left to right ...
- producing portal (basic short) has multiple short consists ... interval set on 2,3 or 5 minutes ...
- consuming portal (basic short) accepts all trains ... no train returns
- drivers instructed to navigate to opposite portal ...
- portals camouflaged by buildings ...

... the hardest part of configuring: every single loc/car i had to choose out of a very long list of (un)known locomotives/rolling stock ... and after choosing the list starts again from top .. it should be easier if you could choose out of several (self)composed consists ...

and i'm satisfied with an animated background on 2 screens for my realworld h0 model track ...
grtz
daveric

2018-10-21-8.png
 
Last edited:
I can confirm that the portals are randomly failing to remove all or part of a consist entering it. It also has a random problem with some consists on production of loading the first part and then stopping in the portal.

I am unable to replicate that. I set up a test session In TRS19 with a portal set to emit a consist every 15 minutes. The consist drives to a trackmark a few minutes away, waits for a minute then returns to the portal with a Navigate To command.

I ran the session for an hour. Every 15 minutes the consist was emitted, travelled to its destination and then returned to the portal. The entire consist was emitted and consumed on schedule every time.
 
... i did my 1st portal-configuration (.. ever ..) in trs19 (early access) ... just simple and basic ... in diorama: blast down under:
- everything runs fine: 2 tracks from right to left and 1 track from left to right ...
- producing portal (basic short) has multiple short consists ... interval set on 2,3 or 5 minutes ...
- consuming portal (basic short) accepts all trains ... no train returns
- drivers instructed to navigate to opposite portal ...
- portals camouflaged by buildings ...

... the hardest part of configuring: every single loc/car i had to choose out of a very long list of (un)known locomotives/rolling stock ... and after choosing the list starts again from top .. it should be easier if you could choose out of several (self)composed consists ...

and i'm satisfied with an animated background on 2 screens for my realworld h0 model track ...
grtz
daveric

Congratulations! :D

You can use consists. Before adding a driver, use Add an Existing Consist (It's worded something like that). You then add your driver and commands. I agree this saves a ton of time when setting up portals.
 
Well I have just tried the portals on my TRS19 layout and they are working perfectly - both in emitting trains to a schedule of driver commands and accepting trains which are then removed from the session.

The portal I am using is <kuid2:30501:22006:3> Portal Basic.

A question if I may to clarify your description of the problem.

"Reaches its mark and just shuts down" - what mark? I am assuming you are using a Navigate To <Name of Portal> command and that the portal is configured to accept all trains.

I'm referring to the spot it hits when normally the portal takes over and begins to consume the train. I use a Navigate To command to get it to the portal.

I'll have to change my compatibility setting and see if that fixes it then. Thanks for your reply.
 
I can confirm that the portals are randomly failing to remove all or part of a consist entering it. It also has a random problem with some consists on production of loading the first part and then stopping in the portal.

Thank you. Glad to know it is not just me. Just tested and when on Maximize Compatibility, the portals work as intended. For me, they are DOA when using Maximize Performance.
 
I am unable to replicate that. I set up a test session In TRS19 with a portal set to emit a consist every 15 minutes. The consist drives to a trackmark a few minutes away, waits for a minute then returns to the portal with a Navigate To command.

I ran the session for an hour. Every 15 minutes the consist was emitted, travelled to its destination and then returned to the portal. The entire consist was emitted and consumed on schedule every time.

Believe it is the Maximize Performance setting I am using. If it is on Maximize Compatibility, then the portals are dead for me.
 
Believe it is the Maximize Performance setting I am using. If it is on Maximize Compatibility, then the portals are dead for me.

I just retested my portal session with the Compatibility Mode changed from "Maximise compatibility" to "Maximise performance" and the portals no longer worked - at all. When I switched back to "Maximise compatibility" then they work perfectly.

A search of these forums revealed other posts on problems caused by using "Maximise performance". Creator pguy has just updated his EIT rule to work under the "Maximise performance" setting but there seems to be little information about what the Compatibility mode "Maximise performance" setting does (at least as far as I can find). A few posts refer to it as something for "future asset updates", whatever that means.

So I will be sticking to using the "Maximise compatibility" setting - perhaps that is the required workaround.

I will put in a bug report just in case.
 
Does anyone have a work around to get the portals to work?

My train runs onto the portal track, reaches its mark and just shuts down. I have to manually drive it off the edge to derail it so the next train can come up to be manually driven off the edge to keep traffic moving.

I have tried each of the portals and none work as expected. Also, is there somewhere we can go to see what bugs have been submitted so I can research this before bothering the community?


Hi, I've just done a portal test in TRS19 which may help. This is what I did.

Firstly, I've never had any portal problems in TANE, TS12 or earlier versions. When I saw this thread I set up a test in TRS19 for each ,... 1 'Portal' - 2 'Portal Basic' and 3 'Portal Basic Short'.

It was a simple drive via a trackmark, then navigate to an exit portal. Each portal was placed, named with no rule instructions added.

I always use Central Portal Control to set up the drivers, consists and commands. They were all set to emit a consist immediately, then produce a sequential consist every 2 minutes with the Timer fluctuation set to 0.

Initially, all portals produced a consist, however 'Portal'#1 didn't emit from the tunnel, it stopped midway then reversed back in. (This was the first time I'd seen a Portal do this)

I exited Driver mode and checked Central Portal Control only to find I could not access it. It displayed "Property Browser Refresh() Not Handled.
PORTAL-CPC-ERROR.jpg


So, I first deleted and replaced the faulty Portal, then deleted and replaced another Central Portal Control with the commands again.
This time in driver mode, all portals operated perfectly emitting a consist every 2 minutes.

There may have been a glitch when I first placed the original portal, but all good now.

Cheers,
Roy
 
The word from QA is that the Compatibility setting "Maximise Performance" is not intended for gameplay, it is a developer option hence its placement in the Dev tab. To quote their response to my bug report in full ..

Thanks for reporting this. For general play you'll want to run using "max compatibility" as opposed to "max performance". If you set to "max performance" you should see a warning on the launcher (next time you launch) stating "one or more developer settings are active, which may negatively impact gameplay".

Historical info: Originally this dropdown was under the "General" tab and it made people associate this with something similar to a video card setting for performance vs. quality. As that was not the purpose of this developer tool setting, we moved it to its proper location (Dev tab) and added the warning. Basically "max perf" has the potential to break functionality and user should not run the game with it.
 
pware - thanks for sharing that clarification from QA about the 'Maximise performance' mode. Appreciated.
 
The word from QA is that the Compatibility setting "Maximise Performance" is not intended for gameplay, it is a developer option hence its placement in the Dev tab. To quote their response to my bug report in full ..

My issue is that my scripts don't work on Maximize Compatibility. I'm going to have to bite the bullet and find the time to update my scripts. Thanks for sharing the info. Appreciate it.
 
I just retested my portal session with the Compatibility Mode changed from "Maximise compatibility" to "Maximise performance" and the portals no longer worked - at all. When I switched back to "Maximise compatibility" then they work perfectly.

A search of these forums revealed other posts on problems caused by using "Maximise performance". Creator pguy has just updated his EIT rule to work under the "Maximise performance" setting but there seems to be little information about what the Compatibility mode "Maximise performance" setting does (at least as far as I can find). A few posts refer to it as something for "future asset updates", whatever that means.

So I will be sticking to using the "Maximise compatibility" setting - perhaps that is the required workaround.

I will put in a bug report just in case.

Hi.

Just a short explanation about Maximise compatibility, Objects Streaming, Maximise performance options. With Tane Tane SP2/SP3/TRS2019, N3V has introduced new APIs for script for searching objects available on the route, which are intended to fully replace the old APIs in some future version. In fact Tane SP2/SP3/TRS2019 are a bi-mode Trainz version supporting both the old API and the new API, enabling content creators using scripts to update their scripted assets if needed (if they use the old APIs now declared obsolete).

These performance options, available only from TRS2019, enable to set which API will work so that the scripters can test their modifications :

with "Maximise compatibility", both APIs are available and works. In this mode TRS2019 should be compatible with all unmodified scripts from Tane SP1 and TS12.

with "Objects streaming", TRS2019 activate the new capability of objects streaming, which means that at initialisation all tiles and objects may be not fully loaded and that any object can be on memory shortage be unloaded. To be compatibile with objects streaming, the scripts needs to use the new APIs and needs to have been designed to support objects streaming (checking the object avaibility before using it, and re loading unloaded objects if needed). The old API still works, so it is a mode that permits to mix old assets not migrated that do not reference any other object (scripts not sensitive to new objects streaming) and objects migrated to new APIs for objects streaming support.
This will be the default mode for some future Trainz version (N3V may say when ? 2020 ? … ) and all scripters should now work hard to migrate their scripts to support this mode. Using this mode with assets not supporting it may give some strange results, as some objects on the route may seem to be missing (objects currently unloaded) while they are still there …

with maximise performance, we go one step further. Old API no longer works. With this option, any scripted object using the old API is no longer usable. And this enables TRS2019 to do not build internally some data structure needed for the old APIs enabling a better performance. This may be in a later future the default mode, but it is a much more longer target as it means that old legacy assets have been all migrated, and that is a lot of work for scripters and for the Content repair group (CRG).

with the last option "show errors on legacy call", it is an enhanced but less performant option than the "maximise performance" as every legacy old API call no longer supported (obsolete) will fire an exception. It is only an help for scripters to retrieve in their code all the old APIs call.

So just now, as probably you are still using a lot of assets using legacy APIs call, you should run in "Maximise compatibility" mode except for new routes and session that explicitly affirms that they are fully compatible with "objects streaming" or "maximise performance" mode, which should be the case for new routes and sessions developped for TRS2019. "Show errors on legacy calls" are only for developpers debugging their script code.

For users of my assets, even if all my assets have been migrated to use only the new APIs, only EITs and MCM supports "objects streaming" mode. All others assets will be progressivly updated to support "objects streaming" but that will take some time and will probably be finished only during 1T2019 or 2T2019.

Hope this helps understanding these new options.
Regards.
Pierre.
 
Last edited:
I'm having the same issue as the original poster of this thread. It isn't a problem with emitting the consist, it is with accepting the consist. I am using "Maximise Compatibility" and basic portal's. However it is after a period of time they just stop accepting trains. I'm not sure how long as I find I am busy driving on other parts of the route.
In the beginning everything runs perfectly, it emits the trains correctly and on time, but then after a while just stops accepting them? Is there a limit to home many times it accepts a consist or is this indefinitely?
 
I'm having the same issue as the original poster of this thread. It isn't a problem with emitting the consist, it is with accepting the consist. I am using "Maximise Compatibility" and basic portal's. However it is after a period of time they just stop accepting trains. I'm not sure how long as I find I am busy driving on other parts of the route.
In the beginning everything runs perfectly, it emits the trains correctly and on time, but then after a while just stops accepting them? Is there a limit to home many times it accepts a consist or is this indefinitely?

Try pressing the pause key, wait a minute or two, and unrelease the program. If the AI that are stopped, resume operation along with the portals than you have the same problem I've been experiencing, but have been told the problem is only mine and no one else has it.

If the trains and portals resume operation than it's the same issue, which is only resolved by using the pause key periodically, or to save and reload the saved session, which doesn't always work as that affects the AI operations in other areas causing derailments, SPADs, and other weird actions.
 
Back
Top