[JohnnyS]

Opacity values for 8 character hex codes found in MSTS lighting.

• 100% — FF
  
• 95% — F2
  
• 90% — E6
  
• 85% — D9
  
• 80% — CC
  
• 75% — BF
  
• 70% — B3
  
• 65% — A6
  
• 60% — 99
  
• 55% — 8C
  
• 50% — 80
  
• 45% — 73
  
• 40% — 66
  
• 35% — 59
  
• 30% — 4D
  
• 25% — 40
  
• 20% — 33
  
• 15% — 26
  
• 10% — 1A
  
• 5% — 0D
  
• 0% — 00

100% white = FFFFFFFF
50% white = 80FFFFFF

Source @stackoverflow

[Csantucci]

 Genma Saotome, on 10 December 2014 - 10:24 AM, said:

... What we have today is OR code and KUJU data. IMO, the data should be corrected, not the code. ...

Well, that's against the OR fundamentals, at least up to release 1.0. As long as KUJU data have a coherence, and as long as MSTS coherently uses such data achieving reasonable effects, OR should emulate MSTS, if possible even improving, but not becoming incompatible.
And moreover code has to be changed only in one place (that is OR code), data have to be changed for the most part of the existing rolling stock.

[edwardk]

The wait for this particular utility may not be too long. Long before my involvement with OR, I have been working on a personal project for MSTS which would allow for the replacement of coupler entries, brake entries as well as a few other options. Two of the processes is not new and is of course covered by other known utilities. At one point I was considering on releasing it, but decided against it so its been a personal utility. After getting involved with OR, I added a OR feature which I believe are friction values that can be added to rolling stock. With the topic of lighting, what would you like to see done? My utility works on the basis of reading text files that can be modified.

Edward K.

[Genma Saotome]

 Csantucci, on 10 December 2014 - 12:57 PM, said:

Well, that's against the OR fundamentals, at least up to release 1.0. As long as KUJU data have a coherence, and as long as MSTS coherently uses such data achieving reasonable effects, OR should emulate MSTS, if possible even improving, but not becoming incompatible.
And moreover code has to be changed only in one place (that is OR code), data have to be changed for the most part of the existing rolling stock.

Do you know what KUJU was doing in their code? James did not and so the choice was no headlights or doing something different that would work.

There is all sorts of stuff in OR that doesn't work the same as MSTS -- brakes and adhesion for two... Steam Locomotive performance... Shadows and the movement of water. Some are better, some are missing, some are just different. I don't see why something as insignificant as a headlight should be pulled up as an example of why 1.0 should not be declared if the other discrepancies are somehow still ok.

A suggestion: Let MSTS go. The Lights() section is complex and most end users stay away from it. Down the road sometime we need a utility (with GUI) that will move the entire Light() section of an .eng file into an .inc file. Once there it can guide the end user in filling out any missing specifications that are due to the many possible conditions -- stuff tht was ignored in the original .eng file. That done ask the user to identify the other .eng files that should use that .inc file... these should be .engs for the same locomotive from the same 3d cad project. Any further tweeks to address subjective preferences can then be done in the one include file. The utility can be used to move the light data into a better data structure too. What the OR team gets is a very standardized block of data in a better format. What the end user gets is a more robust set of correct data for his existing content. Win:Win.

[markus_GE]

 scottb613, on 10 December 2014 - 10:36 AM, said:

Hi Folks,

I have to go read what Markus wrote previously again - but - I agree with Dave and this seems like a perfect job for Markus's DPU 3.0 - sorry Markus - not trying to volunteer you or anything - but once we have some reasonable light data - you've already built the vehicle to modify ENG files - no sense reinventing the wheel if you're willing...
...

What I wrote previously is, that DPU should at one point - no specific date yet - support replacing or inserting any parameter one wants it to into an ENG file. Provide, of course, one sets up the required ¨to do¨ file (data profile) for DPU, But documentation on that will be included and partially already is available in the DPU pack. :oldstry:

Before that all can happen, however, I will sort of have to re-invent the wheel, in that the source code needs a major cleanup, restructuring, and reorganization in form of Object-Oriented Programming (OOP), as otherwise things would become just incomprehensible for me as a coder.

Cheers, Markus

[James Ross]

 Genma Saotome, on 10 December 2014 - 10:45 AM, said:

...one of which is Weather(). Values 0-3 are allowed and they are, effectively, more conditions -- why KUJU didn't put them in conditions escapes me -- with values of 0 = all weather, 1 = rain, 2 = snow, and 3 = dry.

