Scenery File Priority

[davidm]

Hello All,
It's been a very long time since I've been here and I'm still plugging away flying propliners (wouldn't want to fly much else). Anyway, over the past couple of months I've downloaded some scenery files (and installed them) and there seems to be no real problem running FS9. However, I don't want to screw up too much and jeapordize the Calclassic scenery that I have installed so I need to know the priorities for the scenery areas of the Calclassic scenery files. If I remember correctly some of the Calclassic scenery files must take precedence over other scenery files (by listing them before other scenery on the list of files) in order to work correctly. What I need to know is if I have to move my more recently installed files to a lower priority on the list or if I can leave them where they are. Thanks, ahead of time.
DaveM

[Wolfgang]

Hi,

I have it sorted this way:

1. Libraries ( RW12, EZ Objects etc )
2. Traffic
3. Classic Sceneries ( except Munich Riem )
4. Cal Classic Core
5. Cal Classic Landclass
6. Munich Riem Scenery
7 - xx. Addon Meshes, Landclass and default layers

Wolfgang

[Tom/CalClassic]

Hi,

Wolfgang has it correct for the classic sceneries (I suggest a different location for the libraries, but that really makes no difference). If you want a more detailed listing, check out the top of my Scenery page on the CalClassic site.

Hope this helps,

[Tom/CalClassic]

Here is FSAviator's reply. I find that putting the Landclass layers below the photo scenery layers is not really necessary, but it doesn't hurt anything:

SCENERY LAYERING IN FS9 - REMINDER

In FS9 when two sets of mesh with the same level of detail (LOD) overlap, which is very common if we have installed more than one third party mesh, the mesh with the *lowest* priority in the scenery library will be loaded and seen.

*This is a known bug in FS9*.

'Global mesh' must therefore be allocated a higher priority than 'local mesh' so that the bugged MS code actually loads the local mesh from further down the priority list.

All the 'mesh gurus' have suggested that FS9 users should identify their third party 'global mesh' and should move it to the very top of their scenery library with priority 1, 2,3 etc. Any local mesh acquired will then always be given a lower number and a higher priority by the FS9 bug.

Giving the very highest layering priority to global mesh (of any LOD) never causes a problem and may prevent loss of 'local mesh'. FS9 can 'recognise' mesh. It never displays mesh over any other type of scenery. FS9 auto discards low LOD mesh for high LOD mesh in the same area. The main problem is the layering bug when two meshes have the same LOD.

However by default FS9 recognises LOD 11 and LOD 12 meshes and will load them rather than LOD10 but displays them only with the fidelity of LOD 10 (38.3 metre elevation sampling) at run time to maximise framerates. LOD 11 and LOD 12 files are huge due to the extra data that FS9 will not use by default. Consequently lots of mesh whether global or local is compiled by developers using only LOD 10. Global and local mesh are quite likely to have the same LOD, but nevertheless different elevations having been compiled from different data sources. An airport 'flatten command', whether in the bgl code or in the scenery.cfg, may cause a huge depression or raised plateau if used with global mesh when it was designed to be used with a supplied 'local mesh' (or vice - versa).

I believe best layering practice in *FS9* is considered to be;

3P = third party = not supplied by MS

1) 3P Global mesh

2) 3P Object Libraries

3) 3P AI Traffic

4) 3P Regional mesh

5) 3P Local mesh

6) 3P scenery (which has its own internal priorities)

7) ALL Photo scenery

8) 3P Local Landclass

9) 3P Regional Landclass

10) Other MS default layers

The above assumes that we now use only freeware or payware mesh better than the default FS9 LOD for a given region. However payware and freeware scenery developers sometimes include a local mesh whose LOD is identical to the MS default Mesh. They do this to control elevation of the mesh around the featured airport(s) to avoid having the airport in a crater or on a plateau. If we still use FS8 scenery in FS9 we may even need to impose mesh whose LOD is lower than FS9 local default LOD. If we have 3P mesh whose LOD is the same or worse than default MS mesh LOD in the same location to force use of that 3P LOD mesh in FS9 we must create;

11) 3P LOD mesh (ONLY if 3P LOD <= local MS default LOD)

Apart from that it does not really matter where in the sequence we place regional and local mesh, but we must identify them and place all regional above all local so that the FS9 bug selects local. Global and regional mesh should always be released with a jpg which shows its coverage so that we can work out how to layer it versus overlapping mesh coverage.

We must do the opposite with regional and local landclass. FS9 has no landclass layer bug so for landclass local must be above regional in the on screen scenery library (higher priority).

Note also that in FS9 *within a single scenery folder* filenames also have reversed scenery layer priority. If zzz.bgl and aaa.bgl overlap then zzz.bgl will be displayed. Some developers consider this to be another bug. Note however that some developers tell you to merge their mesh with that of another developer in the original folder knowing that their zz******.bgl filenames will 'replace' (some of) the other mesh at run time and some mesh developers have also used this means to bug fix their own mesh. Within a single scenery folder numbers also convey display layer priority. Be warned some developers also use this reversed filenaming display priority in relation to Landclass layering.

If any of you are in the habit of renaming any bgls to make what they display more obvious you need to bear the above in mind. If any of you are in the habit of dumping more than one 'scenery release' of any kind, for the same region, into a single scenery folder (bad practice) you also need to bear this alphabetically reversed filename.bgl layering priority in mind.

FS9 reads up to 331 scenery layers (scenery folders) so most users have lots of scope to layer correctly, but we must remember there is a limit. Remember too that the layer at the bottom of the text in your scenery.cfg may not be the highest numbered layer you have declared. Use the on screen library to check total declared. Beware you may be able to declare more than 331 layers, but no more than 331 layers will load. Only 'required' layers are guaranteed to load when more than 331 layers are declared and FS9 may not discard other layers in a way we perceive to be logical.

Of course we can have a scenery.cf1 for North America and scenery.cf2 for Europe, and scenery.cf(n) for elsewhere, each with 331 layers, each in 331 different scenery folders, renaming only one of them to scenery.cfg before we run FS9.

Finally FS9 makes other display decisions based on actual compiled LOD of mesh and those display decisions may cause various display problems when seen from different ranges if the 'correct' mesh was not loaded. To maximise display quality and avoid 'fake ridges' and 'fake canyons' that 'reconfigure' as we approach we may need to avoid using mesh compiled to LOD 11 or 12 in FS9 if a LOD 9 or 10 mesh is available. We cannot use scenery layering to force FS9 to use LOD 10 if higher LOD is present. LOD 11 and LOD12 mesh may also cause pausing as huge BGLs are loaded. That just depends on your computer spec and cache configuration, not on FS9.

WARNING - This post is highly specific to FS9 = FS2004 = FS-ACOF.

If you use a different flight simulator you need to research exactly how it works and its limits instead. Remember the official SDK will only ever tell you how the software was supposed to work.

FSAviator

[johnhinson]

Nov 19, 2008 12:42:16 GMT -5 Tom/CalClassic said:

FS9 reads up to 331 scenery layers (scenery folders) so most users have lots of scope to layer correctly, but we must remember there is a limit. Remember too that the layer at the bottom of the text in your scenery.cfg may not be the highest numbered layer you have declared. Use the on screen library to check total declared. Beware you may be able to declare more than 331 layers, but no more than 331 layers will load. Only 'required' layers are guaranteed to load when more than 331 layers are declared and FS9 may not discard other layers in a way we perceive to be logical.

I am puzzled by this statement. I currently have 1049 layers and have never seen any strange features or behaviour that would result from such limitations.

Unless FS9 is more logical than is suggested, by perhaps deliberately not loading remote scenery.

John

[emfrat]

