[dcarleton]

The issues with lights and shadows have to be resolved before there can truly be a Version 1. Of course it may be a lot of work to address, but if Version 1 still has glaring headlights and wonky shadows it will discredit the project, perhaps permanently.

[Metro4001]

dcarleton, on 08 December 2014 - 02:52 PM, said:

The issues with lights and shadows have to be resolved before there can truly be a Version 1. Of course it may be a lot of work to address, but if Version 1 still has glaring headlights and wonky shadows it will discredit the project, perhaps permanently.

:rolleyes:

I could have sworn this was a TRAIN simulator and not a lights and shadow simulation. I understand the want for eye candy but to say it'd discredit the project permanently is utterly ridiculous. It's almost as if those in the MSTS community purposely say things that will discourage and outright push away those that are keeping this 13 year old simulator alive.

[Genma Saotome]

A bit harsh there Metro but I grant there is still a valid point in there somewhere and I think it should be this: The project team is charged with making decisions on setting their own priorities. To decide is to divide... some end users will find themselves disappointed, others satisfied. There is just no getting around that. For myself I'm content to see the team make this decision to call it good enough as I am of the opinion that continuing on until they're at milestone 0.9999999999999 won't do anyone any good.

And so there are times when we should just trust their judgment and see how things unfold and I believe this is one of those times.

[R H Steele]

captain_bazza, on 08 December 2014 - 06:35 PM, said:

It is good that the team recognises the pre-release period is for tidying up and fixing, but I doubt that two weeks will be long enough, perhaps four weeks would be the mimimum, then allow an agreed period for a selected group to beta test, with a further period to fix the 'spoiler bugs'.

I believe there is no immedate rush to release required - because users still have OR available to 'play' with in the meantime.

Q1 release [during the first three months of 2015] would allow sufficient leeway, without being tied to a specific date until a few days prior to OR V1 Day.

About the release: given the likely interest, file size and bandwidth hit - where will this release be hosted?

Another issue related to [possible] file size - what about downloaders with slow connection speeds? Everyone hates spanned archives, could the pacakage be in, say, two parts, with OR program files being - for example - as one archive, with additional material in a separate archive? [My double coffee kicked in for this post.]

Cheers Bazza.

:I-Agree: What he said. Please consider last point about file download size and splitting download into two parts, if needs be.

Also dcarleton "glaring headlights and wonky shadows" ........ what are you talking about? I have adjusted headlights, no problem and shadows appear far superior to MSTS??? Anyone got a link to a screenshot? And... "will discredit the project, perhaps permanently" :huh: :rolleyes: .

And finally.... Genmas' post about sums it up for me also.

[markus_GE]

Glaring headlights... yes, there´s a true thing to that, as in MSTS, no matter what the headlight settings in the ENG file, the light beam never lighted the terrain such that at daytime it became white. BUT - that´s a bug that can easily be fixed by altering the eng file itself.

For the rest, some things may still be missing, such as mileposts in trackmonitor (IIRC, that will be taken care of whenever the new UI is ready), but all those things have been deemed "minor" and should be added by V1.1. But most things necessary for MSTS compatibility are there, and working great, partially even exceeding MSTS, which includes shadowing, so personally, I´d agree with V1.0 being due during the next few months.

Cheers, Markus

[vince]

markus_GE, on 09 December 2014 - 04:34 AM, said:

Glaring headlights... yes, there´s a true thing to that, as in MSTS, no matter what the headlight settings in the ENG file, the light beam never lighted the terrain such that at daytime it became white. BUT - that´s a bug that can easily be fixed by altering the eng file itself.

For the rest, some things may still be missing, such as mileposts in trackmonitor (IIRC, that will be taken care of whenever the new UI is ready), but all those things have been deemed "minor" and should be added by V1.1. But most things necessary for MSTS compatibility are there, and working great, partially even exceeding MSTS, which includes shadowing, so personally, I´d agree with V1.0 being due during the next few months.

Cheers, Markus

Oh yes, the headlights startled me at first too! But I figured it was the superior graphics of OR that were finally displaying what the engine file light settings were asking for!
The settings with LightColour ( ffffe4ab ) parameter for some engines with the first byte of x 'ff' was the clue. Thats the brightness byte! and gets you maxium brightness for goodness sake! No wonder it looks like a welders arc.

It was obvious to me that the FF brightness illumination byte was done to mostly all engine lighting in MSTS simply because MSTS was incapable of properly displaying lights from the very beginning!
Now with the modern graphics the FF brightness byte is too bright . . . So? I simply adjust the lighting code to make it look 'right'.

So yes, there are probably going to be many instances of engine code tweaking to remove the kludgy engine setting that KUJU used to get a decent display back in 2001. Brakes, engine power and other whatnot are going to have to be adjusted to FINALLY have a proper running sim.
The developers have done a magnificent job with this! HUGELY (is that a word?) BETTER than MSTS ever was RIGHT NOW with the experimental versions! BRAVO! :rolleyes:
And then there is the framerate thing . . . I'm getting TRIPLE & QUADRUPLE the frame rates I ever got in MSTS with the same good GTX650 graphics card. That sealed it for me.

Best Regards,
Vince.

[Genma Saotome]

The size of the cone of light needs to be changed in almost all .eng files. In OR Angle() should have a value between 4 and 5. Radius() should have a value between 500 and 2000. That throws the cone of light 500-2000m out and where it covers the right of way and not much else. Using common MSTS values you see the cone of light thrown out about 200m and spread so wide you'd think it was a bright streetlight. Looks ridiculous.

[Csantucci]

Does MSTS badly interpret parameters?

[Genma Saotome]

Csantucci, on 09 December 2014 - 12:27 PM, said:

Does MSTS badly interpret parameters?

No. The difference between the two sims on this matter is entirely due to not being able to figure out exactly what KUJU had done for displaying the cone of light. Given the two parameters names of Radius() and Angle() I proposed to James that he use Angle() to represent the spread of light from the point of origin -- the top of the cone, which of course is at the locomotive. That left Radius() for the height of the cone. The later name makes sense if you set the value of Angle() to 180 (that's 180 to the left and 180 to the right). That would produce a sphere of light centered at the locomotive having a radius of some value. That value is what OR is looking for in the Radius() parameter. A realistic value would be based on the performance of real locomotive lights... often 1000-2500m, less for switchers. Locomotive lights also use a lens and cowl to limit the spread of light; a search of literature turned up an answer of 4-5 degrees of spread... which we understood to mean 4-5 degrees of spread off the central axis -- an angle.

Hope this makes it clear.

[EricF]

Any chance there could be a way to offer a means to "tone down" the (bad) MSTS lighting parameters with some generic average values for radius(), angle() and brightness bits in lightcolour() that could be toggled in the Experimental Options? That would allow for better lighting from MSTS .eng files without modifying them at first -- that might be good for new OR users who are a bit "commitment-shy" as to editing their MSTS files straight away. A way to smooth over what is effectively a poor implementation by MSTS so that they can then go on and commit .eng file changes when they feel ready to take it completely to the next level. A bit of a kludge, I know, but probably better than engineering "MSTS detection" when the need for such a feature should gradually decline in years ahead.

For better or for worse, lighting in a 3D application - be it a game, a sim, or otherwise, has a huge impression on the viewer. We humans are rather visual creatures. It might make sense to accommodate that well enough in a 1.0 version to make a good first impression.