Jump to content

Thessaloniki X City Configurator [v3.0] (if you have OOM issues)


EmilG

Recommended Posts

  • Replies 302
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I am sorry but I feel this is not fair.. we have been working so much for you, developer´s have too (them most ofcause in developing it). Some of the request´s you set, would make us wounder do you on

Hi guys, Small patch for those who might have memory related issues with PMDG heavy aircraft. Please shut down FSX and then run the .exe file and select installation type: LITE This should

I just want to get something in the air here. People are funny when they have an issue. The immediately think, well if I have it, others must have it! And the product is broken! I fall into th

Posted Images

please drop the tweaks.

[bufferPools]

RejectThreshold=131072

[JOBSCHEDULER]

AffinityMask=84

..

ALLOW_SHADER_30=1

..

TextureMaxLoad=30

..

SWAP_WAIT_TIMEOUT=2

..

SmallPartRejectRadius=4.0

..

MAX_ASYNC_BATCHING_JOBS=3

That's what I choose on the website:

post-12207-0-72773100-1391108375_thumb.j

Additional question: When I did my 1st flight, I was approaching rwy 10, although this one was not active set in the Configurator. Could this also be a problem?

Attached both cfg files

fsx.txt

fsx_bojote.txt

Link to post
Share on other sites

I did deactivate them from the scenery.CFG list (but not deactivated from the serials via the FSDT menu in FSX if that is what you mean?) but haven't had to reactivate them yet (until I plan on flying into them that is).

Are you saying I will see trouble when I do?

Well... yes i think so. Already got this problem. But there is probably a proper way to avoid this issue.

but are we reducing a lot of VAS by deactivating FSDT airports ? That's the question.

best

Link to post
Share on other sites

well the so called program for registration of the airports has as far as i remember A section of settings dont know if that can be a clue as there you can edit stuff directly in the FSX.cfg as well as some other stuff.. so i wounder if there is something there that might beable to have a effect. now that i see you run that dll. By the way never my favor program of registration any way...

I just wounder if there could be a conections about settings

Link to post
Share on other sites

Well... yes i think so. Already got this problem. But there is probably a proper way to avoid this issue.

but are we reducing a lot of VAS by deactivating FSDT airports ? That's the question.

best

I was not aware that deactivating FSDT sceneries from the scerney.cfg library and then activating them again later would cause problems.

