>Whilst this problem is being reported as an autogen problem,>I happen to believe it is a problem with any object called>from the FS9 object library. I spent a fair amount of time>performing tests using my own scenery files created using>default objects in the FS9 library. As an example of one of>tests I did, I created a series of objects with a view>distance of 8 kilometers. When I flew towards the objects,>they (correctly) appeared when I was 8 kilometers from them>and not before. However, after passing them they did not>disappear after I was 8 kilometers past them. They just stayed>stuck in view - to the limit I had set for visibility. As far>as I am concerned, any object should have a specific view>distance and if you are further than that distance then the>object should not display.That's an interesting find John. Looks like there is really a kind of a bug. I'm not an scenery expert, but this shouldn't be too hard to be fixed by MS or by one of the talented FS enthusiats, should it? Wolfgang

"Whilst this problem is being reported as an autogen problem, I happen to believe it is a problem with any object called from the FS9 object library."That is possible. If you read the default.xml file in notepad, you'll see the tags object data for every object. The objects in the default.xml file appear to be library objects scattered over the terrain. Normal autogen is not treated this way. The autogen (both normal, and the one defined in the xml) DOES dissapear from view when you get some distance from it, but it's possible it's still being "there", still using memory and CPU power, only it's not visible.You can prove that FS DOES release autogen, but at a very big distance:-Start over a dense area near the coast-Slew/Fly to let autogen accumulate-Slew/Fly towards the coast-Slew backwards over the sea, away from the scenery but looking towards it-After quite a while, FPS will suddenly "snap" from 10-15 FPS to 4 times of that or more as autogen is released and only the ocean and distance textures are kept-If you slew back to the scenery area, FPS will be normal again until you let autogen accumulate once again-The distance at which autogen defined in the xml (and possibly normal library objects) are released is too great. It should be not much greater than the actual distance at which the autogen objects dissapear from viewIf this also affects normal library objects, we will get even more problems as developers start putting out detailed airport and scenery with lots of library objects. Imagine having lots of detailed airports in a small area. If the objects don't dissapear correctly as you fly from one airport to another, framerate will be extremely low.Gridley - This does not sound quite like the same problem. I experience the stutters at higher altitudes. It's also not a 1 second pause, it's consitent low FPS after flying over a dense autogen area."Their definition of critical will be constant crashes not just framerate slowdowns, they will expect people to throw hardware at it to aleviate the problem.""I am betting there will be no patch because the flight sim community doesn't have organisation to offer any clout. Look at all the reviews of FS2004 saying how wonderful it is (and it is in many respects, pity it can get hard to enjoy it sometimes), that whats important to MS, image, not things that detract from the experience of hard core flyers..."I think it's possible that MS will release a patch for this, if they are made aware of how many people experience this problem. I was thinknig, if AVSim, Flightsim.com and the other big sim sites emailed MS, they would take notice. Also, I wonder what the reactions are among normal users who bought FS? Did they just think "Oh well guess my computer is not powerful enough" and played another game? Of course it's a bit different for flightsim enthusiasts when these kind of problems occour, because we're addicted to FS and can't just go and play something else. Flight Unlimited III and Fly II are becomming a bit outdated.By the time hardware is powerful enough to handle all the extra workload from the problematic autogen (and possibly any library object), FS2006 will already be out;If I let autogen accumulate (slewing or flying a long distance, then turning around 180 degrees), the framerate over Rural Medium/Rural Large scenery drops to about 8. That's on a 2.2 GHz Athlon. The latest P4 3.2 maybe would get 12 with full accumulation. I'm guessing a brand new Athlon64 would manage 13-15 at most (depending on how much the FS engine benefits from the new architecture). That means we will need something in the region of a 5 GHz P4 to get decent framerate with fully accumulated autogen scenery, and that's with just MS default scenery...Considering deleting the default.xml file and turning off vector objects gives me 4-5 times the framerate (well over 30 FPS instead of 8), it's quite a serious problem. I have removed all but the most essential entries from the default.xml file, but I was surprised to still see a 50% drop (15.6 FPS vs 30+). I mean, I only kept a handful of the objects.

Hi Jimmi,Well I think this problem is one that can't really be solved by the user and I'm not even sure the scenery or BGL compiler SDK will give us any clue as to what is happening. Then again I wouldn't be surprised if in the SDK, the characteristic of objects being retained in view far beyond their specified view distance is described as normal behaviour. Perhaps this was done on purpose, with MS deciding that it was better to hold all the information relating to an object for an extraordinary length of time than a shorter length of time where it might have to be loaded repeatedly. If they did make that decision I don't really agree with it, because the loading part causes much less of a performance hit than holding onto it.There are some other wierd scenery problems I've noticed as well. With one test I did - a 30 mile long string of power pylons spaced at 1 nm intervals, they wouldn't even appear correctly at all, unless I had the autogen turned on. And this was a scenery file - it had nothing to do with autogen. Other people as well as myself have also noticed that objects appear or disappear simply depending on whether you are in slew mode or not.I have no doubt at all that something is wrong with the types of behaviour I've described. It would be nice to have a fix for them, because the problems effect the performance, scenery rendering and the design of 3rd party scenery. I have been reluctant to start any scenery projects because I have no guarantee my objects will necessarily show up, or if they do, they might cause performance problems.

