TRS19 Service Pack 3 Official Release

Removing any .dlls is a really bad idea. Let us fix the bug, and meantime avoid emitting reversed locos from portals.

SetCompressorEfficiency in the class Locomotive broke too

Thanks for the report. We'll take a look.

Re Log errors - in many cases these errors or warnings can be ignored. Basically if you can't see any problem in game, then ignore the logs :)

Has anybody had problem since this last update of trains being real jerky?
No other reports, but if the loco relies on scripts there have been some scripts behaving differently.
Try different locos to compare, and ensure your comparison with any older version is like for like with settings etc to eliminate and fps differences.
 
Last edited:
Interesting. I have been gone for a week and a half. I brought up Trainz and was notified there was an update (I was aware of it before I left). The choices were "Install Now", and "Continue". I did not want to install right away, so I hit "Continue", and it proceeded to install. Never before seen choices of "Yes" and "Yes" before. Apparently "No" was not an option.
 
That is the way the Steam version works. No way to opt out. In the N3V versions, I just close the window with the red X to not install. I'm keeping my Platinum at the way it was released until I'm sure the patches don't hose it. Should be around 2025 when I feel safe to update. :hehe:

William
 
The "Install Now" is an option you choose FIRST. (Install Now, Tommorrow, etc) and the second "Continue" button means to continue with what you choose in the first one. If you want to NOT Continue you must hit the "X" on top with. In short - "Continue" means continue to install now.
 
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.

Slightly off topic, but is there some way the post-install (or any) DBR (or EDBR) can be tuned so it doesn't peg the hard drive? Pretty much makes the computer worthless for the whole amount of time it is running, as nothing else can compete for the drive interrupts.
 
• 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.
 
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.......:hehe:
 
• 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.
 
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.


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:
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.
 
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.
 
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?
 
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:
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
 
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?
 
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.
 
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.
 
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
 
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.)

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.

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:
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:
Back
Top