[Genma Saotome]

While doing an update to the OR manual for lights I found a number of arcane situations for which the existing feature set does not handle. With each one it occurred to me there is a more fundamental question at play: who should control that light -- the player or the .eng file?

As an example, in most cases the player as full control over the headlight but there are varying methods to control what happens to the other, usually small lights. Sometimes they illuminate only when the player turns on the headlight. Sometimes they illuminate only at night w/o regard to anything the player does.

IOW, who is control of each light varies.

Looking at what can be done in the .eng file I see with a few changes it would be entirely possible to remove the player entirely from the equation. Tests can be written for all common situations that turn the lights off or on automatically as well as change their color, releasing the player form having any responsibility for them. OTOH, it is also possible to write the tests such that only the player is responsible for turning lights off and an.

The question then becomes where is the balance, based on what people want? Do people prefer the lights are all automatically controlled... some mix of automatic, or no automation at all? So here is the poll:

[wacampbell]

For player driven trains, I prefer to handle the lights. Just give me some controls. If I am backing up or double heading etc, I'll switch the lights according to my railroad's practice.

But for AI trains, we still need reasonable and logical automation. We want to see those trains go by with proper lighting without user intervention. I suppose this might be done by the activity creator though.

And the same comments would apply for pantograph configuration. Some rr's run front pan up. When double-heading, some want the rear of a multi-loco lashup up, others want the front. And the rules even varied as time went on within a give RR.

There is no way to encapsulate the operating rules of every railroad into the .eng file. Having manual controls, would add to the operating challenges, and the skill in doing it properly.

As for the manual controls, they should be arranged the same way as the prototype. If the prototype had one switch for all, then our model should do the same. etc.

[burgerbern]

Difficult as the poll does not reflect what i do or need.

I prefer to control the headlights/ditchlights and beacons/strobes using the,1,2 & 3 codes (so off = dim lights 2 = bright lights and 3 = bright lights plus beacon or strobe), all the other lights i try to code the eng file to have them on or off as i need them automatically

[Genma Saotome]

wacampbell, on 15 January 2016 - 11:04 AM, said:

Wayne, I started out with the same opinion... but then I started reading rule books. For those of us who think we know what we're doing and are actually doing that in-game, well, it's looking like perhaps we don't know all of the ifs, ands, and buts that are out there (Of course each person has different levels of knowledge -- put for how many railroads?).

As an example, in the steam era many railroad had rules saying do not turn on your headlight (except in bad weather, in tunnels and in snowsheds). Yet other railroads had rules that said turn on your headlight at all times. How many people know which is right for the route they're using?

More arcane: Again, in the steam era, rear end pushers must display red lights to the rear... sometimes always, sometimes only at night, varying by railroad. How many tenders have those lights? How many people know if they should be on only at night?

Here's one we cannot do at all: When stopped on a siding you must change the color of lights at the rear end of the train so the light closest to the main is no longer red. Assume for a sec that can be done. Would you bother doing it?

And so it goes... the more you know, the greater the burden to do stuff that maybe you'd rather not want to be doing. And so I thought a poll might be interesting to see how many people want to control it all vs. not bother.

[Genma Saotome]

burgerbern, on 15 January 2016 - 11:08 AM, said:

I prefer to control the headlights/ditchlights and beacons/strobes using the,1,2 & 3 codes (so off = dim lights 2 = bright lights and 3 = bright lights plus beacon or strobe), all the other lights i try to code the eng file to have them on or off as i need them automatically

That preference is selection #2 of the first question.

[R H Steele]

I prefer to control the lights myself. I would prefer not to have to keep tweaking the engine files for each situation as I do now. My default now is all the lights are on all the time .... but that is not realistic and I would prefer to have controls easier at hand than placed within the engine file.

[Howky]

I prefer to control the lights myself .-)

Video from czech loco

https://www.youtube....h?v=fpd4aElQZv4

[Hamza97]

I too would like to control ALL lights myself, with some suitable automation if its driven by AI.... :)

[That Genset Foamer]

This has got me thinking--could the scripting be set such that other conditions trigger a lighting state? This would be along the lines of emergency brake lighting or the "does horn trigger bell" option, albeit defined by the end-user.

Basically, most Amtrak and commuter engines out west have a feature where--if the horn is sounded--the ditchlights will flash for a given duration afterwards. What the end user would do is define a lighting parameter about detecting the horn's starting trigger (and the potential to integrate an "or" condition so that quill activation could be possible if the modeler sees it fit), and having the ditchlights active for the duration of the horn blast(s) plus a given duration thereafter. Flashing ditchlights could be written as a "module" from there that is returned from the given conditions.

[Genma Saotome]

That Genset Foamer, on 16 January 2016 - 12:49 AM, said:

This has got me thinking--could the scripting be set such that other conditions trigger a lighting state? This would be along the lines of emergency brake lighting or the "does horn trigger bell" option, albeit defined by the end-user.

You'll have to get an answer from one of the guys who work with the code but I'll guess the answer is yes. All each light() clause has is a set of criteria to test and display instructions to use when the criteria is met and so it stands to reason anything could be added to the test criteria. As for extending the second half, what I've been calling Display Instructions, I think it would be best if it remained exclusively for illumination but the whole concept of criteria / action to take certainly could be the template for other uses -- for example, criteria of rain or snow with results that wipers are on.