TRS19 Service Pack 3 Official Release

Looks fine here in the ECML Dundee sessions. Please check CM to see if anything is modified or provide more detail about which loco, which version of the rule is being used.

Any loco, any route, and I didn't modify anything. Was fine in SP2.

Edit: Seems to be random (it decided to display again suddenly while driving a session).
 
Last edited:
Video of in-Portal Derailment in Map Mode

This YouTube video shows an example of TRS19SP3 in-portal derailment for a session that worked flawlessly in SP2. The derailment occurs towards the back of the train within the portal. Not shown is the train is indeed ejected driver-less and uncontrollable.

Here it can be seen both the consist speed and the interval for adding a new car vary quite noticeably. In SP2 there was no such variations. The longer the train gets, the more these parameters vary. We can hear the coupler compression and expansion. Perhaps this SP3 loss of "fixed intervals and speed" is associated with the new derailment characteristic?

The consist manually ejected using the QPM consists of the following:

kuid2:37573:1000268:4
kuid2:37573:1000268:4 (reversed)
kuid2:334896:200083:2 x 30
kuid2:334896:200089:1 x 30
kuid:86105:15090

Click the YouTube lettering for best visibility.
 
Last edited:
For instance in the case of the portals I have emitted trains with over 50 cars with a pusher at the end with no problems. But my pushers have all faced forward - because that's the way I have always seen them on the trains going through my area every day.


But as mentioned earlier its not just pushers, it happens with multiple units as well. Even the Build-in content derails. The test train I made with the EF81 and the SJ Os flat cars is all original build in content.
 
Hi deneban - you quoted me but didn't provide the KUIDs requested. :)

I also quoted you in post #87 but that did not seem to draw a response :), I am happy to receive this feedback . I did not supply the KUIDs because I characterized the problem as occurring with a "wide spectrum of diesel locos with varying games versions and authors", meaning it should be apparent without much trial and error. I supposed I could have qualified it with "North American Diesels", but the video and post I made adjacent to this post suggests it is more related to train length/mass rather than what kuid locos are placed back-to-back. The longer the train gets as it is emitted from the portal, the greater the "push-pull" effect and coupler sounds heard.

However, no need now as QA have now been provided with a repro that results in a regular derailment.
I guess QA (Quality Assurance) would acquire it (as the collector of "field" data?), no such assurance can be made now, once the horse is out of the barn; by now I hope it is in the hands of dev.

Obviously in all our beta testers we don't have any that run reverse locos through portals to have discovered this issue prior to release.

That is quite surprising since most North American class I railroads, except for mountainous regions, operate their cabs in a back-to-back lash up so the pair can take on either heading without a lot of making and breaking of connections:

Diesels.png


Is it possible the testing was not sufficiently structured to encompass what users may model from modern railroad practices? In North America "plains" areas, like Ohio, back-to-back lash-ups like that above with 250 cars are common and very frequent.

Also, is it verified the testers received the new portals? You said in p
ost #101 "there have been many thousands of hours of testing for SP3", and in this post https://forums.auran.com/trainz/sho...l-inside-re-rail-portal&p=1862358#post1862358 said the portals were being worked on March 8 (i.e. at the later end of development). The release was April 15, so hopefully the testers got the new portals in what seems to have been an ambitious schedule.

As for the script error, it is complaining, rightly, that there is no driver.

Ok, I take it the report is a bi-product of the derailment mishap, not the source of it.

We're working on a fix for this along with the other issues raised and we'll be releasing an update to resolve the problems. Meanwhile, the solution is to un-reverse those locos to avoid the derailment and you'll be back to normal.

Easier said than done. Surveyor doesn't seam to readily allow consists kuids to be "revised". In the screenshot below I made all cabs face forward on an established consist kuid preconfigured into my quick portal manager sessions. Using the "Get Consist" tool, does not allow an overwrite of an asset kuid, the option is ghosted. Nor can one make a new superseding version. Correct me if I am wrong or there is another method besides editing config files.

Screenshot-2021-04-23-085312.jpg
 
Last edited:
Comment on the Portal weirdness

Oddly, I just saw this weird Portal behavior. This with SP3 and TRS-19 Port Zyd on which portals normally work flawlessly.

I added a two engine "engines light" consist to the Central Portal Control rule. I used two of the GT GP9 blacks. The engines were configured as "forward" but when they emerged they were long hood forward. I changed both engines to "reversed" and jumped back to the session.

When the session started up from this change a consist was built and emerging. This was not the one I just made. This was the first consist configured in the rule (as one would expect). The complete consist was emerging out of the portal but then it started the "shaking" back and forth and it then ran backward into the portal and was consumed. The next consist build and emerge was normal as were all following ones, including my added "engines light" consist.

So what I saw here was that a changing the directon for a vehicle does something to the rule which affects the next consist out. Then the rule "settles down" and runs as it should. Perhaps changing of the rule mid-session may be causing some of these issues. At least here.

As a final note. After seeing this weird behavoir I saved the session at a point where I knew no consists were being built and ejected. After this save things worked normally on startup.

Addendum: Thinking about it.. it's as though the script applied the new consists' "reverse" setting to the first consist coming out of the portal when session was restarted. But only after the emerging consist was built and coming out. Then once the script ran through this particular consist which was consumed, the script continued with a new consist and worked fine. Hope that makes sense. ie: the "direction" parameter (variable) is not being applied properly on restart.
 
Last edited:
Hi deneban - you quoted me but didn't provide the KUIDs requested. :)

