[eric from trainsim]

I'd like to see snow handled a little differently...

Unless there's a specific texture identified for a specific tile, just leave the underlying terrtex files as they are, but apply a filter or "microtex" style layer over that to obscure the "normal" terrtex. Ideally, it could be done on a variable basis, allowing for anything from a partial dusting to a full whiteness.

Imagine turning on a snowstorm and watching your route go from clear to obscured over a 2 hour period... :oldstry:

[Csantucci]

James Ross, on 08 January 2015 - 12:46 PM, said:

This seems like a specialised solution for one route that's in serious danger of triggering further requests to enhance the known-limited system of seasons (this has already been shown in this thread, in fact).

I'm much happier with simply replicating MSTS's seasons, so existing content works, while focusing on providing a much better system for Open Rails format content. If that solution can be retro-fitted to MSTS content in some way, that'd be good too, but is not a requirement to me.

OK, I reverted the changes I just committed. I hoped simply providing a default .ace for missing snow textures different from blank.bmp could be accepted, but I see it is not so.

[Genma Saotome]

James Ross, on 08 January 2015 - 12:46 PM, said:

I'm much happier with simply replicating MSTS's seasons, so existing content works, while focusing on providing a much better system for Open Rails format content. If that solution can be retro-fitted to MSTS content in some way, that'd be good too, but is not a requirement to me.

It is a trivial code change that addresses an incomplete / flawed KUJU design decision. Fixing that decision in some way establishes a requirement that any future OR seasonality needs to find a way to accomplish about the same.

Can the same flawed decision be found to justify Multiplayer? Timetable Operations? No. But they've been added. Extended view distances? Perhaps... and it too has been added. There are all sorts of things that have been added because one programmer or another wanted that feature. I've wanted a solution to this problem from before OR started... and have been asking one of you guys to do something about from the very beginning of the project. We're I doing code it would have been among the first things I would have contributed. Plenty of other things as well... just like all the team programmers do.

But no... I don't get do code and so little I suggest gets done. I don't know why I bother.

[James Ross]

Genma Saotome, on 08 January 2015 - 01:24 PM, said:

It is a trivial code change that addresses an incomplete / flawed KUJU design decision. Fixing that decision in some way establishes a requirement that any future OR seasonality needs to find a way to accomplish about the same.

Can the same flawed decision be found to justify Multiplayer? Timetable Operations? No. But they've been added.

Don't think for a minute that I am happy with all the things in Open Rails. Multiplayer especially, I strongly dislike the implementation of it and the way it just appeared one day. I also didn't say that this change cannot go in, only that I dislike it. It is up to other people how much my dislike means - clearly in this case, they elected to take it out (at least for now, I don't know).

This is why I am in favour of policy regarding additions to Open Rails, so things are agreed first. Or we can go full-on Dictator and have one person in complete control of what goes in and what doesn't.

The current policy is to have no policy, and you're going to have to live with that for now. Advocate for changing that, instead of just being annoyed at the coders having their way with the project. :oldstry:

[Genma Saotome]

I have, as you know.

Process determines results. You guys follow no design process... AFAIK no other shared processes either other than agreeing to use the bug list. And yes, I do know the lack of followed processes drives you wild w/ frustration.

What you're really telling me James -- and I'm not placing any blaming on you here -- is if I want anything, code it myself. That way if anyone on the team complains I can say "too bad".

I don't code. What I do is administer this board on behalf of the project and I try to make useful comments, here and elsewhere, and provide constructive feedback to the coders. As far as I can tell, I earn no credit for any of that. and that drives me wild w/ frustration.

Not a happy situation for either of us is it? Misplaced expectations will do that every time.

[conductorchris]

Not to try to get in the way of solving the situation, but I'll say that I have noticed and appreciated both the value of this board in the advancement of open rails and the value of Dave's administration and suggestions.
Christopher

[vince]

In Spades Chris!

Bravo for the information and idea exchange that this board sllows.
.
vince

[Kazareh]

eolesen, on 08 January 2015 - 12:56 PM, said:

I'd like to see snow handled a little differently...

Unless there's a specific texture identified for a specific tile, just leave the underlying terrtex files as they are, but apply a filter or "microtex" style layer over that to obscure the "normal" terrtex. Ideally, it could be done on a variable basis, allowing for anything from a partial dusting to a full whiteness.

Imagine turning on a snowstorm and watching your route go from clear to obscured over a 2 hour period... :)

I absolutely -love- that idea. That would be amazing, that and with dynamic weather that can at the -least- change without you having to use the debug commands; at best using a system like FSX where you can get real weather here-and-now and such for that area.

[Csantucci]

I have changed my mind. The change I had already introduced and then withdrawn does not influence at all actual routes neither in MSTS nor in OR, nor does it preclude any global functional improvement about seasonal terrain textures. So, it does not harm and it can be useful in some case.
As I did not have a stop to the change, I have re-introduced it again in release 2832.

As already described in some preceding post, default snow texture names are introduced: ORTSDefaultSnow.ace and ORTSDefaultDMSnow.ace, to be positioned within folder TERRTEX\SNOW of the concerned route. For the snow textures that are missing in the SNOW subfolder, and only for them, ORTS uses such files to display snow, if they are present, instead of using file blank.bmp.

So, simply, specific default files are used instead of a generic default file.

The two terrtex files are not present in the patch, because they are "Contents". However, if someone is interested, here is the couple of files I currently use
 DefaultSnow.zip (242.08K)
Number of downloads: 434

To have a minimum working snow texture set, also file microtex.ace must be present in the SNOW subfolder.

[Genma Saotome]

It solves your problem, it does not solve The Problem -- KUJU's poor design. Peter's solution did.

My concern is once something is done nobody will touch that topic again... it's that way forever, w/o regard to a better solution.

:rotfl: