We received a last minute bug report that X-Plane 11.20r2 deletes scenery packs from scenery_pack.ini. This is true! It is also by design, not a bug, the same as X-Plane 10, and not particularly brilliant on my part.
scenery_packs.ini persists the order of your packs (putting newly discovered packs “in front” in alphabetical order upon discovery) and maintains enable-disable status. But it does not retain any other information. The file is totally rewritten on every run and the following otherwise useful stuff tends to get destroyed in the process.
- Comments and notes to yourself
- Whitespace and formatting
- Any scenery packs that can’t be found
Unfortunately this means that if you symlink to an external drive that is unmounted and run X-Plane, your scenery pack order gets lost. This definitely does suck.
In a future version, I can fix this. But we’re not going to mess with it now during RC because it’s totally not changed or broken compared to all past versions of X-Plane since we introduced the scenery_packs.ini file.
For now: you can lock the file as a hack-around to preserve your well-created order while your remote drive is unmounted – when you re-mount and restart, your order isn’t lost. But in this order, new packs aren’t persisted to the file, although they will be used.
If there’s things you want the scenery_packs.ini file to do, commenting on this post would be on-topic. One thing to consider: if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?
Thanks for the heads-up, and welcome back from most-definitely-not-vacation.
Bit of a related question: do you think we will ever see a scenery manager implemented to manage the packs instead of the file?
I’m sure most of us that have used XP for a while don’t have any issues managing the usually fairly large list of text (or use a tool like xOrganizer), but it’s not exactly user-friendly or great for new users.
Maybe some day – but I think third party utilities may always provide more advanced power than what we’d have natively. It was always the intention that some kind of UI go on top of the scenery_packs file, whether it’s third party or ours.
Even simple UI that has just basic functions would be nice. Most of use use xOrganizer anyway, but newcomers don’t. Using text file might seem complicated and discouraging for beginners who don’t need advanced features like xOrganizer has anayway.
That being said I would like to retain the option to use just the text file as well.
I believe you’re speaking of my bug report.
I understand the purpose of the way things work, but my symlinked network drive WAS mounted the many times that I was having the issue, hence my filing of the bug report. I can’t, for the life of me, work out why it was removing those symlinked items when nothing had changed except the X-Plane version.
There are different kind of sceneries like
– addon libraries (only library.txt, no DSF, no apt.dat)
– overlay sceneries (apt.dat, DSF)
– base tile sceneries (DSF, no apt.dat, e.g. HD mesh, Orthophoto tiles)
The scenery_packs could indicate the type of scenery found in each directory somehow or even create a few separate sections – each only containing one kind of scenery and put those sections right into the propper sequence. Like all overlays ontop of all base tiles, pure libraries can go to either end – as they are scanned separately before everything else, anyways.
Its a pitty you only know you’ve got a base mesh tile after you analyzed most of it. The good old DSF usage docu still says there should be a sim/overlay property in there.
Hi Michael,
The sim/overlay property should be reliable – if you have a mis-match of whether it IS an overlay and whether this flag is set, all hell will break loose inside the rendering engine!!
Maybe there could be some way to make comments inside the file, so that when X-Plane loads, it comments out every line that doesn’t exist. The user can then recover those lines easily at anytime without reordering them.
What about giving the option of having sceneries stored in more than one folder; not only by symlinking to custom sceneries but having X-Plane really look for scenery packs in folders different from custom sceneries.
Those folders could be managed (added, deleted and ordered[!!]) in a tiny UI or – again – in another file.
X-Plane would then parse all those folders at startup and re-write scenery_packs.ini with every run. If a folder is mounted at this time, those scenery packs will be included.
Following the given order parsing the folders it would be easier to maintain airports above mesh for example.
You could have different folders for different kinds of scenery packs and the config-file (created by the tiny UI) would look like this:
D:\MyAirports
H:\USAirports
Custom Scenery
D:\VFRSceneries
D:\X-Europe
E:\Overlays
D:\XPLibraries
E:\Ortho
F:\Mesh
X-Plane would parse those folder top down and every scenery found would be written to scenery_packs.ini in this order.
If flying in the US, you mount this external drive H:\
Otherwise those scenery packs won’t be loaded (and thus not included in scenery_packs.ini). F:\ could also be an external drive and you only mount it when flying in regions without Ortho…
No one would have to have that many folders, but it might make things easier for people to add new scenery packs and automatically have them added to scenery_packs.ini; not at the top of the file but where it belongs…
Sorry for the wall of text, I hope you get the idea…
We’ve considered sub-folders, and some day we may have them. One reason we didn’t _initially_ do them “for free” was that it would be hard to tell what’s a real sub-folder and what’s the contents of a scenery pack. E.g. if you do this
my pack/Earth nav data/Earth nav data/apt.dat
Is “Earth nav data” a sub-pack of my_pack?
Adopting some ideas and features of XOrganizer as builtin
functionality would be nice
Ben wrote:
“One thing to consider: if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?”
If the file named inside the *.ini file could not be found tell the user about the problem and ask for deleting the entry from the *.ini file or aborting the launch of XP
Please don’t “fix” this. I like it that the stuff I remove from custom scenery is automatically “cleansed” from scenery_packs.
The stuff that I don’t want to see removed, I change to “disabled”, and as far as I know, this means it will skip this line when checking, and keep it even if it doesn’t find the scenery.
So to me this is working as designed, I like it, and it’s a RTFM topic. People who have a particular situation where they have scenery that is in another drive that gets disconnected sometimes should simply back the file up (imho)…
Thanks
The ideal will be to have an interface to be able to manage the contents of this folder and to be able to classify the elements not only in alphabetical order
That X-Plane differentiates the types of scene, Airport, Overlay, Photo area, Mesh, …
I wrote my own Java utility to manage the contents of the Scenery Pack folder with symbolic links and generate the scenery_pack.ini file at my convenience.
It is currently available in beta and only in French on the x-plane.fr website but an English version will soon be available on the.org website.
The ideal will be to have an interface to be able to manage the contents of this folder and to be able to classify the elements not only in alphabetical order
That X-Plane differentiates the types of scene, Airport, Overlay, Photo area, Mesh, …
I wrote my own Java utility to manage the contents of the Scenery Pack folder with symbolic links and generate the scenery_pack.ini file at my convenience.
It is currently available in beta and only in French on the x-plane.fr website but an English version will soon be available on the.org website.
Translated with http://www.DeepL.com/Translator, i ma french
The keyword scenery brings me to a question that has been bothering me for a long time.
The arrangement of streets and buildings come from openstreetmap. Were these data taken over once in X-Plane or is this done at regular intervals?
My small town has many tall buildings with 10 to 20 floors. Because the number of floors is not listed in openstreetmap, my home looks like a village. Does it make sense for me to complete this data in openstreetmap, hoping to see it in X-Plane in the foreseeable future?
I believe the mesh files are cut once every major revision (unless something drastically changes or breaks to cause Laminar to re-do them) So you would effectively be using OSM data from 2017.
You can update this using third-party tools e.g. ortho4xp and over-ride X-Planes overlays. Any OSM additions you make now are more likely to show up in XP12 than a future XP11.XX update.
On Mac, I use Automator to destroy scenary.pack.ini and automatically launch X-Plane whenever I put or remove a new file (Scenery, Orthophoto, …)
I wonder: I the program detects that a scenery is missing, why rewrite the file at all?
Alternatives might be: Add a enabled/disabled flag, keeling the entry but just disable it. Then, if the scenery reappears, just enable the entry. Still I wonder what the benefit of disabling it would be if you’ll have to recheck all scenery on every start anyway.
The problem is that you may want to disable some scenes without having to move. Being able to edit the file manually is a good thing.
If X-plane updates it automatically, then another code than SCENERY_PACK_DISABLED would be required.
“if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?”
A pop-up confirmation dialog box listing the rows that are being erased could be a solution. If we drop a pack we need the .ini file to be cleaned up, but in such a way we would have the control.
I think that global scenery_pack file would tend to be always problematic. I would vote for including information about scenery draw order and enabled/disabled status directly into scenery. Draw order may be composed of two integers – layer (mesh, area, airport,…) and priority…
Wait – this seems like a not-great idea, at least in part. We ship some custom airports, and some users like to turn them off.
If we write the ‘enable’ state INTO the scenery, then the users will have to mod the scenery to turn it off, and our installer will undo their work.
One of the main goals of scenery_packs.ini was to separate user decisions about deployment from installer decisions, so the two wouldn’t fight each other.
With that in mind, I agree that some default hint about layering in the scenery (“This is meant to be a mesh”) could help us have a smarter default priority.
Well, not sure how the installer works, but maybe there could be one default file provided by the installer and let’s say override file which could be provided be user / external tool. That extra file would not be known by the installer and will not get modified by the update… Just an idea 🙂
Please don’t write it into the scenery, if you accidentally used the wrong version of WED to alter it, the things that could happen are not good.
A simple GUI, with a couple of simple options would rock
1 Ordering suggestion IE what should go where. As a new user this is what confounded me the most.
2. ” ON/off” selections for each
3 Save/backup of the INI elsewhere ( useful for testing/mounting drives etc)
4 IF possible a rename function.
I think that would cover most of the big issues folks have at ” day one” and would be fairly helpful for those of us who have been around the block a few times
Well, here is my dream vision of the future of scenery_packs.ini:
An external gui app/program to act as a manager, to be used outside of X-Plane like Planemaker is, proper external. As ugly as an Excel document would work just fine, nothing flashy, just functional.
You load it up and it scans the Custom Scenery folder, detects what’s in there just like X-Plane does at start up and populates it with any new entries at the top.
Then you drag and drop the entries for ordering and double click to disable or re-enable an entry.
Maybe you could even save and load customized scenery_pack.ini’s to cut anything you’re not going to be using for your next session in a single click or two.
And maybe maybe even, completely extra and optional in my dream: Have it detect content in your scenery packs within reason, like detect if a folder contains airport data or DSF’s then it could put a little ‘A’ and/or a ‘D’ in that folder’s entry.
Just my thoughts… 🙂
Could solve a lot of drama, would also make adding, deleting, enabling and disabling scenery a major breeze for newcomers and X-Plane veterans alike.
Curious what your thoughts on this would be.
It seems for me wouldn’t be superfluous to have a scenery_packs.bac.ini file like the earth.wed.bac.xml in WED.
Do you think the file will become too big to handle? Most of the time people are adding to it. How often will they remove or uninstall scenery packs? Is there a large penalty for invalid/inaccessible entries in the file? If a scenery installer adds to it, the uninstaller should remove it. I don’t think x-plane should be responsible for that.
“How often will they remove or uninstall scenery packs?”
Answer is very. Very often.
I’m guessing you don’t use Ortho4XP.
Speaking of scenery packs, is there any reason after every update I’m getting a KLAS airport installed in my scenery folder? It keeps overwriting my Glitter Gulch scenery. I’m so confused. lol
Yes, because it’s ours. Stop over-writing or nuking it. This is exactly WHY scenery_packs.ini exists – disable it there and go home happy!
Copy that. If I may ask, why is KLAS treated differently than every other Laminar airport in the game? Did you guys add custom buildings or something?
The current KLAS pack is a mash-up of a gateway airport and custom elements…we’ll someday restructure it into a gateway airport and a landmarks pack.
I would start by deciding what features I want / dont want:
“newly detected scenery packs will be automatically added to the top of scenery_packs.ini” (seems like a good idea)
“scenery packs that are no longer found will be removed from scenery_packs.ini” (this sounds like it was a side effect – perhaps you dont want this – I dont)
“scenery packs that were once not found, and removed, are added back to the top” (yeah, probably not a good feature since its the ortho thats on the flakey drives)
Also, if you’re thinking about adding more information to each scenery_pack.ini like, please do not overload any single status/flag-names, but use additional ones.
One week of vacation is not enough before opening Pandora’s box :-)))
+1
Maintaining the scenery_packs.ini is as easy as writing a shopping list.
Organizing the scenery order etc. by working the file provides maximum control to the user and I think there is no really good reason to change it.
Just two things should be considered:
a) Link to other drives:
A command like [external_path:~\Custom Scenery] could then lead to an external drive. Example:
================
SCENERY_PACK Custom Scenery/Madeira_1_LPMA/
SCENERY_PACK Custom Scenery/Madeira_2_OBJ/
SCENERY_PACK Custom Scenery/Madeira_3_TEX/
[external_path:D:\Custom Scenery]SCENERY_PACK Custom Scenery/KBOS – Boston Logan International/
[external_path:D:\Custom Scenery]SCENERY_PACK Custom Scenery/KBOS – Boston Logan International Orthophotos/
[external_path:D:\Custom Scenery]SCENERY_PACK Custom Scenery/KBOS – GroundTraffic City/
================
This would clearly indicate that the Madeira scenery is installed on the drive X-Plane is installed on and the Boston scenery would be on an external drive.
Using such a command makes it really easy for X-Plane to find the scenery on an external drive where the external folder will be treated like the custom scenery folder.
b) A command for remarks:
This could be as simple as done at many other places: “#”
By placing remarks in the same line as the scenery path, X-Plane will always know where the remarks belong to and deleting it if the scenery was uninstalled will still work and also clean the remark.
Example:
================
SCENERY_PACK Custom Scenery/Madeira_1_LPMA/ # requires “RWY follows terrain switched” on
SCENERY_PACK Custom Scenery/Madeira_2_OBJ/
SCENERY_PACK Custom Scenery/Madeira_3_TEX/
================
Adding those features the way described above will
– maintain compatibility to ini-files of older versions
– and do not require to change anything in existing ini-files users already have.
Kind regards,
Marc
+1
Very nice idea, although I have no idea if LR will change this standard until next major build.
If I may add to Philou67 idea, to address the missing custom scenery:
Maybe instead of immediately remoe the scenery line from file, you can add a “flag + counter” to the line, something like: SCENERY_PACK_LOST_{n}, “n” represent number of tries. It will be modified every x-plane start, and once it will try three times, for example, it will be removed from file.
This will allow the user to fix any “mount” or “symbolic link” issues and , in my humble opinion, should be simple to implement until a more complex options will be introduced.
cheers
Saar
I have noticed that the scenery_packs.ini file did change, but a problem I had was that it also removed an airport scenery I had downloaded. The airport ( LFBO ) was working fine before the update.It was also working when I tried it on a backup XP 11.20b5. When I tried to reload the airport into XP 11.20r2 it still would not show the scenery. I hope it hasn’t removed other airport sceneries that I haven’t found yet.
Now we are getting big houses in x-plane, I think some kind of protection for scenery files could be implemented. One of the developers disabled “demo option” only in X-Plane because it was way to easy to simply copy the objects and DSF.
It’s been on our radar for a while to provide decryption “hooks” in the SDK – third parties could do their own DRM and basically only hand the decrypted content to X-plane once they were satisfied. That way we (LR) aren’t responsible for building a strong enough lock for third parties.
The reason we haven’t “just done it” is that the sim’s engine requires multi-threaded access to the file system, and plugins don’t have threading primitives, so we have to sort that out before we can make an API.
Oh no, I knew this had to come up one day – the DRM thingy…
One of the coolest things X-Plane allows is to have a 1:1 full backup on my NAS.
If something goes wrong I simply copy that backup to my SSD and X-Plane runs like a charme.
Remembering my FSX days with all those different DRM solutions, a re-install took days of work – total crap!
I understand that software piracy is an issue but all those people purchasing their software have to pay the price by loosing the really superb backup option.
Also none of the DRM solutions finally work. Tons of cracked FSX scenery versions are available on the internet. The music industrie has learned that DRM makes people dislike such mp3 downloads. Since DRM was removed from most mp3 files, most people accepted to purchase for music legally and sales went up. I think there are good reasons to learn from that and to not follow the failed path.
As more and more really stunning freeware sceneries show up, people may prefer to use the freeware sceneries instead of purchasing payware scenery that potentially comes with trouble. Just imagine you do a longhaul flight and inflight and/or when arriving destination, the user gets some of those “The scenery may not look correct” or “scenery cannot be loaded” errors. Click on “understood” and you are back on the dsktop – just because the scenery developer decided to ask for a password every 3 months and I cannot remember it during flight… Scary scenario!
Just my 2 cents…
Regards,
Marc
Well, the problem is simply that otherwise developers still do their DRM techniques and simply write globally active DRM plug-ins that do weird thing inside the sim, that cause havoc for other plug-ins.
For planes DRM is already more or less standard.
So I think that it is much better if we have standard hooks where DRM systems can be asked and activated at the start or if needed, than the alternative if some hardly known developers with one scenery is always active, even if I am on the other side of the planet.
Don’t remove scenery not found, just disable it with a tag like SCENERY_PACK_MISSING and inform the user in just one message box at startup that some scenery included in scenery_packs.ini has not been found, marked accordingly and that the user should check the ini file.
Don’t include an overly complex UI for scenery stuff. Moving things up and down, and disabling/enabling is fine, but other functionality can be done by 3rd party tools.
And always retain the basic scenery_packs.ini functionality, including automatic alphabetic recreation when deleted. I still order my scenery based on folder names and try to avoid the ini file whenever possible.
“Don’t remove scenery not found, just disable it with a tag like SCENERY_PACK_MISSING”
^^ This !
Pascal