Kicking around som eideas, part 2

[muskokaandtahoe]

One aspect of every project is coming up with fresh ways to look at old, familiar issues. This thread (and maybe more later on) is an attempt to ask the wider community for some ideas to raise for consideration by the Open Rails team -- consideration; not a commitment. Please keep that in mind.

The topic of this thread will be about lights, mostly locomotive lights but it could include any other kind of light -- car exterior, interior, or even part of a static model. Once again, think broadly.

I'll start with some thoughts I've shared with some of the Open Rails team; Please provide some feedback and then chip in with ideas of your own

[muskokaandtahoe]

Poking around in my own .eng files, I did not find any instance where the coupler() parameter is used. IIRC that was supposed to control what happens to lights when zero, one, the other, both couplers, or "don't care" were in use, no doubt turning lights down (or off) when it was facing a coupler in use (i.e., facing the end of a car).

First question: Does anyone know of an example where a value in coupler() works?
Second: Is being able to vary the appearance of a locomotive light, depending on what coupler is in use, a feature that OR should consider implementing?

Speaking for myself, I kinda like the idea idea of having this... I dunno whether I'd really want it on the locomotive I was controlling (as I should know to turn off a light) but that aside, it does make a fair bit of sense to have working for an AI locomotive... you know, if the locomotive was flipped and the front was facing a string of cars, I'd want the lights to be different than if it was not flipped.

Anyway, this is meant to kick off the discussion. Feel free to comment on the above and/or add your own suggestions about what features about lights appeal to you.

[twpol]

IIRC that was supposed to control what happens to lights when zero, one, the other, both couplers, or "don't care" were in use, no doubt turning lights down (or off) when it was facing a coupler in use (i.e., facing the end of a car).

While this would also be the reason I'd think to reference the couplings, as best I can tell the condition is backwards. Coupling 1, 2 and 3 refer to the front, rear or both ends being coupled - providing no way to condition a light to go off when coupled. Something we could consider extending (like MSTSBin does with other conditions).

Second: Is being able to vary the appearance of a locomotive light, depending on what coupler is in use, a feature that OR should consider implementing?

The almost-released version of OR implements the MSTS-defined Coupling() values of 1, 2 and 3 (and 0 means 'ignore' as with the others) but as you noted, there's a lack of anything to test it with so I can't be sure it works - and I'm not even sure MSTS itself implemented it.

[mestevet]

I used a "Coupling ( 3 )" statement in my Silverliner II cars. I used it in the pantograph arc section for "middle" cars in a multiple car train. I constructed the arc lights so they would be different and activate at different times on the cars in a train. So I used the coupling parameter to differentiate cars that were in the middle (coupled at each end). As for the 1& 2 options, I tend to use the "Unit" statements to achieve the effects when the rolling stock is at the front or rear.

Steve

[muskokaandtahoe]

... Coupling 1, 2 and 3 refer to the front, rear or both ends being coupled - providing no way to condition a light to go off when coupled.

I think that is the case with several parameters here.

First, checking the documentation, it does say

The first thing you must specify is when you want the light or lights in question to come on. This is done by setting a number of flags to define the requirements for the lights concerned to light – if no requirements are listed, the light will always be on.

What exactly does that mean -- use the parameters to turn them off or to turn them on?

[muskokaandtahoe]

I used a "Coupling ( 3 )" statement in my Silverliner II cars.
Steve

Steve, in your opinion is there anything that should be different (e.g., other options or other values) about lights in cars vs. lights in locomotives?

[mestevet]

I'm not going to claim complete knowledge on all aspects of the MSTS lighting system here. I've sort of figured out what I've needed to make it work, and beyond that I'm sort of in "test pilot" mode.

I've thought that it would be nice to have more "user controlled" light options, not just the headlight off/dim/bright, but being able to control front and rear headlights and marker lights separately (through keyboard input). I've also thought that, sort of like using passenger views, that it would be neat to be able to select a car, such as in the "F9" consist view, and operate it's lights individually. {aside - I've had similar thoughts about operating individual car animations the same way, like being able to open the doors/traps or pantograph on one car only}

I think it's been discussed at length elsewhere, but having the ability to activate ditch lights with the horn is another thing (and operate them independently of the headlights as well).

Another option that could be valuable to creating lighting effects is the ability to have a "random" parameter in lights, perhaps akin to the way one can randomly activate a sound, or perhaps even something like a speed related parameter as well. I can think of a couple of effects that could make use of this: pantograph or 3rd rail shoe arcs on electric equipment (both random and speed related), and something like a "glowing firebox" effect on steamers (like a random flicker) - I'm sure folks could find other uses for it as well.

Steve

[eric]

Day & night lighting for interior/passenger views... the lights are not always on full blast at night....

[muskokaandtahoe]

Day & night lighting for interior/passenger views... the lights are not always on full blast at night....

An idea I had some months ago was to make use of the .sd file to add a variety of features, one of which was controlling the time of day for the appearance of night textures. IIRC, it went something like this:

Time_Of_Day_Lighting (
... Season ( Winter
......On (
.........Time ( 16:20 )
.........Randomize ( 15 )
.....)
.....Off (
.........Time ( 21:45 )
.........Randomize ( 60 )
.....)
... Season ( Summer
etc.
etc.

on so on.

I hadn't thought about suggesting this for cars but I suppose it would work just as well for passenger cars as it would for, say. houses.

As for adding it to the .sd file, the reason for suggesting that was because it has been verified that it is possible to append stuff after the existing closing parenthesis of the .sd without cause MSTS any problems. So adding a few things in the .sd would be a cheap way to add a few things w/o trying to mess with the world files.