>I am assuming that was aimed at me.Why? It is plainly clear to me (from quote and context) it was NOT aimed at you.Michael J.WinXP-Home SP2,AMD64 3500+,Abit AV8,Radeon X800Pro,36GB Raptor,1GB PC3200,Audigy 2, Omega 2.7.90 (4xAA 16xAF)

If it wasnt aimed at me then, I apoligise.(note to self, don't read forums at 7.30am ;))Dan.

>>>"The autogen bug never caused a memory leak.">>>He's smarter that the whole lot of us, or haven't you>learned>>that by now... Just ask him, he'll tell you so!:-ukliam >>I am assuming that was aimed at me.No, your assumption is false. It was aimed at the person I quoted, who's name begins with J... :-bang No harm done though, and your apology is gracefully accepted...Bill

" They should have asked Mr. "Know-it-All...""If you have any more personal attacks, flames, insults or other off-topic statements to make, please make them now. Once you and the other children are done, we can continue this discussion. I'm sorry if it bothers you that I know more than you do - you tend to not learn much if you spend all day at a message board insulting people.Microsoft's description of the problem is indeed baffling as by definition it is *not* a memory leak. You don't have to be "Mr. Know-it-All..." to realize that - all it takes is some basic knowledge of how a computer and its software works. If it's a memory leak, memory "leaks" - pagefile usage increases - system eventually runs out of memory and app crashes - typical example of a memory leak.This does *not* happen with FS9, patched or unpatched, unless you place a landclass bgl in a scenery subfolder together with a texture subfolder.Disagree? If so, why?Kurt - you should know that since I believe you are one of those who fully understands the bug.Keep in mind that those who wrote the readme may not be the same who actually wrote the FS scenery engine or the patch."I have never had this bug, before or after the patch, so the only thing I can imagine is that it is system specific."It's actually "area-specific" and "habbit specific". E.g. if I use 1x zoom, performance is still very good. If I use 0.5x there's a wider FOV, more objects on-screen and the framerate is very low. Some texture tiles contain more default.xml-objects than others as well. Mountain-fliers are 100% unaffected by the issue since the forest and rock tiles don't contain a single default.xml-objects. The rural and suburban tiles do contain quite a few so places like south of Portland OR (just an example) will be more problematic. Finally, if you never make a 180 turn, you will not notice the bug.

"Kurt - you should know that since I believe you are one of those who fully understands the bug.Keep in mind that those who wrote the readme may not be the same who actually wrote the FS scenery engine or the patch."Jimmi,My post wasn't meant as an attack or to disagree with you. I've never seen on my system any indication of a memory leak as regards the autogen issue either.I was just pointing out that MS mentions a memory leak, so it can make it confusing to people. Kurt M

Hi all :-)I can understand Alex.Wow, they released a patch but so what? Nearly every software-company offers updates and patches, so nothing special about that (can't understand why there is so much hype about the patch on avsim).I'm really happy with the patch because, unlike on other users PC's, the patch didn't make anything worse- yippeee. The new bridges are just a wonderfull addition, although some are not correctly placed, other users are already asking how to erase certain MS bridges to get the better freeware add-on bridges back and the number of bridges added is not really immense. The lacking of some bridges is a thing which finally had to be fixed.Concerning the other fixes, I can't comment on them, I'm just happy that I didn't need to re-install everything.In my point of view the only good thing is that MS did release a patch which is like a new philosophy regarding customer support. The patch itself is a bit ridiculous...compared to patches done by smaller companies and even one-person developers (Bill Grabowski, PSS, PMDG, SSW,...)Best regards,Stefan

>" They should have asked Mr. "Know-it-All..."">>If you have any more personal attacks, flames, insults or>other off-topic statements to make, please make them now. Once>you and the other children are done, we can continue this>discussion. I'm sorry if it bothers you that I know more than>you do - you tend to not learn much if you spend all day at a>message board insulting people.>>Microsoft's description of the problem is indeed baffling as>by definition it is *not* a memory leak. You don't have to be>"Mr. Know-it-All..." to realize that - all it takes is some>basic knowledge of how a computer and its software works. If>it's a memory leak, memory "leaks" - pagefile usage increases>- system eventually runs out of memory and app crashes ->typical example of a memory leak.Jimmy, it is the tone of your writing and constant habit of using ad hominem arguments that makes me skeptical of anything you write. You make assumptions that - simply because some person doesn't "accept your word" for anything you write means they must be intellectually deficient.I don't know your background, but here's something about me. I'm fifty-six years old, and have been a professional systems analyst and programmer for thirty-seven years. Your constant "smug superiority" is quite wearing, and does nothing to advance your credibility. When you expose youself in a public forum, it stands to reason that - sooner or later - you're going to encounter someone who knows the difference between buffalo cookies and chocolate chip cookies and calls you on it.At its most basic level, what is a "memory leak?" That's simple. Anytime a programmer forgets to save the address for dynamically allocated memory, that previously referenced item is left hanging in memory. This is called a "memory leak." The item will continue occuping memory -- and you'll be unable to get rid of it -- until the program ends.Reasons for a program (or programmer) to fail to deallocate a memory address are legion, but the simplest example is this:int *IntPointer;IntPointer = new int;*IntPointer = 3;IntPointer = new int;What happens when the last command is executed? The IntPointer had been set to 3, but the last command wipes out the address from IntPointer, and now whatever had been stored at that address remains in memory, but because IntPointer no longer stores that address, you have no way to access it, OR delete it.How can the above be fixed to avoid the problem to begin with? Again, the solution is simple, but when you're dealing with mega-thousands of lines of code, it's easy to overlook:*IntPointer = 3;delete IntPointer; //delete the contents of memoryIntPointer = 0 //clear the pointerIntPointer = new int;It seems self-evident that the unloader function used by the autogen procedure contained one or more poorly written statements, that failed to delete AND clear the pointer... hence, a slow but steady decrease in available memory.