Bom dia casmatos,

You can check the link I pasted above.

I don’t remember the other METAR, but you may check with the METAR in the video above. Hopefully I will make videos more often in the future so it’s easier to see exactly the problem.

Abraço!

Hi Ben,

You may check the following video:
https://youtu.be/KsJmBdO8K-k?t=21

Visibility is 0.1sm, but I can see the city lights, airport lights, etc, at FL230!! The link is right when the “phenomenon” happens so you won’t waste time.

But to be fair, even taking this into account, the approach this time was enjoyable, unlike the other time. Unfortunately I was not recording the other one. Would have been a better “report”.

Sorry for the “strange language” spoken in the video and sorry for the swearing. Really hoping for an improved weather engine (hopefully Active Sky will deliver till the end of the year).

Cheers!

If the region modifiers are ignored, then if a library has two regions, the virtual library path is ambiguous.

But we don’t really want to let a library reach past the virtual path into a -physical- path of another library – the physical path is intentionally not the “interface” of the library so that library authors can re-organize their internals.

Yes, I see what you mean Ben.

Regions I think are modifiers for X-Plane to consume, not for the library that re exports the asset; you’d just cherry pick individual resources, regions should not have influence on those.

As or multiple variants, I’d assume the consumer knows what he’s doing, if he re exports a multiple asset, it keeps being a multiple asset.

I know the internals must be crazy complex, but from the outside it doesn’t seem that far fetched to implement, and it would add a welcome flexibility for developers 🙂

E.g. KSEA would have “default_airlines=”dal awe”, a given ramp start may have airlines = “swa”.
Now, if ‘jet_c_swa.obj’ can not be found, it would try the dal and awe suffixes before falling back to the too generic ‘jet_c.obj’.

With that, a scenery may be as specific as it gets at the ramp starts, in hope that a suitable “static aircraft enabled” addon library is installed. And still avoid getting out-of continent aircraft in most cases, if it turns out that exotic airline is not covered by a given users installation.

It would be up to the makers of those aircraft containing libraries to include the right exports to make these available as static aircraft …

Or you ship your ‘regionalization’ library with a script that creates symlinks to make ‘their’ aircraft pop up inside ‘your’ library folder. In that script you’ll have to solve the problem to find that actual directory name and maybe even its exact version to only link to existing aircraft.

Already reported a bug some time ago that might be related. X-Plane has a nosebleed if it encounters unexpected characters in a METAR feed for example /// which unfortunately happens a lot with UK airports. It gives up reading the METAR and substitutes default values, for example QNH 1013hPa.

This is not yet possible. It is also not yet possible to make a library that _depends_ on another library – the feature we would need (which would make such dependencies possible) is library entries that map a virtual path to an existing virtual path.

I’m not sure how resolution would work? E.g. if there are region directives or multiple variants on the object from another library you are targeting, do you inherit those? What if they conflict with you region directives?

Let’s say I’m making a regional library which extends the default library with airplanes with local liveries, as in https://forums.x-plane.org/index.php?/files/file/35116-static-plane-mapping-tool/ so I can take the hard work already done on the FAIB and FruitStand libraries and map the planes to a new library that exposes them with the correct airline codes, along with some new objects. Any ideas? Is there any way to specify inter-library dependencies?