[engmod]

Hi Team,

I always set cameras as follows:-
Camera 2 set to front of train pointed forward,
Camera 3 set to rear of train pointed forward.

I am finding that camera 3 gets corrupted and points to another car on the train.

ORNYMG 172.2 Tehachapi Pass II, 3 bnsf extra board, cam 3 goes to car 44.
Unstable U2026.05.24-1208 Mullan Pass, Into the storm, cam 3 goes to car 13.

Keystrokes to find problem:-

start activity,
number 2, front of train
number 3, rear of train
number 2, front of train
number 3, points to wrong car
from here cam 3 will always point to wrong car

Let me know if you wish for other tests.

As per usual, I will test earlier unstable versions and report here.

Attached File(s)

•  OpenRailsLog.txt (25.2K)
  Number of downloads: 2

[engmod]

I have tested:-

U2025.10.16-1622 as ok
U2025.10.19-2308 as ok
U2025.10.23-1938 as bad
U2025.10.27-0253 as bad
U2025.12.24-0952 as bad

So it appears that the bug started with U2025.10.23-1938

Can anyone duplicate the bug?

[superheatedsteam]

Yes, I'm on the latest Unstable versions and have recently started to experience this.

As I was testing models 'in game' and it was not high on my list of things to look at, I did not investigate further.

Cheers,

Marek.

[NickonWheels]

I´ve noticed this problem too.

AFAIK it happens when multiple vehicles in a consist have the same UiD number; then the simulation seemingly can´t decide which one to switch to.

Please check your .con files or use the F5/F9 displays to check UiD numbers, then correct them. Reversing the consist twice in TSRE consist editor automatically reworks the UiD numbers starting from 0.

[engmod]

Ok, the issue only happens when the last car has a duplicate in the consist.
When selecting the last car number, it goes to the duplicate, but ONLY on the second selection.

The code still has a problem, it is not consistent.
And I have indicated when the problem started.

[Csantucci]

The actual code assumes there are no car TrainNumber + UiD duplicates, because the union of these two values is used as a key to identify the car . The first time the rear camera points to the last car, but the subsequent times it points to the first car that has the UiD of the last car. This is because in the meantime the player could have moved forward the rear camera to another car.
Official Testing and Unstable releases behave the same. Official Stable 1.6.1 points to the last car every time you press the 3 key, and does not remember eventual forward shifts of that camera.
Having car UiD duplicates is a bad thing in my opinion, but I'd like to get also the opinion of James here.

[superheatedsteam]

Thanks NickonWheels, I fixed up my faulty consist files and camera 3 view now works as expected.

Cheers,

Marek.

[engmod]

>This is because in the meantime the player could have moved forward the rear camera to another car.

Carlo, I pointed out when the problem started as described.

And I fixed the 2 consists to remove the duplicates.
All I did was renumber the last car to greater any other number in the consist.

I have many more duplicates in my 6200 consists.

[James Ross]

Csantucci, on 29 May 2026 - 01:50 PM, said:

Having car UiD duplicates is a bad thing in my opinion, but I'd like to get also the opinion of James here.

The MSTS activity files refer to specific wagons in work orders using the Train UID + Car UID pair, so it looks like it was expected to be unique. Thus, we should warn if trains or cars within a train have duplicate UIDs.

As long as this content issue is rare, I'd recommend adding the warning and not worrying about the camera weirdness with duplicates.

[Csantucci]

Unstable U2026.06.09-1322 now includes a PR that logs the duplicates in UiD.
This is an example of a log line:

Warning: 2 occurrences of UiD 24 in consist with name 2 x Dash 9, 20 intermodal. Any UiD value should appear only once in a consist

The PR will be merged also in next ORNYMG release.

[engmod]

Thank you Carlo, that makes these duplicates easy to fix.