This came up multiple times in the comment section, and is probably important enough for its own post: how are conflicts resolved between user-submitted airport buildings (via the lego bricks and Robin’s database) and custom scenery?
The answer is two-fold:
- Scenery pack prioritization
- Exclusion zones
The user submitted airports are in a single pack; the intention here is that they be given the lowest priority of all custom scenery.* If you install a custom scenery pack after getting 10.21, this will happen automatically (because X-Plane installs newly discovered stuff at the highest priority). If you already have custom scenery installed, you can change its priority in the .ini file or simply remove and re-add your packs if you prefer to sort them alphabetically.
Airport layouts for custom packs will automatically replace the default ones – we only load apt.dat from one pack – this is just like before.
For the actual buildings, custom scenery packs should include exclusion zones to remove anything below it.
This is not new. Custom scenery always should exclude what is below it. I’ve been meaning to mention that in a separate post: custom scenery should exclude anything that would “screw it up”, not just things that have already caused problems! If you make custom scenery and you do not “defensively” exclude, you’re likely to get broken by other scenery packs, as well as the default scenery (either via a user submitted airport or a recut).
If you squint and look at this situation, it isn’t really new — we’ve had a scenery pack with all of Robin’s submitted apt.dat layouts for several years now, and it has never been possible to add/remove individual airports. Instead custom scenery goes on top and replaces. We are doing more of the same for buildings.
* We would have liked to have put it in “Global Scenery”, but it is important that the airports be higher priority than any custom base meshes that might be installed.
10.21 beta 1 is here – since this is the first beta of 10.21, you have to run the updater by hand and check “get betas” to see it.
This will be the only 10.21 beta, so please go try it now. Give it a quick once-over if you make custom scenery or a custom airplane. We’ve tried to put in a whole pile of low-risk bug fixes, but better to test than find out that something went wrong the hard way.
Release notes here, bug report form link is on the right.
One note about KATL: this update contains Tom’s KATL building layout, which is built entirely out of library components. It lives in the “Global Airports” custom scenery pack – this scenery pack will grow over time to contain all airports submitted to Robin’s global airport database.
Posted in News
by
Ben Supnik |
First, please read these posts regarding OSM water and recuts. I’ll be here when you’re done.
Okay good! So the short version of it is that there are three reasons* why water might be missing from the global scenery:
- Our OSM data importer had a bug. What can you do to help in this case? Nothing; it’s on us to fix the bug.
- The OSM base map was missing water back in July of 2011, but the water is in OSM now. What can you do to help in this case? Nothing; we just need to get this new data. (Or perhaps it is because of you that the water is in OSM, in which case thanks!)
- The OSM base map is missing water now!
In this last case, you can help; if the OSM water data is wrong, the global scenery will be wrong in the exact same way. Our goal is: if it looks blue on the OSM main map, it should be wet in X-Plane.
With that in mind, I was surprised to find out about this edit: http://www.openstreetmap.org/browse/way/80118306. That’s a change to the dry lake bed in Edwards Air Force Base by alpilotx. Surprisingly, as of 24 hours ago the tagging in OSM was still wrong, just as it was in July of 2011. I had assumed that Edwarads was ‘wet’ due to an import bug by us, but apparently it was due to incorrect tagging.
So if the base map doesn’t look blue, you know what to do: add the missing water. It’s good for OSM, it’s good for X-Plane, it’s good for pretty much any project using OSM data (and there are a lot of them!) and once OSM is fixed, the bug can be fixed in X-Plane forever because OSM is the data we use to get water/land/coastline info.
* There’s actually a forth reason: intentional removal of water that we thought was too small/detailed for the data size of the global scenery. In that cases there’s nothing to be done to put it back — the global scenery has to be able to cover the whole world without being too many tens of GB.
I have a lot to blog about this week, but before I can get into any of it, let me describe the process of recutting DSFs.
Alpilotx and I are now working on DSF recuts. The recuts will incorporate a few important changes:
- Bug fixes to the OSM import code. Some of the major cases of ‘missing water’ (e.g. Botany Bay) were due to a bug in the code that imports vector water day from OSM into our DSF generator. Once we fix this code, recut DSFs will get back water that sould have been there but was “lost on import.”
- Newer OSM data. The OSM data in the simulator now comes from approximately July of 2011. OSM is growing fast and being improved every day; for the recuts, we will take the latest data. If water was missing because it was not in the map in 2011, but that water is present now, recut tiles will get the new water.
- Airport boundaries from the latest airport file from Robin. Due to a last-minute data screw-up by me, many airports in the original DSFs were cut with very old airport data, and thus the airport boundary is wrong or missing. Even the airports that were cut with current data have the airport areas from November of 2011. Recut tiles will use the lastest (March 2013 when I last checked) data.
- Better land-class allocation. While the source land-class data that alpilotx prepared for me is very, very good, the resulting land class in the DSFs is sometimes inaccurate due to the limits of the algorithm I apply to it. I am working on improvements to that algorithm. The details of these changes are probably too technical for this blog, but the short of it is that I am trying to fix as many of the algorithmic problems that we’re not happy with as I can in the short amount of time I have been allocated.
A Tactical Recut
At this point you are asking the two most important questions: which tiles will you recut and how will you get them? The answer to both is: we are starting the process by recutting a small number of tiles that we think are most important to recut, and pushing them out over the network as part of the update process.
At this point we have enough bug data from users that we have a pretty good idea of which tiles need to be recut first. For example, trees on Chicago’s runway, Botany Bay not existing, and Edwards AFB containing a real (and not dry*) lake have all been reporting about 5,290 times each. So we will pick the first set of recut tiles ourselves to fix the most visible, highly reported bugs.
But the goal here is also to start an assembly line that can mostly run by itself. That is, once we get these bugs fixed, we can potentially recut a fixed number of DSF tiles every month and include them in an update, which will move us closer to having the scenery be “live” like the sim and not frozen for the entire version run.
I think moving to a live model for the base DSFs is an important step that we have to make. Back in X-Plane 6 when I first started flying X-Plane as a user, Austin sending out patches with a new version of the sim every month or two was viewed as crazy. Look at how far we’ve come: at this point application updates are built into the Apple app store on iPhone (and the Mac app store), and if you don’t push updates, users want to know if you’ve been hit by a bus. Updates are the norm.
That change is completely logical: back when I started working on commercial software (in the 20th century) distribution was by CD-ROMs, which were mostly sold in stores. Once your software went out, that was it, so “done” was “done”.
Now software is mostly distributed over the internet; with constant connectivity and increasing bandwidth, it would be crazy for a company to not respond to its customers needs and requests by issuing updates. One of the most important properties of software as a “building material” is its flexibility — if users want software to do something different, you can easily change that software. With widespread internet connectivity we have the matched distribution to go with the flexibility of the software itself.
This recut is not a global world-wide recut; I do not know when or even if this will happen. Instead the recut is a first step into keeping DSFs “current”, and the beginning of an on-going process.
The Next Train Leaves in 10 Minutes
The other question that I hear a lot (besides which DSFs and how will I get them) is “when do I need to finish my OSM/apt.dat mods to get them into the recut.”
My goal with incremental periodic recuts is to avoid this issue entirely. Once we recut a DSF, the cost of recutting it again is very low — we just hit “go” on the DSF generator and replace the files in the update.
In other words, don’t worry about when you “have” to get your updates in by. We will recut tiles, and if you make a useful change after the tile is recut, we’ll recut it again. Recuts should be like a train that leaves the station every 15 minutes, not once a week.
(With Robin republished the apt.dat on a regular basis again, apt.dat updates are already like this.)
Executive Summary
TL;DR? Here you go:
- We are recutting a few tiles at a time, not the whole world.
- Recut tiles will come as part of the automatic X-Plane update process.
- Tiles may be recut multiple times to gather new improvements, so don’t worry about “missing” an update when you improve source data.
- We are fixing import/programming problems in the first set of recuts.
- We have enough bug reports on tiles now, we don’t need more yet.
* I’m still not sure what happened at AFB, but my guess is that our importer saw “lake”, got very excited, and ignored the word “dry”.
It looks like 10.21 will not contain new autogen art assets. Propsman has a pile of stuff partly ready to go, but had to go on a pre-scheduled trip and wasn’t able to upload the files before he ran out of time. We’ll cut 10.22 to drop autogen in – it’s not hard for us to run an update to push art assets.
But he did send me a fix for one autogen bug that we’ve received some rather vocal complaints about:
In X-Plane 10.20 Propsman accidentally mapped some industrial warehouses to a land-class that is mostly used for small towns and rural populations. The result is a lot of big ugly industrial buildings in places that don’t make sense.
The second shot shows the same area modified with the new patch, which puts smaller individual buildings into place. This should help the land-scape look less disrupted.
The mapping from land-class to autogen is part of the autogen library, so as we get more art assets into place we will continue to tweak the mapping to try to get the best looking results.
Please note that this change may affect frame-rate, possibly not in a good way. Depending on what your hardware is good or bad at, changes to the autogen will cause frmaerate changes.
I have a bunch of stuff to post about in detail, so let me first clear out the “what’s going on” category.
- I’m not actually going to law school, and we’re not canceling X-Plane to become a non-practicing entity. That was an April Fools Day joke.
- We’re working on the finishing touches to X-Plane 10.21, which will go into beta soon and have a short beta period. 10.21 is almost entirely bug fixes; I’ll write up more detailed notes on this later.
- I have a new semi-official beta of MeshTool 2.x that fixes bugs; if you use MeshTool and would like to test it, poke me. I have not had time to get a MeshTool 3.x (that creates v10 DSFs) working yet.
- I’m working on a new beta of WED, one that includes the “submit-to-Robin” work-flow for submitting airports built entirely out of library parts.
- Alpilotx and I are working on DSF recuts. I’ll post more details on this process in another post – there’s a lot to say about it.
That’s a rough picture of what’s going on – details to follow.
Posted in News
by
Ben Supnik |
Some personal news: this fall a lot is going to change; I’ll be heading back out west (again) and back to school (for a third time) – this time to Stanford. Their joint degree program is really good if you’re looking to get into IP law. At $50k per year, it’s on the pricy side, but fortunately (for me) LR is paying.
Why would Laminar Research pay for this? Well, if you haven’t read the news…
PRESS RELEASE
Laminar Research announces concession to Microsoft Flight Simulator, will withdraw from flight simulation market.
New business model in Intellectual property announced.
April 1, 2013
Columbia, SC:
THE CANCELLATION OF X-PLANE:
Austin Meyer, author of X-Plane, announced today that he will be withdrawing X-Plane, and ceding the flight simulation market to Microsoft Flight Simulator. “Sales of X-Plane are growing exponentially, but I wanted sales to grow exponentially times TWO!” claimed Meyer, citing poor sales as one of the reasons that he will be removing X-Plane from the market.
As well as canceling X-Plane for Macintosh, Windows, and Linux, Laminar Research will be removing X-Plane for iOS and Android from the App Stores. When asked why, Laminar Research President Austin Meyer was very clear. “Let’s be clear”, Meyer said “The AppStore generates significant revenue for Laminar Research, but only after I have UPLOADED the App for people to buy, and this is a frustrating process that can take in excess of 30 minutes… sometimes even 45 minutes if I am downloading episodes of “Breaking Bad” at the same time! I just cannot justify that type of grueling WORK!” Meyer noted that he believes that the Apple AppStore is an old idea with “limited potential” that only benefits a few people at the top of huge mega-corporations, since small, hard-working, creative developers could never get an Application ON the AppStore, thus leaving all of the profits to a few huge, faceless corporations.
THE NEW BUSINESS MODEL FOR LAMINAR RESEARCH:
Laminar Research is announcing exciting new prospects for the future, though! Beginning this April, when Laminar Research removes the X-Plane product from all servers and sales outlets, it will move into the “Intellectual Property Licensing” business. Laminar Research has filed or acquired a number of patents on “blade element theory”, and “using a computer to calculate forces on an airplane”, and will be suing all companies in the flight simulation market for a percentage of THEIR income, rather than actually making anything of it’s own. “Remember” quotes Meyer “Running a business that actually CREATES something is so much WORK! You have to create a product that someone would actually VOLUNTARILY WANT to BUY, and then find a way to PRODUCE, DISTRIBUTE, and SUPPORT it! This is far too much work. It is much easier to SAY that I invented the IDEA of SOMEONE ELSE building a flight simulator, and then SUING anyone that actually DOES! That way, THEY do all the work, and I get the money for it! This is really a much more enlightened business model, and will be very profitable for Laminar Research, since I can now sue MANY companies in the flight simulation space without having to go through the tiresome process of actually MAKING anything!”
When asked for the specifics of how Laminar Research could actually do this, Meyer elaborated his future plans: “The patent system is EXCELLENT!” claims Meyer “All I do is send a piece of paper to the United States Patent Office claiming that I am the first person to think of someone ELSE writing a flight simulator! Since nobody in the United States Patent Office knows what a flight simulator is (Why WOULD they!??! They don’t build flight simulators!!!!!!!!), they OBVIOUSLY approve my patents, and that allows me to sue anyone that has actually CREATED a flight simulator!” When asked how Meyer could do this, when flight simulators have been in use since 1909, Meyer claims: “I never HEARD of anyone writing a flight simulator before I did, so I just logically assume that I am the first person to think of the idea! So I must OWN the work anyone ELSE does in flight simulation. That’s how the patent system works!”
None of the other companies in the flight simulation industry could be reached for comment, but are advised to save up money for their lawyers: Patent-infringement cases run about $2,000,000 in defense fees.
I am very excited for the company’s new direction; I’ve been coming up with obvious programming ideas for years now; finally we’ll get to monetize them without having to debug code first.
Posted in News
by
Ben Supnik |
Why the nerdy recursive acronym for WED? Sometimes the data just stares you in the face.
I spent an hour today doing inventory on the build-up of WED bugs. That’s a screenshot of one of my bug screeners for the public scenery tools bug base – open bugs in WED 1.2b1 sorted by severity. Notice a trend? 100% of the crash bugs come from the import/export module. In fact, export bugs dominate the crash+major category too.
At this point I believe the DSF overlay export code simply needs a rewrite. The current code converts the polygons from my code to CGAL, then attempts to chop them up to fit into DSFs, and then converts them back and exports them. To put it mildly, this code is not working well.
As far as I can tell, CGAL 3.9 (the version we use) has reliability problems on Windows when processing Bezier curves. I don’t know if it’s a build environment issue, something I did, or their bug, but I don’t trust the code path; we don’t use CGAL’s bezier curve processing for the global scenery project, so we don’t have strong data that this code will ever work.
Why Do We Need to Cut?
The current WED export code chops up your polygons to fit them into the DSF tile boundaries, because everything in the DSF must be contained within the DSF, right?
Well…
There’s actually nothing in the DSF file format to disallow ‘overhang’, e.g. a facade or some other shape that is partly in the DSF. And for custom airports, having to cut buildings down the middle at lat/lon boundaries is unfortunate – the results can look ugly.
Unfortunately, as of this writing, X-Plane 10 requires the DSF to not “spill over” its boundaries. But it looks like this could be fixed.
Multiple Export Fixes
This is my plan for fixing WED export, more or less:
- WED will provide a “target” X-Plane version, e.g. 9.00, 10.00, 10.30, etc. This will select what kind of export features it can use. If you try to export a project using a feature that cannot be supported (e.g. custom facade walls to a v9 airport) you will get a warning or error, depending on the nature of the problem.
- WED export will not attempt to cut overlay data on-the-fly; rather it will either export the geometry spilling over the border (if allowed by export target version) or flag the span as an error.
- An edit menu tool will be provided to cut geometry at DSF borders, for at least some DSF geometry types.
Why make border cutting a manual step? I think that it will be more useful for authors to see the result of the border cut. For example, when a facade is border cut and has unique wall choices, the author has no control about the wall type of the wall that was introduced to span the DSF border. With pre-cutting you can slice your facade, then pick a ‘safe’ wall type for the two walls that face each other at the DSF border.*
WED will currently refuse to border-cut some geometry; I think this will continue in 1.2, albeit this will happen in the “cut at borders” command – if you request to cut a bezier type WED may refuse.
* No matter which way you slice it, cutting facades at the DSF border sucks. This is why I think the long term solution is to allow facades to span borders, at least a little bit.
I seem to be having the same conversation with lots of third party developers via email, so I’m going to write up some of my recent thinking on Lua – if nothing else, it will save me typing the same thing over and over.
One thing was very clear in the X-Plane 10.20 beta: while authors can’t agree on Gizmo vs. SASL*, the entire authoring community is surprisingly united around Lua as a scripting language – it’s everywhere in the payware add-on market.
But Lua is being used for a lot of different things – and these levels of usage are paralleled in Gizmo and SASL; my opinion on the use of Lua must be qualified by which usage we are talking about.
- The simplest level is “datarefs and math”. At this point, to fully utilize the aircraft SDK, an author needs to be able to create and do very simple math with datarefs – something that is not possible inside an OBJ or panel.** Right now we don’t have an easy way to do this basic dataref math. Writing a C plugin and compiling for 3 platforms is a huge hurdle to jump just to wire up an animation to a custom rotary switch.
- Gizmo and SASL both provide ‘add-on’ SDKs – custom sound APIs, particle systems, physics, gauges – basically replacement SDKs for parts of the sim’s own extension system where authors wanted more than we provide. This stuff isn’t Lua at all – the underlying systems are coded in C++ and thus can only be maintained by the C++ developer who writes the Lua-based plugin. The development cost (in man-hours) to do a particle system in Gizmo or SASL is abotu the same as it would be to build it into the sim.
- Some authors have written fairly huge scripts in Lua – for example, doing complete systems simulations or navigation code in Lua. (At least, that’s what I am told, e.g. the JAR A320 – I haven’t read the Lua scripts myself.) This is “Lua as language for a huge program.”
This is my current thinking on these three tasks:
- Datarefs and math are a great use of Lua – it lowers the bar for authors, it’s exactly what scripting languages in games are meant for, and the underlying code in C++ is finite, limited, and therefore not a maintenance problem. I don’t know what LR’s relation to Lua, Gizmo, SASL, or scripting is yet, but I have been saying for a while (internally in company discussions) that we need something easier than C for this.
- I think that if an authoring SDK is limited in X-Plane, we (LR) need to make it better. In the most useful cases where people are doing things with Gizmo and SASL, we sometimes have on our road map features to add to X-Plane that are similar. (But note that these features aren’t necessarily coming soon – authors get a time to market advantage by using these outside SDKs.) I consider this plugin code to be a possible maintenance problem. For example, you can write graphics code in a plugin, but it may not integrate well with next-generation rendering engine features.
- I don’t see huge plugins or huge scripts as something LR should get involved in. If you want to make a truly huge or complicated add-on, that’s great, but it’s a big undertaking and it just takes a development team. I don’t know if Lua is good for huge development; the people who say no (people like me) have no serious Lua experience, and the people who say yes have no serious C++ experience. So far I’ve only heard from people who have lived on one side of the grass.
Anyway, one thing is clear: having LuaJIT work in a plugin is a necessity for X-Plane now; with 10.20 we’ve sunk the engineering cost to make this happen. I do not yet know how else (or if) we will leverage Lua.
* Don’t even bother to comment on Gizmo vs. SASL – I will delete any attempts to start a Gizmo vs. SASL discussion so fast that your head will spin around 360 degrees!
** No math in OBJs or panels. An OBJ is a 3-d model – it is data that you view, not a simulation to be executed! We do not want to mix visualization with simulation or data with code!
X-Plane 10.20 went final last night – we are now officially 64-bit (as well as 32-bit).
We have a number of small bug fixes that we will put into 10.2x bug fix releases – the name of the game here is small, unintrusive fixes that make a big difference to the sim without risking more problems. We’ll get to bigger fixes in 10.30.
Small things may include:
- A new apt.dat/nav.dat drop from Robin.
- Fixing the King-Air wipers – it looks like our exporter script went nuts.
- Fixing the command key on Mac – the control key works as expected.
Fog is invasive – that’ll have to wait until 10.30.
Posted in News
by
Ben Supnik |
