Message Areas - "Common folder"

Train-Sim.Com Message Areas

"Common folder"

Email this topic to a friend
Printer-friendly version of this topic
Bookmark this topic (Registered users only)
Previous Topic | Next Topic Conferences MSTS Route Design (Protected) Original message
yellowdog (36 posts)
Jan-31-02, 09:24 AM (EST) "Common folder" I have only minimally worked on the route design aspect of this game, but I've been working somewhat in locomotive painting and *.eng files (mostly implementing others' products). If you work with the locos at all, you know that one of the problems with the loco folders is that they each have a separate "Sound" folder in them. This presents a storage problem b/c each "Sound" folder could contain the exact same files. For instance, let's say I'm going to model the CRR in the early 70s and want to have a complete CRR SD40 roster available to run. That means I'm going to have to have about 25 different folders (one for each loco), and each one will contain a "Sound" folder, at around 1-2 megs each. The sound folders will be exactly alike. However, it is commonly known that you can create a "Common Sound" folder and tell MSTS to look for the sounds in that folder via the *.eng file. Now you just have one folder for those 25 locos (and any other loco that will also use those sounds), and you have saved HDD space. The question is, can you do this, in any way, with routes? Can you create a "Common Folder" and modify a file (similar to the *.eng file) related to routes that will point MSTS towards that common folder? I have heard others say this is impossible (and have seen posts in the forum to the like), but I hoped that since it was possible with locos it would be possible with routes, too. Even if it could only be done with a small portion of route elements, it could potentially drastically reduce storage requirements. Like I said, I haven't worked with the route editor enough to know, but "common sense" tells me if you can do it with locos, you can do it with routes, even if you have to modify a file someplace. I realize, however, that we are dealing with MS- -a company that produces good programs, but often does not seem to operate via common sense. . . I also realize that I'm not much of a "hacker" but I hoped others out there with programming skills might be able to track this down. I guess it's possible that this has already been done, and I'm beating a dead horse; I'm just too much of an optimist at this point to think it can't be done. Alert Edit | Reply | Reply With Quote | Top
Table of Contents

Subject Author Message Date ID RE: Common folder lirc201 Jan-31-02 1 RE: Common folder JohnCS Jan-31-02 2 RE: Common folder sniper297 Jan-31-02 3 RE: Common folder oboe Feb-01-02 4 RE: Common folder sniper297 Feb-02-02 5 RE: Common folder RonA Feb-02-02 6 RE: Common folder oboe Feb-02-02 7 RE: Common folder landnrailroader Feb-02-02 8 RE: Common folder sniper297 Feb-02-02 9

