Best place to place add-on scenery?

[ilovetofly 1]

Where do you recommend to place all add-on scenery? FS9 has a scenery folder with sub-folders (e.g. world). then there is an "addon scenery" folder with subfolders. It seems that all of the designers have different instructions as to where to install their scenery. However, with so many different ones, it can be confusing as to where a file may be stored. Can all of them be placed in just one file? Your fine help will be appreciated

[arno 1]

It does not matter, as long as you refer to the correct folder in the scenery library. You can place the subfolders in the scenery or the addon scenery folder. You could even place all your scenery outside of the main FS folder (that is what I do).

[wsieffert 0]

Arno is correct in saying you can place them most anywhere. However, I caution making more sub-folders in the Addon Scenery folder, e.g.:H:Program FilesMicrosoft GamesFlight Simulator 9Addon SceneryH:Program FilesMicrosoft GamesFlight Simulator 9Addon SceneryMYSCENERYH:Program FilesMicrosoft GamesFlight Simulator 9Addon SceneryMYSCENERYSceneryH:Program FilesMicrosoft GamesFlight Simulator 9Addon SceneryMYSCENERYTextureThe reason I don't recommend adding them in this location is the Addon Scenery folder is listed as an active folder in the Scenery Library listing, as shown from the scenery.cfg file:[Area.038]Title=Addon SceneryLocal=Addon SceneryLayer=38Active=TRUERequired=FALSERemote=I believe it is better to place the new/addon scenery folders in the:H:Program FilesMicrosoft GamesFlight Simulator 9Sceneryor a new folder similiar to the following:H:Program FilesMicrosoft GamesFlight Simulator 9MYSceneryPlaced in this manner doesn't cause the Addon Scenery folder to be addressed twice in the listing. The below is an example of new/addon scenery placed in the Scenery folder:H:Program FilesMicrosoft GamesFlight Simulator 9SceneryKMCO2004orH:Program FilesMicrosoft GamesFlight Simulator 9MYSceneryKMCO2004The resulting scenery.cfg entries would be:[Area.039]Title=KMCO2004Local=SceneryKMCO2004Remote=Active=TRUERequired=FALSELayer=39or[Area.039]Title=KMCO2004Local=MYSceneryKMCO2004Remote=Active=TRUERequired=FALSELayer=39I believe MS intent of having the Addon Scenery folder already active in the scenery library listing was for the purpose of conveniently adding scenery without having to have any knowledge of the scenery library functions. As a matter of fact, the Addon Scenery folder has been around for sometime in prior MSFS and was not used to a great extent. I also find it easier for scenery maintenance to separate the various AFCAD files from the addon scenery files.Most users don't realize that the AFCAD files can reside in other than the Addon SceneryScenery folder. As more scenery design tools become available, I believe you will see the designer's placing the AFCAD information internally with their other files, just as MS has done with the default scenery files.W. Sieffert

[arno 1]

Fully agreed. We also place our AFCAD files in the normal scenery folder of our project. It are just BGL files anyway.On my second machine (only used for designing, not for serious flying) I have very little addon scenery installed and there I have placed them all as subfolders in the Addon scenery folder. I have never seen anything negative from this.The fact that the Addon scenery folder is already loaded does not give trouble, as that entry only looks for the Addon sceneryscenery and Addon scenerytexture folder, all other subfolders are not scanned by it.But I agree that to make things easier to maintain it is better to place them somewhere else.

[ilovetofly 1]

Thanks for the info and help. I'll see what I can do.

[scott967 62]

Just to be contrary, I have always put my scenery folders in addon scenery. The reason is that in Fs2000 and 2002, when you did an "add scenery" the browse box opened with the addon scenery folder highlighted (at least in Win 98), so it was easy to drill down to the new folder to be added. AFAIK, the only thing the "addon scenery" entry in scenery.cfg does is activate addon sceneryscenery and addon scenerytexture, which I leave empty.I agree that in FS9, the behaviour of the browse function no longer defaults to addon scenery, so my reason for doing this no longer exists, other than teaching the old dog new tricks.The various auto installers are liable to put scenery anywhere, that's why I am not a big fan of that install method.scott s..

[Bill Womack 7]