We do support this, though they don't seem to match the numbers you list... we have 0=all weather, 1=clear/dry, 2=rain, 3=snow. If we've got it wrong in Open Rails let's fix it - it's the order of the items in the LightWeatherCondition enum in MSTS.Formats\Lights.cs (around line 139).

 Genma Saotome, on 10 December 2014 - 10:45 AM, said:

Another part of the Lights() block that is suspect has to do with Unit() and Coupler(). I have my doubts that all possible combinations of flipped/not flipped, direction of movement, and coupler in use are present -- both in the range of acceptable data and code to make it all work. I think Unit() is poorly defined: you should never couple two completely different data into one value and yet that's exactly what Unit() does by combining position and direction of travel. And IIRC Coupler() might be missing a data value for Both in use. For a switcher with headlights on both ends you want the light to be dimmed when it is shining into a car end 1.5m away (w/o regard to which end of the locomotive is in question) while the opposite end may or may not be bright, depending on the direction of travel. I'm not sure OR can handle that.

We support the MSTSBin extended values for "Unit":

• 1 - Middle (not first or last)
  
• 2 - First (first and not reversed)
  
• 3 - Last (last and not reversed)
  
• 4 - Last Reversed (last and reversed)
  
• 5 - First Reversed (first and reversed)

The "first" and "last" flags are based on the train as seen from the driving cab, so whether the driving locomotive is flipped and whether the driving locomotive cab is rear-facing.

The "reversed" flag is based on the following conditions:

• Car is flipped
  
• Driving locomotive is flipped
  
• Driving locomotive cab is a rear-facing cab

To be clear: the "reversed" flag is set if there is an odd number of the above conditions present.

And we support the following for "Coupler":

• 1 - Front only
  
• 2 - Rear only
  
• 3 - Both

The "front"/"rear" are based on the direction of this individual wagon, so just whether it is flipped.

Note that this doesn't let you say "front is coupled but I don't care whether the rear is coupled or not".

This is definitely a complex system to reason about and I certainly couldn't make any promises about its correctness. In fact, I can pretty much guarantee it is wrong - I just don't know where yet. We could definitely do with some tests on this code. In the mean time, feel free to make up some examples (e.g. list of wagons, which are flipped, where the driving cab is, etc.) and we can work out which values apply to which wagons by hand (or through running examples - this code does have debug logging available).

All comparisons for the light conditions must be made with MSTSBin, not original MSTS, as I don't think the two are compatible in general - the code is meant to be following MSTSBin's behaviour.

 Genma Saotome, on 10 December 2014 - 03:19 PM, said:

Do you know what KUJU was doing in their code? James did not and so the choice was no headlights or doing something different that would work.

Heh, I think it is based on what MSTS does - or what the docs say - but as we all know, that's not the most reliable source. I'm quite happy for improvements to be made to how it matches MSTS if there relatively simple changes, but I don't think we want to make any major changes here.

[scottb613]

Hi James,

Wow - I've got some more things to try - thanks for typing it up...

Question - will a sphere/cone of light attach itself to a steam locomotives tender while being controlled from the locomotive - so the beam pivots with the tender instead of the locomotive ?

Also - is there any plan to include spheres of light on AI trains and other elements (light poles etc etc etc) within OR - or is that not possible ?

Regards,
Scott

[James Ross]

 scottb613, on 11 December 2014 - 02:21 PM, said:

Question - will a sphere/cone of light attach itself to a steam locomotives tender while being controlled from the locomotive - so the beam pivots with the tender instead of the locomotive ?

Also - is there any plan to include spheres of light on AI trains and other elements (light poles etc etc etc) within OR - or is that not possible ?

Light cones should work fine on any wagon - locomotive, tender or any other type - but there can only be one active light cone at any time. If two or more match their 'lights' conditions, one will appear (usually player's locomotive) and the others will not. This is a complex limitation to break but there are long-term plans to do it.

[scottb613]

Thanks James !
:)

Regards,
Scott

[Genma Saotome]

 James Ross, on 11 December 2014 - 02:00 PM, said:

This is definitely a complex system to reason about and I certainly couldn't make any promises about its correctness. In fact, I can pretty much guarantee it is wrong - I just don't know where yet.

Yes indeed. Thanks for documenting what's in place, I'm sure it will help in exploring what's left to do.

The one thing I know is wrong has to do with what happens when States() are > 1 and the data indicates the light is rolling around so as to pan the end of the cone of light across the right of way and back again. The example I have in hand as done by the author and, IIRC, worked as expected in MSTS but in OR the motion is performed at the wrong end of the cone... it's moving right at the lamp and the far end off in the distance is perfectly still. I believe there is a formal bug report for this.

As for the rest, I'm pretty sure there are conditions of coupler use & movement that are not correct but I do not have an example to share. I'll have to see if I can determine them again... will file a bug report if they turn up.