A good part of the problem lies in the xml method itself.
Imagine you have 10 different addons and you order it to your needs using the old scenery method, just adding the addons and then reordering them.
If all addons use the xml method you have to order them by stating a "layer" number in the .xml file.
What if different vendors use the same layer number in their addons?
ORBX, using ORBX Central, can give its scenery addons different layers all the time.
With V5 and ORBX using the xml method I found it much more difficult to order things as I want them to be ordered. Maybe Norm is right saying that the best method would be to have the insertion points as .xml addons.
Karl
V5 uses both methods - scenery added by scenery.cfg, and many other cfg files and many other addons now by xml. It true xml is not ideal for layering if you require a specific order. If you don't need an specif order and the pile just goes on top it's really not an issue. But it does become an issue with pieces with different layering components; IE, a land class component, then an add-on scenery piece (IE: Higher) that has to be above Lower.! (tongass for ecample.
True that add-on scenery can be added conventionally ie: scenery.cfg or by add-on.xml. And the best way all depends on where it has to be placed. If in the gut or body of the scenery blocks, or if a user is frequently adding scenery it might be easier using scenery.cfg: IE Tongass, Mesh, any global add-ons, 3rd party scenery that might require specific positioning, perhaps libs that have to fire before the add-on scenery, or photo-scenery loading for an area before it's land-class type scenery is loaded but it can be done as xml.
Other scenery add-ons that simply layer on top is xml easy to do and you don't have to worry about order - unless there is specific layering requirement: IE: world scenery at layer 3. (but that is not complex because layer 3 is almost at the bottom of the scenery order - but it still has to be specified in the xml.
Other add-ons when installed can be scenery, simobjects or effects (or just about any other type of add-on!). All devs don't necessarily use the same layer - all depends where the scenery components should be placed in what blocks of the scenery order.
Yes you can have many entries per layer.. IE: Like all world scenery entries should be placed at layer 3. And many scenery pieces have a scenery-world-scenery component. (layer 3 is 3rd from the bottom of the order).
If the scenery is correctly categorized and layered for world scenery at layer 3 they all stack in that layer and are loaded in alpha order. So although there could be many items at layer 3 as defined by the add-on.xml for each, they all are loaded one by one in that layer 3 block: that is after default layer 1 and 2 are loaded but before any layer 4's are loaded (which includes layer 4 [Area.004] in your scenery.cfg.
A long post to say there is many parts or pieces to this stuff but really there are no hard rules here. A combination of xml (add-on.xml, add-on.cfg, dll.xml etc and/or scenery.cfg for scenery, and/or using effects.cfg, gauges,cfg, simobjects.cfg, sound.cfg, etc to define additional paths and links to the various supporting components at other than the default sim locations etc - which can also works well for some stuff if an user is so inclined: but this is not exactly novice stuff here as it takes time to learn to become familiar with the various sim components and it's various triggers.
But then scenery.cfg methods do work too just just that the code is defined in the scenery.cfg rather than a xml. But if the xml add-ons is correctly designed, tested and proven then the end user just has to download it, extract it if necessary and install or simply paste that add-on folder into the default p3d add-ons folder - DONE! Then fire up the sim and enable: simple and very fast to do - and it works without issues.
Norm