[Genma Saotome]

Using directory names as equivalent to class names in the *.ref file seems to be a straightforward 1:1 equality. However, there is a slight performance hit that will occur as the OS will need to make several system calls with each directory change. In an editor that should not be a problem but it could be a slight performance problem for the OR file loader process as it too will have to make all of those extra system calls. IMO that's for the OR team to discuss and for them to pass final judgement.

WRT the route builders perspective, what concerns me is there is parametric data in each line of the *.ref file that will need to be relocated. Moving that concept to a "class" directory ref file is, IMO not good enough because the change will accomplish nothing of value for the route builder. IMO most, if not all of the data in each line of the *.ref file belongs in the shapes own .sd file. Its Shape Description file. If not KUJU's .sd file then an OR defined replacement for the .sd file. There are lots of proposed new features that could be added there as well.

WRT these .sd files... basically what we're dealing with here is all of the game specific data that are required but cannot be recorded in any of the 3d modeling tools. Examples beyond the .sd include .eng and .wag files... they're bigger of course, but their purpose is also game data you cannot record in the 3d modeling tools. That sort of data must be recorded somewhere and that's exactly what KUJU had in mind when the defined all of those. So either extend their design and enhance the .sd file or design a full and comprehensive replacement for it and then for starters flesh it out with the data from the lines in the *.ref file.

Do that and Goku's proposed directories could hold the .s, .sd (or its replacement) and possibly extraneous files such as a uniquely named readme/credit file for each of those shapes. If someone has 20 shapes for various trees, they're going to call them trees, whether it's in a ref file or a directory name. They're not going to set them up as Tom's Tree, Dick's tree, and Harry's tree, etc. etc. 20 different classes. On doing that I expect we'd usually see 10-30 directories created for this purpose. Having done that it becomes a bit easier to grab a directory and move it to a different project, or send it to a friend, that how we do things today.

Route builders will probably consolidate many shapes into these directories, much as they've done with class names

IMO it's VERY important that the proposed directories DO NOT include texture files as there are lots and lots of textures that are shared by many shapes -- track and roads for two examples. Leave textu5res where they are.

[Goku]

Genma Saotome, on 30 January 2017 - 03:11 PM, said:

Using directory names as equivalent to class names in the *.ref file seems to be a straightforward 1:1 equality. However, there is a slight performance hit that will occur as the OS will need to make several system calls with each directory change.

What calls?, what directory change? OR and MSTS doesn't use .REF file.
There is no difference in performance at all. Maybe it is 0.0000001% because of longer file paths. Code is the same. As I told, many routes already use this approach, for Dynatrack tracks and other common objects. It is nothing new ... however I don't like this approach because of ugly file names and that is why it is still not available in TSRE. But I like the idea.

Genma Saotome, on 30 January 2017 - 03:11 PM, said:

IMO not good enough because the change will accomplish nothing of value for the route builder.

Nothing? Now if route builder wants to import object to route, he needs to:
1. Find .s and .ace files and Copy & Paste them.
2. Open .ref file and find proper entry.
3. Open .ref file and paste the entry.
If it is one file, then not that bad. But inporting 50 objects is a pain.

Using subdirectories you need only Copy & Paste files. And if you want one class, Copy & Paste one directory.

Genma Saotome, on 30 January 2017 - 03:11 PM, said:

So either extend their design and enhance the .sd file or design a full and comprehensive replacement for it and then for starters flesh it out with the data from the lines in the *.ref file.

It would require loading all .sd files on app startup, so it isn't good idea ( but something to think about in the future ).

[Goku]

New update: http://koniec.org/ts...SRE5_v0.678.exe

- fixed satellite bug
- save map images to disk (to load from disk just click "show/h map"),
- tracks are not placed outside tile border
- dynamic track .W file values fix

[Genma Saotome]

Goku, on 30 January 2017 - 03:26 PM, said:

What calls?, what directory change? OR and MSTS doesn't use .REF file.

Perhaps I misunderstood your intentions. Where are you placing these directories you propose? I assumed under <routename>\shapes.

Goku, on 30 January 2017 - 03:26 PM, said:

It would require loading all .sd files on app startup, so it isn't good idea ( but something to think about in the future ).

