TRS19 Service Pack 3 Official Release

My work-around for frequently-used DIY routes and sessions has been a simple, pragmatic change in locomotive and vehicle orientation for longer consists being produced by portals, since it is not only locos involved in ex-portal coupler-breakage incidents.
I don't use portals much in any of my routes, but one or two sessions benefit from the additional traffic generation they afford.
Bottom-line however, is that SP3 is such a massive improvement in most other respects over all previous builds that these minor niggles (which will be fixed soon no doubt in a asset update rather than a Hot-fix release) should not be used as an excuse for not updating.
 
Thanks for the extra info on the portals. It is sounding like in addition to reversed locos, it could be related to TNI physics and wheelslip (which we know from other reports is more sensitive in SP3 and being looked at). It could be that with locos pulling and pushing and having different traction, the couplers are stressed sufficiently to break. We'll investigate with these new details.

Steverozuk. Regarding the track spline curvature, there was a change made to address a bug. After feedback from the community it was determined that we would revert the fix and find a different solution to the original problem. I don't have the exact build numbers when this occurred (I thought it was only part of the first beta but could be wrong). The short answer is that the current curvature will remain, so unfortunately you'll need to update your track.
 
Thanks for the extra info on the portals. It is sounding like in addition to reversed locos, it could be related to TNI physics and wheelslip (which we know from other reports is more sensitive in SP3 and being looked at). It could be that with locos pulling and pushing and having different traction, the couplers are stressed sufficiently to break. We'll investigate with these new details.

It definitely has to do with it, that would also explain that the train tries to stop when the last reversed loco is emitted. I did a bit of testing and you notice it gets worse the more locos you add to the front (in forward). But its particularly bad with multiple units that all have an engine if the last unit es placed by the portal (in reverse) it will almost certainly derail (The Shinkansen is a good example for this). As I said earlier the couplers are way too sensitive, especially when the train is running under AI. The only fix I found to this was to lower the Max-accel and Decel in the enginespecs (The add weight trick from SP2 doesn't work anymore) but then the trains just end up creeping along...

Another thing I found not working is that if you want to change the enginespec in game (Surveyor), the selected new engine (and is doesn't matter which one) will turn the engine into a car.

For now I did a complete new install back to SP1 to at least get some "stable" consists:hehe:

On the plus side though I noticed a good performance increase and no more stuttering when running 30+ trains:)
 
QA couldn't repro this derailment so quite likely it depends on the quantity of locos and/or the engine spec. Could someone please provide the KUIDs of locos used (and their engine spec KUID to be safe).

Regarding the freeze in the Driver Listing, this occurs when Russian language is selected. The workaround for now is therefore to change to English to avoid the bug.
 
Last edited:
Having same issue when exiting portal. I am using the following consist... <kuid2:404575:1870403002:10> |CJ| ICE1 (Intl)
The rear 2/3 units break from the consist having 6 carriages and a loco at each end of the consist. TL eight units. Obviously not a long train.

Using most recent quick portal manager for setting up entry and exit controls.

Val.
 
Last edited:
QA couldn't repro this derailment so quite likely it depends on the quantity of locos and/or the engine spec. Could someone please provide the KUIDs of locos used (and their engine spec KUID to be safe).

I made a simple portal test with Build-In content on the front I had 3x EF81 <kuid:-13:137> the Enginespec is <kuid:-1:42004205>. Then I added 20 "SJ Os Flat Car" <kuid:-25:872> (Empty) and on the rear of the train a EF81 reversed. Around the time the portal places the 15th car you can already see the train jumping back and forth like a yo-yo. When the rear loco is placed by the portal the last cars derail and the front locos with the cars that are still on the track keep going at high speed.

QA should be able to repro this, since its all build in and it doesn't matter what portal you use it happens with all of them.
 
Hi all,

I have similar portal problems with Thalys (kuid2:348321:1007:1 - engine kuid2:386541:1021:4) and a Belgian railcar (kuid2:60856:1037:6 engine kuid:60856:51006) and also with the ICE triebcar kuid2:404575:1870840101:11 engine kuid2:404575:1870405005:10)

coupler breaks and jerky behaviour inside any type of portal (basic - long - re-rail - etc...)

Hope this gets better soon.

Greetz
 
...you can already see the train jumping back and forth like a yo-yo.

A very good description. I opened an old session with a lot of rollingstock. After opening the session, I noticed something I have never noticed with Trainz during the last 18 years: A payware Shay-locomotive on its tracks (without any commands) was jumping back and forth like a yo-yo at first and was moving then with high speed into one direction.

Regards
Swordfish
 
