New Orbx Central v4.0 now available to download

[Lorby_SI 2,042]

15 minutes ago, Seat* said:

Oliver, how is it possible to create scenery groups for ex Europe wihout the help of addon as Addon Organizer? Yoy can´t do it inside P3D or? 

/Thomas

Hello Thomas,

the most important aspect to be aware of is, that it is not necessary to have a separate add-on.xml for every single addon. You can have as many Components as you like in the same add-on.xml - for example scenery belonging to a specific continent. And you can have the same Component in multiple add-on.xml packages at the same time too (just make sure that the packages aren't active at the same time).  

Without P4AO the only way would be manually. You would create an add-on.xml containing all the assets that you want in that group, instead of adding each single one of them to its own add-on.xml.

With P4AO you can do it the same way - instead of using the "Groups", you just add/move scenery that you want to belong together into the same add-on.xml. 

This goes for every type of asset - you can have all Carenado airplanes in the same add-on.xml, switching those on and off as needed. etc. The only limit is your imagination.

As food for thought, my favourite example is having two different simulator setups on the same machine, by using only two add-on.xml files. One sim is the contemporary version, with recent aircraft and scenery, the other is a vintage version, with period aircraft and scenery. There is only one P3D installation, and I switch between the two options using only two add-on.xml packages. One contains all current assets, the other all vintage stuff ("stuff" being airplanes, AI, shader mods, scenery - everything). Sure, it takes a while to set it up like that, but once done, the effort to switch between the two is reduced to a handful of mouse clicks.

Best regards

Edited August 10, 2019 by Lorby_SI

[Seat* 53]

Thanks Oliver. Very informative. As I understand it, you do not discourage the use of P4AO now that Orbx has implemented the change in the way that has happened. I mistakenly perceived an earlier post from you in this way. I prefer to use P4AO which is a fantastic tool

 

/Thomas

[Neptune 7]

Hi guys

 

if this can help some of you i do that ..

 

https://orbxsystems.com/forum/topic/177699-recover-insertion-point-orbx-centralv-404/

 

See you Patrick

[Lorby_SI 2,042]

1 hour ago, Seat* said:

As I understand it, you do not discourage the use of P4AO now that Orbx has implemented the change in the way that has happened. I mistakenly perceived an earlier post from you in this way. I prefer to use P4AO which is a fantastic tool

Hello Thomas,

I wouldn't go that far. I have downloaded the new FTX Central yesterday and I am still analyzing it. The main issue that I see here is that ORBX is using the same layer number for all scenery components of the same product (= every scenery component in one add-on.xml has the same layer number). They are basically relying on P3D to read this in a certain way to keep their scenery sequence intact. 

That would mean that one has to turn off "Auto Layer" in P4AO to keep that structure. But once you start moving these products up or down the scenery library, things will get ugly, because at some point proper layering will be required.

I'm not sure that anyone really is at fault here. The P3D specification says that you don't need layer tags, but you can add them if they are required. What it does not say is, that you can use the same layer number more than once. The simulator tolerates this (it has to, because otherwise there would be conflicts between add-on.xml and scenery.cfg), but IMHO that doesn't mean that one can rely on it as a developer. I prefer to force proper layer numbers throughout the scenery library, and that is where there is bound to be trouble when FTX Central does the same, but differently. It is probably more about when you use which tool, which one has to come first. And it is definitely recommended to make a lot of backups...

Other than that, the new ORBX system works fine for me. It didn't force me to migrate all ORBX products, so I can comfortably leave them alone. Only new stuff will be installed in the new library, which is OK. I migrated two products anyway and checked the results, and apart from the identical layer numbers, there is nothing wrong. Quite the contrary, by disabling the ORBX discovery path, you can disable all of their products (that have been migrated) at the same time.

Best regards

Edited August 10, 2019 by Lorby_SI

[Seat* 53]

Oliver

Ok. My problems are huge. I have migrated everything and I have ORBX and other scenerys all over place. I have all my scenerys installed as xml using P4AO. Hope Orbx comes up with some solution to this. Orbx central does not appear to be beta tested with any scenery other than Orbx in the simulator.

 

/Thomas

[Lorby_SI 2,042]

9 minutes ago, Seat* said:

I have ORBX and other scenerys all over place.

Hello Thomas,

that may be so, but theoretically the sim should still work correctly - the scenery layer sequence should be intact, even if there are gaps and other things in between the components - ?

Best regards

 

Edited August 10, 2019 by Lorby_SI

[Lorby_SI 2,042]

40 minutes ago, Lorby_SI said:

The main issue that I see here is that ORBX is using the same layer number for all scenery components of the same product (= every scenery component in one add-on.xml has the same layer number). They are basically relying on P3D to read this in a certain way  to keep their scenery sequence intact.  

To explain a little more why I personally think that this is problematic: the AddOn.Component tags in the add-on.xml are not part of a list, they are stand-alone nodes. I am not aware of a rule in the W3C XML specification that you can rely on an XML parser to read them in the same sequence that they appear in the file (but I'd appreciate any insight that says otherwise).

Best regards

Edited August 10, 2019 by Lorby_SI

[aeronauta 67]

Oliver , this sims to be a special parser as I can prove that if you create an xml say with 4 components with the same layer number, the bottom component will be placed in the top position , as in any of the regions haavong 05, 06, 07, 08..I place 05 at the bottom

<!--                       NZ            -->
   
   <AddOn.Component>
    <Category>Scenery</Category>
    <Path>ORBX\FTX_NZ\FTX_NZNI_08_CUSTOM</Path>
    <Name>FTX_NZNI_08_CUSTOM</Name>
    <Layer>4997</Layer>
  </AddOn.Component>   
  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>ORBX\FTX_NZ\FTX_NZNI_07_MESH</Path>
    <Name>FTX_NZNI_07_MESH</Name>
    <Layer>4997</Layer>
  </AddOn.Component>   
  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>ORBX\FTX_NZ\FTX_NZNI_06_CVX</Path>
    <Name>FTX_NZNI_06_CVX</Name>
    <Layer>4997</Layer>
  </AddOn.Component>    
  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>ORBX\FTX_NZ\FTX_NZNI_05_SCENERY</Path>
    <Name>FTX_NZNI_05_SCENERY</Name>
    <Layer>4997</Layer>
  </AddOn.Component> 

this appears in the scenery configuration in sim as first 05,then 06 and so on...

it never fails.

 

Jorge

 

Edited August 10, 2019 by aeronauta

[Lorby_SI 2,042]

1 hour ago, aeronauta said:

Oliver , this sims to be a special parser as I can prove that if you create an xml say with 4 components with the same layer number, the bottom component will be placed in the top position , as in any of the regions haavong 05, 06, 07, 08..I place 05 at the bottom

Hello Jorge,

yes, I know that, that is not the point.

This may sound strange, but it doesn't matter how P3D works. As a developer you don't rely on any software just doing things, when there is no written spec that describes and enforces this behavior. If there is no spec, you must always be prepared for the worst. If something is really important (as the scenery layering is), and there is a way of making certain that it happens, it is your duty as a programmer to implement that. You cannot just hope that it works out based on an observation or experiment. If what you base your implementation on is not specified, then it can change at any moment in time, leaving your own code stranded. This is especially important on this simulator platform, because there are (hundreds of) others who contribute their own products. If everybody just disregards the spec, relies on how things work at a specific point in time and generally does whatever they want, we end up... where we are actually. 

Best regards

Edited August 10, 2019 by Lorby_SI

[regis9 4,020]

Has anyone that uses UTX rather than vector done the migration to the new ORBX Central?  My concern is that I had to set the scenery order very specifically to get both to work together.

[Seat* 53]

2 hours ago, regis9 said:

Has anyone that uses UTX rather than vector done the migration to the new ORBX Central?  My concern is that I had to set the scenery order very specifically to get both to work together.

Yes I use UTX. I dosen´t work well with new ORBX Central if you migrate. Some parts of it is over ORBZ and some other are below. On the other hand I can´t say what it has impact on P3D. I haven´t been able to force it below ORBX, if that's what you want to happen

 

/Thomas

Edited August 10, 2019 by Seat*

[CFIJose 5,485]

2 hours ago, regis9 said:

Has anyone that uses UTX rather than vector done the migration to the new ORBX Central?  My concern is that I had to set the scenery order very specifically to get both to work together.

If you do not migrate you should be safe.

I don't need to update any airports or migrate. I already have a symbolic link to another SSD and all the scenery.cfg files I'll ever need. If I buy a new airport it gets via installed via the .xml method and that's harmless to my scenery.cfg.

[Lorby_SI 2,042]

15 minutes ago, Rob_Ainscough said:

If the layer is provided it's specific to contents defined within the add-on package, it's not global.

Sorry, Rob, but you are wrong there. The layer number, if provided, is global.

Best regards

[Lorby_SI 2,042]

46 minutes ago, Rob_Ainscough said:

If its Global,

Trust me, it is. I have been doing this in depth for 2 years now. If you don't trust me, try it yourself. 

The spec actually contradicts itself. It says "one higher than the top layer [of the whole scenery library]" and then uses layer "1" as an example - which is the base layer for all the scenery library.

Quote

 how would developer X know what developer Y is using for a layer?

Exactly. There is a lot more to scenery management now than just parsing a cfg file. (and the reason why P4AO and the LorbySceneryExporter exist).

Edit: how this works:
If you don't provide layer numbers at all, then the scenery layer priority will be determined by the sequence in which P3D reads the packages, and within them by the order of the components. If you add layer numbers, P3D will align them globally with the rest of the scenery library. As an example, it is common to place elevation correction BGLs into a scenery component and give it Layer 3 - which puts it right above \scenery\world\scenery and \scenery\base\scenery but below everything else.

Best regards

Edited August 10, 2019 by Lorby_SI

[Lorby_SI 2,042]

43 minutes ago, Rob_Ainscough said:

which implies order of addition defines where it ends up in the global chain.

And that leaves even more to chance, doesn't it? If your product relies on a certain sequence and position in the scenery library hierarchy, how would you achieve that without layers? Rearrange all packages? Insert your component into the package of another developer (or user) because your component has to go inbetween? Simple example: consider you install a few airports or regions - and then you buy and install a mesh product - that needs to go below the others. What now?

In my experience, scenery development is not that clear cut that you can just pile each component onto the next. There are base layer components, AI flight plans, nav and mesh data, that need to go into very specifc places. And probably dozens of other use cases too (I wouldn't know, I am not a scenery developer). Just look at what ORBX does. They have their base layer components on layer 3, while using their "insertion point" layer number for each and every scenery component in the same package (in my sim 153 for GES and 154 for GEN) - knowing that this layer number will insert the package into the right place in the scenery library, while at the same time relying on P3D to read all components in the sequence how they appear in the package (because they all have the same layer). And then they need their libraries on top of all that. I didn't make that last part easy for FTX Central, because I didn't migrate the libraries - so they are still in the scenery.cfg, as are the other ORBX products - and GES and GEN with their respective add-on.xml files must be squeezed inbetween.

And then there is the users. Again in my experience, there are a lot of simmers who like their scenery library to look just so. This is also only achievable with proper layering.

This horse has taken a beating for a long time now (the logic has existed since P3D 3.something). The current implementation IMHO is the best of both worlds.

Best regards

Edited August 10, 2019 by Lorby_SI