Hi Tom -
Thanks for that advice from FSAviator. There are several interesting technical points there.
The whole FS9 scenery layering/priority thing has been a minefield since Day 1. In earlier FS it was good practice to review the scenery.cfg regularly and make sure the layer numbers were continuous. To solve what looked like the same type of problem in FS9, I went through that exercise and wrecked a very nice UK VFR setup. It seems you *can* actually trust the FS9 Add Area routine to get it right.
I got my very nice British Isles working again and decided to add some scenery for Ireland. The readme insisted that the files installed had to be left where their installer had put them, at the top of the scenery library. Once again, that ruined the rest of the British Isles.
Since then I have seen the same careless assertion by a number of developers (not from CalClassic, I hasten to add) - "Just put my scenery at the top of the library and all will be well". It seems to be more an ego trip than anything else - none of these people can possibly know what I already have installed, and I don't expect them to; but I will not have them forcing me to use auto-installers written on the assumption that I only have a bog-standard MSFS default setup with no other addons at all.
Looking around a lot of forums, I found highly respected members of the hobby contradicting each other about the relative positioning of Mesh, Scenery and LandClass.
So I had a look at what happened in a default setup, and it was very clear that the files listed in the Scenery Library loaded from the bottom up. From that it followed that any file loading after the first one had the potential to modify anything previously loaded, especially for the same geographical area.
From that I derived a basic rule that for any given area, I would load the mesh, so that the scenery could be laid over it, load the regional scenery, then load any scenery that was going to modify that (eg landclass) and finally load the local detail stuff like individual airports and scenery objects.
That keeps me happy. I have no wish to make it compulsory for anyone else. The only thing I would make compulsory is the abandonment of all reference to 'higher' or 'lower' priority numbers because that only causes confusion.
Much better to say "keep file y 'above' or 'nearer the top than' file z".
Cheers, and thanks for listening

MikeW

[johnhinson]

Nov 19, 2008 20:33:32 GMT -5 emfrat said:

That keeps me happy. I have no wish to make it compulsory for anyone else. The only thing I would make compulsory is the abandonment of all reference to 'higher' or 'lower' priority numbers because that only causes confusion.
Much better to say "keep file y 'above' or 'nearer the top than' file z".
MikeW

I agree with your points, Mike, except that I think it is still confusing to refer to "above" and "nearer the top".

The Scenery Library within FS lists the index in opposite order to the way they look if you edit the file manually, so it is not at all obvious what is meant by higher. "Greater numbers" perhaps?

John

[emfrat]

Cheers John -
You are right, since even that depends on how someone 'sees' the priority ranking. But if you have someone looking at their Settings>Scenery Library, and you tell them to use the Move Up button to place file Y above file B there is an improved chance they will get it right
The best I have seen recently was a readme which spelled the whole thing out. After getting the new files into \Addon Scenery, the author said 'Go to Settings Scenery Library, and use Add Area to add File J first; then add File K; then add File L; lastly add File M. This will put the files at the top of the list, in the right order. You can move them around if you want but always keep the same order'
But I can understand a designer who has finally completed a project and can't wait to see the back of it! ;D

MikeW

[jplr]

Yup, would be easier to use FSManger to arrange them sceneries & meshes, I don't trust FS with the arrangements, for some reason it gives the wrong layer numbering, would cause FS to crash to desktop!

[Tom/CalClassic]

Hi all,

More from FSAviator:

In relation to the the 331 layers issue. The statement;

>>>>>>>>>>>

Beware you may be able to declare more than 331 layers, but no more than 331 layers will load. Only 'required' layers are guaranteed to load when more than 331 layers are declared and FS9 may not discard other layers in a way we perceive to be logical.

>>>>>>>>>>>

Is correct.


The scenery library is not a menu or a list. It is a layering sequence. FS9 can load and display up to 331 layers of scenery at the same time. It will never load more than 331. Those 331 layers may not be visible. Once loaded the layer is present and 'using a memory slot' whether or not it is currently visible.

If we order FS9 to load more than 331 layers of scenery some Microsoft hard code takes over and decides the priority for unloading and loading from then onwards. Our defined priority is discarded. This might work just fine if the FS9 mesh layering bug did not exist and everybody was very careful what they allocated to a single scenery folder = layer. My first post explained that we must carefully layer our FS9 mesh using reverse logic

Global mesh
Regional mesh
Local mesh

due to the FS9 bug.

FS9 does not know it has a bug and will not use reverse logic when we overload it. It may use no logic or some logic, but it won't use reverse logic.

FS9 has 'some' location or 'distance' logic concerning layer loading. Nobody outside MS knows exactly how it works. If we place sceneries from very different locations into the same folder = layer we will have no problem *so long as we do not define more than 331 layers per scenery.cfg*. We can put Florida and Oregon airports in a single layer and just tell FS9 to load them all as a single layer. The problem comes only if we overload FS9 by allowing it to attempt to load more than 331 layers.