Lobby | Topics | Previous Topic | Next Topic
Messages in this topic
lirc201 (48 posts)
Jan-31-02, 09:44 AM (EST) 1. "RE: Common folder" What you are talking about is being worked on. The NALW folks currently use a common.cab and common.sound folders when installing their cab views (see the gp7 cab). Also the program ConBuilder will allow you to alias your engines to say maybe the default gp38 or other cabs that you have installed.I believe more work is need on this topic including one program that can manage this aspect of the simulation.Brian LaVelle
Louisville and Indiana 70 of 106 miles done!
Conrail Ohio in development
http://belcommunications.net/msts Remove | Alert Edit | Reply | Reply With Quote | Top
JohnCS (274 posts)
Jan-31-02, 11:04 AM (EST) 2. "RE: Common folder" Others have demonstrated that there is no file aliasing in the routes folder. I understand that Route Control effectively accomplishes this however through file swapping/archiving. Remove | Alert Edit | Reply | Reply With Quote | Top
sniper297 (1476 posts)
Jan-31-02, 12:27 PM (EST) 3. "RE: Common folder" The probable cause for the problem is that the sim was shipped out in an unfinished state to meet a deadline. There's no easy solution for it, since each texture in the sim does not have a unique file name. Using Acleantrack1.ace (ballast and ties) as one example, has 4 different regular textures, plus the snow covered textures. The shape file for the track calls for Acleantrack1.ace, and which texture the track gets covered with depends on which one is in the texture folder for that route. If you drive in winter, the shape file does not know or care about that, but since the game redirects the calls from the shape files to the \textures\winter folder, it loads the same filename from the \winter folder, and uses the winter textures. Another example in USA1, Aberdeen Station. AberdeenStation.ace is 171kb for the regular texture, AberdeenStation.ace is 171kb for the snow texture. You can still tell them apart when they're out of the proper subfolders, because one is 5/07/01 7:37PM, the other is 5/07/01 7:38PM. Trying to copy both into the same folder would result in one overwriting the other, since you can't have two files with the same name in one folder. AberdeenStation.ace in the \Night folder is 340kb, but the same problem, it needs a unique file name to be in the same folder, and the shape file won't do that. Vegetation is the most notorious, many have 8 different textures per region, and each region is a different color, for a total of 24 different possible textures for one tree shape.
I'm no programmer either, but it seems to me that a better way to do this would have been to have a global textures folder with a bunch of regional and seasonal subfolders, with the shape files either given a path to the correct region, or have a master DAT file in each route that would point the shape file to the correct texture. Or preferably smarter shape files that would have multiple choices for textures, so that each texture could have a unique name instead of using the same name and keeping them sorted out by having them in different subdirectories. Whatever they do, they couldn't possibly make it any slower and clumsier either in loading or running, so any solution to eliminate all the duplicates couldn't hurt. Remove | Alert Edit | Reply | Reply With Quote | Top
oboe (16 posts)
Feb-01-02, 10:33 PM (EST) 4. "RE: Common folder" If all of the shape and texture files were shared by all of the routes, there would have to be a central registry kept for all of the filenames used for all of the shapes, textures, etc. It's not much of a problem now, but a couple of years down the road with hundreds or thousands of people creating new buildings, textures, engines, cars, etc, etc, It would only be a matter of time before your favorite mainline station turned into a fire hydrant after an innocent download. The current practice of storage within the route prevents that to some degree, but you are certainly right about the HD memory hit, and programs like ALL-STUFF ( Which is a great routine ), could wreak havoc on other routes without some naming standards. I think that I saw a post about file naming standards earlier, and It would probably be a real good idea for some of the people from the different forums to start a "NMRA" of Train-Sims. A standard needs to be created for some kind of a logical filename structure for everything in the sim. A filename registry would probably also be a real good idea. Anyone volunteer ?? oboe ( Hey ... we could really make this a complicated structure with lots of conflicting rules so it could be just like the Route Editor. ) Remove | Alert Edit | Reply | Reply With Quote | Top
sniper297 (1476 posts)
Feb-02-02, 01:46 AM (EST) 5. "RE: Common folder" That's actually my point, if there were an truly global directory and each texture had a unique filename, Allstuff, Ezstuff, and all that stuff would be totally unnecessary. The idea behind Allstuff and it's predecessors, combined.ref and ALL_OBJECTS.REF, is to have a selection of objects for building any kind of route you want. If you use only the ref file and the shapes and textures from USA1, you will have a much smaller route size, but then you are limited to building a route that looks very similar to the NorthEast Corridor. The one thing that would help tremendously without a total rewrite of the program to access objects from a global folder would be for someone to come up with a painless route developer's tool that would automatically write a batch file, or preferably an executable, that would copy only the shapes and textures actually used in the route. "Route Buddy" was supposed to do that, but nobody ever got it to actually work. Many others have come up with space saving schemes that either failed miserably or never appeared. The only one that shows promise is the guy writing VB scripts for checking ref files, and he may come up with something workable in the future.
The key to that is it has to work on every system, and has to be failsafe and idiot proof. The majority of the routes that everyone has trouble installing are based on one of the space saving schemes, and the error messages from all the missing files make people give up in disgust and either delete the route or run one of my Ezstuff.bat files on it to get it to work. And of course that fattens the route up over 450 megs, but a 500 meg route that runs is better than a 200 meg route that runs only to the send/don't send screen.
Port Ogden & Northern version 4 is only 277 megs fully installed, and if you loof at instalpo4.bat you'll see why. I cut all the lines out of the batch file to copy sounds and terrtex files from all the routes, and used only the sounds from USA2, and a couple of terrtex files from USA2. This really doesn't take that much extra work, I'm using some more of the default terrain textures for PO&N5, but I'm keeping track of which ones so I don't have to copy 126 megabytes of terrtex files that I don't use. 150 megs or so could be saved on each route based on Ezstuff3 just by editing the batch file according to the readme. Could I make PO&N even smaller? Sure, if I wanted to stop creating and spend all my time writing a six page batch file. I've never used Baltimore, Philadelphia, or Washington stations in the route, yet the textures for all three of those stations are in there, along with many more unused textures. 239 megabytes of textures, to be precise. Trying to keep track of every single object used from USA1 and adding each one individually to a batch file would be a mind boggling chore, and this is, after all, a hobby, not a job. Adding some lines to delete the largest unused textures would be easier, but unless that could be made failsafe it wouldn't work for general distribution, cuz you know some dope would paste it into the wrong route and delete the original source.
I still think the most workable solution would be for somebody who knows something about programming to make a patch that would put all the textures into \global, giving each a unique name, and leave the shape files to be installed into each route. The shape files only take up 11 megs, so they're not the problem, at 239 megabytes the textures are. And the shape files could be written so that tree01.s from Japan1 would path to \global\japan\textures, and the tree01.s from Europe2 would go to \global\europe\textures if you wanted to use two different colors for the different regions. Again, I'm no programmer, but to me KUJU's idea of trying to save space by using different regional textures for the same shape file was rather dumb, since the shape files aren't nearly as big to begin with. Remove | Alert Edit | Reply | Reply With Quote | Top
RonA (29 posts)
Feb-02-02, 10:27 AM (EST) 6. "RE: Common folder" Very interesting thread, guys.I think we have seen the prevailing mindset in programming these days. With HD space getting larger and cheaper by the day, programmers have long discovered that they don't have to write tight code, when fat, dumb, and happy code will do just as well. (Correction - publishers have forced programmers to think this way.) The people who this effects most is the hobbiest like the folks on these forums, who are then stuck trying to make sense out of something that makes very little sense.I relinquish the soapbox to the next person......
Ron A Remove | Alert Edit | Reply | Reply With Quote | Top
oboe (16 posts)
Feb-02-02, 01:23 PM (EST) 7. "RE: Common folder" I have started a new post on "File naming Standards" to try and help make this idea achievable. There is no way to have a common folder with the possibility of duplicate filenames having different shapes and textures in different routes. If we can get rid of that problem, then maybe at least the huge texture folder can be commonized.It would sure be nice if the "common folder" Idea could be achieved.oboe Remove | Alert Edit | Reply | Reply With Quote | Top
landnrailroader (154 posts)
Feb-02-02, 05:43 PM (EST) 8. "RE: Common folder" It would be nice if a Global Folder system were used. What is required though, is some script or program that you could run on a route's database to determine exactly what shapes and textures were actually used.Consider this: You create a route, (as I am doing) and when you are done, you have a route folder that contains 650MBT, more or less. Now, assuming that everyone can afford sufficient disk space to store a few of these, which is not unreasonable, especially if you have done a partial load of MSTS, and then beefed up your shape and texture folders with the contents of some previous load, you are still faced with the problem of sharing this new route with your buddies - i.e. all of us other guys. Well, folks, I only have a 56K link, and it would take a spell to download 600MBT or so at 56K - get the picture. Now, if I were going to share this thing, the first thing I would do now, is upload only the databases, world files, and tiles, that reduces it to about 200MBT or so. I would also make sure that I uploaded the goodies for anything I had acquired from the group, (i.e. the 3 bay coal mine for example), or that I had created myself, (i.e. better plate girder spans by way of TSM), and altogether, I could probably get it down to 300MBT or so - still an awful lot. We need a guideline as to just what is really required. Is it necessary to upload all of the *.raw files for example?J. H. Sullivan, P.E. (retired) Remove | Alert Edit | Reply | Reply With Quote | Top
sniper297 (1476 posts)
Feb-02-02, 07:41 PM (EST) 9. "RE: Common folder" LAST EDITED ON Feb-02-02 AT 07:53 PM (EST)Which REF file you using, Sully? If you're using one of my packages, see my above post about editing the batch file, or better yet the tips in RouteEditor.txt from Combstuf.zip. Again, about 240 megs of textures from all six routes, less than 12 megs of shape files. The big killer that's the easiest to fix is the \terrtex files, even people who go nuts with 80 different terrain textures for a single route don't need to copy all 126 megabytes of \terrtex from all six routes. And the sound folder can easily be reduced from 50 megs to 11 or so, since you're not likely to use all six sound region sources on the same route anyway. Take that 650 megs final install size down to 400 or so just by weeding out sounds and terrain textures you don't use, and you don't have to fool with the shapes and textures for the actual objects.
As for distribution, to make the zip size as small as possible, I quote from myself in RouteEditor.txt;"When your route is finished, before distribution, go through the error message section and change "myroute" and "Ezstuff3.bat" to the appropriate names for whatever your route's directory and batch file are named. You need to make at least one simple activity to get the route to be drivable in explore mode, be sure to include these for distribution. Delete the following folders; \envfiles \shapes \sounds \textures \terrtex. Do a tools, find in explorer (STARTING IN THE ROOT OF YOUR ROUTE) for *.BK , *E.RAW , and *N.RAW . Select all, delete all. Then zip the route up, delete the copy you zipped it from (you have been making backups as you've been creating this thing, right?) and test the extraction to make sure it works and is playable."All files ending with .bk are unnecessary since they're backups in case of problems, and if you are having problems with the route they should be fixed before thinking about packaging anyway. The *e.raw and *n.raw files are lighting and geometry for the sim, if the route is opened in the RE or run in the sim and those files are missing, they are automatically generated before starting the first time it's run.Custom objects are a different kettle of fish, I haven't added any yet, but if you look at PO&N4 in the installpo4.bat, you'll see that I had some custom textures I used, installed from a \custom folder I left in the route folder. Two ways of doing that, make a \custom folder in the route with \shapes and \textures subfolders, and add lines to the batch file to copy from there, or delete all the texture and shape files that everyone else already has on their MSTS, and paste the custom ones into the proper places without the default stuff before zipping. Note that I used a custom folder since I had to overwrite one of the default textures to change waterbot.ace for the coal mine, if you aren't overwriting a default texture it's not necessary to do it that way.I should add one more thing I've become more aware of since writing RouteEditor.txt, test your route from several starting points in winter at 00:00 to make sure you aren't missing snow or night textures for the add-on objects.As a suggestion, any route developer trying to figure this out, download PO&Nver4.zip from the file library routes section. When you run PortOgden4.exe, the self extractor, uncheck the box that automatically runs the batch files. Then you'll have the unzipped route (not fully installed or runable without stuffing it by clicking on Instllpo4.bat), and you can reverse engineer my packaging by examining the folder structure. You CAN get the zip incredibly smaller than 200 megs, even with custom objects.
Remove | Alert Edit | Reply | Reply With Quote | Top

Lock | Archive | Remove

Lobby | Topics | Previous Topic | Next Topic