Question for Umberto about Scenery.CFG and FSDT sceneries

[altstiff]

I recently discovered the benefits of SCE (Scenery Config Editor) and deactivating sceneries from the my scenery.cfg that are not needed for a particular flight.

This makes a big difference in Virtual Address Space usage for me. It saves me almost 1GB VAS using this technique, not to mention quicker loading times due to slimming down my ultra FAT scenery library.

For example, if I fly from FSDT CYVR to FT CYUL I would only activate those two particular sceneries in the scenery.cfg library

(as well as the default MS FSX stuff that is, of course, needed in the scenery.cfg).

My question is this:

Say I choose my next flight as FSDT KLAX to FSDT KDFW will they have issues with COUALT or do anything to my activation license? Will I see potential problems from having them omitted from the library in one session and then active again in another session?

[virtuali]

Say I choose my next flight as FSDT KLAX to FSDT KDFW will they have issues with COUALT or do anything to my activation license?

The activation is entirely unrelated to what happens inside FSX, you can even remove the scenery, delete all its files and even uninstall the whole FSX, it won't affect activation in any way. The only way to lose an activation is to change hardware or reformat Windows from scratch.

The only "limitation" you have when turning on/off stuff from the scenery.cfg, is that you must restart FSX to apply changes.

[altstiff]

Thank You Umberto.

I just wanted to confirm this as a poster over at Aerosoft said deactivating and then reactivating FSDT sceneries from the scenery.cfg could lead to issues with the sceneries not showing up once they are reactivated in the scenery.cfg.

http://forum.aerosoft.com/index.php?/topic/78173-thessaloniki-x-city-configurator-v30-if-you-have-oom-issues/page-6

See post #203 onward...

[virtuali]

See post #203 onward...

Well, that's the typical uninformed comment based on unfunded urban legends.

Couatl, for start, doesn't have anything to do with it, it would be the Addon Manager, because that's the one that reads the scenery.cfg to know if a scenery is installed, in order not to annoy you with a bogus "Trial is started" message, if you fly over an area that covers an airport, that you don't have installed or you just disabled momentarily. That reading is done only once when FSX starts, it won't continuously check your scenery.cfg for changes that happens while FSX is running and THAT'S also a good thing, because it won't try to constantly monitor that file for any changes, eventually triggering a rescan *while* FSX is running.

That's why, the only "limitation" is that you must restart FSX to apply changes but, I really HOPE you don't try to use an external editor to act on the scenery.cfg, while FSX is running! THAT would mean asking for trouble AND it won't make any difference to VAS usage, because even if you disable an area while FSX is running, lots of memory allocation has already been made, it's not just the things you "see" that takes memory but, for example, the caching of file names and the index of .BGL *boundaries* (Lat/Lon coverage) which ARE cached in RAM, for fast access so, you MUST restart FSX, in order to save THAT memory, which is a different one than the actual objects. If you have LOTS of scenery and many files, the VAS usage just for the directory name cache and .BGL boundaries might be significant.

So, assuming you do the right thing, and close FSX, use that utility to reconfigure the scenery.cfg and THEN start FSX again, it won't make ANY difference or cause any problems with our products, let alone with activation which, as I've said, is NOT stored anywhere in any of the FSX files. It's not even stored on a file, it's in your registry so, you can play in the foulest way with files and FSX reinstalls, it won't affect the activation in ANY way.

I really don't know how I could explain it any more clearer than this...

[virtuali]

As an addition to that, I'd say that, of all sceneries you have, the FSDT ones are probably the ones that you might keep always enabled.

This because, due to the fact that we have about 80% of the scenery NOT in .BGL format, but created programmatically on the fly ONLY when you fly in the airport range AND explicitly destroyed when you fly outside the range, it's guaranteed that their VAS consumption happens only if you use them and the memory is reclaimed if you go away from their range.

You don't risk having KLAX loaded while you are at KLAS, which CAN happen, instead, for every other scenery that uses .BGL entirely, so they are in the hands of FSX memory management and bugs.

On top of that, having so few .BGL files (we have some .BGLs, for things like mesh, AFCAD, etc.), we contribute very little to the growth of the overall .BGL directory and boundaries caches, while another scenery with many .BGLs in its scenery folder, has a larger footprint on it, so it would make more sense to disable it when not in use.

[altstiff]

See post #203 onward...