I have a weird thing here in SP3
When starting to drive a session, the first train (which has the focus) that has a drivercommand schedule, won't run as if the brakes are on
only thing i can do, is go to cabview mode then release the brakes (I am really bad with keyboard shortcuts)
has anyone noticed this or have similar issues?
greetings GM
 
Hey G.M.

I had the same issue with several trains not starting to the first trackmark after session start. I deleted the loc and replaced the same again in front of the consist. After ths all went smoothly again.
 
thanks Frank, good solution for now,
but this is an obvious bug not a feature,
What if a user with a few hundred sessions is faced with this?
does she/he has to replace every loc in every session first?


hope it gets fixed, if not,
maybe I will write a routine in my SDCR to easy(or automatic) release brakes ;-)
greetings GM
 
Hey G.M.

By ths way, I appreciate your routines very much, even though the trainslist remains empty an blocks further use of it.

Chears
 
What AWS On/Off button looks like now:


4V0Gj.jpg
 
QA couldn't repro this derailment so quite likely it depends on the quantity of locos and/or the engine spec. Could someone please provide the KUIDs of locos used (and their engine spec KUID to be safe).

My SP3 portal experience is sessions with portals working perpetually all day in SP2 now experience an in-portal derailment in the rear of the train whenever any companion locos running in reverse are in the consist. It occurs with a wide spectrum of diesel locos with varying games versions and authors. Subsequently, a driver never gets assigned and the portal is rendered dysfunctional. The uncontrollable driver-less train careens until it crashes or collides.

Errors are being thrown from several functions. It is obvious the script reviser wasn't fully acquainted with everything that was engineered into the script. Here are the error messages for dev to chew on:

Portal.png
 
What AWS On/Off button looks like now:

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

 
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.


Tony,

I actually had this problem, but never attributed it to a portal issue because the derailments occurred within the consist usually with some smaller wheelbase vehicles such as "beer tanks" or small covered hoppers. The locomotive would split off at the tanks and run as a separate train while the rest of the consist ended up driverless.

What complicated things is these derailments occurred prior to SP3, making it impossible to attribute anything to the portals. After I had removed those wagons, things worked better, but I would still occasionally get a derailment. With the off and on derailments, I eventually stopped running DPU (Distributed Power Units) on the end of my trains.

With that said, hopefully these fixes will resolve that issue once and for all and I can then again run DPU locomotives on the end of my long consists to assist them with the grades they encounter.
 
Tony,

I actually had this problem, but never attributed it to a portal issue because the derailments occurred within the consist usually with some smaller wheelbase vehicles such as "beer tanks" or small covered hoppers. The locomotive would split off at the tanks and run as a separate train while the rest of the consist ended up driverless.

What complicated things is these derailments occurred prior to SP3, making it impossible to attribute anything to the portals. After I had removed those wagons, things worked better, but I would still occasionally get a derailment. With the off and on derailments, I eventually stopped running DPU (Distributed Power Units) on the end of my trains.

With that said, hopefully these fixes will resolve that issue once and for all and I can then again run DPU locomotives on the end of my long consists to assist them with the grades they encounter.


Yes, as I mentioned before, something needs to be done about the coupler sensitivity, if your train has too many "light" cars, like flatcars the engines will "rip off". Its also part of the yo-yo effect mentioned earlier. But I am glad you found the issue with the reversed locos coming out of the portals.
 
I thought that may have been the case and that was related to the physics of the 'enginespec' used for the beer cars and covered hoppers I was using. They came from a particular author so I thought it was something he had done in his design, or perhaps the couplers he had used. I never thought it would part of the actual game engine its self.

I did see the yo-yo effect once, but like other weird things I could never get the issue to happen again, therefore, I never reported it. The issue being I didn't know what I did to trigger the yo-yo issue. I hate reporting one-off issues because there's no repeatability to the process that caused the problem. If something is repeatable, it's relatively to provide steps to cause the issue so it's more easily fixed.
 
With over 500,000 assets available and all the combinations and permutations that are possible it is remarkable that more bugs don't appear. People are doing things with Trainz that are very diverse and inventive.

This really points out the need for as many beta testers as possible on new versions. Some folks in the past have berated the beta testers for missing some bugs. Many tester, including me, tends to get into a rut of only testing stuff they are working on and don't venture into other aspects of the game. I want to make sure all my stuff works OK first off, and then I try a few other things to test bugs that others have reported. But my routes probably only utilize 40% of the total capability of the program, so there are many bugs which never affect me. So my input is that more people should consider joining the beta testing fray - the more the merrier so to speak.

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.

So in my case SP3 has been a great success and step forward.
 
Back
Top