.
Page 2 of 2 FirstFirst 12
Results 16 to 21 of 21

Thread: Portals

  1. #16

    Default

    Quote Originally Posted by pware View Post
    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 by pguy; October 25th, 2018 at 01:58 AM.

  2. #17
    Join Date
    Nov 2006
    Location
    United Kingdom, Essex, Chelmsford
    Posts
    25
     

    Default

    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?

  3. #18
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    25,057
     

    Default

    Quote Originally Posted by RCresswell View Post
    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.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019: 98592

  4. #19
    Join Date
    Jan 2016
    Location
    United States of America
    Posts
    88
     

    Default

    I actually have the same problem. And it happens on Portal TRS2019 too.
    Investigating TRS2019 Crash since 2019!

  5. #20
    Join Date
    Jan 2016
    Location
    United States of America
    Posts
    88
     

    Default

    (Post Deleted)
    Last edited by JTrainz174; March 28th, 2019 at 08:30 PM. Reason: (Post Deleted)
    Investigating TRS2019 Crash since 2019!

  6. #21
    Join Date
    Jan 2016
    Location
    United States of America
    Posts
    88
     

    Default

    Keep looking down...

    Quote Originally Posted by Roy3b3 View Post
    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.


    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
    Even worse, the portal's modifying menu won't even open at all in driver.
    Investigating TRS2019 Crash since 2019!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •