[Eldorado.Railroad]

?

[longiron]

Eldorado.Railroad, on 28 April 2012 - 07:44 PM, said:

Some months ago James pointedly indicated that for the foreseeable future, OR would only support one visible cone of light per locomotive. This is not how MSTS Bin works, but those are the priorities for OR at the moment.

I have been trying to come up with a way to mimic low/high beams in both directions given the constraints of the current MSTS .eng file and the implementation of said .eng file in OR.

Eldorado

Eldorado,
What James meant was that OR supports the same limitations as MSTS - a cone of llght can only be defined in a single direction - either front or back. OR currently supports MSTS low/high lighting definitions using the MSTS ENG lighting definitions. What BIN does is "flip" the single lighting definition as part of the cab flip process, it doesn't allow for two directional cone of light definitions. Without testing, I believe the OR ENG flip achieves the same thing.

Low beam (one push of H key)


Hi beam (second push of H key)



Here's the lighting code that achieve the hi/low functionality

Light (
  comment ( ** Sphere of light, bright ** )
   Type ( 1 )
   Conditions (
    Headlight ( 3 )
    Unit ( 2 )
   )
   Cycle ( 0 )
   FadeIn ( 0.5 )
   FadeOut ( 0.5 )
   States ( 1
    State (
     Duration ( 0.0 )
     LightColour ( ffffee99 )
     Position ( 0.0 3.53 21.4 )
     Transition ( 0 )
     Radius ( 400.0 )
     Angle ( 11.0 )
    ) 
   ) 
  )
  Light (
  comment ( ** Sphere of light, Front dim ** )
   Type ( 1 )
   Conditions (
    Headlight ( 2 )
    Unit ( 2 )
   )
   Cycle ( 0 )
   FadeIn ( 0.5 )
   FadeOut ( 0.5 )
   States ( 1
    State (
     Duration ( 0.0 )
     LightColour ( aaffee88 )
     Position ( 0.0 3.58 11.4 )
     Transition ( 0 )
     Radius ( 70.0 )
     Angle ( 10.0 )
    ) 
   ) 
  )

[James Ross]

Eldorado.Railroad, on 28 April 2012 - 07:44 PM, said:

3) Consist = Front wagon1???locomotive???wagon2 Back
Result, NOT as expected. When dim or bright are selected, the "Main Cone Light Dim Reverse" and "Main Cone Light Bright Reverse" are only observed, even though the locomotive is the de facto front of the train. Is this not the Unit ( 2 ) scenario, "(the unit is the front most unit of the train)"? It behaves as if it is still a Unit (3) scenario, why?

In this scenario, the locomotive is at the front and back of the train. Because of this, both unit(2) and unit(3) match. However, because they're both light cones you'll only see one at any time (due to the limitations mentioned) - it just so happens you get the reverse one. If you were using glow lights, you should see both forward and reverse lights in this situation.

[longiron]

Eldorado.Railroad, on 29 April 2012 - 07:38 PM, said:

Take a look at my response to James' post WRT to this topic.

The full intent here was to have a means to switch lights in the direction wanted, within the limitation of the current .eng file. So in a nutshell, in a rather limited way, it is possible to have low/high beams mutually exclusive in both directions with the logic provided. What MSTS Bin can do is to fade in/out between cones of light, something that OR does not do in public releases at present.

You are correct that by physically flipping the locomotive in the sim via the ctrl-shift-F key combination, you also flip the orientation of the cone of light. What was desired was that the locomotive not be flipped (prototypical) and that the cone of light direction change by other means. Although the point of my question was missed, I do thank you for having taken the time and effort to read and answer it as well as you did.

thanks,

Eldorado

First, we understand that the fade in/out between the cones in the present release is abrupt, but since OR does switch between hi/low this isn't a high development priority.

Second, we also understand what you desire to do - the point of your question was not missed. In my opinion, having two cones of light that are selectable (front and rear) without flipping the loco is a feature that will part of our next generation OpenRails ENG file format.

[longiron]

Thanks for the suggestion, we'll put the debug idea on our TO DO list.

But DEBUG is a truly a separate issue from having a FRONT and REAR light cone definition for a single locomotive. It's something that's slated as enhanced functionality for our next generation ENG files - not something we are going to insert into the MSTS ENG. I don't want to spend the development, validation and Q&A time to ensure implementation within MSTS ENG files doesn't screw up their operation with MSTS. It's much cleaner to do this within an OpenRails only ENG file.

This is where the roads for OR and MSTS part.

[longiron]

Eldorado.Railroad, on 01 May 2012 - 07:25 PM, said:

I guess there is a misunderstanding here.

Part of my interest with this train sim is with models. I would be as happy as the next person to see activities work the way they do in MSTS Bin, but I realize that this is a tall order for OR. It is within the limitations of the current public release that I build and test my models and at times there is the frustration that certain very simple tools within OR do not exist publicly to make the task of model making/testing easier for people such as myself.

For the moment all of ORs user controlled functionality is either in the registry or command line. Like yourself, I will rejoice on the day that the first configurable OR file comes into existence for public change/use!

thanks very much,

Eldorado

Eldorado,
No misunderstandings, just poor communication on my part. Our objective is to get Activities to run the same or better than MSTS. The next release will make huge strides towards that goal.

Regarding tools, given the limited resources (and every software project I've ever worked on didn't have enough developers) the OR team is focusing our "tools" ahead rather than behind - i.e. on the new OR file formats. There are a number of reasons for this strategy;

(1) ensure better consistency in the use, format and definition of parameters [the present state of MSTS EMG/WAG files is a mess];

(2) cleaner & clearer definition of functionality [many parameters don't do what the MSTS Tech docs say they do and its extremely difficult to replicate unknown MSTS software logic - just the Penalty, Control, Service, TimeOfDay, Weather, and Coupling parameters yields a minimum of 2 to the 6th power logic paths, or 64 potential unknown interactions;

(3) ensure the parameters employed are valid, reasonable and function as intented [we run across wild, ridiculous and downright stupid values for MSTS parameters all the time as community members report "this doesn't work like MSTS" because they've customized the value to achieve an specific outcome

Our goal is to achieve a "reasonable" level of backward compatibility with MSTS, but it's not the holy grail of our efforts. Once we get most things working, we will be concentrating on a better future with tools to allow the community to quickly and easily convert to it.