Sign in to follow this  
Guest christian

Best place to place add-on scenery?

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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,

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Thanks Christian. Yes, I did indeed mean lclookup.bgl, worldlc.bgl is of course simply the landclass scenery file for the default FS world.Holger, that's a fantastic discovery regarding other ground texture numbers that can take AGN's. Now you have uncovered it, it makes sense: the ground textures that have vegetation AGN's built into lclookup.bgl won't accept custom AGN's because they 'find' the lclookup.bgl version first; the one's with no vegetation and no default AGN in lclookup.bgl WILL accept custom AGN it seems - fancy doing some more tests to verify that? It's very exciting because it opens up the possibility of having a lot more custom landclasses in localised landclass scenery by re-using some of these types.If I didn't already have a business to run I reckon I could spend my whole day remapping the world with custom Autogen containing local building styles and all sorts of different trees etc. What a hobby. Roll on retirement, eh!And, of course, if someone could crack the rest of lclookup.bgl that would open up loads more possibilities too. I suspect that FS already have notions for expanding the use of Autogen etc. as FS develops, because they certainly seem to have created a lot of currently unexploited possibilities in the underlying system.CheersGerrish

Share this post


Link to post
Share on other sites

Hi all,Gerrish, the image above shows LC#19 (025b) with custom settlement textures and agn. Thus far, I have tried classes 8, 19, 42, 53, and 69. The last one didn't seem to work but it only has five variants and two seasons to begin with.While there are quite a few more classes without autogen, I've restricted my first round of testing to classes that don't switch to a different class at intermediate slope levels (which would likely lead to strange visual contrasts). I also haven't tested any of the three-digit single-textured classes (e.g., 131, 138, 141) but they would have limited use anyway.Well, at the very least we'll have about four extra classes to use in custom autogen projects, if you keep in mind the basic limitation of no night maps.Cheers, Holger

Share this post


Link to post
Share on other sites

Wow! I didn't expect this question to generate such a thread. Much of what is mentioned is beyond me as I just have no interest or capabilities in programming. However, another question since this created quite a conversation. I downloaded all of the USA files from FSGenesis. Is there a way to put all of these into one folder and have FS9 see it in the scenery file so that I don't have to load all of the BGL files separately? This way I could just have installed one folder with all the necessary BGL's. Thanks.

Share this post


Link to post
Share on other sites

Hi,As a matter of fact, I once replaced all my textures with bitmaps with numbers to determine what texture was used depending on the LC and slope. I did that on FS2002 and updated the data for FS2004 and used it to create an "optimized" LC for France with vineyards, industrial areas, and far better mountain classes (using the gradient map at its best). Recently, I've added classes to represent small towns in the mountains and used it to add some 30 ski resorts. Really nice to fly in the mountains now!I have a rather complete Excel worksheet describing this here:http://arnaud.clere.free.fr/FlightSimulator/landclass.htmlSorry, the page is only in French but the Excel worksheet that is included with the sources should be easy to understand, have a look at :http://arnaud.clere.free.fr/FlightSimulato..._france-src.zipThe LC by itself can be found here. Just follow the very last link on the page to download it freely.http://www.francesim.com/Articles.aspx?C=2...Enr=1243&Cpt=-1Hope it helps!Cheers,Arnaud

Share this post


Link to post
Share on other sites

Hi Luis,French seems to be your native tongue! I'll go on in English, otherwise most readers wouldn't understand.Basically, the Excel document contains one sheet describing for each class:- texture number used- default autogen- can the autogen be modified by modifying the .agnAnd this, for the:- steep slopes- gentle slopes- flat areasIt contains another sheet describing the textures:- Number of variations- seasons available- grid-like or not- existence of a lightmap- existence of a .agn- existence of a mask allowing precise merge of adjacent textures.From place to place, it contains some other annotations on the best use cases for the classes that may not be relevant to other areas than A.Is there anything special you would like me to explain with more details?

Share this post


Link to post
Share on other sites

Hi Arnaud,thanks for sharing that table, it is indeed an impressive piece of work! It's actually quite similar to Joachim's draft table so it allows for interesting comparisons.Thanks also for the link to your France LC project; I had an earlier version, which I liked very much, and I'm looking forward to installing the new; those vineyards look very realistic!My question is in regards to the discussion above about custom agn files for LC types that don't have autogen in default FS9. You say that the table contains a column for "can the autogen be modified by modifying the .agn". Maybe I'm not looking at the right column (e.g., Textures FS9 > column Q) but those classes to which I'm able to attach autogen - 002, 006, 025, etc - don't have an "X". Or perhaps you tried modifying only those classes that already have an agn file?Another question is regarding your comments in Classes FS9 > Column F "t056 non modifiable" and "t027 non modifiable". I assume that refers to the hidden autogen assignments?Thanks again for this great resource!Cheers, Holger

Share this post


Link to post
Share on other sites

Hi Holger,When I tried to add non-existing .agn files, they were not used. Maybe a problem when you're not in the B area ? I'll have to give it another try.Regarding the Excel sheet, that's right. Since adding new .agn was not working for me for France, I just listed what would be working for sure: modifying the existing .agn; and used that information to make better choices when transforming the textures to "create" optimized classes. Don't feel constrained by what's written in it. There are plenty of things you'd think impossible until somebody does it ;)Interestingly enough, modifying the existing 050b2*.agn does not work for me neither which is why I wrote it in red. I thought it was a packaging error of Microsoft.Regarding the 056 and 027, It's just that I'm using them for what they are in some optimized classes which means I must not change them. I made that choice more explicit in front of any other class using those textures to help looking for classes that can still be transformed. It is just a constraint for future lc_france_opt classes. That's the kind of compromise you need to do with a hard-coded class>texture map I guess.Cheers,Arnaud

Share this post


Link to post
Share on other sites

Hi everyoneThat was an excellent and meticulous piece of work Arnaud - well done and thanks. I have been able to add some extra info to my own Landclasses table as a result, and attach an up-to-date copy for everyone.http://forums.avsim.net/user_files/91196.zipOn my reckoning, the 'candidates' for adding .agn's to classes/textures that don't have them are 8, 19, 42, 50, 53, 56, 57, 59, 69, 95, 96, 97, 98, 99, 122, 129, 130, 131, 132, 133, 136, 137, 138, 141 and 142.From what you guys say, though, some may not work (perhaps because of data in lclookup.bgl that we don't understand?).Actually, I think some of the LC's 129/131-3/136-8 and the new 97/98/99 could be VERY useful if they do work because most of them are not widely used in the default scenery and they have no variation with slope - which would be handy for those who have been wanting to model mountain villages etc.Kind RegardsGerrish

Share this post


Link to post
Share on other sites

Some further thoughts:Many of the candidate classes for adding .agn files use texture sets without 'blend masks', which perhaps limits their utility for realistic modelling a bit. But, I wonder if we might be able to add blend masks to some of these texture sets, just as we can add .agn's to some of them ...?CheersGerrish

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this