[eric from trainsim]

Lindsayts, on 14 January 2014 - 03:39 PM, said:

Problem though is collision detection is CPU intensive, from memory OR uses a particle system to show smoke and steam, this means the program has to check EVERY particle to see if it has collided with any part of an object and then determine what path it should take, this usually takes tonnes of CPU power.

Understood at the particle level, and I'm not expecting to see smoke following the bottom of bridges or seeking a tunnel opening...

There could be some compromises, though.

Two possibilities...

1) shorten the path of smoke particles to no more than 1-2M when the source is inside the bounding box of another object (which would immediately stop terrain above a tunnel from looking like a thermal feature at Yellowstone)

2) simply kill off particles when they encounter a bounding box other than the source object

[Sid P.]

gpz, on 16 January 2014 - 01:24 AM, said:

The symbolic link works totally transparently, managed by Windows. So it doesn't matter if you have the file there, or just the link. It works in MSTS too.

Hi Peter-
Thanks for pointing out that Win 7 has symbolic links!
I just tried creating a consist (using Conbuilder Lite) in one miniroute's Consists folder using a symbolic link to the folder containing a locomotive in another miniroute's Trainset folder, and it works beautifully! The loco appears automatically in the list of available locomotives in Conbuilder, the consist is created, and both ORTS and MSTS run fine with the new consist.
This really means that only a single copy of the locomotive and wagon files are required on a drive, but they can be used in any miniroute.

[Traindude]

Here's a thought:

STEAM GENERATORS.

In MSTS, steam engines are quite capable of heating their passenger cars, so why should the passengers of diesel- and electric-hauled trains have to freeze?

[PA1930]

Traindude, on 16 January 2014 - 02:03 PM, said:

Here's a thought:

STEAM GENERATORS.

In MSTS, steam engines are quite capable of heating their passenger cars, so why should the passengers of diesel- and electric-hauled trains have to freeze?

Joining in this nice idea, I'd also suggest something for nowadays trains: high voltage connectors from diesel and electric locos to the passenger cars to make their A/C work. That'd be a funny thing to actually activate it and hear the passenger cars making a "bzzz" sound from the A/C working. :D

[Genma Saotome]

Sid P., on 16 January 2014 - 01:50 PM, said:

Hi Peter-
Thanks for pointing out that Win 7 has symbolic links!
I just tried creating a consist (using Conbuilder Lite) in one miniroute's Consists folder using a symbolic link to the folder containing a locomotive in another miniroute's Trainset folder, and it works beautifully! The loco appears automatically in the list of available locomotives in Conbuilder, the consist is created, and both ORTS and MSTS run fine with the new consist.
This really means that only a single copy of the locomotive and wagon files are required on a drive, but they can be used in any miniroute.

Yes, that is correct (and when you use it on directories instead of individual files it is just the same as a junction).

I think there is still an issue and an opportunity... lemme give an example: say you have 8 miniroutes defined and one original train simulator installation and you want to have directories in the later shared in one or more of the miniroutes. Let's assume you have 500 folders in train simulator\trains\trainsets and the average number of shares per folder is 3. That's 1500 symbolic links (or junctions). I think that's quite a bit to do... and I'd be concerned about so many of such things sitting somewhere on my drive. But at least you could have only the folders you really want appear in each individual miniroute -- it's perfectly suited to that.

A far more simple setup would be to have 100% of train simulator\trains\trainsets appear in all miniroutes... 8 junctions, no physical duplication... but then each miniroute is going to have all sorts of stuff that isn't relevant to it... might as well just use Train Simulator instead of miniroutes.

The logic of such symbolic links and junctions is one source location can be presented in multiple places.

The suggestion I gave is to record a path from a consist file to the trainsets folder... sort of the reverse direction of a junction. This way you'd set up n number of trainset folders... could be by country, could be by era, could be by railroad, whatever you want. And then in the consist file of the miniroute you define the correct path, using a mnemonic on each car line. So that could be $Path1 = C:\dave\1950's_era where 1950's_era is set up exactly the same way as \trainset is.

The logic of this is many car libraries can be presented in many consist files.

I think the later logic -- many to many -- addresses the issues of organizing huge collections of car and locomotive folders better than does one to many.

There many be a better way to solve the problem than I've suggested... but I think I have correctly identified the problem that needs to be solved.

[gpz]

Genma Saotome, on 16 January 2014 - 06:19 PM, said:

That's 1500 symbolic links (or junctions). I think that's quite a bit to do... and I'd be concerned about so many of such things sitting somewhere on my drive.