I really HOPE you don't try to use an external editor to act on the scenery.cfg, while FSX is running!

No I am not trying to do that! SCE runs outside FSX while it is not running. It lets you quickly and manually edit (with click and drag method) your scenery.cfg.

Umberto, SCE works so well (and is totally free) I think you should do a sticky for those users having VAS and OOM issues. It is that good.

I think the biggest problem for VAS/OOM issues is the amount of sceneries users may have installed. Some other users at Aersoft convinced me to try SCE and I am very glad I did.

SCE will change the way I sim.

I really don't know how I could explain it any more clearer than this...

EDIT: I get what you're saying loud and clear.

[cmpbllsjc]

As an addition to that, I'd say that, of all sceneries you have, the FSDT ones are probably the ones that you might keep always enabled.

This because, due to the fact that we have about 80% of the scenery NOT in .BGL format, but created programmatically on the fly ONLY when you fly in the airport range AND explicitly destroyed when you fly outside the range, it's guaranteed that their VAS consumption happens only if you use them and the memory is reclaimed if you go away from their range.

You don't risk having KLAX loaded while you are at KLAS, which CAN happen, instead, for every other scenery that uses .BGL entirely, so they are in the hands of FSX memory management and bugs.

On top of that, having so few .BGL files (we have some .BGLs, for things like mesh, AFCAD, etc.), we contribute very little to the growth of the overall .BGL directory and boundaries caches, while another scenery with many .BGLs in its scenery folder, has a larger footprint on it, so it would make more sense to disable it when not in use.

Because of that I never disable my FSDT or Flightbeam sceneries. I do however disable all my airports and photoscenery for areas I am not flying in. Although I just do it the old fashioned way and untick them in the scenery library instead of using an external editor. For me its just as simple and since I rarely have more than 5 to 10 airports or sceneries enabled at once it only takes me a second to go into the scenery library in the FSX UI and tick or untick the ones I am not using for that flight or series of flights.

[Rafal]

I just do it the old fashioned way and untick them in the scenery library instead of using an external editor. For me its just as simple

Same here. No need for any extra software to do it.

Even though many simmers keep writing disabling other sceneries does not influence VAS, my experience is different.
Plus if I one uses a lot of addon scenery, it should be remembered that sometimes there will be some extra problems with some of them.
I mean not only high VAS usage due to using photoscenery, but also some problematic textures or bgls (e.g. AFCAD files), which the user may not be aware of.
Disabling them takes most of these problems away. So my experience is that it is always smart to keep only e few sceneries active.
I used to check VAS usage regularly (now I rarely do it) and have seen noticeable differences with different numbers of sceneries active. Up to 1 GB!

For instance at the very moment I have 51 airports installed, almost exclusively in Europe (except for Yekaterinburg and Dubai).
But less than 20 are currently active in my scenery library, just those I mostly fly and those I am currently flying from/to.
Once I notice any memory problems (none right now), I will not hesitate to reduce this number further.

One more remark is I am not sure any external scenery managers are actually able to deal with full deactivation of airports.
The reason is some files are installed in different folders, for instance AFCAD, altitude and terrain bgls (but not only).
An example may be Aerosoft's Afd folder where some German airport files go, or the FSX Scenery\World\Scenery folder, which ususally collects quite a lot of new bgls.
Plus there are some scenery installers (hate them of course) which will replace some stock FSX bgls with new ones.

All in all, there is no perfect solution in the search for getting some relief to FSX, but I add my voice to deactivating unused scenery.

[altstiff]

The best part of SCE for me is the click-SHIFT-click-delete method that lets you delete many entries in a few strokes.

I have hundreds of entries (my old MSE V1 California files has over 80 on it's own!).

I save my base scenery.cfg with everything I own active, load it in SCE and then in a few clicks I can delete everything I don't need, hundreds of entries in a few clicks, and be left with just what I need active for the current flight I am doing (instead of manually clicking each one in FSX).

I was reluctant to try SCE at first due to the fact I didn't want it messing up my FSX "house of cards" but after using it and seeing how intuitive and simple it is I'm miffed at myself I didn't try it sooner.

I can't understand how this tip of deactivating scenery you are not using for the current flight isn't being hailed as the holy grail fix for VAS/OOM errors.

I know in my case it was too much of a PITA to do it manually with so many entries, SCE fixed that.