[Eldorado.Railroad]

?

[longiron]

Full BIN lighting control has NOT been implemented, especially regarding lighting and Cab Switching. As for what's been implemented, here's a snip from the documentation

Lighting Functions and Known Issues
Phase one of the Open Rails Lighting adds basic train light functions as detailed below:
• The H key controls these light states: OFF-DIM-ON. As in MSTS, tap once for dim, then again for bright. Press CTRL+H in succession to reverse the sequence.
• Dim/bright lights work as long as the lights are set up that way in the ENG file.
• Fade-in/fade-out is supported.
• Scenery illumination is enabled but only when the headlight is bright.
Lighting states are now fully implemented:
• Penalty, Control, Service, TimeOfDay, Weather, and Coupling modes.
• Multiple States
Known Issues:
• Where the Lights block in an ENG file contains in-line comments (format: #comment), the comments are ignored but each one generates an error message in the console window. Not to worry: The message is more an advisory that an actual error.
• Glow-light objects are built as quads whose "radius" is specified in the Lights block. The position of each quad is also specified there. If two adjacent lights are positioned too closely or if their radius is too large, they will overlap and Z-fighting will occur. This occasionally can be seen in both MSTS and Open Rails software.

[Genma Saotome]

The cone of light is somewhat different, in large part to not having access to Kuju code to see what they actually did. Oh, and one difference is the MSTS headlight had an affect onthe length of the poly of whatever the light played across -- so you could have two adjacent polys, one 2m long and the other 100m long and both would have the headlight fade out at 80-90% of the length of each poly. OR adjusts the pixels instead so the effect the headlight has is uniform and much more realistic looking.

Also note than many MSTS headlights in .eng files are configured for far too wide a spread, at least for common North American headlamps. The OR code will support a more realistic (narrow) beam quite well but you have to change the value of angle to something in the 4.5 - 6 degree range instead of the common MSTS value of 20+.

[James Ross]

Eldorado.Railroad, on 14 October 2011 - 04:03 PM, said:

Before I bring any discoveries on this subject in these forums I conjectured that it is better to ask first as to what exactly has been implemented.

Please just get to the point.

[James Ross]

Eldorado.Railroad, on 15 October 2011 - 08:30 AM, said:

There are a number of cases that Chris/Dave have not described that I have found. You have to give me a few days to write it up so that there is no ambiguity involved. I am sure that you would want examples that are reproducible, and it will also allow me to "double check" my own work before posting.

Your OP was just too open-ended to answer with any detail or accuracy. Find what you think isn't working, check the docs (which Chris copied a bit from), then ask a specific question.