You can create a linked copy of a whole directory to solve this. In the shell extension shown in article the menü item for this is called Hardlink Clone or Symbolic Link Clone. This links only the files, but copies the directory structure. This way you are able to link just the common base, and still be able to add/replace specific files/directories to the miniroute. And I think your concern is baseless: This type of file system object (the link) is as native on a recent NTFS, as a simple file or directory, they are handled at filesystem level. If you aren't afraid of creating a new directory, then you shouldn't be afraid of creating a new link as well.

I'm not against extending MSTS syntax for handling aliases, I'm just saying an alternative way is already available currently, by using existing windows capabilities.

[Genma Saotome]

gpz, on 16 January 2014 - 11:48 PM, said:

You can create a linked copy of a whole directory to solve this. In the shell extension shown in article the menü item for this is called Hardlink Clone or Symbolic Link Clone. This links only the files, but copies the directory structure. This way you are able to link just the common base, and still be able to add/replace specific files/directories to the miniroute. And I think your concern is baseless: This type of file system object (the link) is as native on a recent NTFS, as a simple file or directory, they are handled at filesystem level. If you aren't afraid of creating a new directory, then you shouldn't be afraid of creating a new link as well.

I'm not against extending MSTS syntax for handling aliases, I'm just saying an alternative way is already available currently, by using existing windows capabilities.

Ok. You have a point there so let me back down then and make a final observation on the issue.

The Kuju design presumed consists, cars, and locomotives were global to all routes and that all such files would exist in one place as a single level folder (i.e., all files in the first level of a car folder). Actual practice shows us two things: that assumption wasn't correct -- we have many MSTS directory trees in use to manage our routes -- and (2) the used car and locomotive folders often amount to a very high number of folders, making both management and selection problematic across those many MSTS directories and (3) the use of relative redirection for sound and/or cab files within the "standard" tree worked but was often confusing. I know a good consist editor program would be a huge help with the selection of car and locomotive folders, especially within the KUJU design of directories, but I question the assumption that end users will organize their files only that way. So perhaps what is needed is an ability to point to many \trainset folders at once, something akin to how OR lets us define many instances or \routes and to carry into the consist file whatever information is necessary to make that file function properly given many \trainset foldes. Perhaps all that is needed is to symbolicly link those several \trainset folders into the one folder OR looks at (just like Libraries work, only w/o the limitation libraries have on the number of folders)... or some other solution. Whatever the solution becomes, the problem to solve is the many to many relationship between many instances of \consists and many instances of \trainsets.

Better?

[Sid P.]

More on links ---
I've been experimenting with symbolic links as applied to MSTS directory systems, and have the following observations. I am using the "Link Shell Extension" downloaded from http://schinagl.priv.at . It provides Explorer operations to create different types of links for single or multiple files or folders. It works very well, much more convenient than using a command window.

1) To replace the entire set of trains and consists in a given installation or mini-route (e.g. to use a different set of trains belonging a particular era or railroad), it is only necessary to temporarily rename the "TRAINS" folder in the installation or mini-route, then drop in a single symbolic link named "TRAINS" that is a link to the other TRAINS folder (in another route, or elsewhere) that contains the desired consists, locos, and wagons.
2) That works fine in both MSTS and ORTS in Explore mode. But to use activities written for the linked trains, either the route being used must contain the appropriate Activities, Paths, Services and Traffic files for the linked trains (matching the current route that they are to be run on), or the files will have to be linked in as well. A single activity may require several files in the Services, Paths and Traffic folders.
3) If you wanted to run an existing activity using a different set of trains, it would require a lot of appropriate linking and renaming. But no files need to be duplicated if links are used, and the links can be temporary - keeping the folders cleaner. The renaming worries me, in case of a system crash, or a user fumble.

So to avoid finger trouble that could make your installation unusable, you would need a tool that looks after the renaming, linking, etc. using links. It would perform some of the things that Train Store does, but would not need to move any files. Or, as Dave suggested, ORTS could be smart enough to look after this. Or looking further into the future, the folder system could be rewritten - but that would cut the cord to MSTS!

[jpmackay]

I would like to add " Milepost " for Track Monitor similar to Microsoft Train Simulator Track Monitor. I am not sure if anyone else already did post this and if not, then I would like to have this on the list.

Thank you,

John

[eric from trainsim]

New item.. Installer script for a user who does not already have MSTS installed, to define the mandatory folders ORTS needs and deposit mandatory global files with default settings.

Several people have done this on the side, but it's time to formalize it for new users who may never own a copy of MSTS.