hjwalter

Gregory, Yes, I read about your personal involvement in transforming this well made KGRR scenery from FSX to FS9, in the readme file. Great job and with the assistance of quite some well known international FS9 specialists. To me it has now also become clear that systematically decreasing scenery texture sizes only has minimal effects on scenery loading times and/or frame rates but this could also be influenced by the fact that my machine is fully equipted with SSDs instead of HDs. I guess I can sweep all my own FS9 improvement activities under three combined words: "Technical", "Hobbyism" and "Collectorism", which I think could be rather logical after years of "armchair" FS9 flying and covid lockdowns. Mallcott suggests decreasing the number of my scenery layers but to me as a collector this would be like sinning against myself or even like swearing in a church !! Moreover, my FS9 makes intensive use of library objects, which makes deleting any of my sceneries extremely unpredictable for remaining sceneries. Anyway, I've learned much from this whole "issue" and from all the reactions in this thread. Cheers. Hans, a still convinced FS9 diehard. P.S. "If it aint broke then don't fix it", but just as true, "If it aint broke then don't ...LET ... it be fixed", e.g. via Windows updates and it remains my opinion that the basic Win7 is still the most efficient platform for FS9, whatever it's size.

JSMR, The textures I was experimenting with were those of the Grand Rapids, Gerald Ford KGRR airport in USA. Why this particular airport ? No other reason than that it was the most recent one I had downloaded/installed. I've used FS9 almost from the day it was first published and through the years it has grown to 133 Gb, almost 1000 scenery layers, hundreds of different flyable aircraft/paints, 1318 active AI aircraft/paints, very many self made static versions and all are devoid of unnessary ballast while also having been optimized for utmost (frame rate) efficiency. After all this, one of my remaining ideas concernes texture sizes and whether or not these could have an effect on loading times, frame rates and possible stuttering. It's for this reason that I first tried converting the DXT3 textures to DXT1 via the Convim program but this proved to have some rather unpredictable results, especially with respect to alpha channels. Tim Wright suggested the Texture Manager program, so I tried that as well. However, this gave some strange error messages, which turned out to be related to my Win7 file, ntdll.dll. I downloaded and replaced it with a newer version and that worked great ..... until I shut down my machine and later wanted to re-start it ......> completely dead !! However, after my machine's resurection, I still had the texture folder with the correctly reduced texture sizes and with that I did notice some improvements in the loading up and the frame rates at KGRR but these were not such that I would want to shout out loud that in general the decrease of texture sizes is the way to go. I have therefore now restored all textures to their originals and will let my ideas rest at that. I hope this answers your question. Regards. Hans

O.K. Guys, Thanks for all your reactions but I'm now completely cured of trying to mess around with any new ntdll.dll, especially in combination with the re-sizing of FS9 scenery textures via my original DVD version of Win7 64bit. My huge FS9 has been working great for many years and as the saying goes: "If it aint broke, then don't fix it". Thanks again. Hans

This whole issue in trying to reduce my scenery texture sizes, was based on my assumption that (complex) airport sceneries would then load faster. My first test method in transforming DXT3 textures to DXT1, was not very successful because first of all, many alpha channels were lost during the conversion process and secondly, as Gaputz correctly points out, there were problems with certain semi-transparency textures. However, in the single and as yet successful case of me reducing the texture sizes of a complex airport (421 textures) via the Texture Manager program, their DXT3 compressions were all retained ..... and ..... loading times for the airport concerned, were noticably faster. When now panning around in external view, frame rates and stuttering seem to have improved as well but not really enough to make loud noises about. What I have also noticed is that when approaching the airport concerned in good weather and from a great distance, the sudden appearance of an untextured white blotch on the ground and on which the airport scenery objects then begin popping up as I get closer, has diminnished. This is most probably related to the mipmaps which have also been retained. I'm now testing the night textures and to see if there are any differences in details/apron light splashes, etc. Regards Hans

