TRS19 SP2 and TRS19 PE SP2 Beta

HPL - thanks for the info. Could you please provide route Kuids and map locations for these issues.
Most likely there is one fix to resolve this issue everywhere, but knowing the exact locations will assist us in testing.

Route: <kuid:304444:101096> Mold and Denbigh Branchline (on the DLS)
Coords: -1935.49,2804.38 (Post #15); same at -1031.24,3126.29

Route: <kuid2:154322:101483:23> ECML Kings Cross - Edinburgh (DLC)
Coords: 82653.56,30681.97 (Post #17) and 57226.87,16442.84 (Post #18)
 
I submitted a ticket late on this very issue I found on one of my own routes. I also submitted some samples but didn't hear back because this version came out the next day. With your other examples on the built-in and DLC routes, this will help the QA Team resolve the problem sooner.

In all honesty, the more we report NOW the better we will be in the future and long run. There's nothing worse than a really awful bug remaining after the version has been released because the only thing we can wait for then is a hot-fix or a new service pack, and that means waiting as everything goes through the testing process again.
 
Confirming HPL's observation that there are issues with tunnels in Mojave Sub. Specifically, Tunnels 7, 8, 9, 10 and 17 on my Build 109641 version.
Also commonly found on built-in routes such as Kickstarter County 2, several junctions show up with two red-arrow junction direction markers instead of red/ green and a few show red (error) spline joints on junctions.
The red/red junction indicators revert to red/green when switched manually however, so this is not a major performance issue.
 
I'm not so sure about the flashing junction arrows, the red ones are a different matter. I have rebuilt a few junctions on my own routes because they were too tight or at odd angles and that fixed the problem. I did notice, however, that the past few builds are more sensitive to junction angles so might be intentional.
 
Thanks for the feedback folks - we're investigating all the issues and will report back in more detail once we've worked out the best solution for each.
 
Update Nov 3.

Collapsed tunnels - this is related to changes with digholes to make them more reliable. For full details see this thread here. This includes the "tunnel entrance" assets shown in the timberline route (MS Tunnel 15e), and the "terrain spline" in Mold, and the tunnel entrances in ECML.

Collapsed bridge in Route: <kuid:304444:101096> Mold and Denbigh Branchline (on the DLS) - this issue is related to a change in the "bridge" asset. <KUID2:84609:32165:1> was a bridge spline while <KUID2:84609:32165:3> isn't. Older versions had the bridge data cached and therefore the bridge appeared correctly. To adjust the current "bridge" you need to adjust the hieght of the vertex and resave. It will then remain in the new position.

Flashing junction arrows and red junctions - these appear to be correctly identified as "not within the procedural limits". The reason as to why they weren't red previously is less clear and we're investigating further.
 
Don't know if this has been reported elsewhere or if it is particular to my route but I have been relaying track and I have noticed that I can name two junctions with the same name and not get a warning.
Can somebody confirm this please as it will be a problem if using Interlocking Towers.

Peter
 
Don't know if this has been reported elsewhere or if it is particular to my route but I have been relaying track and I have noticed that I can name two junctions with the same name and not get a warning.
Can somebody confirm this please as it will be a problem if using Interlocking Towers.

Peter

Peter,

Confirmed. I can do the same, therefore, report this as a bug since as you say this can affect interlocking towers among other things that require named objects since this also affects signals as well.
 
I get that same thing with track marks and signals. Accidently named 2 of them the same for some AI actions, and the train went to the second, then reversed to the 1st.
 
I get that same thing with track marks and signals. Accidently named 2 of them the same for some AI actions, and the train went to the second, then reversed to the 1st.

That's interesting and shows that it's all nameable track-objects that can setup a hole for the AI to fall into. This issue may explain some of the odd behavior questions we get regarding AI.

I don't name signals or junctions too often so discovering this one during testing is rather enlightening.
 
That's interesting and shows that it's all nameable track-objects that can setup a hole for the AI to fall into. This issue may explain some of the odd behavior questions we get regarding AI.

I don't name signals or junctions too often so discovering this one during testing is rather enlightening.


Just to confirm bug report has been created and sent...
 
I can't believe this. I have just had this reply from QA

Hi peterwhite - Thank you for your report. Labels are strictly the purview of the user and the system does not prevent duplicate labels for objects in a route\session.

If the game generates two objects and assigns the same system name, that'd be a bug.
The same thing occurs with trackmarks, triggers, etc.
We only check for dupe names against saved route, session, and saved driver sessions.

Totally missed the point that the game is no longer warning the user that they have duplicated a track object name.
 
I can't believe this. I have just had this reply from QA

Hi peterwhite - Thank you for your report. Labels are strictly the purview of the user and the system does not prevent duplicate labels for objects in a route\session.

If the game generates two objects and assigns the same system name, that'd be a bug.
The same thing occurs with trackmarks, triggers, etc.
We only check for dupe names against saved route, session, and saved driver sessions.

Totally missed the point that the game is no longer warning the user that they have duplicated a track object name.

Keep at it Peter and reexplain the issue again. Tell them that it affects Interlocking towers and other assets that require uniquely-named signals, track marks, and other track objects.
 
Eureka!!!

Thanks for the info - looking at TANE and a few other previous TRS19 builds after I sent my first reply I do see it working there. An oddly enough found two dupe named juncs in ECML as well so the system lets you override it but it used to prompt you.

A task has been submitted.

Ref: TSR 589311372
 
Keep at it Peter and reexplain the issue again. Tell them that it affects Interlocking towers and other assets that require uniquely-named signals, track marks, and other track objects.

Hey all - thanks for reporting that to QA.

We understand there are assets that require no dupe names exist in order for them to work.
Apologies we did not read "No warning is given when two or more junctions are given the same name" as "The warning no longer is given...":eek:.

Please note it can help expedite things if bug reports state when something that used to work no longer does and what build (or closest version you can recall) it worked in.
I just had to go a little further down the rabbit hole to find out where it changed and immediately submitted a task.

Thanks for your patience & understanding that sometimes a bit of back & forth communications occur to get issues sorted.
 
Back
Top