TOWE_VIWEW:Condsider what goes on here...It retains scenery information for a long time while your flying to the destination as it maintains the departure airport as its point of view for the whiole flight.Could this play a part in maintaining sccenery info for too long?Any way of disabling tower view.Maybe some ecxperimenting with relocating the towere forward to the flight path>?Allen

DSosorry aboutht he typoI broke my wrist this summer and am onlyt recovering nowIts TOWER VIEWAllen

Hi all.The original thread pointed to ends on this note:"It looks like my header changes were a total waste of time!It diffinite now compressed BGLs will make some PCs stutter. This is certainly a Microsoft problem. and I was only following correct precedures in compressing these files. So the update on friday will invlove uncompresing all BGLs, I'll keep the smaller headers as well as Im not spending another day changeing them back and in theory smaller header should be smarter thing to do anyway"This has nothing to do with the scenery design, but with the use of compressed BGLs.The format of the new FS2004 default object placement and object library BGLs are a mystery. It is a completely new format, and will probably remain a mystery unbtil we are able to decipher the upcoming Scenery SDK.Dick

I have to correct mayself and to appologize for any misleading. Yesterday I posted, that reducing autogen from extremly dense to very dense had solved the progreesing performance loss for me. That's what I thought yesterday, but it was not correct! I did some flying over high density autogen scenery last night and the problem was there again, even with autogen st to very dense. Arrrgh!So I will try Jimmy's solution tonight.Wolfgang

Ouch!I really wish MS would fix this mess. It's such a beautiful sim with so many improvements over FS2002, but at this rate, I'll have to go back to FS2002...Will be interesting to see what happens as more 3rd party scenery is devloped.Maybe the problem with library objects being tied to Autogen settings happens because the default.xml autogen objects are actually library objects, so MS decided to just tie the two together in the display settings?

In the same folder as the fs9.cfg file is a "scenery cache" folder, which is allways empty. If you delete it, it will automatically be regenerated when you do your next flight. What function does this folder have? Is it only used, if you do not run a full install for storing the scenery files from the CD?Can this folder create a performance slow down, similar to empty, unecessary texture folders e.g. in landclass files?Wolfgang

What's so frustrating is that FS2004 DOES perform better than FS2002, except for this behaviour with 3D objects. FS2004 seems much better at handling textures (less blurries) and it's much faster when dealing with detailed mesh scenery.

Hi JimmiG.I think your fix ( renaming or deleting the XML file ) is a GREAT discovery. I don't know if this is a bug or simply a design flaw, but you have definitely found the solution.I agree there is something not quite right here. I'm starting to suspect it isn't in the nature of placing the library objects as autogen, but that the problem lies in the library BGL itself.It might be as simple as the BGL compression. Maybe FS2004 doesn't handle BGL compression correctly.Or this might be a problem with the object designs themselves... or the new Library BGL structure.Or maybe this is just too many polygons for the CPU to handle ( where's that 5 Ghz CPU? ).Until an SDK is released that will help us decode the default library, and some brave soul attempts a decompiler, we'll remain in the dark.But for now, getting rid of the default.xml file seems to be the best solution.I wouldn't give up FS2004 because of this issue. I got rid of the XML file, and I really don't miss the extra autogen. In a year or so, when I upgrade to that elusive 5 Ghz CPU, I'll add the XML file back in.Again, thanks for the effort you took to find the cure for this drastic FPS drop.Dick

>In the same folder as the fs9.cfg file is a "scenery cache">folder, which is allways empty. If you delete it, it will>automatically be regenerated when you do your next flight.>What function does this folder have? Is it only used, if you>do not run a full install for storing the scenery files from>the CD?>Can this folder create a performance slow down, similar to>empty, unecessary texture folders e.g. in landclass files?>>WolfgangYes, it should only be need for partial installs in order to cache scenery from the CD. If all the scenery is already on the HD, then it doesn't get used. The folder itself wouldn't cause slowdowns, but caching scenery from the CD obviously would.

"I think one serious issue is that for some odd reason FS02 or 04 DOES NOT utilize the full complement of available physical RAM. "This is not so strange.FS would first load what you can currently see into RAM. After that is done, and if there's enough RAM free it will probably begin to cache things that you are likely to see later such as the rear/sideview VC textures (if you're currently looking forward), scenery textures, ATC voice messages, AI high LOD models etc. However, there's probably a limit to how much it will cache, since it would be pointless to keep a whole continent-worth of scenery in RAM.You will still benefit for more RAM, because it will be used as disk-cache by FS.This means that when loading up a new flight for the first time, it will load entirely from disk. However, the next time you start a new flight, much of the data is still in RAM and loaded from there.The memory used for disk cache is not shown in the WinXP/2k task manager, and it's automatically released if other programs need the RAM. XP/2k have very efficent disk cache, while Win9x/ME requires some tweaking (cachemon) to benefit from lots of RAM.I don't recommend disabling the swap file in WinXP/2K. Set it to a fixed size (min and max size to the same value) and set it to about 512MB to 768MB for both min and max.