One major shortcoming of MSTS is that it does not directly support flashing lights on crossing signals. In my opinion, this was a major faux pas on MS' part. And it is here that I see a golden opportunity for OR to address this issue brilliantly.
The only way to circumvent this so far is to use moving lighted discs to represent the lights, and to treat them as "gates" with a negative value for the animation speed. They move forward and backward, alternately going in and out of the light housing to simulate the appearance of flashing lights. But if you get the camera up close to them, you can see the disc visibly moving back and forth. Because each crossing signal object can only have one gate, a complete crossing signal has to be made up of several components assembled on site in Route Editor, with the base of the mast and gate unit being one object, and each set of flashers a separate object. This takes a lot of time to put together, not to mention having to manually edit the world file to silence the bell sound on all of the signal objects at the crossing except for one. To me, this is a really clumsy and unsophisticated way of simulating a vital and ubiquitous piece of equipment!
And, to make matters even worse, if the camera gets too far away from the crossing, the overlapping polygons of the lights and light housings blend into one another and you can't see the lights at all!
How I think ORTS could handle this better would be to define flashing lights on crossing signals as an actual light source in terms of position, size, facing direction, and color... and having properties settings to adjust the flash rate individually on each signal in the route editor as they are placed. But to set the default values for the flash rate to those specified in chapter 8C of the Manual on Uniform Traffic Control Devices (35 to 65 flashes per minute officially, but somewhere around 45-50 seems to be about the average in the real world), so that in most cases no changes are necessary and the signal works realistically just as placed. If it's done this way, each crossing signal can be made as a complete stand-alone model with the gate and flashers all in one piece. And some signals even have two gates mounted on the same mast... the normal one for the road, and a smaller one that lowers in the opposite direction to protect the sidewalk behind the signal. Burlington Northern was a major user of this type.
Would there be any way to also incorporate working flashing gate arm lights too? Somehow, the position of the light source would need to be continually updated to track the motion of the gate arm and stay in its correct position relative to the gate as it is being lowered and raised. But this is just a matter of some fairly simple mathematics involving the distance and direction from the center of the gate's rotation to the center of the light source, as well as the gate's rotation speed.
Also, the default rate for gate raising/lowering should be set to a more realistic value as well (MSTS' default is 4 seconds, but I always change this to 8 seconds in my routes).
And, I think we need to have support for using more than one bell sound file in the same route. Some crossings have mechanical bells, and some are electronic. Some ring at different rates, and some made by different manufacturers sound a little different from one another. So, in the Properties box that you would see in the Route Editor as you're placing the signal and setting it up, perhaps there could be a drop-down box where you would select which sound file is used at that particular crossing. Then, furthermore, there should be perhaps a series of radio buttons where you select whether the bell is: on continuously any time the signals are activated; turned off once the gate is all the way down; or not used at all. Not every crossing that has flashers and gates (particularly in areas without a lot of pedestrian traffic) is equipped with a bell.
I think there needs to be a way that all of the signals at a crossing can be placed and positioned individually in the RE, but linked to one another (as well as any and all car spawners passing through the crossing) so that all activate at exactly the same time. Also, it would be good to have a variable parameter to set how far short of the actual crossing point of the road and tracks the cars will stop (this value needs to be considerably increased if a crossing is sharply angled). Otherwise buried "dummy" tracks need to be placed under the road at the point where the cars need to stop, and this is far from an ideal solution because these things can rear their heads and become visible through the pavement anyway!. And, finally, if there's anything that can be done about that 4-track limit on how many tracks can be protected at the same time by each signal, that would be great too.
Looking forward to hearing your thoughts,
Bruce Bridges
The only way to circumvent this so far is to use moving lighted discs to represent the lights, and to treat them as "gates" with a negative value for the animation speed. They move forward and backward, alternately going in and out of the light housing to simulate the appearance of flashing lights. But if you get the camera up close to them, you can see the disc visibly moving back and forth. Because each crossing signal object can only have one gate, a complete crossing signal has to be made up of several components assembled on site in Route Editor, with the base of the mast and gate unit being one object, and each set of flashers a separate object. This takes a lot of time to put together, not to mention having to manually edit the world file to silence the bell sound on all of the signal objects at the crossing except for one. To me, this is a really clumsy and unsophisticated way of simulating a vital and ubiquitous piece of equipment!
And, to make matters even worse, if the camera gets too far away from the crossing, the overlapping polygons of the lights and light housings blend into one another and you can't see the lights at all!
How I think ORTS could handle this better would be to define flashing lights on crossing signals as an actual light source in terms of position, size, facing direction, and color... and having properties settings to adjust the flash rate individually on each signal in the route editor as they are placed. But to set the default values for the flash rate to those specified in chapter 8C of the Manual on Uniform Traffic Control Devices (35 to 65 flashes per minute officially, but somewhere around 45-50 seems to be about the average in the real world), so that in most cases no changes are necessary and the signal works realistically just as placed. If it's done this way, each crossing signal can be made as a complete stand-alone model with the gate and flashers all in one piece. And some signals even have two gates mounted on the same mast... the normal one for the road, and a smaller one that lowers in the opposite direction to protect the sidewalk behind the signal. Burlington Northern was a major user of this type.
Would there be any way to also incorporate working flashing gate arm lights too? Somehow, the position of the light source would need to be continually updated to track the motion of the gate arm and stay in its correct position relative to the gate as it is being lowered and raised. But this is just a matter of some fairly simple mathematics involving the distance and direction from the center of the gate's rotation to the center of the light source, as well as the gate's rotation speed.
Also, the default rate for gate raising/lowering should be set to a more realistic value as well (MSTS' default is 4 seconds, but I always change this to 8 seconds in my routes).
And, I think we need to have support for using more than one bell sound file in the same route. Some crossings have mechanical bells, and some are electronic. Some ring at different rates, and some made by different manufacturers sound a little different from one another. So, in the Properties box that you would see in the Route Editor as you're placing the signal and setting it up, perhaps there could be a drop-down box where you would select which sound file is used at that particular crossing. Then, furthermore, there should be perhaps a series of radio buttons where you select whether the bell is: on continuously any time the signals are activated; turned off once the gate is all the way down; or not used at all. Not every crossing that has flashers and gates (particularly in areas without a lot of pedestrian traffic) is equipped with a bell.
I think there needs to be a way that all of the signals at a crossing can be placed and positioned individually in the RE, but linked to one another (as well as any and all car spawners passing through the crossing) so that all activate at exactly the same time. Also, it would be good to have a variable parameter to set how far short of the actual crossing point of the road and tracks the cars will stop (this value needs to be considerably increased if a crossing is sharply angled). Otherwise buried "dummy" tracks need to be placed under the road at the point where the cars need to stop, and this is far from an ideal solution because these things can rear their heads and become visible through the pavement anyway!. And, finally, if there's anything that can be done about that 4-track limit on how many tracks can be protected at the same time by each signal, that would be great too.
Looking forward to hearing your thoughts,
Bruce Bridges