As I said, the less stuff you have active in the scenery.cfg equals the less sceneries loading up (even if you're not flying near them) and the less impact it would have on your VAS.

Mind you I had many sceneries active before I tried this technique.

And I have not tested and I am not sure if leaving just the FSDT airports active along with the airports I am using (in my example flight of LGTS - LGSK) would give the same results as not having them active would

does this make sense? :D

I am not sure how much of an impact active FSDT airports have on the VAS, even when you are not flying anywhere near them. I suspect deactivating ORBX areas and photo real areas had the largest impact on my VAS footprint to be honest.

I did post this over at the FSDT forums to get a definitive explanation from the source>>

http://www.fsdreamteam.com/forum/index.php/topic,9848.0.html

EDIT: This is NOT an issue according to Umberto over at FSDT (see the link above)

Link to post
Share on other sites

OK, had a succesfull filght with AXE from EDDM to LGTS rwy16 with the follwing parameter:

- no weather

- LGTS set to "Lite"

- fsx.cfg as in my other post (Venetubo Version)

- sceneries and addons: MA Munich, VFR Germany, Austria Pro (old version), FTX Global, FEX, FSGlobal Ultimate, AES, FSUIPC

After shutting down the engines at the gate 660MB VAS left. VAS was quite constant during the whole flight at 1.4GB and started droping when LGTS got loaded, landed with 730MB left and then remaining VAS oscillated between 530 and 660 MB while taxiing to the gate. fps where absolutely excellent (17-20 in windowed mode which is about 20% below full screen mode in my case)

Next flight will be done with real weather (ASE).

Link to post
Share on other sites

Strange...

With these settings:

  • Thessaloniki X set to default.
  • Time set to dusk.
  • Weather set via FSGRW.
  • PMDG 737-700 NGX set to High res VC, Model and Displays. Terrain display turned on
  • FTX Global Base pack.

My VAS never exeeded 3,2 GB

My FSX settings are:

Graphics section:

  • 1920x1080x32
  • FPS Locked at 30
  • Global texture resolution: Max
  • Preview DirectX 10: Off
  • Lens flare: Off
  • Light Bloom: Off
  • Advanced animations: On

Antialiasing and Anisotropic filtering controlled via Nvidia Inspector

Aircraft section:

  • Show tooltips: On
  • High resolution VC: On
  • Aircraft casts shadows on the ground: On
  • Aircraft casts shadows on itself: Off
  • Aircraft landing-lights illuminate ground: On

Scenery section:

  • Level of detail: Large
  • Mesh complexity: 100
  • Mesh resolution : 5m
  • Texture resolution: 15cm
  • Water effects: Low 2x
  • Scenery complexity: Extreme dense
  • Autogen complexity: Dense
  • Ground scenery: Off
  • Special effects detail: Medium

Weather Section:

  • Cloud draw distance: 60mi
  • Thermal visualization: None
  • Detailed clouds: On
  • Cloud coverage density: High
  • Download winds aloft data with real-world weather: On
  • Disable turbulence and thermal effects on aircraft: Off
  • Rate at which weather changesover time: No change

Traffic section (My Traffic 2013 installed):

  • Airline Traffic density: 25
  • General aviation Traffic density: 15
  • Airport vehicle density: None
  • Road vehicle density: 16
  • Ships and ferrys density: 16
  • Leisure boats density: 10

The only FSX.cfg tweaks I use:

[GRAPHICS]

HIGHMEMFIX=1

[Display]

TEXTURE_BANDWIDTH_MULT=70
WideViewAspect=True

[Main]

FIBER_FRAME_TIME_FRACTION=0.25

[JOBSCHEDULER]
AffinityMask=7 (I know - normally this should be 14, but the Majestic Dash7-Q400 runs smoother with 7)

[bUFFERPOOLS]
UsePools=1
Poolsize=8388608
RejectThreshold=126976

My system:

i7 3770 @3.4 Ghz (No OC)

8 GB RAM

Nvidia GTX 560 1GB

Win 7 64bit Home edition

Finn

Link to post
Share on other sites

Well... yes i think so. Already got this problem. But there is probably a proper way to avoid this issue.

but are we reducing a lot of VAS by deactivating FSDT airports ? That's the question.

best

Hey Dom,

Been using SCE for a couple of months now with both FSDT and FlightBeam airports, and have only 2 or 3 times seen an issue, and those only at FSDT's Zurich airport, where I began the flight there at LSZH. I had missing buildings, but a simple close out and restart of FSX solved it. Did you encounter issues at any other of their airports?

Link to post
Share on other sites

Hey Kyle, I am still not using SCE (but i will). I can just tell that i expercienced issues with some FSDT american airports when i uncheck them in the FSX library. If i reactivate the scenery, FSaddon manager says : airport installed but not active.

But, guys, you know that FSDT is top notch programming, i am shure they already thought about this. I will read what Umberto says about that. thanks Alstiff.

best

Link to post
Share on other sites

I did post this over at the FSDT forums to get a definitive explanation from the source>>

http://www.fsdreamteam.com/forum/index.php/topic,9848.0.html

EDIT: This is NOT an issue according to Umberto over at FSDT (see the link above)

Just read that post over in FSDT's forum and found the explanation how the VAS footprint (and memory management) can be very different between different airports depending on how much the airport scenery relies on .BGL files. Didn't know about that before and if I understand this correctly that would also mean VAS usage isn't all about math like has been said in here many times but it's also about what techniques are used creating the scenery.

Thanks for the link!

Link to post
Share on other sites

Just read that post over in FSDT's forum and found the explanation how the VAS footprint (and memory management) can be very different between different airports depending on how much the airport scenery relies on .BGL files. Didn't know about that before and if I understand this correctly that would also mean VAS usage isn't all about math like has been said in here many times but it's also about what techniques are used creating the scenery.

Thanks for the link!

Yeah it was very informative for sure. And that is the great thing about a thread like this, users working together in a combined effort for a better sim experience.

Link to post
Share on other sites

Yeah it was very informative for sure. And that is the great thing about a thread like this, users working together in a combined effort for a better sim experience.

I fully agree, these are the kind of discussions you really learn from and gain experience!

Link to post
Share on other sites

Made another test with 2 different fsx.cfg:

- ver. 1 vanilla, with only highmemfix applied

- ver. 2 with Bojote's tweaks:

attachicon.gifvenetubo.jpg

Result: ver. 2 gave me only a drop of ~200MB versus ver.1 with nearly 1GB

Strange, isn't it?

No, almost all these tweaks increase buffers etc and increase memory to get a better view. As I keep saying, a default FSX.cfg (with highmem tweak) will almost always give the best overall results and stability.

Btw, we have now looked at many dll.xml's etc from people who are low on memory. We found that some of them have 60 or more entrees (a default FSX has 6 of which some can be removed). Some of these DLL's are large and some are not unloaded when they are no longer needed. Some are also loaded on FSX startup even though you are not using the aircraft of airport they belong to. We have also seen some fsx.cfg that has stuff in there that was only for FS2004 and a lot of people has stuff there that was only useful for FSX pre SP1.

Link to post
Share on other sites

No, almost all these tweaks increase buffers etc and increase memory to get a better view. As I keep saying, a default FSX.cfg (with highmem tweak) will almost always give the best overall results and stability.

Btw, we have now looked at many dll.xml's etc from people who are low on memory. We found that some of them have 60 or more entrees (a default FSX has 6 of which some can be removed). Some of these DLL's are large and some are not unloaded when they are no longer needed. Some are also loaded on FSX startup even though you are not using the aircraft of airport they belong to. We have also seen some fsx.cfg that has stuff in there that was only for FS2004 and a lot of people has stuff there that was only useful for FSX pre SP1.

I know my dll.xml has lots of entries but in my case this was not the issue for having low VAS upon loading. My problem was having too many sceneries active in the Scenery.CFG.

And removing unused scenery from the CFG had the largest impact (like night and day, over 1GB of extra VAS).

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.

This tip of shutting off unused sceneries should be made into a sticky as it made a world of difference for me (and has helped many other users as you can see, this tip even made it into the PMDG 777 manual).

Link to post
Share on other sites

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...

Link to post
Share on other sites

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...

But the focus seems to be only on that, and it took other users to suggest disabling sceneries to me to find a fix (and I thanked them for pointing me that way).

Instead of telling users to "get their sims in order" maybe it would be more productive to have some suggestions on how to do it?

Such as removing dll's entires from your dll.xml, and for those who don't know, maybe explain how to do it, or suggest disabling scenery entries if you are not using them.

Link to post
Share on other sites

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.

Link to post
Share on other sites

Speaking about the dll.xml file, one thing I'm not sure if I understand is how the backup files are used. This doesn't really have anything to do with Thessaloniki so sorry for drifting away a bit but since the contents of the dll.xml file can be of importance to the success rate running the Thessaloniki scenery I hope you'll bear with me. Let's assume the following scenario:

I start by installing 5 addon sceneries named A, B, C, D, and E in that order. As a part of the installation process for each of these addon sceneries a backup of the dll.xml file is made showing what dll.xml looked like before the installation of the new addon scenery. After all 5 addon sceneries are installed I decide I no longer want addon scenery C. When I then uninstall addon scenery C how will the dll.xml file be restored?

If the uninstall program for addon scenery C simply overwrites the current dll.xml file with the backup that was made during installation any entries in dll.xml done by the installation of addon scenery D and E will of course be lost since these were not yet installed at the time addon scenery C made it's backup of dll.xml.

Or...let's say I uninstall addon scenery C and then later on I also uninstall addon scenery E. Looking at the backup of dll.xml that was made by the installation program for addon scenery E, at that time also addon scenery C was installed. Wouldn't that mean if I uninstall addon scenery E and it's backup off dll.xml will be restored I will end up with a dll.xml that again include the entries made by addon scenery C although I no longer have that installed?

Reason I came to think about all this was that I manually removed an entry from my dll.xml file for an addon module that no longer is in use. However I then noticed I have some 10-15 backups of dll.xml made by various other installation programs. This made me think that if I want to make sure this entry I manually removed from my current dll.xml file will stay out of my dll.xml file I must manually also remove it from all the backups made of dll.xml. If not when I decide to uninstall one of these other addons and they use the their backup of dll.xml the entry I manually removed will be back again.

Hmm...guess most of you are as confused by now after reading this as I am after writing it ;) but maybe (and hopefully) there is an easy explanation to all this I just haven't thought about?

Like I wrote in the beginning I find it rather important to fully understand how all this works if you want to make sure you maintain a clean and tidy FSX installation always performing at it's best both when flying to LGTS or elsewhere :D

Link to post
Share on other sites

Those backup files got nothing to do with the uninstall process, as it would be fatal to simply role back to a file that is also altered by other programs.
The reason for those files being created, is simply best practice to make a backup of a file you are going to change. Same, when somebody asks to change something in fsx.cfg "but please make a backup before".

So a tool to deactivate entries in the dll.xml could be really usefull similar to SCE.

IMHO not necessry. see this post: http://forum.aerosoft.com/index.php?/topic/78173-thessaloniki-x-city-configurator-v30-if-you-have-oom-issues/?p=559704

Link to post
Share on other sites

I always disable the sceneries i don't use before the flight with the scenery editor software and still the oom's persist

Enviado do meu GT-I9505 através de Tapatalk

I think it was somewhere in this thread I wrote before that how much of an improvement you'll see disabling scenery comes down to what kind of scenery you have installed. You'll mostly benefit from disabling scenery if it's photo real scenery and not much if not.

When I tried the SCE in the past it only gave me about 100 MB extra VAS after disabling about 35 payware addon airports some of them very complex like LFPG, EHAM, EGLL etc but still...this only gave me another 100 MB. However I still think the SCE is a very nice tool since it will allow you to manage your scenery library in a very easy fashion as has already been mentioned. In your case (and in mine) I think there must be something else causing the high VAS usage and especially @ LGTS.

