I was counting on winning the $525 million powerball lottery last night. Didn't do it. I might have to re-think the options now......

 

LOL and I was counting on you splitting the winnings, oh well I gues we are both stuck for now.

 

Ahah!!!!! So... you too :-)))) I'm, all on the p-51 now ;-)

 

Yep, me too. The only problem is the learning curve on both, talk about complex systems.

Ahah!!!!! So... you too :-)))) I'm, all on the p-51 now ;-)

 

Hey Juan C, you just got me interested in it. How do you like it?

Hey Juan C, you just got me interested in it. How do you like it?

 

PM ;-)

The biggest mistake they made, in my most humble of opinions, was to bury the terrain data into what seems to be a very challenging format to manipulate.

 

If I may make another observation as to why this may be a poor decision from a usability standpoint:

 

Lately, I've been spending far more time "playing" in WED 1.2 than in X-Plane itself. I've reworked a dozen or so airports in my local area or of general interest to me and my FSEconomy flying in the hopes that someday the simulation rises to its potential. I've been designing them with full intentions to immediately submit them to Robin Peel for the master XP database of airport layouts, but also for inclusion in the "crowdsourced lego-blocks" repository method which was talked about in the early days of X-Plane but as yet is just a glimmer in Laminar Research's ever earnest eyes.

 

At about 1/2 of the airports I've worked on, the actual taxiways and aprons extend well beyond the airport borders which are baked into the underlying DSF file. This results in trees, inaccurate roads, and often autogen homes sitting on tarmac. I can add an exclusion zone to remove them all, but that's only good on a "Custom Scenery" instance of the airport.

 

If I were to submit the airport to Robin Peel for inclusion in the official airport data package, the NEW, accurate airport boundary I created would no impact whatsoever on the underlying textures/roads/autogen. Because of all the precalculations and prerendering, the only runtime use for the airport boundary is the optional airport flattening option. Adding insult to injury, the exclusion zones I've created are not "airport data", they are considered "scenery data" and are not part of the airport files sent to Robin and summarily out to all users in the updates.

 

With that being the case, many of my newly submitted airports would have trees and houses on the taxiways until such time as Laminar Research entirely recuts the DSF tile on which the airport sits, using the airport data files which contain my fresh revisions. if the calculation was done at runtime instead of being pre-designed, this would not be an issue at all.

 

This pre-calcluated landuse method puts significant limitations on airport redesign work. End users will have trees in their way and trailer parks sitting on the ramps until a full fledged DSF recut is performed, and who knows when that will ever happen.

 

For a simulation so desperate for user and 3rd party participation and development especially in the scenery realm, this choice to trade flexibility for what I'm sure is merely modest performance gains is most regrettable, and only further underscores the need for more frequent global DSF updates and/or a user-friendly tool to allow end users to do it themselves.

 

-Greg

... this choice to trade flexibility for what I'm sure is merely modest performance gains is most regrettable ....

Please re-read (for example my ominous interview has lots of that info - if you like, I re-link it the n-th time here) the reasons why this approach was chosen, because your belief here is not necessarily reflecting the real situation of the sim (there is always more in the shades than meets the eye). Calculating all the things at runtime, which you take as granted in the current DSFs might hurt you much much more, than you might imagine ...

 

Though, I wouldn't argue, that in a (possibly distant) future re-design (when ever it comes - I am not foreshadowing anything here) many of these aspect might, could or even should be changed (if it doesn't collides with other, higher priority interests) ... because Laminar sees these drawbacks too (and have seen it - I think - from the beginning), but traded them for something else, which was at least as important (or even more important).

 

This is nothing which can / could / should change overnight ....

Thanks again for your contributions to the discussion, Andras (*not to mention the sim itself!) - I've studied all the posts, notes, blogs, interviews and other items on scenery since the first beta/demo released in November 2011. I should temper my remarks because truly I don't know the inner workings of the sim. I apologize for even remotely inferring that have the expertise to claim that the tradeoffs would be minor.

 

As someone coming in from the "other" platform, which operates in the "other" way, it's frustrating. I don't expect it all to work the same, but I was hoping for similar capabilities from a scenery creation standpoint, which isn't the case yet. My frustrations abound - I'll spare you the list, as you can probably imagine what they are.

 

Since I don't enjoy actually flying in XP10 just yet due to its scenery shortcomings, I've found enjoyment in working on airports and improving fields I am familiar with or have an interest in. Yes, enjoyment! On the plus side, it IS a fairly straightforward process to rework a basic local airfield in WED... the major international ones would be a real pain, but your local one/two runway municipal fields are a couple hours work tops, and it can help with the immersion, even if the surrounding areas are wonky.

 

But it is frustrating to run into more headaches just when I thought I found a creative outlet as I wait for things to develop more. I apologize - I'm not looking to take this personal against anyone at all - I'm just venting as a relative newcomer to the X-Plane culture.

 

-Greg

Hi Greg,

 

At some point I sympathize with you (and many others who have brought up this "shortcoming" already), as I (especially as "data guy") see this drawback as a "brake block" for many developers. On the other hand - luckily - it "only" (I know, this is not a small "only") really affects the base mesh (which includes the landclass and effectively the autogen layouts too), which is ... because of the (I hope) already well known technical reasons ... complex, and not easy to create (without the right tools, knowhow etc. etc.). Most other parts of the scenery system are far less "problematic" and more accessible, like road / rail / powerline networks (see OSM2XP), the airport layouts (with the limitation, that it not directly affects the surrounding default environment), object placements (thats how you do your airports etc.), adding buildings as facade (again, see OSM2XP) or even the forests (yes, they are definitely not so complex). So, all in all its not entirely bleak ...

Still - as you already understood - there are (not so bad) reasons why it is (at least now) the way it is ...

 

Andras