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