[Csantucci]

Fixed in x.3735, then in x.3736 adding explanatory comment lines as per patch below
 Signals_semaphorescomment.cs.patch.zip (782bytes)
Number of downloads: 253

[James Ross]

 Csantucci, on 01 January 2017 - 12:46 PM, said:

It doesn't indicate in the logfile the signal affected as of now, because it writes only a line for every OR run; writing a line every time the patch modifies the semaphore indexes would mean that a line is written for every instance of the affected signal shapes, and that would in my opinion fill up the logfile with information messages. However if there is a better way to report the patch action in the logfile, I can improve the bug fix subsequently.

This problem has been dealt with elsewhere by having a variable recording which problematic items have been reported; in this case, the signal type would do. Have a look at WorldFile.cs, class Tr_Worldfile and the static field UnknownBlockIDs.

[Csantucci]

Thanks for the hint. I opted for a flag in SignalTypeData. A bit more memory consuming, but faster, even if a hash research is fast. Uploaded in x.3738.

[Jovet]

 Csantucci, on 30 December 2016 - 03:42 AM, said:

I'm not in favour of providing to the user means to enable/disable this option. It is a very technical one, and if the user makes the wrong decision he gets faulty semaphores.

Lots of things can be faulty with experimental options (e.g. advanced adhesion, fancy shadows, etc.). I believe that's why we go to the effort of writing a manual. Because this fix is new and not yet tested and proven over time, it is still experimental in my mind, and should be able to be turned off for troubleshooting. I do think it should be enabled by default, however, as it's a positive change in signaling compatibility with MSTS, especially considering it seems understood when it is needed and when it is not.

 Csantucci, on 30 December 2016 - 03:42 AM, said:

I'm neither in favour to apply the option only to signal files residing in the route's main folder, as this again makes only things more difficult for players; moreover for some routes it is useful to simply copy the signal files into the OpenRails subfolder, to have a better behaviour of SignalNumClearAhead; the player should therefore know that when copying the file also semaphores would work differently.

 James Ross, on 31 December 2016 - 04:43 AM, said:

I don't think it should be an option, but I am also not sure whether it should be active for OpenRails\sigcfg.dat or not.

I believe that once you start invoking Open Rails-specific files that the rules change. This fix is aimed at fixing a MSTS quirk, which I suspect simply stems from MSTS internally hard-coding 2-keyframe semaphore signal shapes' animation a certain way. A person creating OR-specific files needs to know what they are doing, and "reduced MSTS technical compatibility" is a natural consequence of OR improving on and expanding on what MSTS started. Catering to incorrect sigcfg.dat coding in OR-specific files is just rehashing the quirks/mistakes of the past, which we're obviously still dealing with.

 James Ross, on 31 December 2016 - 04:43 AM, said:

I'm not sure where this comes from, actually. A basic semaphore signal only has two states, so why does it need 3 key frames?

Ask Kuju. A third frame may be expected to return the shape to its original pose, such as if continuous animation were to be applied as if it were just a scenery shape. But as no 2-frame semaphores were shipped with MSTS, we'll probably never know. I've given all of my animated shapes an extra frame to return to the original pose because it looks better and smoother outside of the game (i.e. Shape Viewer).