Jump to content

Missing essential information...


AnkH

Recommended Posts

Hi ORBX, I am slightly disappointed by the communication about the new FTX Central 4.0. Reason: I am now looking around in the forum but it seems to me that there is essential information missing or I have to use the search function to find it, cumbersome approach. Information missing:

 

- Does FTX Vector work when all ORBX sceneries are migrated to an add-on.xml based installation? Does it need something else (like makernwys.exe, Lorbi-SI)?

- which ORBX products besides FTX Global Base can not be moved or does not work properly with Central 4.0 at the moment (read about issues with YBBN in the forums)?

- are third party scenery library re-ordering tools still possible to use or not?

 

Especially the first two points should not be asked by customers but be clarified in a sticky post in this subforum. Or in the User Guide...

Link to comment
Share on other sites

Hi!

 

Thank you for your feedback. It is very important for us to know what information is missing and we'll be working to improve it based on community feedback.

 

43 minutes ago, AnkH said:

- Does FTX Vector work when all ORBX sceneries are migrated to an add-on.xml based installation? Does it need something else (like makernwys.exe, Lorbi-SI)?

 

We're still establishing the compatibility of Vector. The discussion thread is below. Once we've got a solution that works for everyone, we'll document it.

 

48 minutes ago, AnkH said:

- which ORBX products besides FTX Global Base can not be moved or does not work properly with Central 4.0 at the moment (read about issues with YBBN in the forums)?

 

All products should be available now. YBBN and YSTW didn't have their downloads enabled - this was our mistake.

 

48 minutes ago, AnkH said:

- are third party scenery library re-ordering tools still possible to use or not?

 

That depends on the tool in question. Central is designed to layer Orbx products correctly out of the box. We haven't tested any particular tool as these third-party tools fall outside our teams support area. There is a thread discussing compatibility below.

 

Link to comment
Share on other sites

Thanks for the great heads up!

 

I have seen this Vector thread. My question is: does the pinned guide on how to use Vector with add-on.xml based scenery still work as a workaround? If yes, that would be an easy solution to me, I anyway need a generated scenery.cfg (either by makernwys or Lorbi SI) for Pro ATC /X to work after adding add-on.xml based sceneries.

Link to comment
Share on other sites

Ok, fair enough. A small kind of criticsm is allowed: did really no one of the Central 4.0 developers think about FTX Vector and how this will work when all ORBX products are switched to the add-on.xml based variant? I mean, something more obvious to adress is hardly possible, no? If I am not wrong, it was discussed a million times in the forums that FTX Vector is unable to detect add-on.xml based sceneries...

Link to comment
Share on other sites

8 minutes ago, AnkH said:

A small kind of criticsm is allowed: did really no one of the Central 4.0 developers think about FTX Vector and how this will work when all ORBX products are switched to the add-on.xml based variant?

 

That is fair criticism. We did consider it, though as there is already existing workarounds for add-on.xml based products we opted to keep it as it was. When you've got a few hundred products and a small team working on it (along with actually developing the software :P), we need to set a standard on how far we can go with patching existing issues.

 

We're not going anywhere though, we're going to keep working on these issues until they're resolved. We'll likely be defining a standard workaround for Vector compatibility in the short term and once resources permit we'll consider ways we can put a permanent solution in place.

Link to comment
Share on other sites

I totally understand. And it IS a minor issue, if the workaround still works (which I assume it does, at it is pretty straight forward). Anyway, keep up your good work!

Link to comment
Share on other sites

Is it possible that this whole thingy with the add-on.xml method was not properly reasoned and rushed?

 

Over at avsim, there are rumours that the novel FTX Central 4.0 uses a so called "discovery path" for the add-on.xml resulting in greatly elongated loading times. And that (at least some of) your ORBX products do not have a layering defined in the add-on.xml resulting in all ORBX stuff ending up on top of the scenery library? Does this not brake any additional addon that needs to be on top of ORBX?

 

Seriously, the more I read, the less I am ready to already update to FTX Central 4.0...

 

EDIT: add FTX Central 4.0 overwriting HD Buildings to this growing list of things obviously not checked before release...

Link to comment
Share on other sites

1 hour ago, AnkH said:

Central 4.0 uses a so called "discovery path"

 

Seems to be correct, at least I do have this entry in my add-ons.cfg:

 

[DiscoveryPath.0]
Path=F:\AddOns\Scenery\Orbx\Library\p3dv4
Title=Orbx Main Library
Active=TRUE

 

Cheers,

Greg

 

Link to comment
Share on other sites

On 8/6/2019 at 9:40 PM, AnkH said:

And that (at least some of) your ORBX products do not have a layering defined in the add-on.xml resulting in all ORBX stuff ending up on top of the scenery library? Does this not brake any additional addon that needs to be on top of ORBX?

 

The only products that don't have layers specified are things like Orbx Libraries and Global Base, which generally won't conflict with any third-party add-ons. We'll be always continuing to improve the layering system based on public feedback and issues that appear.

 

On 8/6/2019 at 9:40 PM, AnkH said:

Over at avsim, there are rumours that the novel FTX Central 4.0 uses a so called "discovery path" for the add-on.xml resulting in greatly elongated loading times.

 

The discovery path is used for discovering new add-on packages, which are then cached by Prepar3D. We've used the Prepar3D add-ons documentation in the SDK to match the platform expectations of how add-ons should be distributed. I wouldn't expect any performance difference between using a discovery path versus adding an add-on package directly to the add-ons.cfg, except for potentially a small increase while Prepar3D scans the discovery path for add-ons on launch.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...