[eugenR]

If in ManualMode a Distantsignal at the same pole with a Normalsignal before a switch
ask the state of the next signal type NORMAL ( behind the switch)
with the function next_sig_lr (SIGFNTYPE_NORMAL) it get always STOP as answer.

The same Distandsignal stand alone, with the same script work fine.

At the Bugreport here:
https://bugs.launchp...or/+bug/1650012
I have attached a Testroute and pictures

[Csantucci]

I have checked.
The problem arises during execution of this else if clause within sigscr.dat

else if (next_state ==# SIGASP_CLEAR_2)	

and in particular in calculation of next_state, that is

next_state = next_sig_lr (SIGFN_NORMAL);

Within the OR code this calls next_sig_lr(MstsSignalFunction fn_type) .
Within this method sigfound[(int)fn_type] for fn_type equal to SIGFN_NORMAL is -1, because in Manual Mode sigfound is not routinely computed. The method then calls SONextSignal(fn_type) to find sigfound. However SONextSignal returns -1 if the "starting" signal is NORMAL and the request is for next NORMAL signal. This explains why in the test route the standalone distant signal works correctly, while the composed distant signal+normal signal does not work well.
Instead of modifying the delicate signal code, I have preferred to routinely compute sigfound within the method CheckManualPath of train.cs, and have implemented this patch:
 Train_nextsignal.cs.patch.zip (575bytes)
Number of downloads: 190
This is the .dll to be replaced within x.3714
 Orts.Simulation.dll.zip (386.66K)
Number of downloads: 193

I wonder if the same should be done with method CheckExplorerPath.

If there are no objections, I have the intention to commit the patch.

[Csantucci]

Fixed in x.3718.

[eugenR]

Csantucci, on 26 December 2016 - 07:02 AM, said:

Fixed in x.3718.

Hi Carlo, It work fine.
So I can let this old minor Signal-Problem in the old Year!

Thank You
Eugen