.
Page 12 of 17 FirstFirst ... 21011121314 ... LastLast
Results 166 to 180 of 248

Thread: TRS19 Service Pack 3 Official Release

  1. #166
    Join Date
    Nov 2006
    Location
    France
    Posts
    2,391
     

    Default

    • When the HUD is hidden the clock is no more displayed when moving cursor to top of screen.
    • Headlights don't automatically turn on in tunnels like they did before SP3.

  2. #167
    Join Date
    Nov 2006
    Location
    New Jersey
    Posts
    2,690
    Blog Entries
    2
     

    Default

    Quote Originally Posted by Forester1 View Post
    OK, that's easily confused, at least by me. Maybe some thought should be put into being a bit clearer than that? Normal software and patch installs have a clear yes or no or cancel choice, not two buttons that mean the same thing, and I did not see that the "Install Now" was a pulldown choice? Completely escaped me.
    Could be worse I guess. At least your aren't being made to sign in with your Microsoft Account before continuing.......
    i5 8600k 4.4 GHZ-ASUS ROG STRIX Z370E-MSI GTX 1070ti
    16GB DDR4 2666-Samsung EVO 850 1TB SSD
    US Army 1978-84

  3. #168
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    29,700
     

    Default

    Quote Originally Posted by HPL View Post
    • When the HUD is hidden the clock is no more displayed when moving cursor to top of screen.
    • Headlights don't automatically turn on in tunnels like they did before SP3.
    I did report the clock issue and went through QA with various scenarios on breaking it. The issue was passed up the chain, but I don't know of the status of it after I worked with it.

    I have had headlights turn on in tunnels so I don't know if its asset dependent or a quirk.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019/Trainz-PLUS: 109641

  4. #169
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts (originally from NYC)
    Posts
    1,237
    Blog Entries
    17
     

    Default

    Quote Originally Posted by Tony_Hilliam View Post
    Let us fix the bug, and meantime avoid emitting reversed locos from portals.
    Given that Class I railroad diesel back-to-back "lash-ups" are virtually ubiquitous in North America, that puts a freeze on all my TRS19 simulations until the bug is fixed for the reasons explained at the end of post 144.


    Quote Originally Posted by Tony_Hilliam View Post
    Removing any .dlls is a really bad idea.
    More importantly, there is an invaluable result from Williamg's finding: Removing TNICorePhysics.dll results in all the portals behaving as they did in SP2: no portal jerking, no portal speed variation, no variation in intervals to add the next car, no derailments.

    This implies the dev team expended resources to make a real world physics package act on a fictitious Trainz simulation construct, a portal. Whatever possessed them to do that? If this is the case, I hope your management oversight can preclude the nonsensical from breaking the simulator in the future.
    Last edited by deneban; April 27th, 2021 at 07:30 PM.

  5. #170
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    29,700
     

    Default

    This implies the dev team expended resources to make a real world physics package act on a fictitious Trainz simulation construct, a portal. Whatever possessed them to do that? If this is the case, I hope your management oversight can preclude the nonsensical from breaking the simulator in the future.
    Perhaps it's time again for the Devs to spend some time building a route and testing. This will give them firsthand experience with the things we note and complain about.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019/Trainz-PLUS: 109641

  6. #171
    Join Date
    Nov 2006
    Location
    was in the Netherlands
    Posts
    5,371
    Blog Entries
    1
     

    Default

    Quote Originally Posted by JCitron View Post
    Perhaps it's time again for the Devs to spend some time building a route and testing. This will give them firsthand experience with the things we note and complain about.
    All true but what route? Considering the almost limitless combination of objects that can be put in a route, no finite test will ever uncover all potential issues. Given the open nature of how Trainz is built, that one feature is both its greatest strength and its greatest weakness. If you don't buy in to that and want a tightly controlled game where almost nothing is your choice, I think there are other places for that. After almost 19 years in various versions of Trainz, I want all of the flexibility inherent in the way Trainz is built and am willing to live with its limits.

    And if the latest version is not for you, there is no reason why you cannot stay with the version that works for you. Thanks to a complete backup of the previous version of TRS19 Platinum before the upgrade to SP3, I reactivated it and will now continue using it until the current storm blows over and things settle down.


    70337:
    TRS19 Platinum, build 110491 SP2, Win10 Pro 64 bit, i7-7700 3.6GHz 16 GB, GTX 1070 Ti

  7. #172
    Join Date
    Apr 2009
    Location
    Bangsaen,Chonburi, Thailand
    Posts
    415
     

    Default Script command GetEngineSetting("regulator")

    The script command regulator = GetEngineSetting("regulator");
    ALWAYS returns value 0 in DCC MODE when driving.
    In CAB MODE working OK.


    I am using above command inside my Loco assets.


    The command was working in TRS19 buildno 110491.
    I had this version luckily saved.

    Has anyone else noticed this?

  8. #173
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts (originally from NYC)
    Posts
    1,237
    Blog Entries
    17
     

    Default

    Quote Originally Posted by martinvk View Post
    All true but what route? Considering the almost limitless combination of objects that can be put in a route, no finite test will ever uncover all potential issues. Given the open nature of how Trainz is built, that one feature is both its greatest strength and its greatest weakness. If you don't buy in to that and want a tightly controlled game where almost nothing is your choice, I think there are other places for that. After almost 19 years in various versions of Trainz, I want all of the flexibility inherent in the way Trainz is built and am willing to live with its limits.
    Hi Martin,

    I believe many of us are here for that reason. No one expects such a flexible software package, let alone a real world simulator, to have 100% integrity. The question is (posed in post 144) whether the current testing approach is sufficiently structured to catch the big items and EXPECTED usage, whose failures can break the sim. Have the major expected sim scenarios that modelers are expected to employ, predicated by standard railroad practices globally, been identified? And then is someone or group designated to test for those? Case in point: If portals were augmented in SP3, why didn't testing catch the reverse-facing loco issue? Many high speed unit passenger trains globally, as well as North American freight diesel lash-ups (see post 144), almost ubiquitously, have a reverse-facing loco to pre-empt a lot of making and breaking of loco connections. The "furnished" Freccia Rossa consist <kuid:212731:501128> for example, has a reverse-facing loco to match the prototype, but derails on portal emission in SP3. Perhaps the testing process needs to be revisited to establish a better validation procedure.
    Last edited by deneban; April 28th, 2021 at 11:48 AM. Reason: added boldface

  9. #174
    Join Date
    Nov 2006
    Location
    Netherlands
    Posts
    443
     

    Default

    Have to agree with Deneban
    and posted this a few times when SP2 was released
    Cant just (factory) test with kickstarter, Sebino, Nidderthal etc.
    they are simply too small and do not contain assets the bulk of us use
    Good examples of routes to test with (and on DLS)
    -UMR2021 from Neil
    -Lille-London from anathoth71
    Why are they good?, they have size enough and were made in many years
    so they contain old and new content and portals, much like we all use
    then use 40+ trains and long trains


    The reason I had to make many options in my SDCR, is because current Trainz
    is not optimized for big routes (the ones most of us now use)
    If testing is done on those routes with many trains,
    a few current limitations would have been caught maybe 2 years ago
    -greying out of driver commands
    -the not very functional and too slow drivers list
    -portal issues
    -spline issues
    -script issues


    The new TNI is promising, but should never break standard behaviour
    an on/off switch in Trainz setting could be an option for now.
    Beta testers are never to be blamed ! I respect all their work.
    I can't be a beta tester, or we never get a next release :-)
    lets have fun with trainz again
    greetings GM

  10. #175
    Join Date
    Nov 2006
    Location
    At home
    Posts
    139
     

    Default

    Quote Originally Posted by deneban View Post
    Given that Class I railroad diesel back-to-back "lash-ups" are virtually ubiquitous in North America, that puts a freeze on all my TRS19 simulations until the bug is fixed for the reasons explained at the end of post 144.




    More importantly, there is an invaluable result from Williamg's finding: Removing TNICorePhysics.dll results in all the portals behaving as they did in SP2: no portal jerking, no portal speed variation, no variation in intervals to add the next car, no derailments.

    This implies the dev team expended resources to make a real world physics package act on a fictitious Trainz simulation construct, a portal. Whatever possessed them to do that? If this is the case, I hope your management oversight can preclude the nonsensical from breaking the simulator in the future.

    This is what I don't understand: Why isnt there an option to disable the TNI physics and let Trainz behave like TS12? I managed to play around with the dll by modifying it but still with various results. It would be much better to have it as a selectable on/off option especially if your layout has portals or many AI trains.
    For me Trainz has always been a model train simulator so personally I think these real world physics just don't belong there, the trains behaved perfectly well in the older versions of the game so why change that?

  11. #176
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    29,700
     

    Default

    Have to agree with Deneban
    and posted this a few times when SP2 was released
    Cant just (factory) test with kickstarter, Sebino, Nidderthal etc.
    they are simply too small and do not contain assets the bulk of us use
    Good examples of routes to test with (and on DLS)
    -UMR2021 from Neil
    -Lille-London from anathoth71
    Why are they good?, they have size enough and were made in many years
    so they contain old and new content and portals, much like we all use
    then use 40+ trains and long trains
    This is why I test using my own routes. Being rather large entities, or in the case of the Gloucester Terminal route I have being a small compact route, I can test for these issues. The problem I found with the portals, which I didn't report at the time, was the error occurred at the weakest link being the small tank cars and light covered hoppers. This lead me down a different path, besides, the error was inconsistent because the same consist worked in one direction but not the other even though the same portal asset was used in both cases and the same consists ran out of the portal. This was to represent east-west traffic at different times throughout the driving session.

    Given that we have so many variables, testing something consistently enough to repeat a failure becomes impossible because we don't know who is causing or what steps were made to cause the problem.

    Back in the early days of TRS19, I reported jerky performance here in the forums, mostly asking if others had the same issue, when consists were extruded from the portals. I was told nope I don't see it here by a couple of users, so I didn't report the issue and figured it was due to some really, really high-poly freight car I was sending out with a consist. After that, I rebuilt my consists and the problem went away, and that coincided with code changes that made the portals work from SP1 through SP2. Go figure!

    Now with the introduction of yet another variable of the TNI code, this breaks whatever was working, and makes things yet another bale of tangled wire to unknot and hope that things will actually remain straightened out.

    This again brings me back to the fact that the coders do not test their own code other than in a quick "yup" there are no errors fashion. Mr. Windwalkr even came out and said sometime ago that he doesn't even use the program! If the coders were made to build a route using the various parts. It doesn't have to be pretty, but do more than check the syntax of their code and actually feel the pain in some cases what we're experiencing, this issue may not have occurred because in their tests, I'm sure they would have used the built-in content such as the Italian highspeed train with two opposing locomotives and would have found the problem.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019/Trainz-PLUS: 109641

  12. #177

    Default

    Well said John. An internal route building test doesn't have to use extensive assets, though surely not beyond the capabilities of N3V internal systems to use a checksum and see what people are using (interlocking towers and TRC crossings come to mind, both of which ISTR have had issues following updates). Just the workflow and simple process of using Surveyor might cause some reflection on the suggestions that have been made to improve it over the years.

    The other issue could well be not all route builders want to be tied up to the subscription or premium model and therefore do not have access to the beta testing programme (happy to be corrected if that is wrong). So, with respect, N3V may not be getting the right people they need to test certain aspects of the programme. True beta testing is a laborious undertaking often requiring repetition of tasks and exhaustive methodology to identify possible bugs. Having it carried out by customers (some, not all) who may just have paid so they can play with the new version before everyone else may not be the most efficient means of testing software. There is a world of difference between play testing something and in depth technical let's see if we can break it, evaluation.
    Building In TRS19, Driving Trucks In Snowrunner

  13. #178

    Default

    Quote Originally Posted by Vern View Post

    The other issue could well be not all route builders want to be tied up to the subscription or premium model and therefore do not have access to the beta testing programme (happy to be corrected if that is wrong).
    I fall in to that category. Cancelled my subscription and now running standard edition again.

    I think also that things are rushed somewhat in order to meet deadlines for the quarterly updates for Trainz Plus. Design, code, internal testing, beta testing, fix as many issues as possible before the 3 months are up, then release where the real testing begins. A bit of a tall order so that the subscription promise can be met. An own goal by N3V in my eyes.

    Fewer updates, say 2 a year, would at least allow for more stringent testing before releasing to Joe Public. It's just no fun having to spend so much time fixing things that worked fine before an update was applied.

    I don't post that often, but read the forums every day. I've been a Trainz fan for many years and I take my hat off to all of you for suggestions and workarounds over the years.

    I made a mistake of buying my copy of TRS19 from Steam (because it was cheaper than buying direct from N3V) and I don't have the option of not upgrading because Steam forces application updates on you. It's a pain. What is really needed is a rollback feature or the ability to download a previous version. I have so many backups it's getting ridiculous. Yeah, disk space is cheap but that is a cop-out in my eyes. Just think about Blender as an example, if you don't like the latest release or find too many faults with it you can always download a previous version(s), take your pick.

    Regards to everyone,

    John

  14. #179
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts (originally from NYC)
    Posts
    1,237
    Blog Entries
    17
     

    Default

    Quote Originally Posted by JCitron View Post
    This is why I test using my own routes. ...

    Given that we have so many variables, testing something consistently enough to repeat a failure becomes impossible because we don't know who is causing or what steps were made to cause the problem.
    Hi John,

    Neither of these occurred for this SP3 portal breaking event - the "variable item" has been identified. Williamg and other users below did the end-user testing for you and I and found that the built-in SP3 portals were intentionally revised to use the TNIPhysicsCore.dll. It was not "impossible" here, we pretty much know what broke the sim by process of elimination.

    (That dev decided to make real world physics apply to the fictitious sim construct, the "portal", is a whole other discussion.)

    Quote Originally Posted by JCitron View Post
    This again brings me back to the fact that the coders do not test their own code other than in a quick "yup" there are no errors fashion. Mr. Windwalkr even came out and said sometime ago that he doesn't even use the program! If the coders were made to build a route using the various parts. It doesn't have to be pretty, but do more than check the syntax of their code and actually feel the pain in some cases what we're experiencing, this issue may not have occurred because in their tests
    It is not in our purview to dictate who does release testing, that is up to Tony and his QA manager. There is no reason why non-coders cannot do the testing effectively, it is common business practice.

    Quote Originally Posted by JCitron View Post
    I'm sure they would have used the built-in content such as the Italian highspeed train with two opposing locomotives and would have found the problem.
    One cannot assume that if it is not written into the test program/procedure, or if testing lacks adequate structure. In this case for example, portals were modified, so a viable test procedure would have listed out all the furnished consists and have the tester initial off for each furnished consist successfully emitted from the new portal. Then this Freccia Rossa error would have been be caught. Relying on random "self-guided testing" is not reliable, and has no traceability or accountability. Even as a lone developer, I conceive and write out my testing matrix in an excel workbook then go and execute the test matrix step by step. That is how I remain accountable to my end users.

    I have also raised the question as to whether the release schedule afforded adequate time or distribution in Post #144 given that portals were one of the final changes in SP3.
    Last edited by deneban; April 28th, 2021 at 07:24 PM.

  15. #180
    Join Date
    Nov 2006
    Location
    Australia, Qld
    Posts
    6,544
     

    Default

    There's quite a bit of speculation going on here, and much of it is missing the mark.

    SP3 introduced a TNI Physics plugin. This takes the previous "native" physics code and exposes it in the plugin that developers can then edit, update, replace etc. In theory, everything should work in the same fashion as it did. In practice, some edge cases result in different behaviour and bugs can also lead to different behaviour.

    Portals were not "revised" at all. It's just that TNI physics was running rather than native physics. Without physics, trains don't go anywhere, so the idea of not having physics for trains coming out of portals would turn those trains into scenery objects. (In other words, portals have always relied on train physics).

    Our testing goes well beyond the builtin routes. However, there are many thousands of routes and hundreds of thousands of assets. Testing just the set of routes from the DLS would take, at a guess, 100 many years. That isn't going to happen. Having a wide range beta testers testing on their routes and reporting issues is far more practical. Beta testing for SP3 included non-Trainz Plus testers, so any thought that only members are testing is incorrect.

    Portals were reported as buggy. The test cases provided (after several iterations asking for more feedback) led to a test case that was reproducable. The bug was identified and fixed. The "reverse heading loco" bug was not reported during beta testing, and therefore slipped through. Using reverse heading locos in long consists has been added to our test cases for various tests.

    The Frecc is one of over 300 locos included in TRS19 and DLC - again, testing every loco under every situation isn't practical. Asking volunteer beta testers to run test cases has been discussed and perhaps we should simply offer the option for those interested so that there is more structure to the testing. It would also give more visibility to which test cases have been run and completed so that when we get to this stage after the next release, we can check on that list to see whether there was a gap in the test cases, or if a new test case is required.

    With regard to release time, the beta testers were submitting 1 or 2 new reports a week. It is only after expanding from hundreds of testers to thousands of users that these issues were identified (and even then it took quite a long time to nail down the specifics).

    My suggestion to those who would like to see less bugs on official release is to join in the beta testing when we request wider testing.

    And just to add that another software company, Microsoft, are winding back an update to Win10 that managed to get through their QA and beta test process. And they probably have more than 1 fulltime QA person.
    Last edited by Tony_Hilliam; April 28th, 2021 at 09:26 PM.
    Tony Hilliam

    Got questions about TRS19? Click here for TRS19 FAQs

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

Posting Permissions

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