If we have a thousand layers defined in a single scenery.cfg and they are spread right across the planet, and we made each folder = layer 'very local' in content then FS9 may never actually try to load even 332 of the one thousand during a single (short) flight. If however we have 332 layers containing bgls relating to the entire length of a much longer flight FS9 will eventually try to load a 332nd layer and will cease to use our layering sequence. It will start to decide what to load and unload according to its own logic. It is bugged. Our bug fix ceases to work *and* it might load only a very local folder into the only memory slot available in preference to one with scenery stretching from Oregon to Florida even though the Florida bgl is one we need to navigate by shortly. We lose control of what loads if we define more than 331 layers. Up to 331 we have total control and we can be careless about regional converge within a single folder = layer. Everything we need will *all* load anyway so long as we never define more than 331 layers in a scenery.cfg.

To be sure we retain control of the layering logic and what gets loaded we must define no more than 331 layers per scenery.cfg. Anything else has a risk of wrong mesh loading and needed scenery not loading. The more layers we declare above 331, and the more layers we force FS9 to load, by having huge area converge in a single layer, the greater the risk of overload somewhere round the planet, and the longer the flight the greater the risk of overloading FS9 and causing display errors with our excess defined layers.

Anyone who has more than 331 layers in a single scenery.cfg must think much harder about which layers must have a REQUIRED flag, what they can include in a single folder = layer, and how far they can fly without invoking the 332nd layer.


To extend my original post a little.

We must each take control of layering. The developer of a scenery, whether mesh, or photo, or landclass, or local scenery cannot. He has no idea what we have installed in which layer already.

When we download some scenery whose installation instruction is 'add three folders in the following sequence'

1. nicefield airport
2. nicefield area landclass
3 nicefield local mesh

It cannot mean sequentially. Sequentially ignores the FS9 layering bug. The airport must be inserted within our 'airport layers', the mesh must be inserted within our 'mesh layers' and the landclass in our 'landclass layers'.

Suppose we place nicefield airport at layer 50. The supplied local landclass could be at layer 51 or layer 250 so long as either is above our regional landclass layers. However even layering the local landclass at layer 1 would not allow it to load if we have photo scenery for that region in any layer at all. The provided local mesh may need to be all the way down at layer 300 to make sure it is below all our regional mesh layers. Layering it two layers below the airport has no relevance and won't work. In FS9 local mesh has to be layered below all global and regional mesh. Where airports that sit on it are in the layering sequence has no relevance at all. Mesh must be layered solely in relation to other mesh and landclass solely in relation to other landclass.

If we add more scenery than we know how to layer correctly we introduce layering errors. Developers cannot do it for us. Worse until about early 2007 the mesh installation instructions and the mesh auto installers of mesh developers were all wrong (if applied to FS9) anyway. They had not yet noticed the FS9 mesh layering bug.

FSAviator.

[jplr]

Hi Tom, thanks for posting that info, I didnt know anything about it till now, would be very useful to some buds who still don't know

Pao

[emfrat]

Hi Tom -
I suspect we all might be "vehemently agreeing" here
This subject has come up at a very opportune moment for me. I have just made a separate install of FS9.1, to fly the classics in. I did not want to tamper with my VFR/Modern installation, as it took me many months to get that 'just so'.
It will take about the same time to get my FS9.1_Classic up to the same standard, and of course once it is there I won't want to be tampering with it either. So if there is a different approach, now is the time to be testing it.
I remember John Woodside (aka 'bones') suggesting the same sort of grouping as FSAviator has done. As I recall, John's proposal was for FS2002, but he may also have meant it for FS2000 - I didn't get into addon sceneries until later.
Regardless of that, we had a small flood here a couple of nights back and although there was no damage there is a lot of mess to clean up, so not much time for simming until that is done

As I said, it's a great opportunity to experiment and I will continue when I can, and report back.

Cheers
MikeW

[Tom/CalClassic]

Hi Mike,

Thanks, and I hope the cleanup isn't too arduous.

[emfrat]

Hi Tom -
Just popped in while having a well-earned beer with lunch. Despite the flood, we are still on water restrictions, so I can't use a hose. It could have been a lot worse. The last time it was up to the third slat on the side gate you can see open near the stairs.
Cheers
Mike
www.visualflight.co.uk/forums/topic.asp?TOPIC_ID=8410

[Tom/CalClassic]

At least your house is raised up.