My Win7 being completely dead, i.e. not even getting so far as to boot, was caused by the new ntdll.dll file, which evidently needed all the past Win7 patches/updates to at least be able to boot. My Win7 is still the original from the DVD and my self built machine has never been connected to the internet, therefore no patches and/or updates were ever installed. However, via a problem solving diagnostic tool I was able to break into the Win7 folder concerned via a kind of back door, to get at the now offending ntdll.dll file, to delete it, followed by renaming the backed up original to it's original extension. My machine now boots and works normally again .... but .....the Texture Manager program now no longer works. However, that's now become a minor problem. Regards Hans

gaputz, I agree with you completely and I've already seen what you say about converting DXT3 to DXT1. Luckily I was only testing and have in the meantime reverted back to the original texture folders. However, I now seem to have comitted a Win7 mortal sin by renaming my existing ntdll.dll into ntdll.dllORGXXX and then adding the newer version in the same Win7 folder. Although the Texture Manager program now at least test-worked correctly it seems that my Win7 is now as dead as a doornail and no longer boots up. Oops !! Anyway, thanks for your warnings. Hans

Tim, I've been busting my brains on this particular problem for two whole days now but have finally found what was causing my "corrupted memory" problem. It turns out that the Texture Manager program also needs a newer version of ntdll.dll and with version 10.0.19041.423, dated 9/1/2020 now installed in my Win7 64bit system, the program suddenly and much to my surprise, reached it's normal end. Thanks for your advice about this program. Works great !! Hans

Tim, You are completely correct, in that the Texture Manager program has many more functions than CONVIM, one of them being that the physical sizes of all BMP textures within a selected texture folder can be reduced. However, for me the most important thing was that any existing alpha channels were being preserved during these reductions as well. But, but, but, ...... After processing about 20% of the contents of any (previously backed up) scenery texture folder, I keep getting an error message saying: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt". ???? Clicking the "OK" button just gives the same error message but for the next texture to be processed, all the way to the last one. I most probably already had mwgfx.dll installed in my Win7/64 but downloaded and installed the latest version 4.00 anyway, just to be sure .... but sadly .... no difference. There's nothing in the supplied PDF program description file about such error messages and any parts of my memory being corrupt, would certainly be a great surprise for me. Would you have any ideas on the above, please. Thanks in advance. Hans

Thanks Tim for your prompt answer. However, I've already been using the CONVIM program and it's especially this program which in an unpredictable way, seems to like "eating" alpha channels during any of it's batch conversions. I'll try the advised DLL file one of these days when I have some time, and will report pack in this thread. Thanks again. Regards Hans

Hi Guys, Does anyone know of a utility which can convert FS9 scenery textures in bulk, whatever they are, to DXT1 textures and without losing their alpha channels in the process ? I'm now doing this one by one, which can be a long and very tedious process. Regards Hans Always remember, that pushing your stick/yolk forward makes houses get bigger !!

Tom, I suppose that some machines with very high tehnical specs will be somewhat less sensitive but the basic issue remains, epecially when more than a few flyable planes are active as AI. The same stuttering will also occur when, e.g. a complex airport suddenly comes into view but it's related textures, other than those of flyable planes, are structurally be mipped so as to greatly reduce this effect. External AI plane textures are normally mipped as well, for the same reason. Regards. Hans

It's not advisable to assign any type of flyable aircraft as AI because of the multiple and complex external textures involved. These will cause stuttering whenever they (unexpectedly) come into view and especially when there are more of them (flying) around. Also don't forget that such flyable "AI" aircraft are always burdend down by cockpits/panels, possible virtual cockpits, programmed instruments, custom sounds, far more complex model and air files, etc. AI aircraft have none of the above but have purpose made far simpler mipped external textures only and are not really suitable for close-up viewing. However, a quick search on my part did not turn up any AI Stearmans ..... yet. Good luck. Hans

It's not advisable to assign any type of flyable aircraft as AI because of the multiple and complex external textures involved. These will cause stuttering whenever they (unexpectedly) come into view and especially when there are more of them (flying) around. Also don't forget that such flyable "AI" aircraft are always burdend down by cockpits/panels, possible virtual cockpits, programmed instruments, custom sounds, far more complex model and air files, etc. AI aircraft have none of the above but have purpose made far simpler mipped external textures only and are not really suitable for close-up viewing. However, a quick search on my part did not turn up any AI Stearmans ..... yet. Good luck. Hans

