[ATSF3751]

hey everyone,

As I do a lot of sounds for steam locomotives something has come to my attention that may be of use to everyone if possible. It not only would save space but end up being less work for everyone that does sound design. Being there has to be 2 different sound sets for interior and exterior sounds. Wouldn't it be possible and more efficient to just have the exterior sounds play for the interior sounds as well? That way we do not need to have a stereo sound set and a mono sound set as we currently have.

It would make sound design much quicker to do and would also save quite a bit of space on everyone's PCs.

Another thing I thought of is we have a lot of the same class of locomotives, freight and passenger cars in the same paint scheme and the only difference is the #s. Would there be a way to render Open Rails so we could use one paint scheme for a specific locomotive and railroad and then have a way to just change the number on the locomotive? We could do the same thing for locomotive cabs as well. Have the same cab with a way to just change the number in the cab instead of a whole different rendering of the same cab just for a locomotive number.

Just a few thoughts I had.

Brandon

[Weter]

Hello.
That's good, You care for disk space.
In one thread over here, Erick told, ORTS doesn't care, stereo or mono, so, it's possible.
About numbers (decals/plates) we have freight animation attachments for main shape.
Alias-paths give us some economy; Include-files allow to go further with it.
:offtopic:
I see, that bar graph about laptop's disk turned red: 4.3GB free of 56.
At 1999, I've spent $200 for addition 4.3GB HDD to my 1.6 with W95

[ErickC]

The reason we use separate clips is locomotives sound vastly different inside than outside given the insulation and soundproofing in the cab. There are also vibrations from engine harmonics that are audible in the cab but not outside, plus the sound of traction motor blowers and the like. Turbochargers and roots blowers in particular tend to sound vastly different between inside and outside. It's an artistic choice, so there's no technical reason not to use the same clips for the interior and exterior. Even MSTS didn't require a separate sound set for the interior. MSTS didn't actually need the interior clips to be in stereo, either; whether or not an SMS used stereo samples was determined by the presence or lack thereof of a Stereo() flag at the top of the SMS. Typically stereo samples are used in the interior to give the impression of a 3D space, whereas mono is used in the exterior because the locomotive becomes a point-source in a 3D space anyway.

I will say that sound designers need to be conscious of what the content is in the actual clips - there's no reason to use a 44100Hz sample when there's no content above 11,025 KHz. A 22050Hz sample rate would be more appropriate for that particular case.

I would argue the single biggest culprit of rolling stock waste in the OR world is probably using a bazillion copies of the same model in a bazillion individual car folders given that OR will load textures from wherever the WAG file is even if the model is located elsewhere - think of all the models that could be culled this way.

Insofar as alternate road numbers go, I have had great success using decal shapes for this purpose. They're simple planes with alpha textures applied that are set up as freight shapes. Typically, I do them in sets of 32 (usually a 1024 x 1024 pixel texture sheet with 32 256x128 pixel texture slots), meaning a single car folder can have 32 roadnames. I generally build car kits so that each texture folder can have 4 paint variations in it. That's why my 100-odd BN hoppers only really take up 44MB of space. This might sound like a lot, but I had 100 road numbers across 16 weathering variations - 44MB isn't a lot considering what it would have looked like with 100 individual car textures. Given that a single 1024 x 1024 pixel DXT5 image is around 1.5MB, and that a car of that size would typically need 2 of them, that's 3 MB per car or 300MB across a 100-car train using conventional methods. These cars were also set up to use the remotely-located models from the base package, meaning those 4 models were it. No duplicate models located anywhere, just the same models from the base package being used by 4 separate car folders with textures in them.

This image shows the placement of the decal shapes on my 100-ton triple hopper:



And this is the corresponding decal sheet:



I set my decals 0.25" above the surface of the car - this seems to provide a good compromise between minimizing the appearance of floating above the surface and minimizing z-buffer issues at most viewing distances.

[griggs]

I've found the greatest source of used space on my computer for OpenRails to come from the overhead accrued by many of the files on my hard drive. Often its the routes that I have that take up the most space, being able to store them in uncompressed zip files so that the game can still read what is in them without having to do any decompressing would make a huge difference, though I think this was something talked about with the additions of a "virtual filesystem." Have any developments been made on this yet? I believe it was something that was to come with 1.5 but I think it might have been delayed for a future update.

[engmod]

>Have any developments been made on this yet?

I doubt it as it will effect older system too much.
Older system have much lower i/o speed and looking through large zip files will take much longer that looking for individual files.

[eric from trainsim]

I'm also a big decal user... my fleet of 30+ Metra F40s is a single SLI model with 30 FAs that have the light boards and numbers/names on the individual FAs. Did the same for my UPRR business car fleet on the freeware BLW cars.
I've carried that into other areas like CTC boxes at control points. Much easier to make tweaks to the shape details for the base model...

[cjakeman]

A useful tool is the Auslogics free duplicate file finder

It's very fast and has a neat interface with a preview to help you remove duplicates (but keep the last version). It will find activities that you forgot about long ago.

[Jovet]

Another big thing to think about with MSTS and Open Rails is hard drive cluster size.

A cluster is the base unit of allocation on a file system. When a file is created, space for it is allocated in multiples of that cluster size. MSTS/OR use many tiny files, yet those tiny files can still consume an entire 4K cluster. (*On NTFS drives, if the file data will fit inside the Master File Table entry for the file, it will be stored there and regular data space will NOT be allocated/wasted.) For this reason, it can be advantageous to use a lower cluster size than the usual 4096 byte default. Unfortunately, this is something only to think about when setting up your computer or formatting a new hard drive. It can't be changed without wiping the drive's data and reformatting it.

[eric from trainsim]

Honestly... local storage and cloud backup have become so cheap that I stopped worrying about it.

I can't fill a 1Tb drive if I tried.

[Genma Saotome]

I use a fair number of symbolic links. I started that to save on disk space but that's not much of a problem anymore. I continue to use those links to avoid the duplication of files. For example, I have all of my sim directories grouped by region and a date range. A route may appear in 3 of those date ranges. The symbolic link means only the disk space for one is used and if I were to edit that route the changes appear in all three locations. The \trains folder is unique to each of the date ranges. I also link \global to all locations and for the most commonly used rolling stock I've moved/edited the files into one folder (e.g., XM_SP_B-50-15) and linked that to the appropriate date ranges.

For good measure I have a daily .bat file in each region = date range that writes a file showing the links and that file is backed up daily. It's not in dos command format but it can be edited quickly to become one so if I lose a disk I can rebuild with a minimum of effort.