You could wait until first use. Do you load every .s file right now, just in case it is to be placed somewhere? But that's not really all that important, what is important is that data from the *.ref lines has to be recorded somewhere, right? What are you proposing to do with it? Throw it away?

[Goku]

Genma Saotome, on 30 January 2017 - 07:12 PM, said:

You could wait until first use.

But if .sd files will be replacement for .ref file, all should be loaded on startup to make list of classes and objects.

Genma Saotome, on 30 January 2017 - 07:12 PM, said:

Do you load every .s file right now, just in case it is to be placed somewhere?

No, because there is .ref file with basic object info.

Genma Saotome, on 30 January 2017 - 07:12 PM, said:

But that's not really all that important, what is important is that data from the *.ref lines has to be recorded somewhere, right? What are you proposing to do with it? Throw it away?

I don't want to throw .ref file away now. Subdirectory is only solution to extend this file. I think it is not right time to think about .ref file functionality replacement.

[Genma Saotome]

Goku, on 30 January 2017 - 07:15 PM, said:

I don't want to throw .ref file away now. Subdirectory is only solution to extend this file. I think it is not right time to think about .ref file functionality replacement.

Extend? What do you have in mind?

[StationWhere]

ABOUT GOOGLE MAPS IN TSRE

Goku, on 28 January 2017 - 01:57 PM, said:

....Only displayed, like OSM layer....

Hello. I understood but can we hope that it will be used as TERRTEX later?
It will be a good feature instead of painting ground....

Regards

[longiron]

StationWhere, on 31 January 2017 - 12:13 AM, said:

ABOUT GOOGLE MAPS IN TSRE

Hello. I understood but can we hope that it will be used as TERRTEX later?
It will be a good feature instead of painting ground....

Regards

Totally agree

[Jovet]

Goku, on 30 January 2017 - 12:15 PM, said:

One directory = one ref class, not one .s file.

I missed that qualification earlier. I can see some merit in that suggestion, even if I'm still skeptical about multiple, random sub-folders.

Goku, on 30 January 2017 - 12:15 PM, said:

Harder? Finding shape in directory containing 99999 files is almost impossible by hand. You need to use "search". Subdirectories is the way to make it more user friendly.

It's only hard if you don't know the filenames you're looking for. Typing a few characters to jump to files starting with those characters in the sea of shapes is very easy.

Goku, on 30 January 2017 - 12:15 PM, said:

It breaks nothing. Textures are still where they are.

It totally would break Shape Viewer. Shape Viewer only looks for a shape's textures in two places: The same folder as the .s file, or in a ..\Textures folder relative to the .s file. If you arranged the shape files in subfolders, say Shapes\Vegetation\60ftcedar.s, then Shape Viewer would look for textures in Shapes\Vegetation and Shapes\Textures (which obviously does not exist). That is not to say Shape Viewer can't be updated to handle the new scheme properly, but I can't assume it will happen, either.

Genma Saotome, on 30 January 2017 - 03:11 PM, said:

IMO most, if not all of the data in each line of the *.ref file belongs in the shapes own .sd file. Its Shape Description file. If not KUJU's .sd file then an OR defined replacement for the .sd file. There are lots of proposed new features that could be added there as well.

I agree there, Dave. I like that idea. But one thing needs to be considered upfront: A single shape can be used in multiple ways (e.g. as a static model, or as a Pickup shape, for instance) and that needs to be reckoned in.

Goku, on 30 January 2017 - 03:26 PM, said:

It would require loading all .sd files on app startup, so it isn't good idea ( but something to think about in the future ).

I don't think that's a bad thing. When the editor loads it already has to load a bunch of information, so enumerating all of the shapes via their .sd files may add some seconds, but it only needs done once per editing session and shouldn't be a big deal.

StationWhere, on 31 January 2017 - 12:13 AM, said:

Hello. I understood but can we hope that it will be used as TERRTEX later? It will be a good feature instead of painting ground....

I think that such instant-use is dancing around the copyright of the Google images. I don't know about them retrieved through an API, but when you actually look at them on Google Maps, they do have copyright watermarks. Others might not mind, but I would not want to see those on a route.

[Goku]

I will do terrain textures from google satellite view, but you are right. Using google satellite images in route textures is piracy and if someone is making commercial route, it's risky. Satellite images are very expensive, so if google will see their pirated images in your commercial route, their demands can be high too.