[ATW]

Nice job getting MSTS sky's to work in ORTS.

But one bug I like to report is if anyone besides me is getting flickering skys and cabs since X1992?

[rdamurphy]

Walter Conklin, on 04 February 2014 - 06:28 AM, said:

Hello,

Wow, the sky textures are starting to look very realistic in OR v1995! That said, I did notice that the ends of some of the clouds seem to be cut off at the horizon as shown in the attached image:

Open Rails 2014-02-04 09-17-05.jpg

Moreover, the skies, as rendered in OR, seem to be stretched and more vertical oriented. In regards to the latter point, the clouds look like they are upside down in other words. The sky texture shown above comes with the How In The World Cotton weather environment. I used Kosmos to add the environment.

Thank you to Robert and the other members of the OR team for implementing Kosmos and How In The World weather environments in OR.

MSTS skydome sizes are defined in the .env file, and I haven't quite got that bit connected yet...

Same with the Distant Mountains buffer issue, this is a very early experimental version, with only a very few items "hooked up" to the .env files. There's still an awful lot of work to do. But we're definitely on the right track! ;)

BTW, is KOSMOS a payware program, or is it obtainable somewhere?

Robert

[copperpen]

Kosmos is free and should be in the Trainsim.com library.

[Buttercup]

At trainsim.com: kosmos10.zip, kosmos101.zip (patch),

Plugins: hitwskyw.zip, hitwskyr.zip, hitwskyc.zip, pvkosmos.zip, mstorm1.zip, mostorm2.zip, winrain1.zip, forwind.zip, winsnow1.zip, windfir2.zip, seasurf1.zip, river1.zip, winstorm.zip, softrain.zip mountriv.zip expr100.zip, severers.zip, articb2.zip, articb1.zip, engmalf2.zip, engmalf1.zip, fstorm1.zip, cburst3.zip, cburst2.zip, cburst1.zip, bbreeze.zip, bpkosmos.zip, msbolts3.zip, bpsummer3.zip.

Tutorial: senvtut.zip

Help files: http://www.tospitimo...Help/index.html

[rdamurphy]

Well, I know what I'll be downloading tonight!

Thanks for the info.

Robert

[rdamurphy]

Works for me... I'm pretty sure I understand how it works, but if I have any (many) questions, I'll shoot them to him. Always better to have an informed answer than make an (un)educated guess...

Robert

[edwardk]

Started running V2013. Previous version is V1966. Knowing that the use of the MSTS environment has been added to the experimental section, I started working with it. The first screenshot is MariasPass31 with the use of the MSTS environment unchecked and the second is with it checked. Quite a big difference in sky color. Nice, but just a tad too dark. I have to check, but I believe the environment is the default environment. Evidently the sky color parameter needs tweaking. The second set of shots shows the rain weather from Scenic2 with the above option unchecked. Evidently there was a change that is not connected with the MSTS environment because there was no difference with the option checked.

Edward K.

Attached thumbnail(s)

• 
• 
• 
• 

[edwardk]

I found out that there must be something with the environment file used with MariasPass31 because another route did not have this so I am going to upload the env file.

Edward K.

Attached File(s)

•  USA2SUN.txt (17.69K)
  Number of downloads: 343

[Metro4001]

The environments are still looking a bit wonky so I'm going to hold off for the time being. This is definitely a step in the right direction though.

[Simon E]

Genma Saotome, on 01 February 2014 - 12:21 AM, said:

No... not at least if you mean universally. I don't have a problem w/KUJU's directory design as a proposed starting point, it does have some things going for it but IMO it's is waaay too early in the OR program to declare it the final design as well. Consider the \global\shapes directory. It's a decent enough idea, certainly when content came from one source. But wouldn't it have been a bit easier to build routes if KUJU had the time to think thru that shapes directory and add a few subdirectories... gauge perhaps? Or to divide track from roads for better management? European from North American? Almost anything would have made life soooo much easier for the route builder. KUJU's solution had no provision for being able to filter away anything not relevant. You either figured out how to strip the tsection file or you scrolled endlessly thru tens of thousands of lines looking for one. And pre-junctions you had to keep them all in each miniroute.

The tertex directory is wholly inadequate. \Trainsets and \Consists are inadequate as global constructs as is \Textures --- I'll spare you the details in this post.

Point is that KUJU's directory design -- as is -- holds back OR. It might be suitable as the foundation, but it should never be the end point.



No again, at least not universally. I think, for the most part it's an ok idea but the OR team should reserve the right to introduce different file types, different file extensions. Consider that it may be advantageous to drop the SIMIS format and use JSON instead... the later deserves it's own design.

I proposed assembling complex shapes from multiple components -- a freight car assembled from carbody, trucks, brakes, coupler files where, obviously, the last three get reused in the assembly of many freight cars. Where does that go -- the wag? Maybe. Maybe not. And speaking of the .wag, why have the coupler and brake data in each and every .wag so assembled when it makes more sense to put the brake data with the brake model file and the coupler data with the coupler model file: most of the physical parametric data moves to the .sd files and leave the .wag for purely descriptive and categorization purposes.

So again, IMO the KUJU solution holds back both the OR feature set and technical changes.

I agree with every point brought up here. The stuff about brakes and couplers, sound a bit like what I had in mind. Also The Different Road shapes and Different Rail Gauges. All of this needs Fixed. It is a complete crazy mess...