[conductorchris]

I'm really happy this exists. It is really going to change things in a good way.

I got to wondering . . . could the same basic concepts and coding be used to augment activities and explore mode. Imagine defining in your profile an activity file with static consists that also got loaded in explore route mode and maybe timetable mode. An activity with services that got loaded in explore mode. Even better if you could specify to pull randomly from a folder. Would do a lot for making the playing of the simulator more fun (as timetable mode has also).

Christopher

[Genma Saotome]

James Ross, on 19 May 2021 - 11:35 AM, said:

For MSTS-organised content, the files would be subject to the same restrictions on location within the virtual file system. So if the locomotive shape is in virtual folder "/MSTS/TRAINS/TRAINSET/KIHA140", the textures would also have to be in virtual folder "/MSTS/TRAINS/TRAINSET/KIHA140". The change is that those files would not need to necessarily be in the same physical folder, as long as the packages and virtual paths lined up as described.

Question: There are files that already have a path coded in them -- world files, .wags and .engs come immediately to mind, for example:
SIMISA@@@@@@@@@@JINX0D0t______

Wagon ( XM_SPS_10164_Lumber_LD

WagonShape ( SP&S_Box_10164.s )
FreightAnim ( USRA_50t_parts.s 1 1 1 )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\USRA_DS_Boxcar\\XM_USRA_DS_Empty_Car.inc" )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\USRA_DS_Boxcar\\XM_USRA_DS_Lumber_Ld.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Cast_Iron_Brakeshoe_Friction.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Type_D_Coupler_Generic_Draft_Gear.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Single_Pipe_AB_Brakes.inc" )
Sound ( "genfreightwag2.sms" )
Name ( "XM 40' SPS 10164 Lumber Ld 1919-55" )
)

)
That is the entire .wag file.

All six .inc files could be referenced by any number of other .wag files found in different folders than the .wag file I example here -- IOW each .inc file has a 1:many relationship with .wag files (and in some cases with .eng files as well).

A similar situation could occur in world files where a shape substitution has occurred for track and/or road shapes (i.e., you want the same dimensions as the global shape holds but the substitution is made to introduce alternative textures... ballast, road surfacing, etc.). Right now all of the alternative shapes are found in \shapes but given the size of the substitution set it makes more sense to move them out into their own library folder. Were that implemented the .s files in the library would have a one to many relationship with world files in many routes.

How are these facts implemented in this proposal? I can see the sense of storing them in a zip, but it would be unreasonable to make n copies of those zips... and if there is only one zip how would it be referenced so this proposal works?

[eric from trainsim]

Has this been disabled in the unstable or testing versions? I'm not seeing an option for the dir/file to use a VFS.ini file....

[gpz]

Yes, it is disabled. The problem is, that modification to the gltf patch would also be needed, but it is impossible with github to enable PR-s that depend on each other. So either the gltf PR is enabled, (x)or this one. So my idea was to wait till the gltf is merged, then this can be re-enabled. Unfortunately the gltf patch merging seems to take longer than I expected originally. :-)

[eric from trainsim]

VFS is shelved in favor of GLTF?... I'd think it should be the other way around.

VFS mounts can be used today. Are there any serious efforts available that use GLTF?

[gpz]

It is not actually a shelving. There are "tags" at the Github project site for being able to switch each PR on or off. It is a matter of switching gltf off and vfs on within 10 seconds. Just there are oppositions for both:

vfs: remove configurability, witch I wouldn't like to.
gltf: remove the animations, which I wouldn't like to.

Stalemate, nothing is going anywhere.

[eric from trainsim]

Unfortunate timing I guess.

I was going to start working on a modification at Trainsim to imitate the root mount point folder structure as we build zip files for download. Sort of an autocorrect for uploads that only provide a folder deep in Trainset or Routes...

I'd like to propose recognizing either folder "msts" or "content" within a zip as what you have defined as the /msts/ mount point.

Ideally, adding a neutral term for the mount point might help distance us from the Legacy naming, as well as to avoid the perception one needs to have msts installed. The more we keep the msts name around, the more confusing it gets.