[Genma Saotome]

I think it will fly with the rest of the team because what it does is supply a very simple solution to replace a solution entirely dependent upon lots and lots of files in multiple directories, even, as you noted in mentioning your snow problem, when it really didn't make any sense at all.

A few more design thoughts... I cannot think of any reason in particular why the new *.tertex files belong in \tiles, \world, or some other location... it's all a toss up. As for the art, IMO it would be better to put them all in one directory -- tertex art is simply tertex art; If the route builder wants to apply a naming convention to help organize his work (e.g., Q4S = winter snow), fine, if instead he wants some specific textures to be used in many conditions he just repeats that name inside of the *.tertex file instead of making n copies of the file (essentially mimicking the way the /snow file works for ordinary objects). Or some combination of both -- Whichever way he wants to go will work equally well.

There are numerous ways to construct the data in the *.tertex file... as I did, as you did in the zip... or turn it around and have the texture name followed by some identifier to indicate which patch to apply it. Best of all it will solve both your problem w/ tertex and mine with both tertex and water and do so with very little effort.

[Csantucci]

My aim is not to implement features that need defining new file structures, also because this probably will be done within the route definition group.
I have implemented the feature as I proposed it (with a default file for normal terrain and another one for DM); here is a picture taken from the Bernina freeware with only the two default files:


I also tried to remove the snow files from the standard Marias Pass route, and inserted only the two default files. Here a picture:


I think I will upload the simple feature in the next days. It allows for fast snow versions of the routes, that then can be refined by adding further specific snow terrtex files.

The two files won't be part of the patch, as they are "content".

[RTP]

I insist. I fully agree with this solution, with no more complications. Regards.

[gpz]

Genma Saotome, on 05 January 2015 - 11:54 AM, said:

as you noted in mentioning your snow problem, when it really didn't make any sense at all.

A few more design thoughts... I cannot think of any reason in particular why the new *.tertex files belong in \tiles, \world, or some other location... it's all a toss up.

Just two minor notes :D
1. Please note the current extension is .terrtex, with double r.
2. The default snow texture problem was mentioned by Carlo, not me. :)

+1: It doesn't matter where such a file resides, but eventually it must be specified where we want to see them. It is not a good design choice saying it may reside anywhere. Certainly the current naming convention can be modified, but for this not being so strict a reference must be placed either in world or tile file, which cannot currently be done without doing further extensions to their format. In the future, when our world file format will be specified, there may be a place for some kind of a terrtexReference tag in it, which removes the need for specifying a naming convention.

Carlo, it looks nice! It is a real simplification. :)

[Genma Saotome]

Csantucci, on 05 January 2015 - 12:53 PM, said:

My aim is not to implement features that need defining new file structures, also because this probably will be done within the route definition group.

Forgive me Carlo but this is what drives me nuts with the OR team.

High iteration coding -- throw code against the wall and see what sticks -- has lots of merits... it gets plenty of things done quite quickly because there is a whole lot of feedback right away, but it needs a robust dialog about the idea, before the coding, as well as after the various implementations. I gave you feedback about the idea and to rephrase it to cut to the chase: Go bigger, not smaller with your solution. Whatever happens long term (1) can easily incorporate the contents of a text file and (2) is, at this time, at most only a few thoughts about possibly thinking about something as firm as smoke.

[Genma Saotome]

gpz, on 05 January 2015 - 01:08 PM, said:

Just two minor notes :)

2. The default snow texture problem was mentioned by Carlo, not me. :)

So it was. :D

gpz, on 05 January 2015 - 01:08 PM, said:

+1: It doesn't matter where such a file resides, but eventually it must be specified where we want to see them.

Of course. Sorry if my indifference on that point conveyed more than intended. If pressed to voice an opinion then I'd say if the * in *.TerrTex is a name such as the example I used then I'd vote for adding the files into \world. If, OTOH, it is a quad tree name, then \tiles. Between the two choices the former would be much easier for users to locate and edit. As for the long term, IMO it's better not to hide such data inside of a binary file -- let the raster file be a raster file and let the assignment of an art file to a specific location be handled like any other assignment of a file to a specific location: in clear text.

[gpz]

These files currently naturally would belong to tiles, since the original textures are also referenced from tiles. I just modified it because of your example. There would be a need for having some specifications for our new route data structure to decide where it will belong.

[Csantucci]

Genma Saotome, on 05 January 2015 - 03:24 PM, said:

Forgive me Carlo but this is what drives me nuts with the OR team.

High iteration coding -- throw code against the wall and see what sticks -- has lots of merits... it gets plenty of things done quite quickly because there is a whole lot of feedback right away, but it needs a robust dialog about the idea, before the coding, as well as after the various implementations. I gave you feedback about the idea and to rephrase it to cut to the chase: Go bigger, not smaller with your solution. Whatever happens long term (1) can easily incorporate the contents of a text file and (2) is, at this time, at most only a few thoughts about possibly thinking about something as firm as smoke.

Dave,
Your principle of going bigger and not smaller is in general the one that should be followed, however the context has also to be considered.
The context is that:
1) a task force has been set up to specify route editor design, so I would not feel of behaving correctly if I defined and used new file types for routes before the task force has published its work;
2) a release 1.0 is due in reasonably short time, and for sure before the task force has been published its work; so adding functionalities not present in MSTS within the framework of the MSTS file structure seems to me a good thing for OR, as it contributes to add value to OR release 1.0 towards MSTS.

[Genma Saotome]

Carlo, I have no problem at all waiting for version 1 to be released... indeed, waiting for 1.0 to clear is the only reasonable course to take right now.

FWIW, I've been waiting for at least 6 years for this to be changed. Do a search on this board for the word precipitation and author Genma Saotome. You'll find ~30 different posts going all the way back to 2009, most of which --all? -- are describing how Kuju got seasonality and the appearance of precipitation all wrong. There were more in the SLW private forum and you'll find more over at TS.com and maybe even 3dtrains and UKTrainSim as well, which is to say I didn't just come to realize this is an issue when I read your original post.

As for waiting for the future route editor team, I suggest instead you regard this proposal as fixing something Kuju did badly rather than defining what the future world editor should or should not do, much in the same way we regard using the Davis Formula instead of the MSTS Friction formula. What I mean by that is there are all sorts of new features hidden in the code; somehow you guys all think that hiding new stuff in the code is not so great an offense as putting it out in the open in a user readable file; That, IMO, is about as logical as claiming virginity is retained because a condom was used. Sorry, but IMO the OR team "crossed the Rubicon" a long time ago and every occurrence of ORTSwhatever() and/or new coded feature is testimony to that fact.

So once 1.0 is out and the dust as settled, throw some code against the wall and see what sticks. Peter's code (attached above) or something else.

[James Ross]

Csantucci, on 04 January 2015 - 10:05 AM, said:

Before considering implementation of this simple feature, I would like to have some opinion if this can be of interest for other people, and of more general use, or if it would solve only my particular case.

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.

[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.