[Icik]

So, I found 2 problems that can be solved from You :

1. When the trigger points of the left and right markers overlap, there is a problem and OR selects the default audio tracks. It could be treated so that the OR fetch markers only in the desired direction and accordingly elected audio tracks.

2. If I place one of the markers (eg left) and second (right) in long distance (I do not know how many km), OR again selects the default audio tracks. In the MSTS is it unlimited or somehow treated.

Please try this fix.

GOOD


NO GOOD

[Csantucci]

First case: markers overlapping: this is wrong placing of markers, I don't see why OR should take into account this case. Markers must not overlap.
Second case. Distant markers: if there is an uncovered zone between two back-to-back markers, the most logical approach is that in such uncovered zone the standard track sound is played. If this is not what the route builder wanted, he only has to use near back-to-back markers, which seems quite obvious.
So I don't see reasons to change OR operation. OR can't solve the problems of badly created routes.

[Icik]

Csantucci, on 11 December 2016 - 09:08 AM, said:

Second case. Distant markers: if there is an uncovered zone between two back-to-back markers, the most logical approach is that in such uncovered zone the standard track sound is played. If this is not what the route builder wanted, he only has to use near back-to-back markers, which seems quite obvious.

No, that is not what I think. Markers are face to face and this is not working in OR when the distance between them is to far.

[Csantucci]

OK, I understand. In fact from the code I see that OR reverts to 0 tracktype if no sound region marker is found in the loaded tiles and within 8192 meters behind or 8192 meters ahead of the train. I'll study whether a wiser decision can be taken (maintain last tracktype?)

[Icik]

Yes, maintain last tracktype. This sounds logical.

[Csantucci]

Icik, have a careful test with this patch files for x.3690. They should solve problem number 2.

12/12/16: Attachment removed because patch committed.

[Icik]

Hi Mr. Csantucci,

I have tested and looking good. Second case is solved. Good job.

[Csantucci]

Fixed in x.3694.