[cjakeman]

Genma Saotome, on 12 December 2021 - 01:39 PM, said:

Another thought of file duplicates.
Perhaps allowing a user to add a parameter to certain files to indicate always use this one and ignore any duplicates would be the easiest solution. Sort of like sticking a tack in it so it stays put.

Perhaps I'm missing something here but, instead of inventing another mechanism, why not move the files you really don't want overridden to the end of the VFS config file?

[Genma Saotome]

cjakeman, on 13 December 2021 - 07:49 AM, said:

Perhaps I'm missing something here but, instead of inventing another mechanism, why not move the files you really don't want overridden to the end of the VFS config file?

Maybe its a non issue if rolling stock isn't distributed with activities and/or routes.

I'm quite protective of what I have inside of \trainset and make a point of always installing rolling stock outside of any content tree so I have a clean place to hold what was downloaded and a different clean place to edit so as to bring the values up to my standards. Only then does it move to \trainset, often by symbolic link (which helps a whole lot to deal with the many to many relationship between routes and rolling stock).

I think the new approach will be fine for most things, certainly useful for reskinning, but for rolling stock the zip files and their routinely edited rolling stock files may prove problematic because of how many people tweek stuff whereas everything that is normally unchanged under route\ will always be just fine.

Hmmm... this sparks a thought: What if rolling stock uses it's own variant of this mount point methodology that inverts the trainset tree, one that conceptually looks like this:

Zip file for rollingstock
-- goes here (abc)
-- goes here (def)
etc.

If something like that could be worked out the many to many issue is solved and the zip file itself could continue to use the current thinking for things like replacing skins. There is no duplication and should any editing occur it gets reflecting into all specified locations.

[conductorchris]

It sounds like Dave Nelson believes the virtual file system will over-write the source zip files in your TRAINSET(S) folders on your drive if there is a duplicate. That wasn't my reading of what others are sayin, which I took to be that the over-riding is happening in memory as the activity or timetable starts up. Which is correct?
Christopher

[Genma Saotome]

conductorchris, on 13 December 2021 - 06:09 PM, said:

It sounds like Dave Nelson believes the virtual file system will over-write the source zip files in your TRAINSET(S) folders on your drive if there is a duplicate. That wasn't my reading of what others are sayin, which I took to be that the over-riding is happening in memory as the activity or timetable starts up. Which is correct?
Christopher

Not over-write but use whichever is read last and if the last one isn't yours then your data values are not used.

When the matter is about original KUJU shapes and textures it's not a problem at all. When it's just skins the odds are darn good it won't be a problem at all -- in fact almost all of the files will work perfectly. It's only when the end user has edited values that there MIGHT be a problem, or with peculiar combinations of mine and yours, such as use my .wag and your replacement skins. It will all depend on which file is read last, whether you know your data wasn't used, and how easy it will be to say only use your own data when that is what you want.

If all you use are "stock" files produced by others AFAIK there will never be a problem and the compression via zips will certainly save space.

[gpz]

There is also a possibility to add mount options to a line in the vfs config. Since we have the filenames at mount time to work with, theoretically we can do all kinds of filename-magic. I could imagine options like:

-="*.eng,*.wag" could mean exclude these files in case they would overwrite an existing one (black-listed overwrite),
--="*.eng,*.wag" could mean exclude these files entirely (black-listed),
++="*.eng,*.wag" could mean use only these files exclusively from this package, nothing else (white-listed),
+="*.eng,*.wag" could mean overwrite only these files by not overwriting anything else, but use non-overwritables (white-listed overwrite).

I don't know if something like this would be desirable or usable, I wouldn't like to overcomplicate things.

conductorchris, on 13 December 2021 - 06:09 PM, said:

I took to be that the over-riding is happening in memory as the activity or timetable starts up. Which is correct?

Christopher, I can confirm that the correct interpretation is that everything happens in memory only. Currently the sole place where VFS is used to actually write something to the disk is to update the timetable binary paths (*.or-binpat). Since there is no MSTS installation base path anymore for the VFS (MSTS might be just a simple zip package somewhere without actually installed), for writing anything to a route's /PATH/ folder such a directory must be mounted as a real directory. It might be totally empty, but must be a real windows directory, like:

C:\working_dir\ /MSTS/ROUTES/USA2/PATHS/OPENRAILS/

(The route's /PATHS/OpenRails/ folder is the one where the *.or-binpat -s are tried to be written and read.)

[Csantucci]

I have a problem, maybe also because I'm completely a dummy about this feature.
I have built the actual unstable release, and I have run it to check César's new PR.
Here is the logfile I get:
 OpenRailsLog_Mount.txt (81.45K)
Number of downloads: 195
Two things can be seen:
1) I have a lot of archives that are mounted. These archives, however, are there only because I have sometimes uploaded zipped files, or sent them to someone, and so on.
I don't want to mount all these archives. In my case, the VFS should see no compressed archives at all. Is there a simple way to tell the VFS not to mount archives? Else, I'd be happy if it were possible to have a checkbox to disable the VFS mounting feature.
2) At the end of the logfile a crash is logged; this is for sure caused by the mounting of a not updated file (which is one reason why I am asking for a simple way to disable the mounting of all compressed files).

At the moment I have skipped the MountArchive () method to progress with my tests.

[gpz]

Hi Carlo, yes, sure, why not? I will add an experimental checkbox tomorrow. Sorry, I didn't expect it would cause problems to anyone, probably because I never stored such zips in the insrall folder. I tried to find an implementation method for vfs that is as transparent as possible to the previous working of the "profiles". (I cannot disable the vfs entirely, because it is so fundamental to how the files are loaded.)

[Csantucci]

OK Peter, thanks for attention!

[gpz]

Carlo, I've added the option. A would like to mention, that by utilising the VFS a possible workflow change could be to keep one's install directory clean, and add a parallel working direcotry to try out different eng-s, wag-s, etc. with a vfs config file like this:

C:\MSTS_Installed\ /MSTS/
C:\MSTS_Working\ /MSTS/

In this way one could make e.g. some eng development in C:\MSTS_Working\TRAINS\TRAINSET\somelocomotive\somelocomotive.eng , while keeping the original untouched in C:\MSTS_Installed\. One could also maintain multiple working directories, like MSTS_Working1, MSTS_Working2, etc., like the git feature braches, for trying out different concepts. All in a clear, separated space, not confused with the original and each other.

I've just mentioned this because it might be in your interest. (Btw the logfile with the lots of zips in your intall folder is enormous! :-) )

Regards,

[Weter]

Hello.

Quote

In this way one could make e.g. some eng development ... while keeping the original untouched in ... One could also maintain multiple working directories, like ... like the git feature braches, for trying out different concepts. All in a clear, separated space, not confused with the original and each other.

That's what I need, while debugging and enhancing rolling stock!
Thank you very much for that solution.