noted ORBX Central Still Mixes Up Scenery layering

[demio]

 

Operating system:  W7 Home Premium

Simulator:  P3D 4.5.12

Screenshot:  -

Issue:  ORBX Central mixes up the layering of my sceneries. I've tried it with "Advanced Layering" off, which seems to be like FTX Central 3, in that it ignores add-on.xmls and re-sequences the scenery-cfg. With "Advanced Layering" on, that doesn't happen anymore, but instead a number of sceneries are re-arranged (please refer to attached log). I can't tell yet which logic is applied. This is a little annoying, especially seeing that I have to re-install openLC North America for the 4th time due to missing textures (night textures in the daytime) after the 1.4.3 update of openLC NA. Thanks for your help.

 

central.log

[demio]

So, after sleeping on it, I might have the reason: I use the very good P4AO to manage my sceneries. I only activate the ones that are relevant to the flight at hand. P4AO uses, as far as I know, a small hack to "deactivate" sceneries. It's very possible ORBX Central doesn't recognize those add-on.xml entries and sorts "around them". I will check the behavior with all sceneries active and report back!

[demio]

I finally got around to testing again, and sure enough, as long as all sceneries are activated, OC doesn't re-arrange them (with "Advanced Layering" selected).

[Mitchell Williamson]

Hi!

 

On 10/5/2019 at 7:18 PM, demio said:

So, after sleeping on it, I might have the reason: I use the very good P4AO to manage my sceneries. I only activate the ones that are relevant to the flight at hand. P4AO uses, as far as I know, a small hack to "deactivate" sceneries. It's very possible ORBX Central doesn't recognize those add-on.xml entries and sorts "around them". I will check the behavior with all sceneries active and report back!

 

That would make sense. We look at the AddOn.Component that sit in add-on.xmls and use those to build up the scenery layers. P4AO renames these components to something other than AddOn.Component when disabling add-ons and therefore Central isn't recognizing them. 

 

I've made a note of this. We may be able to take these disabled add-ons into account when performing layering in a future update.

[demio]

Great, thanks!

[kevinfirth]

11 hours ago, Mitchell Williamson said:

Hi!

 

 

That would make sense. We look at the AddOn.Component that sit in add-on.xmls and use those to build up the scenery layers. P4AO renames these components to something other than AddOn.Component when disabling add-ons and therefore Central isn't recognizing them. 

 

I've made a note of this. We may be able to take these disabled add-ons into account when performing layering in a future update.

That would be excellent, Oliver's app is exceptionally good and if we can seamlessly use it and OC that would make a lot of us very happy

[kevinfirth]

On 10/24/2019 at 5:22 AM, Mitchell Williamson said:

Hi!

 

 

That would make sense. We look at the AddOn.Component that sit in add-on.xmls and use those to build up the scenery layers. P4AO renames these components to something other than AddOn.Component when disabling add-ons and therefore Central isn't recognizing them. 

 

I've made a note of this. We may be able to take these disabled add-ons into account when performing layering in a future update

 

To quote Oliver himself "IMHO, what ORBX should have done is, to load the whole scenery library config into a temporary structure, then find the insertion point, insert the ORBX assets, renumber the scenery library, and then save it again - across all add-on.xml files and the scenery.cfg. That is what P4AO does and it is not particularly hard to achieve. As long as the scenery layering remains the same, nobody will complain that all scenery config files have been updated."

 

