You can see in the last screenshow, above, a small portion of the normal sequence of events used by Train.exe, in this case it's reads files from \tiles before it reads files from \world; and once it starts reading from \world it goes world file at a time and reads all of the files from \shapes that are recorded in each world file. Not shown are the reads from \textures, but they're in the listing too.
Here's what you can do with all of this:
If there is an abort, you can use this data to track down what file -- program of data for the game -- was the last thing that the program attempted to use. It can be a bit tedious at first, but the basic steps are simple: you start at the bottom and use the Find function (or scroll) to work your way up to the last meaningful lines.
For instance, if you havn't a clue as to what's gone wrong, going to the end and then searching up for the name of the route is very likely going to put you at, or near, some lines that'll provide that clue.
The other day I made changes to 40-50 different shape files. And then RE would abort when I jumped into any one of several tiles. Rather than methodically check (or rollback all 40-60 files, I fired up Process Monitor, worked my way up the list, and found the name of the cul;pret file -- it was the last one the game tried to read before it blew up. I rebuilt that file, moved it into \shapes, ran RE again, and everything was fine. I imagine I saved myself quite a bit of time.
In a similar fashion, you can use the same techiques after installing bin (should it not want to run). Process Monitor will show you all of the program files it's using, in the order it's trying to use them. Again, the last one listed is likely the culpret.
Moving on... something else I've learned: by checking the list of files being opened I came to realize there are advantages to having a good sort of files in your world file. I now add slider values on all objects in congested tiles: 0 for all \global files and higher numbers for ordinary files in the routes \shapes directory.
I also preload commonly used shape and texture files in tiles that are typical scenario starting points. If any of those shapes or textures are found in adjacent tiles they are not read a second time when you move into those tiles as they're still in memory. A minor gain, but it works.
============
I hope some of you find this as useful as I have. It's been a real timesaver.
Edit
P.S. Please understand that Process Monitor is not going to give you a message that indicates "Here is your problem". It only gives a listing of what the program was actually doing. You're going to have to figure out from that listing what the problem most likely is -- and whatever it was, it is most likely going to be near the end (as in within a few hundred unfiltered lines) of the recorded lines for Train.exe... you know, where the abort occurs :lol:
This post has been edited by Genma Saotome: 08 December 2008 - 03:00 PM
Log In
Register Now!
Help
01_Procmon_Window.jpg (19.9K)
