[FS.E652 091]

scottb613, on 17 April 2023 - 02:48 PM, said:

Hi Folks,

I think "Bodner" was the name and these were the boards all the Button Box's were using. I did all the investigation into this topic a few years ago - so things may have changed - please take them with a grain of salt.

Bodner - Switches to USB
https://www.leobodna...=index&cPath=94

Regards,
Scott

Thanks to Scott for the reply, I'll take a look at the Link to be able to better understand something, however, also replying to Weter, and effectively closing this "Out of Discussion" for which I apologize, I think something could be done with Arduino Leonardo, But then again, I'm pretty backward in electronics.

It would still be useful to open a Post and maybe keep talking about it there ;-)

[Traindude]

Jonatan, on 11 April 2023 - 09:33 AM, said:

I agree with Scott on all these.

And additional active light cones for special FX like fire glow etc would be great, it's one of my biggest wants.
https://media.discordapp.net/attachments/331817060361437184/942467129310081045/Open_Rails_2022-02-13_06-01-54.png?width=743&height=418

This gives me an idea for another lighting condition: FireDoors ( x ). For this there are only two settings: 0 = ignore, and 1 = Fire Door Controlled. This is intended to simulate the opening and closing of the firebox doors on a steam locomotive and is intended to be associated with a rear-facing emitter in the locomotive cab (as Jonatan's screenshot that I have quoted illustrates). When the condition is set to 1, the light will automatically vary in brightness depending on 1) How wide the firebox doors are opened (100% brightness for 100% open, and "off" for closed), and 2) the burn rate of the fuel (higher burn rate = brighter emitter). Thus, the first two hexadecimal digits in the LightColour ( xxxxxxxx ) parameter of each state will dictate the absolute maximum brightness the emitter can achieve.

Does this sound like something to add to the list of new lighting conditions?

[Albertosaurio65]

Perhaps another good idea to add as a variable would be the speed of the train and the selected panto, that is, a variable that activates the light when exceeding x speed next to X raised pantograph, I would use it for the sparks from the pantograph rubbing against the catenary, currently I use the variable that is seen only at night, but it still looks bad when activated while parked


Also adding which pantograph is up is to put it on all the pantographs of the train and it is activated if that one is up or not, and a hybrid train can also happen that exceeds the established speed and activates but does not have any pantograph up why does it go diesel mode

[pschlik]

Reviving this thread as I have taken most of the ideas here and implemented them in a new set of lighting enhancements that will show up in unstable soon.

Highlights include:

• Multiple conditions! One light can now have multiple sets of conditions, and if any one condition is true, the light will activate. Very useful for a light that should activate in many contexts, but you don't want to copy-paste everywhere.

Previously you'd have to do something like this:

Light   (
        comment( Nose light bright )
        Conditions      (
                Headlight ( 3 )
                Unit ( 2 )
        )
        FadeIn  ( 0.5 )
        FadeOut ( 0.5 )
        States  (   	1
                State   (
                        LightColour ( FFffffe6 )
                        Radius ( 0.6 )
                        Position ( 0.0 4.12 6.55 )
                )
        )
)
Light   (
        comment( Nose light bright DPU )
        Conditions      (
                Headlight ( 3 )
                Unit ( 4 )
        )
        FadeIn  ( 0.5 )
        FadeOut ( 0.5 )
        States  (   	1
                State   (
                        LightColour ( FFffffe6 )
                        Radius ( 0.6 )
                        Position ( 0.0 4.12 6.55 )
                )
        )
)

But now, this has the exact same effect while reducing the number of lights the game has to process and saving lines of code:

Light   (
        comment( Nose light bright )
        Conditions      (
                Headlight ( 3 )
                Unit ( 2 )
        )
        Conditions      (
                Headlight ( 3 )
                Unit ( 4 )
        )
        FadeIn  ( 0.5 )
        FadeOut ( 0.5 )
        States  (   	1
                State   (
                        LightColour ( FFffffe6 )
                        Radius ( 0.6 )
                        Position ( 0.0 4.12 6.55 )
                )
        )
)

Hope that will be useful, even though it's a strong deviation from MSTS.

• New light conditions (the topic of this thread, after all)! First one is the Brake condition. Handy for brake indicator lights on coaches. Valid settings are: Brake ( 0 ) -light ignores brakes, the default state Brake ( 1 ) -light will be enabled when the brakes are released Brake ( 2 ) -light will be enabled when the brakes are applied. Note that this is triggered based on the presence of friction brake force, dynamic brakes will not activate this type of light.
• Next is the often-discussed Reverser condition. I've found this one to be very useful, plenty of trains have lights that you'll want to change depending on the direction of travel. Note: for every single one of these conditions, the "0" setting is the "ignore" setting, so I'm not going to mention that every time. If you don't put the condition in (every condition is optional) then the "0" setting will be assumed the default. Settings for the Reverser are: Reverser ( 1 ) -light will be enabled if the direction is set forward Reverser ( 2 ) -light will be enabled if the direction is set reverse Reverser ( 3 ) -light will be enabled if the direction is set neutral Reverser ( 4 ) -light will be enabled in forward or reverse Reverser ( 5 ) -light will be enabled in forward or neutral Reverser ( 6 ) -light will be enabled in reverse or neutral

Note that a flipped loco/wagon will also automatically flip the sensed reverser setting, which is the behavior you'd probably want. Ie: if your locomotive is not flipped, but the locomotive at the end of your train is flipped (HST, Acela, ICE, stuff like that), setting the reverser forwards will cause the flipped locomotive at the other end of the train to detect the reverser is actually in reverse (and vice versa). I'm contemplating changing the name of this condition to "Direction" as that better describes the behavior of the condition, but everyone here liked the idea of "reverser".

• A lot of passenger trains have lights that respond to the doors, so there's a Doors condition now. Doors ( 1 ) -light will be enabled if all doors are fully closed Doors ( 2 ) -light will be enabled if the left side doors are opening/opened/closing Doors ( 3 ) -light will be enabled if the right side doors are open Doors ( 4 ) -light will be enabled if doors on both sides are open at the same time Doors ( 5 ) -light will be enabled if either the left or the right side doors are open
• Then we have an often requested one, Horn, ideal for flashing ditch lights. When the horn is sounded, this condition will disable or enable lights depending on the setting used, and those lights will remain disabled or enabled for 30 seconds after the horn stops sounding. This 30 second timer can be changed with ORTSHornLightsTimer ( time ) in the engine () section of the .eng file. Unlike what some people have suggested, the timer does NOT go in the Lights () section! That just didn't make sense. Horn ( 1 ) -light will be enabled if the horn has not been sounded recently Horn ( 2 ) -light will be enabled if the horn has been sounded recently (or is sounding right now) Side note: if ORTSHornLightsTimer ( 0s ) is set, lights will activate in response to the horn but only while the horn is continuously sounded. I think some MBTA locomotives do this.
• Horn-enabled lights are somewhat common, but there are edge cases with bell enabled lights, so the Bell condition does the same sort of thing. The timer for the bell can also be set in the .eng file with ORTSBellLightsTimer ( time ), but it defaults to 0 seconds (lights only activated while the bell is currently ringing). Bell ( 1 ) -light will be enabled if the bell has not been rung recently Bell ( 2 ) -light will be enabled if the bell has been rung recently (or is ringing right now)

As a note for flashing ditch lights, the light set to represent the not-flashing state of the ditch light will need to use the Horn ( 1 )/Bell ( 1 ) condition, while the flashing version of the light (obviously) uses the Horn ( 2 )/Bell ( 2 ) condition. The not flashing state needs to use the "1" condition to ensure those lights are turned off when the horn/bell is used, otherwise both lights will overlap eachother. Here's an example configuration of the conditions for a ditch light:

Light   (
        comment( Right ditch light )
        Conditions      (
                Headlight ( 3 )
                Unit ( 2 )
                Horn ( 1 )
        )
        States  (   	1
                State   (
                        LightColour ( FFFFFFFF )
                        Radius ( r )
                        Position ( x y z )
                )
        )
)
Light   (
        comment( Right ditch light Flashing )
        Conditions      (
                Headlight ( 3 )
                Unit ( 2 )
                Horn ( 2 )
        )
        States  (   	2
                State   (
                        LightColour ( FFFFFFFF )
                        Radius ( r )
                        Transition ( 1 )
                        Duration ( 0.5 )
                        Position ( x y z )
                )
                State   (
                        LightColour ( FFFFFFFF )
                        Radius ( r )
                        Transition ( 1 )
                        Duration ( 0.5 )
                        Position ( x y z )
                )
        )
)

• Finally, another odd but useful light condition, MU. I saw various ideas for this type of condition and came up with my own twist. The MU condition can be used to detect if the locomotive the light is attached to is the lead locomotive, is connected to the lead locomotive with no wagons/coaches in between, or is separated from the lead locomotive with wagons/coaches (ie: a distributed power unit). MU ( 1 ) -light will be enabled if attached to the lead locomotive itself MU ( 2 ) -light will be enabled if attached to a locomotive directly MU'd to the lead locomotive (will also activate if attached to the lead locomotive itself) MU ( 3 ) -light will be enabled if attached to a locomotive not directly MU'd to the lead locomotive (MU ( 3 ) will also always activate lights attached to a wagon)

I've found this setting very handy for representing that some lighting signals are sent over MU, and others are not. For example, the USA system does not send ditch light signals over MU, so I have ditch lights set to activate for MU ( 1 ), the lead locomotive. The system also doesn't send light signals over radio to remote locomotives, instead, when a DPU is added to the end of a train its light is manually set to dim, so I have the dim lights set up to remain on all the time for MU ( 3 ).



Now I have not investigated adding a secondary headlights switch as that goes beyond just changing the backend code to scan files for more settings. Maybe that's easy, but with the need to add new keybinds, look for more keyboard inputs, add cab view controls...I'm guessing it won't be a 5 minute coding adventure. Still, these new conditions dramatically increase the flexibility of lighting, even with just the off/dim/bright settings.

Also, a disclaimer if you want to use these conditions: I may need to change the names of these conditions and if that happens things will break. If you don't want things to break wait some weeks until this is 'done' and in the testing version.

[SYogurt]

I cannot WAIT to test this tomorrow - the horn/bell triggered ditch lights is a game changer for realism for me.

[Weter]

Quote

( 2 ) light will be enabled if the left side doors are opening/opened/closing
( 3 ) light will be enabled if the right side doors are open

Are these the same? meaning "not closed"?

Quote

ORTSHornLightsTimer ( 0s )

is "s" compulsory?
What are MBTA locomotives?

What if combinations (for sake of example only) as
Headlight ( 3 )
Unit ( 2 )
and
Headlight ( 2 )
Unit ( 4 )
defined?
As You said:

Quote

and if any one condition is true, the light will activate

How can we prevent bright light being on @ unit 4 position, when light switch is not in 2 state?

[scottb613]

Hi Folks,

Whoa - Phillip- this is some pretty heady stuff - and could be a real GAME CHANGER for this thing of ours.

Thanks so much for all the effort - very much looking forward to playing with this.

:sign_thanks:

Regards,
Scott

[pschlik]

Weter, on 11 February 2024 - 02:45 AM, said:

Are these the same? meaning "not closed"?

Yeah, all the doors conditions check if the doors are not closed, so doors currently opening or closing will count as the doors being "open". This seems to be the case on just about everything

Weter, on 11 February 2024 - 02:45 AM, said:

is "s" compulsory?

If no units are specified, the number is assumed to be in seconds. You can use s (seconds), m (minutes), or h (hours) for any time unit, don't know why you'd ever set the lights to run for minutes or hours but it will work.

Weter, on 11 February 2024 - 02:45 AM, said:

What are MBTA locomotives?

MBTA is the commuter railroad out of Boston, the Massachusetts Bay Transportation Authority. Investigation for the MBTA F40PH-3C in Train Sim World Boston Sprinter led to the realization that the things have a strange ditch light behavior where the ditch lights only flash if the horn or bell is currently sounding...and the horn doesn't activate the bell. So if you honk the horn, the lights would only flash for a moment. It's very strange but I wanted to make sure the option to recreate that was in Open Rails.

Weter, on 11 February 2024 - 07:07 AM, said:

What if combinations (for sake of example only) as
Headlight ( 3 )
Unit ( 2 )
and
Headlight ( 2 )
Unit ( 4 )
defined?
As You said:

How can we prevent bright light being on @ unit 4 position, whrn light switch is not in 2 state?

If we implement this case like so:

			Comment ( Bright headlights. First unit. )
			Conditions	(
				Headlight ( 3 )
				Unit ( 2 )
			)
			Comment ( Dim headlights. Last unit reversed. )
			Conditions	(
				Headlight ( 2 )
				Unit ( 4 )
			)

Then the light would activate when (Headlights Bright AND First Unit) OR (Headlights Dim AND Last Unit Reversed). In this setup, the light would NOT activate in unit 4 position and headlight switch in bright. Unit 4 + Bright fulfills neither condition set: the first condition fails because it needs to be unit 2 for the first condition, not unit 4. And the second condition fails because it needs headlights dim, not headlights bright. (true AND false) OR (false AND true) is still false overall.

[Weter]

Thanks

Quote

don't know why you'd ever set the lights to run for minutes or hours but it will work

The question was about, should we sign zero by s - as in Your example, or just (0) would be valid too.

[SYogurt]

Weter, on 11 February 2024 - 09:24 AM, said:

Thanks

The question was about, should we sign zero by s - as in Your example, or just (0) would be valid too.

I got my ditch lights flashing with a 10 second timer but just inputting (10) so (0) should be valid without seconds.

Love this new feature and hope it can be put into a stable branch after some more testing, it really does change the game for lighting realism!