ACSoft

Dear Simmer's,I have just discovered that, when booting my PC in /3GB mode for FS, the other games I have, which have the StarForce protection system, just crash hard my machine, when attempting to run them (black screen + reboot and then, after the reboot, Windows saying it recover a "serious" error). This occur, for example by me, with Lockon 1.12b (StarForce Internet protection) or Silent Hunter III (StarForce media protection).I wonder if some other simmer's of this large community, have experienced the same problem ? Or the contrary ? Can somebody affirm he is able to run StarForce protected games with his machine booted in /3GB mode ?Many thanks in forward for your numerous testimonies. They will be probably very helpful to clarify the situation about this problem.ACSPS: My PC run Windows XP version 2002 / SP3 (32 bits / French)

Hoops, Armen, sorry for the name !You mean probably "PMDG_MD11_NoseGearAirflow.wav" but not "PMDG_MD11_NoseGearAirflowxxx.wav" ?I guess the "xxx" version is the old one and probably forgot behind.Alain Capt

So, I suppose the sound "PMDG_MD11_NoseGearAirflowxxx.wav" can be deleted as it is probably never used ?ACS

I can insure you that I perfectly understood all what you explained and the fact that, to your taste, I have used the term "memory" in an inappropriate manner, does not mean you failed to convey this clearly. French is my mother language and it is very difficult for me to express such complex things in English.Finally, You probably missunderstood (because of my poor English) the sense of my question. It was just a technical curiosity. No suspicion or fear, or whatever you want, about the /3GB trick. So I didn't needed to be convinced about the benefit to use it or not.Oh l

n4gix,I have maybe a last question for you:Does the "/3GB switch trick" really solve the OOM problems, or just delay it ?In other words, does this increase of room for applications in VAS table, on the detriment of OS room, allow the Memory Manager to stabilize, when harassed by FS ? I mean, the hudge fragmentation of VAS stabilize at one point and therefore, we enter into a stable situation, where OOM won't occur anymore ?Or, with the FS behavior toward the memory, it is just a matter of supplementary time (or more complex and demanding addon) and the OOM will be there again ?I ask me this question, because you clearly said that the OOM does not come from the fact there is really no more room, but the system cannot anymore found a single contiguous space large enough, to fullfil the request in this chopped virtual memory.It will be probably difficult for you to answer, as I know yet that we are all blind to really monitor what's happen, but I guess you should have your opinion about that matter, maybe based on experiences you made.Thanks in forward,ACS

Yes, and this restriction make all the problem !Such a memory management is maybe sufficent for "standard" applications in a multi-tasking environment, but probably the worst one for FS, which never stop to request and release ton's of memory blocks.This "rolling fire" of textures load/unload should NEVER has been implemented straight forward over the Windows system Memory Manager layer !!!The visible symptom of the horrible slicing of the virtual memory, made by FS, is probably the growing of "Virtual size" we can see into the "Process Explorer". For example this afternoon, I made the following test: I flew my "OOM flight" and saved along the flight "Virtual Size" and "Virtual Bytes" values (yes I know, it is a non sense, but it is all what I have !!!), while doing in the same time, a "Flight" save, in order to be able to restore the exact same situation later.So I got:Top of Climb -> VS=1288MB / VB=731MBTRA -> VS=1402MB / VB=754MBMILPA -> VS=1547MB / VB=775MBNARAK -> VS=1557MB / VB=761MBVASUM -> VS=1552MB / VB=728MBOOM -> VS=1554MB / VB=739MBThen, I reloaded the situation for VASUM and, after having well played with all views, internal, virtual cockpit, map at different zoom factor, etc..., to make sure all textures loaded, I looked at "Virtual size" + "Virtual Bytes" values and I got: VS=1020MB / VB=659MB.Quite a dramatic difference !!!So, what is missing in this Memory Manager, is a possibility to "defrag" the memory.But I think I guess why it isn't implemented !!! To defrag the memory would probably require to hang all running process until defrag is done, and a mechanism to make them aware that their private memory allocations are going to move elsewhere !!!ACS

Touch wood Red1 !!!ACS

