[Goku]

I think TSRE will use something different than ref file. I think better solution will be subdirectories in Shapes directory where you simply put files and not use ref file at all. Each subdirectory will have config file where object settings will be defined.
But .ref editor is good idea to do in the future.

[conductorchris]

Goku, you've done some great work in the last few days! Wow! Thanks!
Christopher

[StationWhere]

Bonjour.

Goku, on 29 January 2017 - 11:46 AM, said:

I think TSRE will use something different than ref file. I think better solution will be subdirectories in Shapes directory where you simply put files and not use ref file at all. Each subdirectory will have config file where object settings will be defined.
But .ref editor is good idea to do in the future.

Ho Thank you! As usual it is good idea. But....
Do we will can continue to customize CLASS?
Regards

[StationWhere]

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

GOOGLE EARTH AS MAPS

Waouhhh! I did not dare hope for that.
You are amazing!
Thank you.

[Jovet]

Goku, on 29 January 2017 - 11:46 AM, said:

I think better solution will be subdirectories in Shapes directory where you simply put files and not use ref file at all. Each subdirectory will have config file where object settings will be defined.

I think more sub-folders is a bad idea. And it sounds like you're proposing a sub-folder for every individual shape or collection of shapes. Maybe if this were some sort of global repository that all routes could draw from I could see it, but for each individual route? Nah. A central repository for Reference information that all routes could use to identify whatever arbitrary .s files they have in their Shapes folders would be a good idea. But if the user wants to add a shape to the route, the Editor can 1) let the user browse for an .s file 2) look for a .ref file in the same or parent path as the shape being added. 3) locate the .ref entries for the shape in that .ref file 4) automatically import that information into the route being edited's .ref file 5) copy the shape's files (.s, .sd, .ace) to the route's folders 6) make the shape immediately available for use. If .ref file data is not available, the Editor can prompt the user to fill in the information (e.g. Type [Static, LevelCr, etc.], Class, Shadow, Description, etc.) and then proceed with step #4. If other shape data files (.s, .sd, .ace) are missing, the operation fails with an error. If the .sd file calls for extended, seasonal textures that do not exist, the user gets warned or the operation fails with an error.

[Goku]

Why it is bad idea? It doesn't increase file count. Only drawback is that you will have "directory/filename.s" in .W file instead of "filename.s", but it is used this way by many route builders already.
Directories are much easier than .REF file. Directory name is .REF class name. Each directory can contain any number of .s files. Each directory has one settings file that define type of world object.
Of course it is only Alternative solution suggestion, not .REF replacement.

[Goku]

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

- more advanced and intuitive "stick to track"
- gui fixes, better behaviour
- pos & rot tools for groupObj
- better app themes

[Jovet]

Goku, on 30 January 2017 - 07:44 AM, said:

Why it is bad idea? It doesn't increase file count.

Yes it does increase the file count. As far as the file system is concerned, folders are files. I would say MSTS installations with millions of files are already stressful enough on the file system.
It makes it harder to find and manage shape files in a route. "Hmmm which folder are _those_ in, again?"
It breaks software like Shape Viewer which is coded to look for textures in the shape's folder, or a peer folder called Textures.
It makes backing-up and manually archiving routes more complicated because of having to manage the sub-folders.
It could help prevent one type of file name collision but introduces folder name collisions.

[Goku]

Jovet, on 30 January 2017 - 11:56 AM, said:

Yes it does increase the file count. As far as the file system is concerned, folders are files. I would say MSTS installations with millions of files are already stressful enough on the file system.

No it doesn't incrase. Ok, it increase but by constant value of only several files (1-100 fies/route). One directory = one ref class, not one .s file.

Jovet, on 30 January 2017 - 11:56 AM, said:

It makes it harder to find and manage shape files in a route. "Hmmm which folder are _those_ in, again?"

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.

Jovet, on 30 January 2017 - 11:56 AM, said:

It breaks software like Shape Viewer which is coded to look for textures in the shape's folder, or a peer folder called Textures.

It breaks nothing. Textures are still where they are.

Jovet, on 30 January 2017 - 11:56 AM, said:

It makes backing-up and manually archiving routes more complicated because of having to manage the sub-folders.

?? You just copy or ignore Shapes directory like now.

Jovet, on 30 January 2017 - 11:56 AM, said:

It could help prevent one type of file name collision but introduces folder name collisions.

Folder name collisions. How?
Maybe you don't understand the idea ...

[CrisGer]

Goku thank you so much for continuing to develop this amazing help for us all. much much appreciated. thank you also for working with all of the suggestions so patiently and thinking it all thru. Everyone here means well and wants to help you and I am so glad to see great discussion going on.

thank you again this work you are doing is some of the most important work done since the start of OR.

:sign_thanks: :sign_thanks: :sign_thanks:

Chris

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