I'm with you, Scott. I've always put my addon sceneries into discrete folders within the FS Addon Scenery folder, and never had a single problem with it. Is there a demonstrable problem with this, or does it come down to preference? Preference is, well, preference, but if there's a real problem I'd like to know a.) what it is and b.) why I've never suffered from it that I know of.thanks,

[wsieffert 0]

Hi Bill,I don't think there is a problem. My concerns are over cluttering the basic Addon Scenery folder with new subfolders and priority levels of the Addon SceneryMYScenery(s) folders.I don't know of anyone experiencing problems but I prefer to use the Scenery folder vice the Addon Scenery folder.My usual mode to is let programs like SceneGenX or Airport for Windows compile and place my beta bgls into the Addon SceneryScenery folder until the project is finished then move those files to a dedicated folder within the Scenery folder.As you say, preference!!W. Sieffert

[Guest GerrishGray]

Guys, this really is just a matter of personal preference and your preferred style of "good housekeeping". As Arno said in his first reply it makes ABSOLUTELY NO DIFFERENCE what path, or even disk drive, you use for the ..scenery folder that holds your BGL's as long as that path is listed as an 'area' in your Scenery Library settings. The only difference between different paths is the 'priority' you assign to them in the Scenery Library - paths/areas with higher priority will take priority over those with lower priority and, in particular, exclude files and 'switches' only exclude stuff from lower priority areas. This 'layering' of different scenery priorites was VERY important in earlier versions of FS but tends to be somewhat less important these days except when using excludes or using different sceneries that overlap the same area (such as overlapping landclass or mesh sceneries).And of course there is a limit of 331 separate areas/paths.The actual path to each area is of NO signficance whatsoever and will have NO effect on performance in any way.Placing texture files is a different matter. Basically they can be put in one of two places: EITHER in a 'sister' ..texture file pairing the local ..scenery folder, OR in the 'main' texture folder along with thousands of other texture files. When FS is asked by a BGL file to load a particular texture, it looks first of all in the local sister ..texture folder (if there is one), and then in the main texture folder if it couldn't find the file first time. If it can't find the file it needs in either of those locations, it will display the object as an untextured white box - it will NOT look anywhere else. Generally speaking the rules should be1. Place unique local textures in the local ..texture folder2. Place 'shared' or 'stock' textures used by multiple sceneries in the main texture folder to (a) avoid duplication, and (:( avoid wasting time, memory resources, and framerates on loading multiple copies of the same texture from different folders.There are a couple of other things to remember though:(a) landclass scenery can usually only be placed in a ..scenery folder that has NO matching ..texture folder - not even an empty one. This often means that landclass scenery has to be placed into dedicated 'areas'/paths of its own.(:( Textures for library objects must be placed either in texture or in the ..texture folder local to the ..scenery folder containing the library BGL. The latter choice can lead to problems, however, if there happens to be more than one copy of the same library object's BGL in different folders and FS may end up unable to locate the required file, with the result that the object(s) are displayed without their texture(s). If this happens to you, move the library object's BGL into the scenerybasescenery folder (or scenery for older versions of FS), DELETE any other copies of the same BGL from other ..scenery folders, and move the texture(s) to texture.Sorry for the long and complicated post, but I see this discussion come up SO often that I thought is was worth explaining the REAL rules!Kindest RegardsGerrish

[Holger 0]

Howdy,very nice summary, Gerrish - thanks for writing this up!Two additions (the second one you alluded to already):1. With mesh add-ons the priority in the Scenery Library is reversed! This is only of interest for (add-on) mesh of the same LOD but it means, for example, that someone creating a LOD9 add-on mesh for Africa would still have the LOD9 default Kilimanjaro override the add-on mesh, as the default mesh resides further down in the Scenery Library (Default Terrain). Guess the FS design team really like their local high-res mesh files ;-)2. The landclass-with-no-texture-subfolder rule has an important exemption: if the designer supplies ALL of the textures tiles called by the landclass/waterclass file there will be no memory leak. This is probably not a common occurrence but, I for one, am working with these local texture sets as they provide better control for my particular landscape scenery. Cheers, Holger

[Guest GerrishGray]

