Alias default textures??

[mdanie]

Just a thought relating to textures and the space they consume, especially when replicated many times in different routes.

I guess it would be possible to create a set of shape files copied from the default routes and stored in, say, a \routes\common.shapes folder (or a dummy route called "common") that aliased textures in, say, a \routes\common.textures folder. Then instead of copying in shapes and textures from the defaults for each new route installed, the route builder would use the shapes aliased to the common.textures and the user would need only one set of the common textures in the correct folder - presumably saving quite a bit of space when many routes are installed.

Obviously standardisation would be needed - and the process probably requires a script to decompress, search, check and rename the appropriate strings in the shape files, as well as one to replace the "copy" batch file we all use at present. If it works, it could be extended to new models that authors wish to share too.

I can't check it out myself at present since I'm at work - but any thoughts?

[bristolian]

hello,

Route Riter already does this, it enables you to store the textures on a CD. An excellent utility for which we should all thank Mike Simpson.

Best wishes, Bob.

[mdanie]

Route Riter already does this, it enables you to store the textures on a CD.

Hi. I'll look into it this w/e, but do shapes actually alias textures on the CD or copy the defaults in from there to new routes during instal?

[bristolian]

Sorry,

I misread your post. What Route Riter can do is enable you to store the default textures on CD, thereby enabling you to delete the default routes if you want to, and save a not insignificant amount of HD space.
To set up a common texture folder would mean masses of work if you wanted the routes that have been already created to use it. I'm not even sure that MSTS would let you do that anyway. Also, it is more than likely that people may have replaced some default textures with some of their own creations, but keeping the original filename. That could cause routes to look different from what their author intended.

Best wishes, Bob.

[gregp]

On NTFS formatted disks you might be able to use "hard links". These make it look like the file is in each directory but in fact it is only in one.

The "fsutil hardlink" command creates hard links.

[mikesimpson]

As the textures are called from within the shape files, any alias would have to be hard coded into the shape file (even if it would work, and I do not know that it would).

As there are sometimes over a thousand shapes on a route some of which have up to 40 associated .ace files, you would need to uncompress 1000 shape files, and manually edit them all.

I think it would be easier for you to save up for a larger hard drive?

[mdanie]

A quick test this morning shows that it works in principle [decompressed carlisle.s in europe1, found the "images" section and aliased to ..\\..\\common.textures\carlislenew1.ace and carlislenew2.ace, recompressed then moved the 2 textures to a common.textures folder under "routes". Default S&C runs fine]

BUT

the problems come when needing night (or seasonal) textures (flagged in the shape.sd file). The sim now looks for these under "routename\textures\night\..\\..\\common.textures" ie appends the added path from the altered shape file. So it would be necessary to copy the few night and seasonal textures to their own folders for each route that uses them all rather messy!

I have yet to try gregp's hardlink suggestion (that's originally a UNIX concept, isn't it?)

BTW - this was just a "what if ....." topic. I wouldn't recommend anyone tried to manually repath all the textures but it could probably be scripted by those with "the knowledge" The idea was that a common pool of shapes and their textures might cut down significantly on diskspace.

[mdanie]

A quick test this afternoon to try out Greg's hardlink proposal.

Duplicated the europe1 route, piped a "dir" listing from the textures folder to a txt file, and used Word's find/replace to manipulate the list into a batch file with "fsutil hardlink create" for each ace filename (there's probably a more elegant way to do this) with the required path.

After deleting the textures from the duplicate route and running the batch file to create the hardlinks, MSTS runs fine

This could be incorporated into the routines that create the "installme.bat" batch file replacing "call xcopy" with the hardlink command. However, as far as I'm aware this would be for NTFS file systems ONLY. It would be an effective way to use a pool of common shapes and textures, though.

[mikesimpson]

Yes, that fsutil option would appear to be workable, with the proviso that it only works on NTFS formatted drives, AND that all files have to be on the same drive.

