I’m not saying that we can’t prioritize. I’m saying that we can’t prioritize a priori – that is, prioritization must be done by the user on their machine, not for them in advance by multiple developers who are not aware of each other’s work.

Hi Ben, got any baby puke on ya yet?.:)

I guess we can agree to disagree on this but I’m not quite sure why. If there’s no right answer to prioritization, then we can’t prioritize, can we. Now I’ll give you something to consider, a thousand pictures of your childs life, properly named and dated so you can quickly see those 16th birthday pics or when he he took his first dump, OR, those same pictures thrown in a shoebox,,,well, I know there’re in there somewhere..

I think what you are referring to is a pack with multiple elements in it, (something I disagree with) and that’s where file tagging of some sort would be more efficient, I guess, keeping those elements seperate would be a lot easier but I don’t suppose you can dictate that. But regardless I’ll continue to rename my scenery so I know what I have and don’t have. After 5 kids and 5 grand kids I’m running out of shoeboxes….

Now quit this loafing around and go back work

Hi Thomas,

I have to disagree.

A naming convention implies that there is one right answer to scenery prioritization. (If there isn’t one right answer, packs must be renamed, which is bad for installation.)

An .ini file implies that scenery prioritization is a local user specific configuration, like joystick settings.

I think there are things we can do in the long term to solve basic prioritization problems (e.g. meshes vs overlays). But consider a payware package and an airport included in a virtual airline’s customization pack. Which should be higher priority? How about two payware packs. Which should be higher priority?

_EUR_France_apt_LFSJ Douzy v5.3
_EUR_France_apt_PARIS_airfields_DSF
_EUR_France_area_overlay_Mont-St-Michel
_EUR_France_area_overlay_PARIS_suburbs_DSF
_EUR_France_area_phoscenery_PARIS
_EUR_Germany_apt_ED03 Pohlheim_Viehweide
_EUR_Greece_apt_LGKO tdg
_EUR_Greece_area_phoscenery_LGSR Santorini
_EUR_Hungary_apt_LHBP Budapest tdg
_EUR_UK_England_apt_EGLL Heathrow
_EUR_UK_England_apt_EGSS – London Stansted
_EUR_UK_England_area_overlay_EGLC_Canary Wharf
_EUR_UK_Scotland_apt_EGPF Glasgow
_EUR_zContinent_area_overlay_Treelines_Farms_v2
_NAm_USA_MA_apt_KACK Nantucket_v1.2
_NAm_USA_MA_apt_KBOS v101
_NAm_USA_MA_apt_KEWB New_Bedford_Regional
_NAm_USA_MA_apt_KMVY Marthas_Vineyard_2.1
_NAm_USA_MA_area_phoscenery_KACK Nantucket Island Photo v1.0
_NAm_USA_MA_mesh Nantucket_Island v1.0
_SPa_NewZeLand_apt_NIUE Niue Intl. Airport
_SPa_NewZeLand_apt_NZCH Christchurch_AP
_SPa_NewZeLand_area_overlay New_Zealand_Overlay
_SPa_NewZeLand_area_phoscenery Christchurch
_SPa_NewZeLand_mesh New_Zealand
Libraries remain untouched and are grouped at bottom

This is a small example of my Custom Scenery Folder, scenery.ini file bedaned. A simple naming standard could be set in place by LR for developers to follow and none of this bs would exists. Andreas grouping suggestion is dead on but we don’t need another app to it. I don’t think any scenery developer would complain about following a naming standard for their creations when it’s going to guarantee their work gets loaded properly and they don’t have to type two paragraghs explaining how to edit the .ini file. In five years that .ini will be a-kind to the windows registry and users custom scenery folder will look like a windows directory, G forbid, instead of what you see above. Just saying….

with all graphics settings maxed, I’m only seeing the plausable houses being generated on a very small amount of the roads.. Ill list what I am seeing

all settings maxed…

Forest areas: 1/3 of them are filled in.. the ones that are filled in, are filled in nicely
Roadways: 1/2 maybe less has autogenerated houses/buildings attached
no city area anywhere on the Island.. I dont see any scenery texture representing a city tho.. so I suslect that is just down to it not being there.. Never the less.. the roads… Is there a way to force the roads to spawn the houses? Otherwise I have vast swaths of green grasslands, and residential roads laid out in very nice neighborhood layouts, with not a single house for miles.. and then.. a single road leading to the next village, with houses on each side…

I get the impression there is something fundamentally broken and its not just a “bad scenery” deal.. But I wouldnt know where to start, to try and fix it.

This is both with and without my scenery package ..

Right – creating groupings is one of the proposed fixes for the chaos; at this point I’m leaning toward holding off on further structure changes until a major version upgrade to keep from creating a moving target, but in the long term it’s a sane idea.

But now there is a need that the custom sceneries needs to be grouped. For example Ground Mesh sceneries are different to OSM sceneries or airport sceneries. At all not the user should say when a scenery needs to be loaded by XP. The scenery developer should do that. And for this Laminar should do something that the developer can define the time, when X-Plane loads it.

I offer a possible solution. Similar to the library.txt there could be a scenery.txt which defines a layer.
I made a tool which can deal with that. It can group your sceneries and generates the correct scenery_packs.ini file.
Soon I will upload the installer at x-plane.org at the moment you can get it on gihub:
http://lyckade.github.io/xpstart/

I also made script which can generates that exclusion sceneries. You can download them from my webpage. If something is missing you can write me an I will upload them.
http://xplaneblog.de/exclusions/

Hi Jan,

It’s more subtle than that – the DSF recut process does allow roads (but not autogen) on the airport area, but it does cut them if they intersect actual pavement polygons. The results are imperfect – the problem is that we don’t know whether an OSM road should be modeled as a real X-Plane “road” (e.g. draw asphalt over grass with some street lights) or drawn in WED as white line markings on continuous pavement. Cutting at the pavement is the least bad compromise I’ve found so far.

Referring to your point 1 Jan;

That’t the way I handle this. It gives me the view on what and where to exclude, in combination with the custom scenery. Placing an exclusion just “somewhere” by referring a satellite picture, will not result in a good quality exclusion and custom scenery package. It might lead to exclusions blanking to much of airport surroundings.

I need to see where the airport is, taxiways, buildings, roads etc… And than decide what to exclude.

Open WED, Import the apt.dat, import the dsf and add exlusions, export, perfect. Sure this process has to be redone, everytime a custom scenery package gets updated. But this does not happen everyday and just takes a few minutes…