Editing Default.xml question

[Ramasurinen 0]

Hi guys. I'd like to ask a question regarding the default.xml file. I'm afraid I'm a bit of a noob at working with scenery in fsx, but I'll describe my issue and what I'm trying to do as briefly as I can.The issue: Basically I think there's a serious bug in the autogen system, much as there was in fs9.0 before the 9.1 fix, a memory leak or somesuch.I use a track-ir exclusively when I fly and I've noticed a serious problem creeping up. If I start a flight with normal or heavy autogen, everything is fairly smooth for the first few seconds to a minute, and then as I continue to pan my view around over a city, the panning becomes more and more stuttery over the next 10 minutes or so until its almost unusable. FPS flying straight ahead though will be just fine, regardless of autogen density. It's only when I try to pan my view that everything falls apart. I've messed with texture_multi_bandwidth, max autogen config settings, you name it, no avail. Memory usage is stable all the time at 1.2 gb. I'm pretty sure I can rule it out as being a driver, track-ir, or any other hardware issue, because when I remove the default.xml file, its silky smooth *all* the time. I can fly for 10 hours over the densest city with max autogen, and it never drops below 30fps no matter how fast I crane my neck around. It's something to do with parsing that file. I've run filemon and completely cleaned up the texture misplacement nonsense FSX delivers out of the box and it shows nothing but "success" on every file read when I fly. There's a thread on that in the main fsx forum that's turning out to be pretty interesting btw.So, I tried Rhumba's default.xml file and that does improve things very slightly. The stutter is still there, but about half as bad as with the default one.So my question: What I'd like to do is remove everything from the default.xml file except for all the trees, as removing the xml file completely pretty much makes every city in the world look like San Jose, and that is hardly a good thing (sorry any Jose'rs, I lived there, it's ugly). :) However, as soon as I remove more than a few items from default.xml, I start losing autogen everywhere. Also the only "tree" listed for any region in a single poplar, so I have to assume that trees are embedded into the other guid's? I'm keeping the structure the same region wise, just removing classes. The SDK isn't very concise on what is editable in that file, so I'm a bit lost. In Rhumba's file every line is still there, just most of it is dummied out with guid's of 00000000 etc. I'd like to find a way to rip out all those lines completely, get that 5mb beast down to say a few hundred kb. Why oh why didn't they compile that thing into a binary spb?So, sorry that was long. If you've read this far, thanks very much! I could totally be off base on this, so if you think I'm nuts, please let me know. :)BTW, my system is no slouch, a core2duo 6600 at 3.1 ghz, 2 gigs, and a 512mb 7950.Cheers.

[rhumbaflappy 113]

Hi Haldir.I dummied the GUIDs because we can't remove any text lines from the xml. As soon as we do, the random autogen trees disappear.I suppose someone could make the thing an sbp file... but are you sure it's not track-ir? I don't use that, and I don't hve that problem.Dick

[Ramasurinen 0]

Thanks Dick, I thought that might be the case. Tried compiling it into an spb and it errors out, but then the file structure is quite different.And guaranteed it's not the track-ir. I get the same thing if I use the spacebar panning method, without the track-ir driver running (forgot to mention that).Myself, I think a lot of people have the problem, but are seeing it in different ways. There are several people who are experiencing a general slowdown in fps over time in the game, much like fs9 did. I'm one of those, but anyone using a track-ir will run across the problem a lot sooner as their heads are constantly on a swivel. I'm just making the sim work a little harder and its showing the bug within minutes instead of hours.Interestingly I think I found a "safe zone" where this problem doesn't crop up, Oslo in Norway. Have no idea why. Been flying around there for a few hours, both with and without default.xml and its just fine. Most other places, even in unpopulated parts of Norway it craps out again. So confused. :) I get the feeling that it's looking for something it can't find quite often and is using up some buffer somewhere, especially in cities. Guess I need to run filemon some more, see if I can track it down. I also noticed that there's an XP service occasionally accessing BMPs in the global texture folder, something outside FSX, which I find a bit strange. Can't tell which service it is, but I don't think it's simconnect. Odd.Anyway, cheers for the reply. :)

[rhumbaflappy 113]

Hi Haldir.If you find some causes/solutions, please let everyone know. :)Dick

[Guest cwright]

Haldir, I haven't really noticed this in FSX but in FS9 it was a big issue. I don't believe it was caused by a memory leak. It was caused by extremely large visibility distances in a whole class of autogen objects (mostly the objects in default.xml).When approaching one of these objects they 'switched on' at a reasonable distance. But they 'switched off' at enormous distances, perhaps at 30 or 50 miles. For example, it was possible to see a telephone pole 30 miles away!When flying and looking forward it's not a problem because those long-distance objects are behind you. But turn around or look back and - wham! - the frame rate plummets.I found that this error was improved in the FS9 patch but not eliminated. As most - if not all - of these long distance objects were in default.xml then a common fix was to get rid of this file.I don't know if this applies to FSX. Possibly not. I haven't noticed this problem in FSX but, then, I haven't gone looking for it either!Best regards, Chris