[leezer3]

Gimme
Any way to do this for already installed routes (Will just replacing the call xcopy with the fsutil replace all files with hardlinks?)
Any speed implications?

Thanks

Chris Lees

http://www.bvecornwall.tk

[ianmacmillan]

My common.loads shape files alias to a commonace folder to save multiple copies of the ace.

I've just tried moving the folder to another drive and editing the alias line in one of the shape files and it works.

[mdanie]

Gimme
Any way to do this for already installed routes (Will just replacing the call xcopy with the fsutil replace all files with hardlinks?)
Any speed implications?

Thanks

Chris Lees

http://www.bvecornwall.tk

PLEASE note (everyone, not just Chris) that at the moment all of this is experimental - I don't know at present whether hardlinks would overwrite the actual files in existing routes, which is what you'd want. Or how RouteRiter would deal with them. Any changes to the batch files may produce unwanted and irreversible effects so test on a duplicate MSTS install or route.

Just to clarify, there are two approaches being considered:

1) to alter shape files so that textures are called from a common folder. The problem with this is when changing to another season or to nighttime, when the new filepath written into the shape file gets appended to the path MSTS searches for the seasonal or night texture (see above). As Mike suggests, this is probably hardcoded into MSTS so is a bad idea for shapes with multi-textures (but OK for those that do not use extra texture variants - like Ian's "common.loads"??). These shapes will have the flag in the shape.sd file to indicate that MSTS must search in the seasonal or night subfolders for the correct texture.

2) more promising for those with a NTFS file system (recommended with WinXP, but not necessarily present on all XP machines) is to use Greg's suggestion and setup "hardlinks" which is a filesystem feature that points to the real location of a file, but uses almost no diskspace (like shortcuts or *.lnk files). Windows shows these links with the same icon and detail as the real file (not very clever!! it would be better to have a different icon to show these were hardlinks). From my reading, the files must be on the same, fixed, physical drive - so should be OK in another volume (eg. drive D: or E:). I didn't notice a performance hit in my brief experiment.

Using the command line to create hardlinks may put people off, unless the utility writers incorporate it into a batch file for use during route install. I'm looking into an opensource hardlink utility for the Windows shell that should create them more easily.

[leezer3]

No objection whatsoever to it being experimental. Can you please post the syntax you used; The MS KB is not helpful, I have tried with full path, direct replacement of the XCOPY command and full path in inverted commas, but all I can get is file not found
If necessary, I'll reinstall my routes, should get back at least 3 or 4 gb of space; routes folder is fast nearing 14gb, and i'm out of space
Never used RouteRiter, except once when I bust an activity so thats not a problem!
Final point- I found on the MS KB that all the hardlink command does is to create another entry pointing to the same space in the NTFS MFT, and thats why it has to be on the same partition.


Chris Lees

http://www.bvecornwall.tk

[mdanie]

OK Chris,
let's say in Newroute\textures you want to create a hardlink to a texture in the Europe1 default route. Open a command window in Newroute\textures (you probably know of the MS "open command prompt here" shell utility, which is handy for this). Syntax is:

fsutil hardlink create texture1.ace mstspath\routes\europe1\textures\texture1.ace

where texture1.ace is the default texture name and mstspath is the full path to your MSTS folder.

I believe names don't have to be the same - but it would become very confusing if you used different ones. In explorer, the link will look identical to the file actually being in Newroute\textures, but should not take up physical space (although its properties will show the linked filesize).

As you can see, it would be a lot of typing if done manually, but OK from a batch file. However, because you need to name each file to create the link you will probably not be able to use wildcards. Keep the default folder structure under textures in Newroute and link to the correct texture from each subfolder.

[leezer3]

Small point on your syntax; Found this after a little fiddling- There should be a slash before msts path, so example goes:

fsutil hardlink create texture1.ace \mstspath\routes\europe1\textures\texture1.ace

Chris Lees

http://www.bvecornwall.tk