The 'Official' Screenshot & Tips thread 4 FSX enthusiasts & flight simmers.
- Thread starter Soya
- Start date
Associate
Associate
V,
You still getting OOM crashes??? I found something at Kostas place.....
hope it will be of help to understand the OOM causes....
Due to the fact that an OOM discussion pops up every now and then, and it usually starts from beginning, today I’d like to start a page about Virtual Address Space. Please note I’ll try to keep this document as little technical as it can be – all the technical information about the VAS can be found on the pages like Wikipedia, Microsoft, Memory Management explanations etc. I’d like to keep this simple, for everyone to understand why is FSX crashing as of late more and more. I have been observing this development in the last couple of years, as the first OOMs appeared. I also have to give my thanks to many other fellow simmers, who also helped me understand the basics of memory management and how FSX works.
Simply explained, VAS is a working space of a program (let’s just call it that). DO NOT think physical memory or page file have anything to do with this. VAS is a specific space for an application, which can, under 64bit operating system be up to 4GB for the 32bit application.
64bit OS + 32bit application (FSX) = up to 4GB VAS
Remember this, as this is the 101 for OOMs.
Does it matter if you have 4GB, 8GB, 16GB, 32GB of RAM? No. Does it matter how big or disabled your page file is? No.
So what does it mean? FSX has 4GB of VAS to work with. Everything you load into FSX, basically loads into VAS. Be that an aircraft textures, airport scenery, tree texture, whatever you install and run, is going to have its place in VAS.
Since we do have a limited space of 4000MB, we have to have concerns when this space is going to fill up. All those nice airport sceneries, HD aircraft textures, they take a very heavy impact on the VAS when loaded.
One of the biggest culprits when VAS is concerned is LOD_RADIUS in FSX.cfg. This setting alone offsets the VAS usage by couple of hundred MB when bumped from default 4.5 to 6.5 (I also suggest this in my guide, but with the caveat that it can pretty quickly cause an OOM).
When this space fills up, you are presented by windows with a very nice message that your memory is low and the application will now close. FSX is going to quit.
What we should be aware of, is how much our addons use. Some use more, some use less, but they always take some VAS space. And most importantly, due to nature of FSX, this space is not freed as you fly along, nor has anyone yet come up with a plan how to free it up or fix this problem. So for example: you start your flight with an addon aircraft and addon airport, and your VAS usage is 2800MB. When you fly along, this usage will slowly grow. If you don’t overfly any other addon airports, it is bound to grow maybe couple of 100 MBs. let’s say for the sake of an example: up to 3200MB. When you come into range of your destination, and let’s assume you have an addon airport, which loads about 300MB into VAS, you will successfully land, as you will end up with 3500MB VAS.
But, let’s assume another scenario, in which you overfly two airports on the way to your destination, or you have some photoscenery, or or or, and the VAS usage grows up to 3700MB until descend. Now you can pretty much sure your sim is 99% going to crash on landing with out of memory = OOM error.
So, what you can do is only counteract it through some sim-management!
1) Always know your VAS usage, keep a tool for measuring it at hand, so you can quickly check
2) Keep your other scenery deactivated – now, while I understand this might be a nuissance, there is a simple way of doing it – SceneryConfigEditor – this tool gives you a possibility to quickly disable all non-essential scenery with a bit of sorting-imagination.
Download here: http://sourceforge.n...sceditor/files/
A word of caution on this tool: while very helpful, it can cost you your whole scenery.cfg if you are not careful. My suggestion is to run it as FSX obviously, but uncheck the “Follow the NewScenery convention”. This will always change the scenery.cfg directly, which means, after you install a scenery, if the installer is following the NewScenery.cfg convention, you MUST start FSX first, before the scenery will appear in the scenery.cfg. Also always keep a manual backup of your scenery.cfg.
3) Keep away from really high quality textures, as much as you can – I know they are looking nice and beautiful. If you know what you’re doing, by all means, load them up, but flying NGX with McPhat HD textures over ORBX into UK2000 EGLL with 4096 clouds is not a possibility, so much I can tell you.
4) If you are in flight, and notice a high VAS usage (meaning very high, so that you probably won’t be able to land): save and reload the flight, possibly lower the LOD_RADIUS in between. Make sure however you are flying the aircraft that supports that (PMDG stuff does for example).
So how do we measure VAS:
There are more ways than one, but for me, the simplest one is a tool called “Process Explorer”, can be downloaded here:
http://technet.micro...s/bb896653.aspx
When you start it up, I suggest you press on the Process column, to sort the processes after their names, alphabetically. As the next step, in the menu -> View -> Select Columns -> [Tab] Process Memory -> [check] Virtual Size -> OK. Additionally you can deactivate any other columns that are displayed by default, if any. In the main window, press onto “Virtual Size” column, to sort after the virtual size. This will always put FSX as the first when running.
This will give you a neat view of FSX VAS so you can quickly monitor it.
So, I’d like to urge everyone, before you start yelling at developers that their scenery is causing OOMs, reflect upon your system and see how many OTHER stuff you have running and question yourself which one is the biggest culprit and where can you optimize.
Most importantly, if you have something to add to this page, which might benefit everyone, please make a comment, I’ll be glad to add it into the page.
Additionally, I will start here with couple of VAS usages for addons I own and use a lot, so you get a feeling what each addon uses, and I hope to expand the list as the time passes:
PMDG NGX: 741MB
PMDG 747: 711MB
UK2000 EGKK: 140MB
ORBX ENGLAND: 200MB
You still getting OOM crashes??? I found something at Kostas place.....
hope it will be of help to understand the OOM causes....
Due to the fact that an OOM discussion pops up every now and then, and it usually starts from beginning, today I’d like to start a page about Virtual Address Space. Please note I’ll try to keep this document as little technical as it can be – all the technical information about the VAS can be found on the pages like Wikipedia, Microsoft, Memory Management explanations etc. I’d like to keep this simple, for everyone to understand why is FSX crashing as of late more and more. I have been observing this development in the last couple of years, as the first OOMs appeared. I also have to give my thanks to many other fellow simmers, who also helped me understand the basics of memory management and how FSX works.
Simply explained, VAS is a working space of a program (let’s just call it that). DO NOT think physical memory or page file have anything to do with this. VAS is a specific space for an application, which can, under 64bit operating system be up to 4GB for the 32bit application.
64bit OS + 32bit application (FSX) = up to 4GB VAS
Remember this, as this is the 101 for OOMs.
Does it matter if you have 4GB, 8GB, 16GB, 32GB of RAM? No. Does it matter how big or disabled your page file is? No.
So what does it mean? FSX has 4GB of VAS to work with. Everything you load into FSX, basically loads into VAS. Be that an aircraft textures, airport scenery, tree texture, whatever you install and run, is going to have its place in VAS.
Since we do have a limited space of 4000MB, we have to have concerns when this space is going to fill up. All those nice airport sceneries, HD aircraft textures, they take a very heavy impact on the VAS when loaded.
One of the biggest culprits when VAS is concerned is LOD_RADIUS in FSX.cfg. This setting alone offsets the VAS usage by couple of hundred MB when bumped from default 4.5 to 6.5 (I also suggest this in my guide, but with the caveat that it can pretty quickly cause an OOM).
When this space fills up, you are presented by windows with a very nice message that your memory is low and the application will now close. FSX is going to quit.
What we should be aware of, is how much our addons use. Some use more, some use less, but they always take some VAS space. And most importantly, due to nature of FSX, this space is not freed as you fly along, nor has anyone yet come up with a plan how to free it up or fix this problem. So for example: you start your flight with an addon aircraft and addon airport, and your VAS usage is 2800MB. When you fly along, this usage will slowly grow. If you don’t overfly any other addon airports, it is bound to grow maybe couple of 100 MBs. let’s say for the sake of an example: up to 3200MB. When you come into range of your destination, and let’s assume you have an addon airport, which loads about 300MB into VAS, you will successfully land, as you will end up with 3500MB VAS.
But, let’s assume another scenario, in which you overfly two airports on the way to your destination, or you have some photoscenery, or or or, and the VAS usage grows up to 3700MB until descend. Now you can pretty much sure your sim is 99% going to crash on landing with out of memory = OOM error.
So, what you can do is only counteract it through some sim-management!
1) Always know your VAS usage, keep a tool for measuring it at hand, so you can quickly check
2) Keep your other scenery deactivated – now, while I understand this might be a nuissance, there is a simple way of doing it – SceneryConfigEditor – this tool gives you a possibility to quickly disable all non-essential scenery with a bit of sorting-imagination.
Download here: http://sourceforge.n...sceditor/files/
A word of caution on this tool: while very helpful, it can cost you your whole scenery.cfg if you are not careful. My suggestion is to run it as FSX obviously, but uncheck the “Follow the NewScenery convention”. This will always change the scenery.cfg directly, which means, after you install a scenery, if the installer is following the NewScenery.cfg convention, you MUST start FSX first, before the scenery will appear in the scenery.cfg. Also always keep a manual backup of your scenery.cfg.
3) Keep away from really high quality textures, as much as you can – I know they are looking nice and beautiful. If you know what you’re doing, by all means, load them up, but flying NGX with McPhat HD textures over ORBX into UK2000 EGLL with 4096 clouds is not a possibility, so much I can tell you.
4) If you are in flight, and notice a high VAS usage (meaning very high, so that you probably won’t be able to land): save and reload the flight, possibly lower the LOD_RADIUS in between. Make sure however you are flying the aircraft that supports that (PMDG stuff does for example).
So how do we measure VAS:
There are more ways than one, but for me, the simplest one is a tool called “Process Explorer”, can be downloaded here:
http://technet.micro...s/bb896653.aspx
When you start it up, I suggest you press on the Process column, to sort the processes after their names, alphabetically. As the next step, in the menu -> View -> Select Columns -> [Tab] Process Memory -> [check] Virtual Size -> OK. Additionally you can deactivate any other columns that are displayed by default, if any. In the main window, press onto “Virtual Size” column, to sort after the virtual size. This will always put FSX as the first when running.
This will give you a neat view of FSX VAS so you can quickly monitor it.
So, I’d like to urge everyone, before you start yelling at developers that their scenery is causing OOMs, reflect upon your system and see how many OTHER stuff you have running and question yourself which one is the biggest culprit and where can you optimize.
Most importantly, if you have something to add to this page, which might benefit everyone, please make a comment, I’ll be glad to add it into the page.
Additionally, I will start here with couple of VAS usages for addons I own and use a lot, so you get a feeling what each addon uses, and I hope to expand the list as the time passes:
PMDG NGX: 741MB
PMDG 747: 711MB
UK2000 EGKK: 140MB
ORBX ENGLAND: 200MB
Thanks for the above mate, a very useful read.
I've not had any since I had that nightmare day on Friday. But not done the same flight which was EGPH to EGLL.
I actually found that Scenery Config Editor yesterday after doing much research about OOM.
One question about the software. Can you untick the Base scenery or shouold this stay ticked?
Thanks again.
I've not had any since I had that nightmare day on Friday. But not done the same flight which was EGPH to EGLL.
I actually found that Scenery Config Editor yesterday after doing much research about OOM.
One question about the software. Can you untick the Base scenery or shouold this stay ticked?
Thanks again.
Check out this video, amazing how it spins/cartwheels over like that, more amazing that only 2 died.
http://www.cnn.com/video/?/video/us/2013/07/07/vo-plane-sf-plane-crash-on-cam.courtesy-fred-hayes
They must've known they were well under the glidepath, but no go around? Interested in seeing the final NTSB report.
http://www.cnn.com/video/?/video/us/2013/07/07/vo-plane-sf-plane-crash-on-cam.courtesy-fred-hayes
They must've known they were well under the glidepath, but no go around? Interested in seeing the final NTSB report.
wow!!! Yes amazing that only 2 people died!!
Associate
I get that it was a fluke that someone managed to capture it on video, but in the age of the smartphone i'm surprised its still such a low res.
Sadly toString sounds like he hit the nail on the head - If that FDR data is accurate, then the throttles shouldn't have been anywhere near idle until the last 30 feet or so (might be a little higher for a 777 mind). Also 2.5 seconds between stick shaker and go around call is a fairly long delay given the circumstances. Stuff like that should be an instantaneous reaction, no questions asked.
On the flip side it still doesn't add up to me. Can't quite believe such an experienced crew could make such a basic mistake without all their aids (the ILS was out). People always say plane crashes are never due to one single thing. I'd be interested to see what the crew has to say about it.
Sadly toString sounds like he hit the nail on the head - If that FDR data is accurate, then the throttles shouldn't have been anywhere near idle until the last 30 feet or so (might be a little higher for a 777 mind). Also 2.5 seconds between stick shaker and go around call is a fairly long delay given the circumstances. Stuff like that should be an instantaneous reaction, no questions asked.
On the flip side it still doesn't add up to me. Can't quite believe such an experienced crew could make such a basic mistake without all their aids (the ILS was out). People always say plane crashes are never due to one single thing. I'd be interested to see what the crew has to say about it.
Last edited:
Has anybody done this tweak?
Is this the same as changing the TEXTURE_MAX_LOAD=4096 tweak?
Got this from the AVsim forums?
Desktop Heap Limitation:
A second reason for OOM’s occurring is the default setting for the Desktop Heap is low: we recommend you change this as follows:
To modify this, follow these steps:-
1). Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
2). Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems Right-click the Windows entry, and then click Modify.
3). Right-click the Windows entry, and then click Modify.
4). In the Value data section of the Edit String dialog box, locate the SharedSection entry, and then increase the second value to 20480, and the third value to 1024.
Is this the same as changing the TEXTURE_MAX_LOAD=4096 tweak?
Got this from the AVsim forums?
Desktop Heap Limitation:
A second reason for OOM’s occurring is the default setting for the Desktop Heap is low: we recommend you change this as follows:
To modify this, follow these steps:-
1). Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
2). Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems Right-click the Windows entry, and then click Modify.
3). Right-click the Windows entry, and then click Modify.
4). In the Value data section of the Edit String dialog box, locate the SharedSection entry, and then increase the second value to 20480, and the third value to 1024.
Yes thanks P after I posted the above. I read a bit more and you right nothing to do with the TEXTURE_MAX_LOAD.
cheers
Permabanned
- Joined
- 15 Apr 2010
- Posts
- 10
Just installed Aerosofts new Twin Otter Extended
Quick test flight, will be doing circuits at EGPR after work tonight
Quick test flight, will be doing circuits at EGPR after work tonight
Soldato
Great shots! Looks like a nice little aircraft. Is that ORBX scenery?
Just been doing a full reinstall of FSX onto an SSD and new system and you forget just how long it takes! I've spent the best part of a week installing various payware and freeware addons and still feel like I've got loads to get through still and then get tweaking.
Just been doing a full reinstall of FSX onto an SSD and new system and you forget just how long it takes! I've spent the best part of a week installing various payware and freeware addons and still feel like I've got loads to get through still and then get tweaking.
Permabanned
- Joined
- 15 Apr 2010
- Posts
- 10
LOL, Yeah FSX re-install is a nightmare
It is indeed Orbx, FTX Scotland
FTX Global launching soon
http://www.fullterrain.com/product_ftxglobal.html
Associate
I agree that a FSX re-install can be somewhat testing. I followed this guide when I did mine..... http://support.precisionmanuals.com/KB/a87/how-to-uninstall-and-reinstall-fsx.aspx
Just getting the settings sorted, thought I'd post these
Uploaded with ImageShack.us
Uploaded with ImageShack.us
Uploaded with ImageShack.us
Uploaded with ImageShack.us
Uploaded with ImageShack.us
Uploaded with ImageShack.us