Premek
-
Posts
625 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Downloads
Posts posted by Premek
-
-
Found some interesting reading over here -> http://kostasfsworld.wordpress.com/fsx-oom-and-addon-vas-usage/
Ah, sorry - I thought you are aware of it...
http://forum.aerosoft.com/index.php?/topic/78126-thessaloniki-x-out-off-memory-stackhash/?p=557085
-
Yes. It (exe) does (its own 4GB block).
See the JPG - the VirtualAddressSpaceTest uses 3.5GB and FSX uses another 1.8GB - together far more then 4GB.
The misleading point here is probably that it is shown as a child of FSX, but it is so from different reason (to show it was called called from there)
-
1
-
-
Coualt.exe runs outside FSX, it has no access to the memory occupied by FSX. It communicates with FSX in order to load the GSX vehicles for example. The Coalt-engine itself has no impact on VAS usuage...
Indeed!!!
That's weird since I think it's running outside FSX just like KLM737 also said above. Not sure what Process Explorer looks like and how good it is, could it be that you "misread" the value or an actual problem with the app itself?
Yes, it is running outside FSX but ProcessExplorer shows it as a "child" as it was run from the FSX.
Wrote a simple test executable just allocating 3GB of memory (which proves it runs its own VAS) and run it via exe.xml.
Here is how it looks in the Process Explorer.
-
You can easily see how much you get when couatl.exe occupies ca.118.MB - see the purple line in the picture (http://forum.aerosoft.com/index.php?/topic/78126-thessaloniki-x-out-off-memory-stackhash/?p=557129)
So as WebMaximus said - you should decide whether you need it.
-
Well, it is possible - but this is question to Umberto I'd say.
-
couatl.exe should be found in exe.xml
-
1
-
-
Please don't take me wrong altstiff - it's definitely not meant like "your fsx - your problem".
This is more like a process how to identify what could be improved with what effect.
I'm convinced that once there is identified what steps are necessary to do to get significant result then Aerosoft will for sure present it - it's in their own interest ;-)
But one very important point - it is not necessary to remove DLLs - they can be just disabled!
And if this has significant effect I can imagine it would be possible to write an SCE-like editor to allow users to disable/enable DLLs based in their needs.
-
For whatever it is worth to you, my dll.xml is still the same and my VAS issues are no more. Same goes for my FSX.cfg, it's exactly the same one I had when I was having OOM issues. I think you are chasing a red herring when blaming and looking at those things.
Well, I do not have much info of how much memory each of those DLLs consume.
More than that - I do not have many ORBX sceneries so I'm bit on dodgy ground here, but it looks to me that one loaded ORBX's ObjectFlow library could take aprox. 8MB of VAS.
When I'll take it as an average, then 60 loaded DLLs could easily get over 0.4GB... So I'd say it's worth to give it a try and to disable unnecessary DLLs.
That said, I don't think it's not chasing red herring - I guess it is more like Aerosoft is trying to help and find whatever the problem could be...
-
2
-
-
Danke für ein tip!
-
Check the PM - waiting there for you from yesterday
-
Liz, try to follow Anton's way
-
Liz
I confused myself - your order was OK (putting OSM Facades to folder called "zzzeurope") see here - http://wiki.x-plane....ion&redirect=no
But what I realized there was one more thing which you probably didn't - to put an "Exclude" DSF file in between the Zurich DSF and OSM Facades DSF.
The "Exclude" DSF is just empty DSF including only excludes (those types you need - so facades in our case).
And the order should looks like this (sorted alphabetically):
A - Zurich scenery's DSF
B - Exclude DSF
C - OSM2XP Facades DSF
Hope this helps.
-
My German writing is at least to say not too good, so I try in English.
I downloaded the europe OSM scenery package and put it in the customscenery folder with the name zzzeurope. The scenery perfectly shows up in X-plane but there is an issue with the airports Zurich and Lugano which I purchased from Aerosoft.
The OSM buildings are also on the ramp of these airports and show up inside other buildings as well. I tried to define some exclusion zones in WED for Facades which worked nicely for the OSM buildings but unfortunately the airport buildings in the Zurich/Lugano package disappear as well.
Am I doing something wrong by defining the exclusiion zones or is it just not possible for these airport packages to solve this?
Hope somebody can help me out as I want to keep the OSM AND the very nice Aerosoft airport as well.
Answering in German language is OK as I can read german very well.
Regards,
Lizz
Hi Liz
I'd say your idea of exclusion is not wrong, but the OSM2XP data should be "under" the airport files. Could you try to change the name of the folder 'zzzeurope' to something what is in alphabetical order prior the Airport scenery?
-
Sorry for delay max_mts.
Yes, we plan to update Keflavik scenery after we'll finish Prague Airport.
-
Hallo. Ich habe jetzt die AI Flugzeuge runtergeladen und im XPlane Menü eingefügt. Nur "liegen" die Flugzeuge jetzt auf mir uns verteilen sich nicht an die einzelnen Gates. Muss ich noch irgendetwas einstellen?
Dankeschön.
Gruß
Hi
I'm sorry to answer in English but I'm better in German reading then writing
It's worth to read Chris' article together with comment to that:
-
Didn't we miss something between 209 and 300? ;-)
-
Looks VERY nice
-
I guess Martin 2-0-2 should be favorite:
but as I'm not sure whether form "two-O-two" will be accepted, the AS/SA 202 Bravo is a good replacement:
-
Transall C-160:
-
Aero L-159:
-
A mandatory C-152:
-
A mandatory C-152:
-
Avia B-122:
-
Tupolev Tu-104
Thessaloniki X City Configurator [v3.0] (if you have OOM issues)
in Aerosoft Scenery
Posted
Sure, it is.