TRS19 Service Pack 3 Official Release

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


Its not the same behavior though, I ran the exact same consist I tested under SP3 in the original TRS19 I have as backup and there was no derailment. I can understand that you cannot test all trains, but the tests I did was with the original "Auran" content (EF81) and they failed so its quite hard to believe that there was testing done when even the original content derails because of the physics. And that no one ran a reversed loco or multiple unit trough a portal, not realizing the abrupt stop the consists makes whenever a reversed unit is emitted? And this happens with all trains so how come this wasn't noticed?

What you said about the TNI is not really correct, the trains do emit from the portal and they do run, you just don't have control over them (Whats missing is TNIAllocPhysicsVehicle). But as soon as TRS loads TNIAllocPhysicsVehicle the trains start to jump around when coming from the portal so clearly that needs fixing.
As I said earlier the player should have a choice to choose between Native physics and TNI physics, since TNI is as far as I read still in Beta stage and especially with the variety of content.
 
Hi Williamg. TNI Physics is not in beta stage. TNI physics is a full replacement for the original physics and any variation is most likely a bug.

What you are describing is a bug, simple as that. We have a repro, and once it's fixed, and the update release, it will work as expected without the user needing to do anything. As mentioned earlier, doing anything with any .dlls basically is guaranteed to break something. It's like taking a part out of your car and expecting everything to work. Please let our engineers sort the problem out and release the update.
 
Hi Tony,

That "in-portal" physics was introduced in SP3 is not speculation. In Williamg's experiment, he rendered the portal without the new physics library and the resulting behavior matched what has been standard for the history of the franchise. The consist is coded to move at a constant speed and add a car a fixed intervals, without regards to mass or locomotive effort. In other words, no physics. The earlier physics library appears to have been coded to "keep" out" of the portal internals. In contrast, looking at the video in post #142: as the train gets longer, new variations in consist speed and car add interval vary for the first time ever. Physics at work right inside the portal. And where it doesn't belong.

No one is suggesting that every bit of the release be tested (your 3rd paragraph), or every loco (your 6th paragraph), and I am frankly saturated with hearing that as a reaction whenever a major bug punches through to the release.

"Wider testing" is not the answer to overcome this repetitive SP bug problem (your penultimate paragraph). Case in point, 50 some-odd testers can decide not to test the Freccia Rossa in a portal. Structured testing is the proven answer, for any product in general, for any industry, concentrated on the new changes at hand. If portals have been impacted by new physics then the conceived release test procedure should test the 30 to 40 some-odd consists that are furnished with the sim. It is only logical because each consist has its own unique physics inputs. The tester initials off on the procedure as each furnished consist is successfully emitted. Maybe 2 hours worth of testing worst case. But the structured testing is concentrated on the changes at hand. It promotes traceability and accountability.

Of course to have structured testing, dev needs to report all changes they make so it is effective. Judging from what I illustrated in Post #87, where the 13th asset status flag in TrainzUtil was not checked, this was NOT happening, and that is another vulnerability that has to be overcome.
 
Last edited:
As mentioned earlier, doing anything with any .dlls basically is guaranteed to break something. It's like taking a part out of your car and expecting everything to work. Please let our engineers sort the problem out and release the update.

I know its not a solution but as I have a layout with many Japanese EMUs that just all broke when coming out of the portal. Changing the .dll to unload the vehicle physics was the only option (Till its fixed). And as I said if your remove the file mid game you do have control over your trains just all physics are gone.


Regarding the Beta according to the wiki -> https://online.ts2009.com/mediaWiki/index.php/TNI_Physics_Interface it states "TNI Physics is currently in beta release. Information may change."
 
I'm running the latest WIN10 Pro, and Trainz Plus. I have TRS19 core on SSD C:\ drive of a Ryzen 7 4500U Mini PC. Userdata is mounted on a Synology NAS. It is linked to my PC mapped as z:\ drive.

Task is to download various Trainz authors who are declaring a Creative Commons license for their assets if hosted on DLS.

Over the last month I have suffered from dropouts of TRS19. Generally these have been unable to repro. Sometimes produces a crashdump file of 0KB so no luck there. Sometimes assets.tdx is missing, other times not. Sometimes it can be found next to assets.bku. Reinstalling assets.tdx Trainz behaves normally after DBR. Same if I use my last backup of assets.tdx or rename assets.bku.

In my efforts to build an asset repair utility I use a lot of keywords that can then be used to enhance CM functionality. More recently I discovered keywordsbackup.dat so all my keywords can be exported and imported as well as acting as a backup when assets.tdx goes walkabout. It's not very well advertised, being buried in CM\Developer\Run Trainzutil..., but is a boon for people who use keywords a lot.

I digress.

During research I started using WINDBG utility, part of WIN10 Pro. I have it set to open and analyse if TRS19 and WIN10 Pro have a disagreement. Today it triggered twice and showed a WIN10 PRO violation of ntdll.dll. Whereas the previous crashdump files were 0KB, the last five all in TRS19 ver 111951 were of the ntdll.dll violation type.

So is it WIN10 PRO at fault, or is it TRS19 !!! In any case automatic recovery of assets.tdx would be workaround of this problem.
 