Hi HolgerI didn't mention your second point about landclass files on purpose because (a) it is so specialised and I didn't want to complicate an already long first post, and (:( it leads to an extended load time for FS. In FS2002 you could use this technique in a somewhat neater fashion by moving all the ground texture files and AGN's from worldtexture to texture - it was not then necessary to copy everything to the local ..texture folder as well, only the AGN's plus any CHANGED textures. But FS2004 is somewhat different (mainly because I pointed out the anomaly to MS and they seem to have fixed it in a manner different to what I intended!) - although I haven't tested exhaustively.This technique opens up the possibility of having a completely local landclass system for a particular area, with different textures, different AGN's, different Autogen building texture sheets (but not trees unfortunately), and, with the new Autogen SDK, different Autogen objects too. I have had a plan to produce localised Autogen scenery on this basis ever since I discovered the possibility in the early days of Autogen in FS2002, but have just never had the time to do anything about it. It would even be possible to create localised trees (my particular passion, as everyone knows by now!) by using Autogen objects, although this needs a rather crafty trick if you want to have localised trees in woodlands/forests and not just as street/garden trees in towns, and the tests I have done so far suggest that it may impact rather significantly on frame rates. I was particularly hoping/intending to tackle the tropical trees problem (palm trees, rain forests etc) using this technique if only I didn't have a business to run and had more time ...!Kind RegardsGerrish

[Holger 0]

Hi Gerrish,interesting points again.I too discovered the increased loading times when builing up my local landclass scenery/texture combination. It's not as bad as photoreal but definitely noticeable.My localized project includes custom LC textures and agn modifications. With the latter, I exchanged most of the deciduous trees in settlements for coniferous trees - more typical for the northern Pacific coast. Unfortunately, there's a big BUT: the slope-induced replacement class for all "wet" settlement types is forest type 26, which is pure deciduos. Since the vegetation agn files are not readily accessible my new settlements with conifers remain surrounded by deciduous slopes - grrr! Can't think of anything that would fix this.Cheers, Holger

[Guest GerrishGray]

There's no solution I'm afraid without decoding worldlc.bgl. Christian Stock managed to locate the table that maps landclass numbers to textures under normal circumstances but not for slopes, and that is as far as anyone has got as far as I know. The AGN's for the vegetative textures are also almost certainly encoded in this BGL, but identifying them and making sense of the file structure is another matter.I am afraid that ideas of 'open source' seem to have been mostly dropped by MS of late, so I very much doubt that they are going to help us ...RegardsGerrish

[Holger 0]

Hi Gerrish,to continue on the off-topic thread...I actually had partial success last night with getting local landclass textures of settlements without surrounding deciduous trees. I made a mistake in re-naming agn files (isn't that always how "progress" happens?) and out of sudden had houses and conifers across mountain slopes that were supposed to be wetlands. It turns out that some of the classes that don't have any autogen by default (e.g., 8, 19, or 42) can be assigned custom autogen. Since most of these "bare" classes don't change with steeper slopes, the custom autogen works well. In fact, it allows to place houses on hillsides where the default settlement landclasses don't (see screenshot). It's only a partial victory because these "bare" classes don't read lightmaps (and some only two or three seasons). However, for my purposes that's okay since I was mostly interested in outlying settlements with scattered houses, which aren't much of a light source anyway. What has been helping me a lot is a draft table by Joachim ("Jobia", the German scenery expert of the seasonal CTD patch fame), which lists the two levels of slope replacement classes for all landclass types. Let's hope he'll publish this document soon.Cheers, HolgerP.S.: I believe that worldlc.bgl is just the basic landclass allocation file, whereas the more interesting information is hidden within lclookup.bgl, also located in SceneryBaseScenery.http://forums.avsim.net/user_files/90437.jpg

[Guest christian]

I'm glad I read this thread, I almost didn't. Gerrish is right, I translated the landclass mapping in lclookup a long time ago (he accidently mixed the name up I believe), but only for land and waterclasses. There is a whole lot of other stuff, which I presume is slope and agn related stuff, and probably also the season related mappings. I'm quite sure that there is a 'bug' in the lclookup table causing the CTD, which I luckily haven't had yet (probably because where I'm flying). I'm glad to share what I know, if anyone wants to have a go at the lclookup table.Cheers, Christian