A Boeing 737-400 air file being used in combination with your Stearman-4 ?? Sounds great, especially when your very sluggish Stearman is now a "little" over-powered ?? How does it handle at 34000 feet ?? LOL. Pleae supply the exact file name of the Stearman-4, which you've evidently downloaded and are now happy with, the one with the missing air file ? I would like to try my own B737-400 air file on it. Thanks in advance. Regards Hans

Anwar, You will need to supply us with more information so that we can try to help you. 1. Did you change anything in your plane's panel.cfg file ? 2. Did you replace the original panel by any other panel ? 3. What is the exact type of plane ? 4. Is it a default plane or a downloaded one ? 5. If it concernes a downloaded plane, what is the name of the download file and where did you download it from ? 6. Do you have any kind of backup for your plane ? Any further information could be helpful. Hans

If you type "Thunderbolt" into the FS2004 File Library/search function and scroll down through a few pages, you will find some P-47 Razorbacks in RAF paints. Not sure though that these are the ones you are looking for. Good luck. Hans

Don't you have a FS9.cfg backup from a time before your problem appeared ? Hans

Have you tried engaging the AP in any of your FS9 default aircraft, e.g. the B-737, when in level/stable flight and with a minimum speed of 200 knots ? Happy landings Hans

Tom, When thinking further about this thread I must now assume that when the SAMM program is used, not only to create a static aircraft but at the same time to position it somewhere, that the end result will be a combination BGL file as you describe and which cannot be un-geolocked via the "geolock" program. This problem now seems to be what the initial poster in this thread was trying to make clear. Hans

Tom, You are absolutely correct in saying that when both placement and model data are combined within a single BGL file it automatically means that the related scenery objects are in fact "Geo-Locked", something which the geolock program seems not to be able to undo. However, what this geolock program then CAN or should be able to do, remains unclear, at least for me. The only way to un-geolock such BGL files is to firstly disassemble such files into XML files, to then manually separate the placemant and the model data and finally to re-compile each separately, thereby creating un-geolocked library scenery files. I've in fact already successfully done this a number of times and can now place these objects anywhere ..... but .... only for my own use. Hans

Hey Guys, Some scenery (or scenery object) developers protect their created library type scenery objects from being pirated by "geo-locking" them within certain geographical areas, outside of which these objects cannot be positioned, e.g. via the (payware) Abacus EZ Object placement program. As far as I know the SAMM program can furthermore only be used to create static aircraft, preferably based on existing AI aircraft and I have used it successfully many times for this purpose. The in this way created statics can then be positioned as un-geolocked scenery objects anywhere in the world, e.g. via the above mentioned Abacus EZ program. However, in the meantime I've understood that the SAMM program can also be used for positioning such self created static aircraft but I've never used that function. The question I have now is what the relation is between the SAMM and the Geolock programs in this thread but the possibility does exist that the static aircraft concerned has been made by a scenery developer and in order to protect it from piracy, has in fact geo-locked it, as in my first paragraph above. However, if one tries to use the Geolock program for un-locking (or to pirate) a gro-locked static scenery aircraft, failure is guaranteed because it just doesn't work. Regards Hans

I've had this problem before as well and it was definately wind direction/strength related. Taking off from the opposite direction on the same runway confirmed this. I changed the wind direction to come from dead ahead on the runway and re-saved the flight concerned. Hans

The big remaining question is if anyone has actually managed to get this program to work because I certainly havn't, with or without long paths to the (scenery) BGL(s) concerned. It could be that I've been doing something wrong during the past two years or so but in the meantime it's become my opinion that this program just simply doesn't work. I'm using Win7 64 bit. Regards Hans

Hey Guys, Does an OOM mean that you simply do not have enough memory or does it mean that because of a programming error in something which is programmable, e.g. a cockpit instrument and which error is then trying to access an area outside the area alotted by Windows to software, like FS9 ? I've always been lead to believe that the latter was the case because substituting the whole panel usually solved my OOM, while only later, when I had more time, the culprit instrument was routed out and replaced. However, it's been years since I had my last OOM. Regards Hans

I installed this "patch" quite some years ago but as an advice found somewehere on the internet. Did not perform any before/after frame rate tests though but I've been using it without problems ever since. Hans