OK, but the informations reported by "Process Explorer" in section "Virtual Memory", are more or less in correlation, or if you prefer, "in connexion" with the VAS. In other words, you mean we cannot deduct from the behaviors of "Virtual size" and "Private Bytes", what really happen on the level of VAS table.More or less that !!! Yes, I undersand it is very difficult to explain such a complex way of managing memory in a computer (with Microsoft, I always thought his phylosophy should be: "Why to make it so easy, when you can do it soooo complicate" ). But, I must say you succeed really well to enlight the darkness in which we are all plunged !!! After the Library, the antiquated card catalog, the books, now, the mathematical beauty of a Beethoven Symphony !!!I love your imaged explanations. It really help understanding !!! :( I understood that "Virtual size" was the memory address "interval" into process VAS and "Private Bytes" the quantity of used memory repartited into this interval.So I was looking at "Private Bytes" thinking it can, "IN THEORY", grow up to a maximum of 2GB (the section of the VAS allocated to applications) and the maximum contiguous space still available could be deducted from 2GB minus "Virtual size".But in fact, all this stuff is muuuuch more complex, as you try to explain here.NOW I AM CONVINCED that we are just totally BLIND.That the single tool we have is not even a "blind person's stick" !!!That Microsoft, as usually, created a "Monster" on which we don't really have control. Yeah, bam! That's what happen when the Monster wake up :oBut something really shock me:To have a computer with absolutely all unecessary task's & services shuted down, 2GB of good physical memory, 4GB of good cache memory defined on the HDD, so in all, a virtual memory of maximum 6GB, just running FS2004 version 9.1,... and this computer come to the conclusion that it is out of available memory when using ""only"" 750MB.I also do not understand why the "Virtual size" grow up so much when you are flying, even if the "Virtual Bytes" remain stable (no memory leak). This is for me, the only visible symptom that FS just make the Microsoft Monster crasy.So, in conclusion, we know how to avoid to wake up the Monster (64bit OS and/or 3GB tweak), but we will NEVER have a real solution to OOM's, because we don't even know what really happen when FS return this error."n4gix". Again many thanks for your patience and your imaged explanations. :( Regards,ACS

N4gix, thanks for these interesting explanations.What is the relationship between the applications VAS and the "Virtual size", respectively "Private Bytes" shown by the tool "Process Explorer" ?Isn't the "Virtual size", the "application VAS" of each process ?Shall I understand that a single PC system only have a single VAS ?Does the so called "OOM" error come from a VAS operation failure ?Thanks in advance for the further enlightments you may give to me on this matter.Regards,ACS

Hi Word Not Allowed ! Don't be upset !Where did you see, in my initial message, that I was asking for explanations or solutions ?!?!? I said in further answers, this was just a testimony that, to my humble opinion, the generally accepted "theory" about FS OOM is simply not confirmed AT ALL by the monitoring of the events with Process Explorer. Period.Dont worry, I know perfectly how to fly without OOM on my system. It is very simple. I just have to desactivate Ultimate Terrain Europe and I never have any OOM again.Regards,ACS

Sorry Word Not Allowed, not really. I don't believe you are right.In my tests, OOM occur far before biggest parts of an airport are loaded. In any cases, whatever provoke the OOM in my example, IT IS JUST IMPOSSIBLE it is provoked by the famous "theory".OK, let's even say, the approaching airport weight 300-400MB. Let even say when the OOM occur, FS try to load all this stuff, which I don't believe AT ALL on second. What is sure, FS is NOT going to do just a SINGLE memory request of 400MB. You will have a salvo of many requests of different sizes and only the last one, close from the OOM condition, will fail. So, if this "theory" was correct, Process Explorer should show a state much more closer to that famous OOM condition, which is obviously NOT THE CASE.Process Explorer display only OS informations in relation with the process. So, even if the process is hanged by a OOM error, Process Explorer continue to scan these datas. We can even see them still changing after the OOM and after you answer to the OOM error message (proof these datas are still alive & valid).Regards,ACS

Bob, my point with this thread is not to believe or not this fact, my point is to testify with my example, that the theory found everywhere on the Net, about the reasons why these OOM's happen, is probably simply incorrect.I love to really understand things ! Word Not Allowed, I prefer to amuse you rather than bother you !!! LOL !!!But again, my point wasn't to believe or accept anything.In my search & read about this matter here and elsewhere, I didn't found a previous testimony that this apparently unanimously accepted "theory", about the reasons for these OOM's to occur, could be totally wrong?So, this is my stone in the building !!!Again, I love to understand things and if the reason given is wrong, I though that maybe they were other tracks to explore ? Of course, I didn't knew, when I started the thread, that even ACES itself just gave up on that. So I am going to give up myself too !!! LOL !!! Like you said, otherwise, it would be like the holy grail quest !!!Apparently, it is a long time you follow these discussions about OOM's. I saw your name in many thread's. So I can understand you start to become tired of that. But it isn't my case, sorry.By the way, many thanks to always take the time to answer & help peoples about that.ACS

As far as I know, this is not determinant, as long as you don't have a hudge quantity of stuff's running, who would be able to overflow the total capacity of your RAM and swap page file.Each process receive this famous 2GB of adressable space called "Virtual size". Then, the private bytes used in this space, are physically mapped into the RAM and/or the hard-disk swap file "pagefile.sys".If you look on my picture, you will see that 852MB of the 865MB are located into RAM (physical memory). This mean obviously that my PC is optimized to run FS2004 in the best possible conditions. Apart FS, you just have the strict minimum. As far as I know, this is a separate memory mapping. I have two physical hard disks, one for the system and another one, for FS and other games. Both disk are about 3/4 empty. Both disks are optimized with "UltimateDefrag".My cache page file is defined on system disk and has the max possible size (4GB fixed). I tried also with 2 cache files (one on both disk), but it does not make any difference. LOL !!!That's a good question, unfortunately !!!ACS

You put the finger right on the point of my initial message the "IMPOSSIBLE" OOM.If you look carefully on my image, you will see that private bytes where 865MB, repartited into a virtual size of 1655MB. So, from the theory you have developed here, we have potentially about 1135MB still available and the largest known contiguous space is 345MB.I simply cannot believe that a single memory request operation would requiring over 345MB !!! This sound impossible to me !!! Therefore, we are missing something here. Does FS9 return us an OOM error, but, in fact, it is NOT a real OOM ? FS9 just get lost with his own internal memory management ? I have even had OOM's with private bytes under 800MB and a virtual size under 1500MB !!!It is also interesting to observe the evolution of "Private bytes" and "Virtual size" during a test flights (over "high graphical" regions). It is symptomatic to see that the "Private bytes" remain relatively stable (in my case, a variation inside 750 to 780MB interval). But, what is bad, very bad, is the permanent growing of "Virtual size" during the same time. In this case, I started with 1098MB and finished with 1365MB !!! Here also, we can suspect that the OS memory management is doing rather poor things.OK, a 64bits OS and the 3GB patch seem to solve the problem (I would say overturn the problem !!!). But, for those who cannot upgrade to such a system (almost not now, like me), it is really sad to think that a 2GB RAM / 32bits OS PC would be probably widely enough powerful to run FS9 and all these beloved addon's, if the memory was simply managed as it should.Unfortunately, most of the time, "The way things goes with Microsoft".ACS

So something, relatively close to my case, but in contradiction with the "theory" too and that was my point. Of course, almost right my configuration !!! No miracle !!! Very interesting !!!This mean there is, in fact, no valid "theory" about FS OOM.I didn't knew that. Fortunately, I have only very few of them and like you said, in some particular flights.But I notice, Thanks !!!Upgrade to a 64-bit OS is the solution, if I cannot accept anymore those few OOM's.ACS

Hello,Running FS9.1 on Windows XP SP3 standard (no 3GB tweak) on a system with 2GB of memory + 512MB of video RAM, a pagefile.sys file of 4GB, It happen to me to have sometimes the hated OOM error.I read all about these damned OOM errors, in this forum and other places. What I mainly understood, is that OOM will occur as soon as FS9 fail to get memory, because there is no more available memory into the 2GB adressable range for the process.If this is true, why do I get OOM error in the following case ?As you can see, OOM occured when FS was using "only" 865MB, inside a virtual size of 1,655GB. It occured, as usually, during the approach of my destination airport.1,655GB of virtual size, mean probably that the 865MB of private memory usage are quite heavily fragmented into this space. But, nevertheless, 345MB of remaining adressable space, should have been far enough, even in the case the memory request wouldn't have fit into some of the holes inside the used range.Do I missunderstood something ?If some Guru's out there have an explanation for this case, I would love to know it.Thanks in forward.ACS

Hi,Please help !!!Does anyone has an idea of what can cause this ?In the meantime, I discover that in 16 bits colors, flickers dissapear. But, of course, I want to use 32 bits mode. So this won't be the solution, but may a track for the Guru's out there !!!Thanks in forward for any help.A. Capt

Hello,This is "flickers on black" (a very short lost of the image). This does NOT occur while playing, but only in circumstances like these one:- If I load a Flight, during all the loading time, I see some burst of flickers on the FS splash sceen image.- If, when playing, I press "Alt" key, to get menu bar, I see a burst of flickers.- If I press "Esc" while playing, immediately a burst of flickers. Then again when I confirm I want to quit.- Etc ...The very old 91.33 Forceware NVidia driver which was installed since today on my PC, had this problem already, but ONLY if FS9 Anti-Aliasing was activated (this is why I was keeping it).Today, I installed last version 182.08 with the hope to not have this problem anymore, even with anti-aliasing activated. But the situation became worst. Now, I have these damned flickers with or without anti-aliasing set. In fact, I simply cannot get rid of this problem, whatever I try (FS9.cfg delete, a lot of custom settings combinations in NVidia "MS Flight simulator 2004" 3D profiles). As I sill use a good old cathodic monitor display (Samsung SyncMaster 997), I tried also to change refresh frequency, but here again, no joy.Does anybody has an idea/clue of what can be the problem and how to cure it ?Many thanks in forward for any help.Alain CaptACSoft ProductionsMy PC Config: Motherboard: ASUS P5W DH DELUXE Proc: INTEL CORE DUO EXTREME (CONROE XE) 2.93GHZ Memory: DDR2 2GB [1GBX2] DDR800 (PC2-6400) CORSAIR TWINX Hard-disk: 2X SATA300 320GB - 7200 HITACHI DESKSTAR T7K500 (16MB) Graphic: MSI GeForce 7900GTX 512DDR OS: Windows XP version 2002 SP3 (french)

Sorry Dan, but I have some difficulties to understand exactly what you mean.Let me take an example:Suppose I do a flight with a quasi empty aircaft (speaking of payload). So, I set this situation in the the payload editor, I save, then I launch FS and one of my "cold start flight" file, prepare my flight, takeoff and finally save a Flight situation, for example during the approach.Later on, I do the same way another flight, using the same method, but this time, with a quasi fully loaded aircraft.Now, some days later after this last flight, I run FS again and load straight forward my Flight situation during approach. Are-you telling me that my landing will behave EXACTLY the same as it behaved during the original flight when I saved ?If it is the case, it is great !!! It would mean the aircraft use "station_load" parameters just as a "memory" of what was set into the Payload Manager. It would mean that, in fact, these "station_load" parameters in aircaft.cfg, are useless as soon as you are flying, because it is only the memorized current weight and cg which will affect the physic of the flight, almost speaking of PMDG aircraft ?Is-it that what you said ?Thanks in forward to confirm.Alain Capt

Hummm, I have some doubt that "aircraft.cfg -> station_load.X" parameters are of no importance and for sure, the Load Manager do update them, when you press "save to file" in it.Being part of "Aircraft.cfg" they should affect the FS flight model, unless PMDG code would overwrite the internal corresponding FS variables, with the original values at the time the flight save was done by the user. No problems, take your time to ask this to the "specialist". I am not in hurry, I just wanted to be sure my request was taken in account.Alain Capt

Toc, toc, toc ! Dev Team, anybody there ?I would love to receive an answer, this is why I added this, to restore my question on the top.Again, thanks in forward.Alain Capt

Hello,As you know, both PMDG 747-400 & md11 have the ability to restore their states along with Flight save files. This is great, because it allow to save a flight and reload it later, to continue the flight, to review a interesting situation, etc...Suppose now I decide to reload a Flight made some time ago and I know that I made several other flights since that time, with different payload configurations. Obviously, my Flight made some time ago, WILL NOT FIT with the actual payload configuration (payload is memorized into "aircraft.cfg").My question is, for both PMDG 747-400 & MD11 aircrafts:If I reload my Flight, will I fly with the last flown payload values, or does PMDG sophisticated code restore internally the "load stations" variables, with values saved within the PMDG aircraft state, generated when I saved my Flight ?In other words, can someone of the development team explain to me, the exact behaviors of both aircraft's in regard with that matter ? This would be very useful for me, to know how to manage properly my saved Flight files.Many thanks in forward.Alain Capt

Thanks Randy, i will follow your advise.BestAlain

Hi All,I am the very happy owner of the 747-400 "Queen of the skies" for some days now. As a FS freeware developer myself (ACS-GPS, ACS-MD11, etc..) I must say that this "Queen" really stunt me !!! This is really the very best addon for FS2004 I ever seen !!!Speaking of the 747-400F additional package, I read carefully the list of new features/improvements for this additional package, so I know already what apply specifically to 400F only, or to both 400 & 400F.I am NOT very interested to fly cargo, so I wonder if I must buy this further package, just in the meaning to upgrade my "Queen of the skies" ?With just the "theoretical knowledge" of the list mentionned before, for quite a lot of these list items, it remain very difficult to figure out if this is a "must have" or not. I precise that all what is in the "eyes candies" category is secondary to me. What is important, is all what concern logical system simulation (avionics, etc...), flight dynamic behaviors and technical behaviors (frame rate, stability, etc...).Can some experienced user's, which have already experienced both stages (747-400 1.10, first without and then with 747-400F expension) tell me their opinions in the context defined before ?Many thanks in forward for your help.Regards,Alain