.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 37

Thread: Trainz Plus and TRS19 SP3 Beta 11178x update

  1. #16
    Join Date
    Nov 2006
    Location
    Australia, Qld
    Posts
    6,516
     

    Default

    Paul - are you sure you’re not emitting and consuming at the same time?
    Is this a 100% repro or a "sometimes" one?
    Which portal KUID?
    Does this happen with different cars?
    Loaded/unloaded?
    Under AI control or manual?
    Anything else that might help us repro?
    Last edited by Tony_Hilliam; March 12th, 2021 at 07:29 PM.
    Tony Hilliam

    Got questions about TRS19? Click here for TRS19 FAQs

    Looking for answers to in-game functionality? Click here for help

  2. #17

    Default

    Hi Tony.

    Just to report I am currently unable to patch from build 111603 to new build 11178X : Trainz detects there is an update and proposes to patch, but when I confirm, under the patcher, just after validating my user (pguy) and password, I receive the following message : there are no patchable products associated with this my Trainz account ... That is a new patcher behaviour as I had no problems patching with earlier patches until last one to build 111603 ... From the error message, I believe the solution is probably on your side ...???

    And sorry but for the moment I cannot test the new build to verify there is no problems ...

    Regards.
    Pierre.

  3. #18
    Join Date
    Nov 2006
    Location
    Australia, Qld
    Posts
    6,516
     

    Default

    Pierre - the server was down for a few minutes earlier so retry now and it should be fine.
    Tony Hilliam

    Got questions about TRS19? Click here for TRS19 FAQs

    Looking for answers to in-game functionality? Click here for help

  4. #19
    Join Date
    Nov 2004
    Location
    Thailand, Phu Pan Nat'l park proud neighbor
    Posts
    3,750
    Blog Entries
    1
     

    Default

    Quote Originally Posted by Tony_Hilliam View Post
    Good news Roy - QA have been able to work out a repro in a test map for your redraw issue and for the freeze!

    Meanwhile, some interesting information about the splines redrawing:
    - height adjustment under any other spline increases the likelihood of the redraw occurring (so height adjustment of non-spline areas is fine)
    - the further you zoom your camera out from the area you are adjusting, the less often the splines will redraw
    - the longer the "stroke" as you draw, the more likely it will redraw the nearby splines (so keep movements shorter and no problems at all)
    - adjusting an area that affects lots of splines is the most likely way to get the freeze to occur
    Dear Tony,

    thank you for the good news indeed
    BTW I did sent QA team a copy of the profiler report on freeze a.w.a the log yesterday.
    Finally we get the redraw qualified as a possible bug.
    The workaround with the small asset preview did not work for me.
    The freeze is pretty annoying as I did not have that in older releases!! older than 111xxx let's say early feb i did not see this and i did this adjust terrain a lot on the canl too!

    I know the zoom has influencee on the redraw but not if you are zoomed in close even look from top so no further distant asstes affected still redraws heavy by times. Even after redraw the same area done already will redraw again a.s.a. you 'stroke' the topology command adjust height and brush it in same place and further.
    Anyway you and most of us know and I am not the only one with this phenomina.
    Hope you can identify the buffer that fills to the top and makes the freeze kick in. It happens most within or at the edge of 2 bordering baseboards.

    have a nice weekend and stay safe.


    Roy
    Last edited by RoysTrainz; March 12th, 2021 at 10:36 PM.
    The makers of the famous Canadian Rocky Mountains routes
    Master my all new TRS19 Canadian Rocky Mountains routes

  5. #20
    Join Date
    Nov 2006
    Location
    United States of America, TN, Memphis
    Posts
    1,751
     

    Default

    Quote Originally Posted by Tony_Hilliam View Post
    Paul - are you sure you’re not emitting and consuming at the same time?
    Is this a 100% repro or a "sometimes" one?
    Which portal KUID?
    Does this happen with different cars?
    Loaded/unloaded?
    Under AI control or manual?
    Anything else that might help us repro?
    Tony, thanks for the response.

    I have submitted a bug report and have been in correspondence with QA.
    I am using <kuid:-25:1264>
    I always use separate portals for emitting and consuming trains.
    Its an interesting issue. It only becomes a problem with trains with over 20 cars or so. Many of my trains enter the portal loaded. The interesting things is if you watch in map view the train entering into the consuming portal you of course can see the cars being eliminate. However the distance between the last car eliminated and the back end of the portal becomes less and less. The issue then on a long train is that the next car to be eliminated "bumps" into the end of the portal and derails. That's why short trains are not effected,- there is still space left between the last car and the end of the portal.
    At any rate QA asked me a series of questions which I have answered which hopefully will allow you to track down this bug.

  6. #21
    Join Date
    Nov 2006
    Location
    New Zealand
    Posts
    3,315
     

    Default

    Paul_Bert - Have been unable to replicate your troubles with portals with consists much longer than 30+ cars in this and other recent beta builds of TRS19.
    However, in the previous non-beta build (110491), I did experience issues with consists exceeding 20+ cars when one or more of the wagons was 'reversed' within the train.
    Suggest check the orientation of each car in all consists bound for and emitted from your portals. (2nd or 3rd column in the portal's consist list settings dialog) This allows you to switch the orientation of each coupled car.
    If they are all 'Forward' or all 'Reversed' then the portal worked correctly.

  7. #22
    Join Date
    Nov 2006
    Location
    United States of America, TN, Memphis
    Posts
    1,751
     

    Default

    Quote Originally Posted by PC_Ace View Post
    Paul_Bert - Have been unable to replicate your troubles with portals with consists much longer than 30+ cars in this and other recent beta builds of TRS19.
    However, in the previous non-beta build (110491), I did experience issues with consists exceeding 20+ cars when one or more of the wagons was 'reversed' within the train.
    Suggest check the orientation of each car in all consists bound for and emitted from your portals. (2nd or 3rd column in the portal's consist list settings dialog) This allows you to switch the orientation of each coupled car.
    If they are all 'Forward' or all 'Reversed' then the portal worked correctly.
    Not sure how you can tell by looking at a consist whether a car is reversed or not. When a train is emitted from a portal shouldn’t all the cars be properly oriented?

    As I narrow down the problem it also appears that the problem is time sensitive. A train which reaches a consume portal in 5 minutes or less functions OK. A train that reaches a portal in 20 or more minutes has the issue.

    I will investigate the orientation suggestion some more but again I’m not really sure how to know whether a box car in a train is properly oriented. If I have a train with 50 box cars in the consist how do you tell if one is backwards?

  8. #23
    Join Date
    Nov 2006
    Location
    New Zealand
    Posts
    3,315
     

    Default

    It is shown as either 'Forward' or 'Reversed' in the portal's setup dialog box (Direction column) for each consist. I typically have multiple consists being randomly emitted (or consumed) by any one portal, and found that very long consists (40+ wagons) occasionally fouled up emanating or being consumed by one of my portals even when there was plenty of room for them to issue entirely.
    Upon investigation, (examining the portal setup dialog for the consists being generated/ consumed) that when I originally created the consist, I had one or two wagons 'reversed' from their default 'forward' orientation.
    When all the cars were set to 'Forward', (or all 'Reversed') the portal derailments/ issues went away.


    +many more container flatcars...

    Note that in the example given here (2nd consist for a particular portal) two of the locomotives are reversed and all of the 40+ container cars are set in the same forward orientation. Seems to tolerate reversed locos ok, but not a reversed wagon coupled to the 38th car!
    Likely also to be a script timeout issue if the session is particularly busy with 20-plus consists busy going about their duties as is typical for many of my AI sessions.
    Go figure!
    Last edited by PC_Ace; March 13th, 2021 at 03:30 AM. Reason: 2 locos reversed - not one in my example illustrated above

  9. #24
    Join Date
    Nov 2006
    Location
    United States
    Posts
    146
     

    Default

    Quote Originally Posted by dgallina View Post
    I'm still seeing hard crashes to desktop running Driver with built-in sessions (Kickstarter Country) on ARM Mac. Previous betas wouldn't even complete database repair of downloaded assets without crashing, so it is progress. Haven't downloaded ANY assets to this new beta yet. Bug report submitted.

    Thanks,
    Diego

    FOLLOW-UP:

    I've downloaded all purchased routes & assets. Now it crashes reliably caching content while attempting to start. So basically back to where we were before.
    I have not had any crashes on my ASi Mac mini in Kickstarter County. I have 16gb ram and 512gb hd. What sessions are you running? The database is fine on my Mac.
    Trainz 2019 Big Sur. M1 Macs
    2014 Mac Mini 8gb ram, Intel 1536MB
    2014 Air 8gb memory, Intel 1536MB
    T Driver 2 iPhone SE2 iOS14

  10. #25
    Join Date
    Nov 2006
    Location
    United States of America, TN, Memphis
    Posts
    1,751
     

    Default

    PC_Ace,
    The consists that are giving me trouble are not being generated from a portal, but rather they are sitting on a siding waiting to enter the mainline and travel to the portal. So the question is how do you determine if an asset is facing forward or reversed in this situation.

    I did check all my emitting portals and all the vehicles are facing forward

  11. #26
    Join Date
    Nov 2006
    Location
    United States
    Posts
    146
     

    Default

    Had an odd error with updating from the last build to this build on my Macs. I just hit continue and it updated fine and database rebuild was quick. FPS for both Macs is about the same, though my 2014 Mac mini was lagging on the same settings for both the game and computer. I lowered all Trainz performance settings, which brought the FPS up and the computer was no longer lagging. With the previous build, my computer was not lagging. No crashing on either 2014 or 2020 ASI Mac minis.

    One question I have is in profiler, some of the threads are showing with red text. Should I report those?

    Build 111781

    2014 Mac Mini:


    4.2—12.9 FPS Kickstarter fossil fuel session. Computer and game were very lagging.


    Shadow Quality: off
    Main Shadow Resolution: 2048
    Shader quality: low
    Texture detail: low
    Post processing: low
    Water quality: low
    Detail scenery: off
    Antialiasing: 2x
    Detail update rate: low
    Use PhysX simulation and process objects behind camera, both unchecked


    11.6—25.8 FPS Kickstarter fossil fuel session.

    2020 ASi Mac Mini:


    Build 111781


    22.1-51.2 FPS Kickstarter fossil fuel session. Default window size


    22.5-52.3 FPS Kickstarter fossil fuel session. Default window size, closed most other programs


    15.2-31.4 FPS Kickstarter fossil fuel session. Full window size, closed most other programs



    Trainz 2019 Big Sur. M1 Macs
    2014 Mac Mini 8gb ram, Intel 1536MB
    2014 Air 8gb memory, Intel 1536MB
    T Driver 2 iPhone SE2 iOS14

  12. #27
    Join Date
    Nov 2006
    Location
    New Zealand
    Posts
    3,315
     

    Default

    Paul_Bert -
    So the question is how do you determine if an asset is facing forward or reversed in this situation.
    Warning! Convoluted work-around reply... When you first add cars to a consist to save it for future use, you can rotate each wagon according to your whim before coupling it to the consist (then rotate the entire consist if you wish as well) by using the Rotate Train (R) tool from the F7 flyout.
    If you then add this Saved Consist as an existing consist to a portal, you get to see the orientation of each car as it was originally created in the Direction column as shown above.
    (This is one way to see which way each car is turned in a particular consist programmed in your session to be Consumed by another portal. It is not expected that you will be using the same portal to Produce the consist: - All you want to know is the orientation of the cars beforehand.)
    In the image below, you'll see that I have added the same passenger coach BR Mk1 FK Blue to some track before coupling to set their orientation within the train. One I have reversed (as often happens in real practice) before coupling these cars up to the full consist. I used the Rotate Train tool on one of these passenger coaches, but if I kept adding the same coach, I would have only a 'Forwards' orientation.

    Hopefully - the new 'fixes' to the way portals work will make this a null issue!

    Last edited by PC_Ace; March 13th, 2021 at 09:11 PM.

  13. #28

    Default

    One problem with portals and loaded trains entering is the upward slope of the track. If the consist is loaded, weight plays a part in its arrival to the driver being assigned. I found in the past that a heavy train was slow or broke before arrival but if I entered the same train empty it would arrive as expected. Also the link between wagons may have a problem with coupling and break.

  14. #29
    Join Date
    Nov 2006
    Location
    United States of America, Georgia, Atlanta
    Posts
    512
     

    Default

    Quote Originally Posted by capdiamont View Post
    I have not had any crashes on my ASi Mac mini in Kickstarter County. I have 16gb ram and 512gb hd. What sessions are you running? The database is fine on my Mac.
    It's build 111781 running on an M1 MacBook Pro 13" with 16gb RAM and 1TB flash. But there's almost no variation between any of the M1 machines so i'm guessing this applies to all fo them.

    Crashing in multiple places:

    1. Hard crashes to desktop during pre-caching of installed assets. This can happen if you force a pre-cache from the developer tools or if you run the game and try to use a session that loads those assets. Here's the log header for the last time that happened:
    Process: Trainz Railroad Simulator 2019 [13855]
    Path: /Applications/Trainz Railroad Simulator 2019.app/Contents/MacOS/Trainz Railroad Simulator 2019
    Identifier: com.n3vgames.trs19
    Version: 1.0.11 (111781)
    Code Type: ARM-64 (Native)
    Parent Process: ??? [1]
    Responsible: Trainz Railroad Simulator 2019 [13855]
    User ID: 501
    Date/Time: 2021-03-12 12:39:27.874 -0500
    OS Version: macOS 11.2.3 (20D91)
    Report Version: 12
    Anonymous UUID: FC8299B5-619E-FC16-98A8-1441AE8C3D7A
    Sleep/Wake UUID: AC06AB24-A917-4FDB-BC25-BDA117A1A378
    Time Awake Since Boot: 56000 seconds
    Time Since Wake: 11000 seconds
    System Integrity Protection: enabled
    Crashed Thread: 27 WorkerThread::167
    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: KERN_INVALID_ADDRESS at 0xffffffffaf6dee7c
    Exception Note: EXC_CORPSE_NOTIFY
    Termination Signal: Segmentation fault: 11
    Termination Reason: Namespace SIGNAL, Code 0xb
    Terminating Process: exc handler [13855]
    VM Regions Near 0xffffffffaf6dee7c:
    --> MALLOC_NANO 6000d8000000-6000e0000000 [128.0M] rw-/rwx SM=PRV

    2. In Kickstarter County 2 - Local Freight. It isn't happening immediately. Switching back / forth from internal to external views and maybe also from full-screen to windowed and it eventually occurs

    3. In C&O Hinton - Thurmond Empties. Happens as soon as it tries to load. This looks like an internal app error that doesn't fully hard-crash to desktop (so it doesn't get captured in the system logs). There's no room for the whole error here, but it looks like some kind of track spline problem & the error header reads as follows:

    210314.1055.49| TrackStretch:ActivateSplineCurve> Still loading

    Thanks,
    Diego

  15. #30
    Join Date
    Jul 2011
    Location
    Netherlands
    Posts
    249
     

    Default

    The problems I have on my M1 Mac Mini (8/16/512) with Kickstarter County Fossil Fuels:

    1. A red bug about the TriggerCheckRule appearing sooner or later in the session: sometimes already when picking up the empty coal cars (in which case the junction leading to those coal cars is not set automatically); and at other times that red bug appears later in the session (and then that junction is set automatically).

    2. The session goes awry when first entering DayDream yard - I have already submitted a bug on that (applies to several earlier builds, also for the PC).

    On a brighter node: sessions in Roy's demanding CPR routes run fine: 40-60 fps with middling settings and 10,000 m draw distance.

Posting Permissions

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