DickI always thought it was interesting that MS called the xml file 'DEFAULT.xml' as if they were expecting xml addons to be developed by them or 3rd parties, or both. It's also the only file in that folder.Or perhaps they had other autogen libraries that they were testing but the subsequent ones performed worse than the one that was released, so they went with that one and called it 'default'.XML was also prominently mentioned by MS in one of their press releases for their next Operating System.

Amen!I do fully agree in what you have stated Jimmi!And those, who insist, they are not effected by this autogen bug, I ask to execute the following short and simple test:- set AI traffic to 0 (zero)- set the fps slider to unlimited- enable all types of autogen and set it to extremely dense- enable the fps display on your screen (by hitting "shift z" twice)- Take off at the default KSEA, heading north- climb to 2500 ft- fly north towards Paine Field- a few miles after you have passed Seattle downtown (thats's where all the skysrapers are :-) ) look back to where you just came from by using "shift 2" (2 on the num pad) and watch the fps displayed. You will recognize an extreme difference of fps between forward view and backward view (not caused by the diwntown scenery). On my system I get betweeen 30 and 50 fps looking forwards but only 13 looking back, (getting even less the further I fly!). Now after the CTD problem (which luckily has not effected me so far) has been solved I really do hope, that this autogen bug problem will be next.Wolfgang

Hi I guess I'm with you on this, I think the autogen is pretty cool but as I tend do mostly vfr with photorealistic scenery of the UK and mostly Wales then its not really a problem.Even so I did the Nvidia fix thing then everybody was buzzing about last week and my fps seem well solid at 28/30 fps. My systems is locked at 30fps with Traffic at 69% flying in and out of heathrow with no slowdown whatsoever.oops wandered off the subject there for a moment. Autogen is cool but if this bug exists, and so many have reported it I can only assume it does exist. then MS should get it sorted.Wycliffe

When trying Wolfgang's experiment, also try this:When you have flown north for a while, looked back and noted the framerate, do this:Go to settings, set Autogen to None and click OK. Then go to settings again, set Autogen to Extremely Dense and click OK. Now framerate will be much higher when looking back because the "persistent" autogen is now cleared.After some more tweaking of my joystick assignements, I managed to get a joystick button to do just that (instead of chaning season, which also works for clearing autogen). So now I can just hit a joystick button whenever framerate starts going down. FS will then pause for a few seconds while reloading autogen, then resume the flight.After doing this and trying some flights, I noticed just how often this problem affects framerate without the user knowing it. It doesn't always kill your framerate like it does when you try to demonstrate the problem on purpose.Sometimes you'll be getting maybe 15-18 FPS. It's still playable so you will never know something is wrong, but after the autogen refresh you get over 30 FPS.While this problem may not destroy the sim experience, I think almost everyone who doesn't know/care about or notice the problem is getting lower framerates than what should be possible with their system.I know you can just delete the xml file and be done with it but that feels pretty stupid since one of the big improvements in FS2004 is the autogen.I'm now making it a habiit to refresh autogen as soon as I need to make a turn back towards the backlog of accumulated autogen, especially if I'm landing and need the best framerate possible.Before landing checklist:Landing gear - down and lockedFlaps - Fully extendedAutogen - Reset :-lol

Jimmi, I was about to reply to Wolfgang to add the next step - to do a refresh - but I saw you had already done it. That's an important point. After changing the autogen setting twice you have precisely the same autogen density - but the frame rate can double after doing this. I enjoy using FS2004 very much and this problem doesn't detract from my enjoyment too much - but I'd still very much like to see it fixed. My guess is that the person who set up the affected libraries made a simple mistake and it wasn't spotted by the testers. Microsoft must be well aware of the problem and we can only hope they'll give us a solution in an SDK or a patch. However, I would respectfully remind them that FS2004 has been out for five months now.... Best regards, Chris

Could it be that the programmers programmed FS9 to give a pilots view, forward and side to side, over the current area, which is constantly changing, and didn't really factor in rear-view mirror or driving in reverse as important and that when we use alternate viewing from spot-plane to "look" at where we've been or slew backward that the sim is still doing what it should be doing by scrolling in the scenery just ahead and to each side and at the same time having to scroll in the constantly changing areas we are looking at. The sim would have to constantly keep reading ahead of the current position, altitude and heading of the aircraft, or viewpoint, and preloading the scenery to match. If you keep constantly changing your viewpoint you should expect a drop in framerates. Try hitting CTRL-W to scroll through all of your AI aircraft in the area and notice the drop off in scenery quality. I wouldn't call this a BUG. It would be nice to run the sim on a mainframe and have instant access to any viewpoint with full scenery, weather etc. but I think that FS9 does a good job of producing a fairly realistic simulation of flying an aircraft which works pretty well on the average system. Tony

Doubtful. It does appear to be a big bug. It isn't present in the "standard" Autogen of FS2004 (non-XML), and it wasn't present in the FS2002 version. The enhanced Autogen (fast food stands, silos and barns, electric substations, some highway signs, etc. etc.) is the only portion of Autogen causing the problem - worked around by deleting or renaming the autogen.xml file.The sim already has to read ahead and render the scenery - Autogen pops in at appx 5 miles. The bug exists because Autogen isn't being popped OUT after 5 miles. It is remaining in the sim's "active" scenery area, and that's causing the problem.If it wasn't a bug, we'd see Autogen popping in at 30+ miles. It makes sense that CTRL-W leads you to less detailed scenery. CTRL-W loads up different areas of scenery - just as slewing at a high rate of speed will bring you to muddy textures, so too will CTRL-W'ing out of your currently active area. Wait a few seconds and it will draw in normal - BUT that will leave YOUR aircraft's area to be muddy. This is by design. FS2004 draws detailed scenery around the active camera point only, and the autogen bug comes from the fact that it LEAVES highly detailed scenery in the simspace well outside this circle-of-detail. I have little personal doubt that this is not a "feature" of the sim, and is an overlooked bug.-Greg

Hi Jimmy, You could try to check in the terrain.cfg, the autogen area value number, maybe you could change some value from default, I don't know if this will works.// autogen format// [Autogen.id.type.variant]id = the id of the object specified in the "autogen" tag for the vector data// type = an extra identifier that allows mulitple autogenned types to be associated// with a single tag. For example an autogen type 0 could have a specifier// of type 0 for medians and a type 1 for billboards. Both will be applied to// any vector data that specifies autogen=0.// variant = this is a variant that may be applied to the autogen of vector data.// For each id/type pair multiple variants may exist. On any given segment// that applies an id/type autogen specification a single variant will be// chosen.// AutoObject - guid of the primary object to use// AutoObjectEnd - guid of any endpoint object to use// ObjectSize - length to apply between objects (in meters)// ObjectEndSize - length of the end segments (in meters)// ExlusionWidth - width to exlude autogen around this type// this will exclude along the entire line, // not just where an object is actually placed.// ClipData - BOOL flag that determines whether the object// should be clipped between cells. Should be // 0 for anything with end objects (bridges)// Offset - This is an offset to apply from the vector line// can be used to place object beside a road like// billboards.// Density - This is the percentage of objects to place. If the// number is 50, 50% of all objects will be placed.// This is a repeatably random 50%. This number is // further modified by the autogen density setting.// NOTE: if 100 is set here, then all objects will be// placed and the number will not be modified by the// autogen density setting// MinDensity - This setting determines the min percentage of autogen// that must be present for this object to appear.ThanksChris Willis[link:fsw.simflight.com/FSWMenuFsSim.html]Clouds And Addons For MsFs

I too feel certain that this was not intentional. There is no reason why they would want to make Autogen behave this way. It has no advantages and causes huge framerate problems. You can't make out autogen objects at 30 miles anyway, and if they wanted such insane visibility distance they would have changed both the "on" and the "off" distances. Also, like Greg points out, only the new autogen objects in FS2004 behave this way while the generic houses and trees (thankfully) behave correctly. Imagine the framerate if all autogen had a visibility distance of almost 30 miles - you'd need a 10 GHz machine just for the autogen - and the scene would look identical to one that works fine on a 2.5 GHz CPU.For example if I have been flying at 170 degrees for the entire flight and then have to land on something like Rwy 34 because of the winds, framerate is lowered significantly on final. Just when you need every FPS you can get.Note that some new autogen objects such as telephone poles also do have a slightly higher "on" distance than normal autogen objects, of around 7 miles vs 5 miles for normal autogen. That was probably on purpose. However, the "off" distance of 27 miles must be a mistake that no beta testers noticed. Probably some error by a scenery programmer or designer that never got caught by beta testers. Should be simple enough to fix with a patch if Microsoft would just care about it. Do they even know about it?