This is never okay in a library.txt file:
EXPORT lib/something.obj ../opensceneryx/object.obj
This is a library path that refers to a file outside its own pack by using ../ to go up a directory and hopefully find that OpenSceneryX is installed, at which point it assumes that it knows the internal layout of OpenSceneryX and exports the object.
Do not do this.
This will become a warning as soon as I can write some code.
This will eventually stop working completely, because it’s a terrible idea that I have said multiple times should never be done.
I know I’m a drop in the ocean, but I need better weather 🙁
The current meteorology is completely killing the experience for me, to the point I’m not motivated to fly in X-Plane any more.
Yesterday I was flying from LPPS to LPPR. The METAR at LPPR had 400 meters visibility, vertical visibility 100 feet.
I was able to see the runway perfectly from even before I captured the ILS!!??
Of course, this was at night… This is no fun. It was supposed to be a slightly challenging approach… 🙁
If this happens (METAR says it’s fogged but you can see) please file a bug and include the metar file that caused it.
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.
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!
Hello Bruno.
Can you get the METAR, because i simulate your flight, and i can’t see the runway!
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!
I noticed that this behavior happens because the x-plane start to reduce the visibility bellow the first cloud layer, then if exists one cloud coverage of few clouds at 1000 ft and you are at 3000 ft you can see the runway between the holes of the clouds. Another issue for me about the real weather is the over represented cloud coverage with FEW, SCT and BKN clouds (only with real weather, the OVC is Ok!). I filled some bugs reports about this, hope that they fix in the future. I really like the x-plane default weather, especially after the winds aloft and new clouds graphics, I thing if they fix this bugs and do some ajustments we don´t need to use other weather add´ons.
WED since version 1.6 is also enforcing this:
If such an ‘illegal’ path is encountered, the art asset is NOT shown in the library pane, i.e. it can not readily be placed in sceneries.
Will this allow us to rename Scenery files in the Custom Scenery Folder without breaking some scenery packages anymore?
Yeah. Or I would put it this way.
IF authors avoid doing this illegal thing and referencing files by ../package_name/XXXX then renaming packs will not break anything.
What would be a good way to do this to avoid polluting the scenery folder with repeated objects?
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?
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?
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.
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 🙂
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.
Another idea to get around ‘regionalization’ libraries would be an airport meta-tag to specify a set of airlines the static placer should fall back to before going totally generic:
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.
Say I added several single objects that are not part of any library, into a new package that I simply call stuff library. Would this library be affected?