In my case I think it is a combination of other addons I use like FTX Global (with 3D lights enabled), ASN (with enhanced overcast conditions and a CDD of 150nm), UTX Europe, SceneryTech and not sure but maybe also FS Global Ultimate X mesh has an impact on VAS.

Still haven't had the time to do a complete second flight into LGTS after applying the ver 3 fix using the LITE II mode but at least it looked very promising when I did some quick tests right after I installed the fix so I think (and hope) with this latest fix I'm good. However just out of curiousity I will also do some more testing disabling 3D lights in FTX Global, temporarily disable the enhanced overcast option in ASN etc just to see how much difference it does to the VAS value.

Link to post
Share on other sites

I have disabled all sceneries in fsx that i don't use in the flight. Yesterday, VABB-LGTS only this two sceneries active + ftx global + vector + road lights + orbx trees + ASN (overcast day) + PMDG 777 + LGTS LITE (v3.0), maybe i have to try use LITE II, to see if i have any differences

Link to post
Share on other sites

Those backup files got nothing to do with the uninstall process, as it would be fatal to simply role back to a file that is also altered by other programs.

The reason for those files being created, is simply best practice to make a backup of a file you are going to change. Same, when somebody asks to change something in fsx.cfg "but please make a backup before".

So a tool to deactivate entries in the dll.xml could be really usefull siilar to SCE.

So when it comes to removing stuff from your dll.xml file for example that is all up to the intelligence of the uninstall program?

Reason I ask is I've seen examples where entries have been left after the actual addon has already been uninstalled and if the leftovers consist of an entry in dll.xml and also the dll file itself obviously that's not so good since that mean you will be keep loading something not needed anymore.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Guest
This topic is now closed to further replies.



×
×
  • Create New...