However, no need now as QA have now been provided with a repro that results in a regular derailment. Obviously in all our beta testers we don't have any that run reverse locos through portals to have discovered this issue prior to release.

As for the script error, it is complaining, rightly, that there is no driver.

We're working on a fix for this along with the other issues raised and we'll be releasing an update to resolve the problems. Meanwhile, the solution is to un-reverse those locos to avoid the derailment and you'll be back to normal.



After some researching I found the issue, deleting TNIPhysicsCore.dll from the main game folder and everything is working as normal. No more splitting consists, no more yo-yo effects just smooth running. So whatever is causing these problems must have something to do with that dll file. Even the reversed locos and multiple units run smoothly out of the portals. I don't know if removing that file from the game directory will have any negative impact on the game itself but as far as I can see everything else is normal.
 
Last edited:
After some researching I found the issue, deleting TNIPhysicsCore.dll from the main game folder and everything is working as normal.

OMG, a "Portal" is a fictional construct in Trainz - what possessed a developer/developers to have a real-world physics package be applied to a fictional construct? It all ended very badly.
 
Last edited:
After some researching I found the issue, deleting TNIPhysicsCore.dll from the main game folder and everything is working as normal.
Ah, but the most pertinent questions would be: What did the removal of the .dll file break? Does it control all Trainz physics and if so what other effects will it have? A nice temporary solution I think.
Graeme
 
Portals are like 16 years old now?
Why is so much development time still put in those?
Add 2 or 3 baseboards and make a shadow station, with or without return loop
or/and use the excellent "instant move train" driver command from pitkin
Beta testers are not to blame (never to blame even)
this could have been caught way before any beta
removing the new TNI physics is just a temp solution (I hope)
and indeed what will break if we remove it
Still having fun in build 100240 :)
greetings GM
 
Isn't it odd how the official release versions are labeled as "beta" in the bug report form??


2.png
 
Last edited:
Ah, but the most pertinent questions would be: What did the removal of the .dll file break? Does it control all Trainz physics and if so what other effects will it have? A nice temporary solution I think.
Graeme


It breaks the train physics (Also the dynamic lightning), with further testing it actually does affect the train movement too... You basically have to have Trainz load the file on startup and then delete it(!) If Trainz cant find the file on startup the trains wont move. I just wish there was an option to suspend these physics since they are the cause of the derailments and coupler breakage.
 
Last edited:
You basically have to have Trainz load the file on startup and then delete it(!)

Once the Start Trainz window is opened, TNIPhysicsCore.dll is locked.

If it is removed at the Launch Window, there is no manual train control or AI train control when starting the sim.

Can you be more specific?
 
Has anybody had problem since this last update of trains being real jerky? Had no problems until this last update.
 
sureshot28 - Go back through this entire thread to see comments made by me and others about the jerkiness of consists being emitted from portals, especially if one or more of the locos is reversed and/or banking at the rear of longer freight trains.
Apart from that, no.
The current build (111951) seems to be smoother and overall performance better generally, due to lower (improved) CPU utilisation and reduced scripting errors.
 
Last edited:
PC-Ace this right off the bat. I have not tried portals yet to see. Before this update everything was running fine. I did notice depending on view weather top down or long side view it will go away sometimes. I am also getting 89 to 123 FPS. It does not matter what route i use either does the same thing. It can be loaded down or nothing there at all in the background.
 
I noticed something in CM that seems to be incorrect behavior. I was downloading Togog's DRGW 2-8-2 499 (with snowplow) KUID2:222925:43200:6 and it failed to find the interior for the loco with the kuid2:222925:43260:1 as listed in the loco's config. It was unknown asset. It turned out that the version of the interior that was on the DLS was kuid2:222925:43260:6. I thought that the DLS or CM would have downloaded the latest available version but it didn't in this case. There are no earlier versions available on the DLS. Once I downloaded the interior kuid2:222925:43260:6 manually the loco passed the check of dependencies.

William
 
Once the Start Trainz window is opened, TNIPhysicsCore.dll is locked.

If it is removed at the Launch Window, there is no manual train control or AI train control when starting the sim.

Can you be more specific?


I can remove/rename it before I start the session just tested it. Its true though that after that the controls are limited, as I said there is no dynamic lightning and the animations are all static like wheels etc... but it keeps the trains from derailing and splitting, it basically behaves like TS12.
 
Trying to get my Trainz as clean as possible, and ofc start by repairing my own content if needed.
I f i clear the log, then startup fresh, these are the first few lines:
; <NULL> : TrainzDRMClient::performPlanetAuranLogin> not yet authenticated with planet auran
; <NULL> : TrainzDRMClient::performPlanetAuranLogin> logging in to planet auran cache
; <NULL> : TrainzDRMClient::performPlanetAuranLogin> cache login successful, setting session cookie
- <NULL> : FontManager> Unknown font label 'hud_digital'
? <kuid:30501:1010> : Loading asset <kuid:30501:1010>
; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1017> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1017> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1020> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1017> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1020> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1020> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1010> : Recursive attempt to compile this asset; skipping.
? <NULL> : ScriptableObject::CallScriptInit> <kuid:30501:1010>
; <kuid:30501:1017> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1020> : Recursive attempt to compile this asset; skipping.
; <kuid:30501:1020> : Recursive attempt to compile this asset; skipping.

ofc the first 3 is login in, no problem there
then there seems to be a font missing
then trainz is trying to compile a few buit-in script and fails, these have to do with multiplayer
hope it can be fixed, TY
 
Back
Top