Hi All,For those of you following the "filemon lookup thing" I am making a list of all files that I have moved. Installed FSX on my wifes rig for testing, and going through the whole thing over again. (I new I should have listed them the first time)Question for those who have NOT moved files so FSX could find them on the first try, (topic here: http://forums.avsim.net/dcboard.php?az=sho...77060&mode=full )"How many of you have FSX installed on a seperate PHYSICAL drive, than your OS. And if so, are you exerienceing stutters?"The reason I ask is that I am questioning if part of the reason I no longer have studders (I used too), is simply because I eliminated the repeated calls for those textures that used to "have to" read the filelist.dat "everytime" they were called for to find the thier location within FSX. These dat files are located in the C:/Docs&Settings/All Users/Application Data/MS/FSX/Sceneryindexes folder.eg:http://forums.avsim.net/user_files/168692.jpgFor me, thats a totally seperate physical drive. Whether these texture calls are on a secondary thread or not, your still jumping drives to read the data every time a new one of those objects is loaded.Anyways not trying to start a whole new thing on this, just curious about the question I posed and to see if there is a correlation between the two.Garett

I have never checked file access with filemon, but can report that after moving (reinstalling) FSX from a separate drive to the main (XP) drive, stutters disappeared. Your research may be explaining the reason, thank you.==Marten:Weber==P-D920 3.3MHz 2GB RAM WinXP ATI X1900+1024MB 2xSATA250 2xVIEWSONIC 19"author of http://library.avsim.net/esearch.php?FileName=bbgrfs.zipscreens on http://s141.photobucket.com/albums/r45/abulaafia/

>>I have never checked file access with filemon, but can report>that after moving (reinstalling) FSX from a separate drive to>the main (XP) drive, stutters disappeared. Your research may>be explaining the reason, thank you.>Hey, that's really interesting. I have never heard that before.RhettAMD 3700+ (@2310 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2 GB Corsair XMS 2.5-3-3-8 (1T), WD 250 gig 7200 rpm SATA2, CoolerMaster Praetorian case

One would think MS would have an answer on this sort of thing. After all, they wrote the thing. It seems like when I said install FSX to drive G, I meant install all of FSX to drive G, not just parts of it.Honestly, I am only getting stutters when Active Sky reloads weather. Nonetheless, I have no idea why they continue to write FS this way. FS9 had similar issues where it would continuously call for textures that were located on the other side of the Earth from where I was flying. There were so many of the issues that I just quit looking at filemon because it was too frustrating.

Well, if you said to install all of FSX to drive G:, then the install program did, BUT, files generated by the program at runtime are placed in the user's Application Data subdir, which lives under "documents and settingsUSERNAME...". This is to support LUA/UAC restrictions (ie apps running under "normal" (ie not admin) user rights can't write to all locations on the disk (this is designed to keep malware from modifying your system/program files) and this behavior is required to get the Games for Windows and Vista logo certifications).As to why FSX looks for files in various different places is because devs (both internal and external) asked for more flexibility in where textures had to go (including allowing fallback directories for placing more generic textures while still having a directory for single/limited use textures, etc). So the app has to go through its list of "valid" subdirs until it finds the file in question. Without this, quite a few textures would need to be duplicated in various texture dirs and the disk requirements would go up several fold (like we don't use up enough disk space already :-> ).

>As to why FSX looks for files in various different places is>because devs (both internal and external) asked for more>flexibility in where textures had to go (including allowing>fallback directories for placing more generic textures while>still having a directory for single/limited use textures,>etc). So the app has to go through its list of "valid">subdirs until it finds the file in question. Without this,>quite a few textures would need to be duplicated in various>texture dirs and the disk requirements would go up several>fold (like we don't use up enough disk space already :-> ).>>I think it would be worth it to sacrifice disk space, for a reduction in file searches.I've done some scenery design in the past and I *still* would rather sacrifice disk space for a reduction in file searches. Performance is king in a sim.Or, at least give the end-user the ability to control this searching behavior, via cfg or some other means.Rambling thoughts...RhettAMD 3700+ (@2310 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2 GB Corsair XMS 2.5-3-3-8 (1T), WD 250 gig 7200 rpm SATA2, CoolerMaster Praetorian case

Much of the activity on the C: drive (or OS drive) is a requirement of and defined by the operating system, not FS.An ability to move the users profile from the system drive is something many application developers want to see happen.

Appreciate the feedback, thanks.I understand the fallbacks, but it's the locations and inconsitancy that FSX looks for them that has me curious. The two airport ground textures noticed in the pic (there's alot more than just those that do this), take "that" path to find the bmp. It seems as if those are not using the "fallback path".I say this because if you look at BLDB2 and many others for the building textures you'll see the differnece. When they are looking for a texture, if DDS is not found, they call for the BMP version then go to the root FSX texture folder next and repeat the call (dds, then if unsucesfull - bmp). They dont go looking in sceneryindexes on the root drive and a few other places etc, before checking the root texture folder.Which really has me confused, because the simobjects "have" fallback texture paths in them - but they follow the path (but worse) than the OP. Eg: check out Globalenv_ac_chrome.dds.Just trying to get more of an understanding for the reason why. I know what moving them did for me, thus the question. You know the saying about a little bit of knowledge is dangerous - well then I should have been locked up a long time ago ... ;)Regards'Garett