Would it be possible to do this please? I dont understand what the logic is behind the current implementation, because it just results in duplicated scenery layer numbers and corrupted scenery layering when you have it ordered nicely :(

[icycle]

I am SO GLAD to have stumbled across this thread.  I thought it was just me with this issue.  I also use P4AO, and do the same with disabling my scenery I am not using. and the issue after every time running Orbx Central involving layering was driving me crazy!!  I'm getting duplicate entries, and strange ordering - even within Orbx products.  Causing all sorts of Chaos on my system.

 

Wish I would have known of this, before I updated, or i would have delayed.

 

Hopefully they get this sorted so that all co-exist properly again.

 

Bill

[Benjamin J]

I would like to chime in here. I’ve read a lot of reports of people over the last few months with issues in regards to the layering being messed up due to OrbX Central, so I held off with the migration for a while, until today. With the most recent version, 4.0.23 I believe, essentially OrbX Central appears to respect the layering just fine.

 

and so I decided to carefully migrate a few packages. That seemed to work okay, so I migrated some more things. But then I started running into issues. After migrating a bunch of packages and doing a test flight around Eglin AFB, I noticed an airfield not to far off with a night texture during daytime. I suspected an issue with Global Base or OpenLC, the first of which I had not yet updated to the latest version and the latter I had not migrated yet.

 

So I went ahead and migrated OpenLC as well. And here’s where I ran into bigger issues. The layering of OpenLC and Vector is completely messed up, but all the other scenery appears fine. 

 

I did not expect that out of all packages, OrbX Central would mess up the layering of its own products? Openlc appears to be spread around the other OrbX sceneries, which appears to have caused a whole bunch of issues. Eglin AFB surroundings looks very different right now and there are some landclass tiles that entirely lack autogen. Not a good situation. Last time I saw this I ended up completely reinstalling the sim.

 

it’d be great if I could be pointed in the right direction in reestablishing the right layer order for the different OpenLC entries as well as Vector, and where exactly these are supposed to be? This time if quite like to sort out this issue without a total reinstall of the sim

 

let me just add that currently there there is no issue with night textures during the day, however the surroundings of Eglin AFB do look quite different, making me think that OpenLC might not be properly active. And I think the erroneous layering is to blame.

 

I’m not at my computer right now but let me know if there’s anything I should upload and I can do that!

[icycle]

Yes, similar to the "puddle" I stepped in.

 

Texture issues around Hurlburt Field (just W of Eglin AFB) is what got me looking into the layering in the first place, and down the slippery slope.  I can remove the duplicates in my instance by directly editing the .xml files, but that seems a little extreme, and tedious, and not sure that is the best course here.

 

The muddle (this situation) here, caused me to lose Vector, and roads and bridges disappeared - causing that to have to be uninstalled / reinstalled.

 

Spending more time tinkering, than flying now. Which is not what I would like to be the case. 

 

Some direction on how things should actually look, might be helpful here.

 

Thanks

Bill

[edpatino]

2 hours ago, Benjamin J said:

I would like to chime in here. I’ve read a lot of reports of people over the last few months with issues in regards to the layering being messed up due to OrbX Central, so I held off with the migration for a while, until today. With the most recent version, 4.0.23 I believe, essentially OrbX Central appears to respect the layering just fine.

 

and so I decided to carefully migrate a few packages. That seemed to work okay, so I migrated some more things. But then I started running into issues. After migrating a bunch of packages and doing a test flight around Eglin AFB, I noticed an airfield not to far off with a night texture during daytime. I suspected an issue with Global Base or OpenLC, the first of which I had not yet updated to the latest version and the latter I had not migrated yet.

 

So I went ahead and migrated OpenLC as well. And here’s where I ran into bigger issues. The layering of OpenLC and Vector is completely messed up, but all the other scenery appears fine. 

 

I did not expect that out of all packages, OrbX Central would mess up the layering of its own products? Openlc appears to be spread around the other OrbX sceneries, which appears to have caused a whole bunch of issues. Eglin AFB surroundings looks very different right now and there are some landclass tiles that entirely lack autogen. Not a good situation. Last time I saw this I ended up completely reinstalling the sim.

 

it’d be great if I could be pointed in the right direction in reestablishing the right layer order for the different OpenLC entries as well as Vector, and where exactly these are supposed to be? This time if quite like to sort out this issue without a total reinstall of the sim

 

let me just add that currently there there is no issue with night textures during the day, however the surroundings of Eglin AFB do look quite different, making me think that OpenLC might not be properly active. And I think the erroneous layering is to blame.

 

I’m not at my computer right now but let me know if there’s anything I should upload and I can do that!

 

Look here, this was discussed months ago (by mid-August):

Surprisingly this bug (big mess, I would say, instead) continues to affect a lot of people even using the very latest ORBX Central v4.0.23 . My solution to this has been to manually reorder the scenery.CFG after it has been messed-up by ORBX Central, and I've been doing that since the very beginning, v4.0.1, using the excellent tool Lorby-SI Addon Organizer (P4AO). Once inside your Scenery.CFG file, you should check your openLC entries and your Vector entries, and put all of them in the right order yourself. Keep a backup copy of the "good" Scenery.CFG in case it's messed-up again, you'll needed it.

Seems that ORBX is still lost in space with this problem.

Cheers, Ed

 

 

 

 

[edpatino]

Look at this thread too (it's about the same issue as follow-up):

 

Hope this helps.

Cheers, Ed

[Benjamin J]

Thanks Ed, I clearly should have never started migrating the libraries. I as convinced that the issues people had was about he entire library being messed up. Now it turns out that people's issues revolve around OpenLC. it's unfathomable to me that OrbX releases a product that creates such issues. One reason I'm excited for MSFS2020 is that it would appear that it makes this whole approach that orbX is taking (regions, vector, openLC etc) completely and entirely obsolete. No more will we have to suffer with addons of this kind!

 

At any rate, thanks for highlighting those topics. Base don these topics I've given my own library some scrutiny, and my feeling is that not only is everything messed up in the OpenLC layering, there appear to be erroneous entries that may have not migrated properly? I've now uninstalled all of openLC and am reinstalling to see what folders are being created and where. I made sure to get rid of any other openLC folders that may have persisted first. I'll report back later if there's any improvement in the situation.

[Benjamin J]

Update: Success!

 

For me, completely removing OpenLC and reinstalling fixed the messed-up layering. OpenLC appears to be layered correctly, in the right location, and there are no double entries. Like I said in the above post, I made sure to remove any folders that had OpenLC or OLC in the name - I realized that the migration hadn't properly cleaned up the OrbX folder in the P3Dv4 main folder, and I think this is what probably caused the mess. Removing, clenaing up manually and reinstalling made this a lot better.

 

I then compared to Nick's image here: 

 

And see the same thing that he is seeing around the AFB. So I presume that to mean that OpenLC, Vector and Global BASE all do what they are supposed to do.

 

There is one worrying thing though: my loading time into Eglin is a lot longer than it was. I believe this is something that I read about before, and may be related to something with how P3Dv4 accesses scenery.cfg and addon.xml addons?

 

EDIT: Some further testing revealed that I had accidentally removed some Global BASE stuff, and so I had to reinstall. This didn't appear to effect the visuals though and the layering is still correct. So on my end, it seems that layering issues were fixed by reinstalling. That said, my performance appears to be worse... Still testing at various airports whether this effect is real or maybe something got changed in an unexpected way. e.g., Vetcor seemed to have reset itself when I migrated it. perhaps other addons did the same...

 

[Mitchell Williamson]

On 10/27/2019 at 1:34 AM, kevinfirth said:

To quote Oliver himself "IMHO, what ORBX should have done is, to load the whole scenery library config into a temporary structure, then find the insertion point, insert the ORBX assets, renumber the scenery library, and then save it again - across all add-on.xml files and the scenery.cfg. That is what P4AO does and it is not particularly hard to achieve. As long as the scenery layering remains the same, nobody will complain that all scenery config files have been updated."

 

That is exactly what we do. We load all the layers, sort them in memory, then write them back out. I've got support for the disabled components that P4AO creates working locally and this will most likely be included in the next update. Once that occurs, the behaviour between P4AO and Orbx Central should be identical and it should put an end to these types of conflicts.

 

 

[edpatino]

6 hours ago, Benjamin J said:

EDIT: Some further testing revealed that I had accidentally removed some Global BASE stuff, and so I had to reinstall. This didn't appear to effect the visuals though and the layering is still correct. So on my end, it seems that layering issues were fixed by reinstalling. That said, my performance appears to be worse... Still testing at various airports whether this effect is real or maybe something got changed in an unexpected way. e.g., Vetcor seemed to have reset itself when I migrated it. perhaps other addons did the same...

 

Please keep us updated about your findings.

Want to know if with the current ORBX Central's v4.0.23, after you migrate, install a new global product, region or airport or re-install any of those, you get your scenery.CFG layered correctly or it's still mixed-up.

Thanks, Ed

 

[demio]

14 hours ago, Mitchell Williamson said:

 

I've got support for the disabled components that P4AO creates working locally and this will most likely be included in the next update. Once that occurs, the behaviour between P4AO and Orbx Central should be identical and it should put an end to these types of conflicts.

 

Superb, thanks!

[kevinfirth]

17 hours ago, Mitchell Williamson said:

 

That is exactly what we do. We load all the layers, sort them in memory, then write them back out. I've got support for the disabled components that P4AO creates working locally and this will most likely be included in the next update. Once that occurs, the behaviour between P4AO and Orbx Central should be identical and it should put an end to these types of conflicts.

 

 

excellent! thankyou - happy to help test

[Benjamin J]

On 10/27/2019 at 7:38 PM, edpatino said:

 

Please keep us updated about your findings.

Want to know if with the current ORBX Central's v4.0.23, after you migrate, install a new global product, region or airport or re-install any of those, you get your scenery.CFG layered correctly or it's still mixed-up.

Thanks, Ed

 

 

Of course. I have not done too much since my last report, but what I have done (installing some new sceneries unrelated to OrbX) has not led to any further problems. Thus, reinstalling openLC has solved the layering issues for me, it seems. I might install AYPY over the weekend though as well as Buildings HD, so let's see if that causes any issues

 

The performance problems I thought I had might just be my normal performance... I realized that I always turn on FSPS's FFTF modulator, so usually my performance is higher than it would be in the absence of that tool. When I claimed performance issues I had forgotten to activate that tool...

 

So to summarize, for me all seems well. The one issue I do have, which has been much discussed already, is inactive entries moving when OrbX Central does its thing. It sounds like this will be fixed soon, so that's great!

[edpatino]

On 10/30/2019 at 11:50 AM, Benjamin J said:

Of course. I have not done too much since my last report, but what I have done (installing some new sceneries unrelated to OrbX) has not led to any further problems. Thus, reinstalling openLC has solved the layering issues for me, it seems. I might install AYPY over the weekend though as well as Buildings HD, so let's see if that causes any issues

 

Good!.

Thanks in advance, Ed

[kevinfirth]

On 10/27/2019 at 11:33 PM, Mitchell Williamson said:

 

That is exactly what we do. We load all the layers, sort them in memory, then write them back out. I've got support for the disabled components that P4AO creates working locally and this will most likely be included in the next update. Once that occurs, the behaviour between P4AO and Orbx Central should be identical and it should put an end to these types of conflicts.

 

Pleased to report that Orbx Central appears to be working well handling layering and add-on xml packages