Last edited:
Blinking Red Circles - Adjusting the parameters for Red Blinking Circles on switches/junctions seems to have become much more difficult to adjust. The change in the arc limits for track has added difficulty where you stabilize the circle, do something at a different place on the track and the blinking resumes. Track is fairly straight. all spline points at the same elevation. Sliding a spline point sometimes,it corrects the blinking but then it returns when doing something else nearby. Roads are nearby and cross the track which my be a factor. I do not recall this adjustment (fix blinking spine point) to be as sensitive in SP2.
 
Last edited:
I find that slightly moving a spline that is immediately after the common of the switch stops the revolving red circle(spline marker). But, if I run a train over that marker it resumes red/blinking. Ultra-Track USMainline
Build 111951
 
Here is another one: As we all know, some objects have a radius of interaction with near-by assets. Notorious are the passenger stations: You can't move anything near as the whole station will move. You learn to live with it and use all the tricks we can invent to circumvent the problem. Here comes SP3, and now some catenary posts, have a very large radius, so if you try to move a bush at a fair distance, only the post moves! That post is a very small asset. Used to be that the larger the object the more radius, but a small one? This is not a change for the better and should be corrected.
 
I find that slightly moving a spline that is immediately after the common of the switch stops the revolving red circle(spline marker). But, if I run a train over that marker it resumes red/blinking. Ultra-Track USMainline
Build 111951

Track is very sensitive to curve radius. If the curve is too tight, according to its standards, you'll get the blinking spline circles. A blinking circle will still work in Driver, but a solid red one will not.
 
All manual and DCC cab controls in the Frecciarossa locomotive are not functioning since SP3. This occurs when one allows the game to initiate start up. There is also a very loud tapping sound. Can others please confirm. I am putting in a notification to Help desk.
 
Last edited:
All manual and DCC cab controls in the Frecciarossa locomotive are not functioning since SP3. Can others please confirm. I am putting in a notification to Help desk.

Manual works for me when manual is selected at cab start-up. If DCC is selected, reverser is stuck in reverse and throttle will not increase.
 
Are red & blinking spline vertices defined anywhere? Couldn't find it on the Wiki.

There is no definition of what will cause the blinking or solid red vertices. This is yet another area where documentation is lacking.

There are basically two conditions that can cause this.

For red-blinking vertices on a junction:

1) Uneven track

If the junction is created on a slope other than a meter difference between the start and finish, of the curve, then there will be a blinking spline point.

The diverging track is too tight off of the through track. The curve has to be adjusted to ensure that the curve transition is smooth as it exits from the through track.

2) A solid red vertex.

This is caused by a totally whiffed connection with a severe kink in the junction. Adding in a trailing, or sometime leading, spline point will allow the through track to be straightened and that will fix the problem. All other conditions causing the blinking spline point need to be accounted for of course.

Generally, creating a junction that is too tight will cause the blinking spline point. This is also the same with spline track as well as the procedural track now, which wasn't the case in TANE and early TRS19 builds. I find fiddling just a bit to ensure that the junctions are level and curved gently works, and when I converted an age-old route to procedural track I only had a few junctions that needed adjusting and a couple I had to rebuild completely. The problem, however, is these standards are also applied to crooked branch lines and tight radius switching lines like those found in factory districts where only a small GE 44-tonner might be able to negotiate the curves in and around the buildings and on the streets. This is also the issue with narrow gauge routes as well where the curves and switch radii are much tighter than on a standard gauge mainline.
 
So: You play a session. Save it for later continuing. Save session XXX XXX ? You say yes and a pront comes out saying: "Driver has failed to save game state. There is not enough disk space". Things go back to where you were, and you try again. This time it saves. However, it does not happen all the time. Let's say 60% of the times it happens..? And in a couple of instances, I end up with two saved sessions, the first one that it says it failed and the second that it saved properly. Never happen this before (to me).
 
So: You play a session. Save it for later continuing. Save session XXX XXX ? You say yes and a pront comes out saying: "Driver has failed to save game state. There is not enough disk space". Things go back to where you were, and you try again. This time it saves. However, it does not happen all the time. Let's say 60% of the times it happens..? And in a couple of instances, I end up with two saved sessions, the first one that it says it failed and the second that it saved properly. Never happen this before (to me).
.
Sounds like a chkdsk is in order. Not sure why you think it is SP3-related.
 
Last edited:
2021-05-09-132016.jpg


In TS19+ build 111951. Is anyone else having this happen. This has been broken for the last two updates. The turntable pulls the attachment points around to a match the position it was left in during previses play. Don
 
(image removed)

No, not just the one but all turntables are pulling the track around.

That looks kind of serious so off to check......

Just tried my own constructed turntables and they are behaving as normal after a session save, however I'm never easily convinced.
So added some sample turntables on my test board, ones with multiple roads ones with just a few and a straight forward turntable and they are all messed up, including my own, rotating the actual turntable asset in surveyor however put everything back as it was, this is bizarre and definitely a nasty bug. It's the actual whole Turntable asset that is moving or rather rotating.

My unaffected ones are on my WIP and were placed way back when TRS19 was pre SP1, or rather my working copy was, which may account for why they don't seem to be affected.
 
Do you have Trainz+? If so, It happens when in player mode, you turn the turn table. Then go to edit mode and just move something, any thing on the route level, it doesn't mater. that save and exit the game. When you reload the turntable is wacko.
 
Back
Top