Many of you have taken the time to tinker around with the new ATC system. Many of you have had a good experience, others have found yourselves frustrated for various reasons. My goal here is to try and explain what you can expect from the system moving forward and describe the causes of some of the troubles that you might be having.
First, as I’ve said before, what you see in the ATC system is just the tip of the iceberg. The features are going to expand moving forward. What you are looking at now is not the way the final system will work. If we waited months or even years before shipping X-Plane 10, I’d still be saying the same thing. The reason is that the ATC system has the potential to be very large and very comprehensive much like the scenery system. It will evolve over time. There will never be a lack of new things that would be cool to have, there will never be a lack of things that can be changed for added realism etc. We have to develop things in stages however and what you see is merely the first stage.
The first stage was designed with one goal in mind: to create a system that’s comprehensive enough to give AI aircraft a purpose. Having AI aircraft buzzing around creates a living airport environment. Coupled with Ben’s new roads and railways, the X-Plane world is no longer a static world, it’s one that’s alive! AI aircraft are very low maintenance. They don’t have many requests, they aren’t picky about their routings. They just want to depart from one airport and arrive safely at another airport and the current ATC does that just fine. We’ve also allowed YOU the user to interact with ATC at this point but humans are not as simple as the AI planes. Your goals are a lot more specific and detailed than the AI goals and the current ATC doesn’t handle that so well. That’s coming! That’s phase two however. Right now, your interaction with ATC allows you to “get into the system” so that you can have a turn to use the runway for takeoffs or landings.
For those of you unfamiliar with the real world ATC system, let me tell you what it’s NOT. It’s not a turn-by-turn Garmin navigation system. ATC’s job is never to be your navigator or co-pilot. Yes, they often do assist pilots but this is NOT their primary goal. Their primary goal is the separation of aircraft within their airspace. Often, when ATC is assigning you headings for vectors, it’s because it’s easier for them to put you exactly where they want you to be than it is to let you fly however you feel. They’re controlling your position for spacing, for sequencing and for efficiency. This typically only happens on approaches where numerous aircraft are all converging in tight spaces to use a single runway.
X-Plane is no different. If you file a flight plan with a blank route, you’re expected to go DIRECT to your destination. You will not be given instructions on how to do that. If you file a route, you’re expected to fly the route by yourself. You will not be told when to turn or how to get from fix to fix.
ATC is also not a weather service. If you want to know the weather, you have to tune to the various AWOS/ASOS/ATIS frequencies around the world. These were in v9 and they still exist today. Yes it’s true that real controllers will often give you weather information if you ask. We may add a little bit of that in the future but even in the real world, it’s not their job…they do it because they like to be helpful people.
The first stage of ATC right now will give you an IFR clearance after you file your plan. They will assign you a squawk code for radar tracking. They will issue you a routing to your assigned runway. They will ensure that you are only allowed to depart when it’s safe. They will stay with you until you’re near your arrival airport. They will provide vectors to your approach (visual/ILS) and then they will issue you a landing clearance and allow you to continue as long as the runway is safe to use. If the runway becomes unsafe, they will instruct you to go around for another attempt. When you land, they will issue an appropriate taxi route back to your gate. That is the extent of what is possible with the first stage. It’s not comprehensive but it’s a foundation to work off of.
What kinds of things might you expect in the next stage? (NOTE: these are not promises. The details of future features have not been finalized but i’m trying to offer an idea of roughly where we’re headed). VFR operations. Requesting higher/lower altitudes in flight. In-air conflict prevention and resolution. Changing destinations in flight. Requesting specific runways. Requesting specific approaches…etc. etc. Please do not make feature requests at this time. I’m just rattling off some ideas from memory.
I have one or two remaining stability issues to clear up before I can fix some of the current usability issues that seem to have come up. For now, here’s an explanation of some of the issues so that you may at least understand what’s going on under the hood. I will say, the current system is a lot like a fire alarm in that it only takes one simple problem like a dying battery to be REALLY annoying. But like a dying battery, a relatively simple fix can make the problem disappear.
- “I filed a FP but ATC isn’t talking to me” – That’s because you haven’t asked for anything. Tune your COM1 radio to the appropriate controller for an IFR clearance. At big airports, this is the Clearance Delivery controller. At smaller airports, this can be Ground or Tower.
- “How do i know what frequency to be on?” – You really only need to know the frequency for two people. The guy who’s going to give you your IFR clearance, and the ground controller. After that, you will be instructed by ATC which frequency you should be on for the remained of you flight. You can get the DEL/GND frequencies from a variety of places. First, in the sim you can go to the local map view, enable Airports and then click on the airport that you want the frequency of. Then look at the popup. You can also use real world charts or resources.
- “ATC is giving me a routing that’s through gates and buildings” – This is because the taxi layouts are auto-generated and have no idea where the buildings are. In the future, airport authors will create detailed taxi layouts that will completely alleviate this problem at their airports.
- “I taxi to the runway and nothing happens” – If you were talking to ground, he should have handed you off to tower. If he didn’t, then perhaps you didn’t pull up enough. Make sure to taxi to the very end of the yellow arrows…not necessarily the hold short lines pained on the ground. Again, when human authors make taxi layouts, these should align perfectly (as they do in KSEA) but for autogenerated layouts, they may not. Trust the arrows, not the paint.
- “I contact tower holding short of the runway but i don’t get a takeoff clearance” – This is because it’s not safe for you to takeoff. You have to be patient and wait. There could be someone taxiing on the other end of the runway, there may be an arrival that’s too close, or the last departure may still be in the way.
- “I’m constantly being told I’m off course” – This is because you are…
The problem however is probably not your fault. If you don’t file a route and you leave the routing blank, ATC assumes you’re going “direct”…the current bug is that direct is from the center of the departure airport to the center of your arrival airport. So what happens is that you takeoff, you fly runway heading, you get yourself adjusted, clean up the aircraft….by this time, you can be MILES from the center of the airport where the route line began. Now you decide to “proceed direct” your destination but you’re now paralleling the course that ATC expected you to fly. The real solution to this in the future is me fixing this in various ways but for now, try to fly a course track that emanates from the center of the airport or file a real routing. Real routings may sometimes have the same issues for the same reasons but will be probably be less severe.
- “I’m constantly hearing AI planes getting yelled at for their altitudes” – yeah this is because some of the AI planes are being asked to climb to FL360 or so and they seem to be climbing in an inefficient manner. They end up running out of airspeed at FL330 or so and then are not smart enough to step climb up the rest of the way so they just stay there on a border-line stall. Austin will need to tweak the AI planes in the future.
- “ATC’s not talking to me after I depart” – Why should he talk to you? You’re the pilot, your job is to fly the plane the way you filed. ATC is NOT a turn-by-turn GPS. You need to know how to get to where you’re going on your own and you are expected to do so. The ONLY time you can expect vectors currently is when you get within 30nm of your arrival airport. At that time, ATC will issue you vectors for your visual or ILS approach.
- “ATC forgot about me after issuing me some vectors” / “ATC is vectoring me away from the airport” – Perhaps ATC is not issuing the tightest vectors in the world if you’re in a small GA plane, but it’s not THAT far off. ATC (much like in the real world) typically issues vectors to final using a vectoring Tee (See below). Yes, you may be told to fly away from the airport. Yes he may give you headings that seem out of the way. He will not forget about you. Hang in there. Depending on your arrival angle, you may be given some shortcuts. In the future, I can add some tighter shortcuts as well but it’s actually not that far off. I think in it’s worst case, you can expect an 8nm intercept to final.
So here’s a vectoring tee like the one used by X-Plane’s ATC. The numbers represent the headings you could expect for this sample runway (09/27). Depending on whether you’re approaching from the north or the south, you’ll be given only half of this Tee. Let’s pretend that you were south of the airport…you’d be given a right turn heading 090, then a left turn heading 360, then a left turn heading 330, then finally a turn to 270. Depending on your aircraft type, you may be required to fly away from the airport by several miles. This is normal. ATC has not forgotten about you. You will be turned back toward the airport when the time is right.
So that’s a quick dump of my brain regarding ATC at the moment. There will be more posts in the future about future features and what you can expect. The purpose of this post was to just give you a glimpse of the status of things and alleviate some confusion all around since it’s a completely new paradigm for many people.
I had a chance to catch up with Robin the other day and discuss airports with him. Here’s the basic road map for airports in X-Plane 10.
In version 9, an airport consisted only of taxiway layout data. Robin collected and managed a big database of contributed airport taxiway layouts, which are available under GPL and ship with the sim. WED 1.0 lets you edit these layouts.
In X-plane 10 we now have three categories of airport data:
- The taxiway layout – this lives in the apt.dat file.
- The ATC taxi layout and flow information. This also lives in the apt.dat.*
- Lego brick building placements. This lives in an overlay DSF.
Our plan for the version 10 run is to collect all of this data together and redistribute it all, just like we do the current apt.dat file.
We also plan to build a few airport building layouts ourselves, using the existing lego bricks, without custom elements. This will help us further debug the bricks, get users some more airports quickly, and help us understand the authoring process. We have some of Tom’s time earmarked for this.
WED 1.2 will support taxi layouts and airport building placement. Based on my talk with Robin, I believe I will also need to build a more specialized “Send to Robin” export function that pre-checks and packs the submission to streamline the process; since an exported airport will include DSFs and apt.dat files (and should not contain custom OBJs) having the packing be automatic will save everyone a lot of time.
What about autogen buildings? I don’t know. We wanted to try this before we shipped and ran out of time. I think we could autogen buildings for small airports that just have buildings next to the autogen taxiways, but for custom layouts I don’t know that autogen will ever be good enough to make humans happy.
Over the next few weeks I’m hoping to have more time to roll out tools and documentation to move this process forward. The library is already complete, so the quicker we can get everyone using it, the better.
* If you have an airport layout wihtout taxi layout and flow information, X-Plane automatically generates default flows and layouts.
In my previous post I announced that we have the ability to recut DSF tiles in an update and that we have already started doing this. I pointed out that we’re not signing up to recut the whole planet because we don’t how we will manage distribution yet.
This sets us up to talk about OpenStreetMap (OSM). First the basics:
- The X-Plane 10 global scenery gets its vector data from OSM – that would be roads and water.
- X-Plane 10 does not get its raster data from OSM – we get land class and elevation data from a composite of sources , both integrated by Alpilotx using a mix of tools I wrote and some GDAL/GRASS voodoo. (I think he may have had to sacrifice a live goat. I try to not ask questions about what goes on with the raster data!)
- OSM is the only source of water body data in X-Plane 10.
The result is a lateral move for water body data quality and an ironic one: for the first time the US isn’t the area of the world with the best data sources. OSM coverage in Western Europe is often near complete. By comparison, the US is still quite sparse.* The result is that water bodies that were present in the US in version 9 are now missing in version 10.
(To make matters a bit worse, the OSM extract for the global scenery is from July. I had to take an extract and stop updating to stabilize the scenery development process. We’ll take new extracts in the future but what you see now is months older than the current OSM data, not weeks.)
Why didn’t we use multiple water data sources? There were two problems:
- We ran out of time. It’s really tricky to integrate multiple data sources that don’t line up spatially, and while we had some promising tech, it made the DSFs worse as often as it made them better.
- Because all other sources of water were not in OSM, we had the potential for road/water conflicts, which makes the integration very tricky. In the old days when we used terrible VMAP0 data for roads, we could just nuke the road if the water didn’t match. But OSM road data is quite accurate and we didn’t want to manually edit it.
So my thinking is that what we really need to do is make OSM as good as possible and then recut tiles. Improving OSM improves the global scenery in the long term, everyone can participate, it helps everyone using OSM, and once OSM has the correct water data, getting it into a DSF is just a matter of recutting the tile. If the water data is all in OSM, then we don’t have to worry about water/road conflicts. This is the true power of using OSM: for the first time we can all focus on the source data, because the source data is public and community owned.
I did some work a few months ago to prepare NHD (the US national hydrography dataset) for OSM use. I am hoping to find a little bit of time to continue with this effort – my goal was to make it easier for people to import high quality NHD water into OSM, but there were some unsolved workflow problems when I left off to focus 110% on getting v10 out the door.
What Other OSM Data?
One question that comes up over and over is: what other OSM data will you use? The short answer is that I don’t know, but I think individual building shapes is not on the short list. The problem is that I don’t think we can adopt our autogen at the quality level we like to such arbitrary shapes.
That doesn’t mean that other third party scenery can’t use the data now, or that we won’t use it someday. But it’s not next on my list.
One type of data that I do think we could make good use of is “point of interest” data – e.g. we there is a school tagged in the OSM data, we could drop in a school autogen art asset for a given location – this kind of “shaping” of the autogen could, I think, provide another level of richness and accuracy while leveraging the existing autogen and DSF generation technology.
OSM vs. Airport
One last note on OSM and recuts: in the past we have cut out roads near airports. Our older road data was often very inaccurate and would run right over a runway. The cutting process tried to minimize the insanity.
OSM data is often very good and there are many cases where the OSM data could be left alone for perfect perimeter roads. I do not yet know how we will modify the cutting code to ‘preserve’ such road data, but I would like to get this right in future renders.
One problem that makes this difficult: often the on-airport roadways are modeled in OSM, but without any tagging. The result (when road cutting is off) is a city street down the middle of the tarmac, often where the vehicle paths should be. So we need a way to know whether a given OSM road is okay or not.
* The US road grid was first seeded by integrating TIGER road data into OSM. This gives the illusion of total mapping when in fact some areas have never been hand edited. The TIGER water was not brought in during the initial import, hence areas with roads but no water.
With X-Plane 8 and 9 we had a perpetual problem: the airport layouts ship with X-Plane and are updated frequently by Robin; if an airport layout is changed significantly or a new runway is installed, the airport layout may conflict with the base terrain and autogen from the underlying DSF that was cut when the sim was first shipped.
This resulted in a huge amount of stress for users who were building airport layouts. When is the cutoff for new layouts? What if I don’t make it? It will be years before the DSF is fixed.
I think the solution for version 10 is actually quite simple: we will recut individual DSF tiles and “push” them in sim updates.
In fact, we are already doing this. Five tiles, including the tiles containing Paris and Denver, rolled off the production line broken and we didn’t detect the problem until after we burned the DVDs. The patch is already online, and if you are running with current betas and installed Denver and Paris from DVD, you should have the corrections.
I think we’ve reached a point in X-Plane’s development where we need to evolve the global scenery from a static product that never changes to an ongoing one that can be updated in pieces, on the fly.
The History
I have been involved in X-Plane since version 6; for as long as I’ve been around, the product has been updated frequently with frequent patching. Starting with X-Plane 8 we developed a proprietary installer that let us easily push patches to three operating systems, with users downloading only the changed bits of the sim.*
The problem with the update strategy was that the global scenery was always too big. And what we found was that if we perpetually recut the global scenery, it made everyone who had already bought the scenery crazy mad. The last thing you want to do is buy the sim and discover it would have been better if you waited.
The idea of the “update” strategy is that you can buy into a major version run as soon as you want or late, and if you jump in early you get all of the future updates for the version run for free over the net. So we would update the sim and leave the global scenery alone. Thus there was never an update to the version 9 global scenery.
The Brave New World
The problem with not updating the scenery is that it takes us years to fix bugs, share improvements with users, and integrate changes from users (e.g. better airport layouts). Using OpenStreetMap raises the stakes: anyone can improve raw vector data using OSM at any point. How long do we wait to ship the improvements to everyone?
So I think it’s time to start recutting tiles and shipping them in updates.
Now to be blunt: I have no idea how we are going to go about doing this. So far recut tiles come down in free updates to users who have them installed, but this is just a beginning; we don’t have scalability problems yet because we have recut only 5 tiles.
Airport Anomolies
In the long term I don’t know how many tiles we will recut, when we will recut them, or what percent of the Earth we might recut in a given version run. We are not promising to recut any particular area or set of tiles. Please read that sentence twice. Don’t come back to this post and say “but you promised me free global scenery.” I don’t know how much recutting we can do or what the terms will be. I just know that it is the direction we need to investigate and move in.
With that disclaimer in mind, I do think we will be able to recut tiles that have airport anomalies. For example, I have two bug reports on class B airports. KSFO has an incorrect coastline, and KORD has a collision between autogen and runways. In both cases, I don’t know what went wrong and will need to investigate. And in both cases, pushing the fixed tile in an update seems like a reasonable solution.
* As far as I know, no commercial solution would give us three operating systems, deltas from any past version, while making it quick to cut a patch. Since we use the installer for every beta, the initial development time was worth it to make patching quick for users and for us.
My preferred way to fix X-Plane problems is to fix the problem first, then post second. That way there is no question that what we ship is what we announce.
But there’s a bunch of issues floating around with X-Plane 10, some of which will either take a while to fully fix, or which will be fixed in steps, with some steps happening now and some happening over a much longer time frame as the sim evolves. So I’m going to write some of them up now and get the information out there. A lot of users have taken the time to send in good bug reports, so it’s not fair to then sit on the plan.
A lot of these plans are just that: plans. Plans change. I believe that one of LR’s strengths is that we can change the plan quickly – if we come up with a plan and it turns out to be dumb we don’t have to just go through with it, we can come up with something better.
With that in mind, I had the following conversation with Austin yesterday – over a rather poor cell phone connection:
Me: Heya! Do you want to talk about BAD ALEX?*
Austin: Wait, what? What did Alex do???
Me: Oh…no no. Bad ALLOCs! A-L-L-O-C-S. Running out of memory…
A number of you have seen this error. When X-Plane runs out of memory one of three things usually happens:
- Some low level part of the sim seg faults because the request for memory failed and wasn’t properly detected.
- The OpenGL driver blows up because it can’t function without memory.
- The sim tries to allocate memory and throws an “uncaught exception: std::bad_alloc” error.
So first, let’s make one thing clear: we are running out of virtual address space, not physical RAM or VRAM. X-Plane is a 32-bit process, and thus it can only access 2-4 GB of virtual memory (address space) regardless of what is in your computer. The specific limits:
- 32-bit Windows: 2 or 3 GB, depending on OS settings.
- 64-bit windows: 4 GB
- OS X: 3.5 GB
- Linux: 3 GB – I think.
This address space has to contain a few big things:
- A copy of every texture X-Plane is using. (Most OpenGL drivers will “back up” textures in virtual memory at least some of the time if not all of the time.)
- Every mesh that will be drawn for all scenery, planes, etc.
- The weather system (physical and drawn).
- The physical mesh that is collision checked.
- The sim itself.
- etc.
So if you increase the combination of screen size, texture res, turn on HDR (which allocates a bunch of textures to render to), crank up the autogen, the sum can exceed X-Plane’s virtual address space limit.
The Short Term: Surviving With 3 GB
In the short term there are a few things that you can do and a few things that we can do. If you are seeing crashes or bad_alloc errors:
- Turn down rendering settings. The major ones are: airport detail (set to default), forests (set to something moderate if you are using autogen too), and texture res (first run with compressed textures). Don’t use 4x SSAA when in HDR mode – use FXAA instead.
- If you are on 32-bit Windows, consider moving to 64-bit Windows, at least in the long term.
- If you are on 32-bit Windows with 2 GB per process, increase that limit to 3 GB as shown here.
Note that buying more RAM will not help! We are out of virtual address space, not physical RAM chips!!
In the short term we can:
- Improve the error reporting to make it more obvious what has happened.
- Attempt to detect a lack of memory earlier and give warnings.
- Tighten our memory belts – I need to go on another memory hunt. Unfortunately we went on a pretty serious one before we shipped so there may not be any quick wins.
- Detect 32-bit Windows that are running without the 3 GB warning and flag this for users clearly with help instructions. If you’re running with 2 GB on 32-bit Windows it’s hard to see this in the OS itself, but getting that extra GB makes a big difference!
The Long Term: 64 Bits
The long term solution is clear – we need to migrate X-Plane to 64 bits. This is not going to be particularly easy or fun.
- On Mac, we have to port all of our platform specific Window/UI setup code from Carbon/C++ to ObjectiveC/Cocoa because Apple doesn’t provide our APIs in a 64-bit variant. Thanks Steve.
- On Windows we have to change compilers, as the one we use now is old and doesn’t build x64 apps.
- Sandy and I will have to make a 64-bit variant of plugins.
- 32-bit plugins won’t run in a 64-bit app. As far as I know none of the three operating systems provides a way to bridge DLLs like this, so plugin authors will need to create 64-bit compiled versions of their plugins.
It’s not a trivial amount of work. But it is what we need to do. It’s crazy to have a video card with 3 GB of VRAM and an app with only 3 GB of address space – in that situation by definition an app could only fill VRAM with textures if it had no code (let alone data). For years the cards, CPUs, buses, everything has been getting faster, bigger, more, except for virtual address space limit, which we have finally smashed into face first.
There have been a bunch of posts in which I have said “we know we need to do 64 bit” but now we’re saying “it really needs to be on the next train that leaves the station.” We will probably start the porting work once we get the 10.0.x series of patches stabilized.
X-Plane 10.03 beta 4 is out – just a few unrelated notes:
- Legacy scenery packs should work – I’ll write that up in detail in another blog post.
- If you have Paris or Denver installed, you need to update using the newest updater (version 3.02). If you update from the About Box, you get this version automatically. But if you have a version of the updater already on your hard drive, get a new one here.
- If your third party add-on worked in v9 and is still not in working in v10, please file a bug if you have not done so already. If you did file a bug, please bear with us – we’re killing off compatibility bugs with each patch, but there are still some major ones out there. (For example, I have on my plate to fix some bugs with OBJ materials that affect a lot of airplanes.)
And I meant to link to this: everything you ever wanted to know about global scenery but were afraid to ask.
I have a number of technical issues to cover relating to v10 scenery, so I’ll try to increase the blog post frequency to get through it all over the next week or two.
The short answer is: I think it will be fixed for everyone in 24 hours, but less if you want to get it by hand. Here’s the whole story:
The Paris DSF rendered incorrectly when we cut the global scenery. We discovered this after we cut the global scenery DVDs, but before they shipped out to users. I found the bug in the DSF generator (it was an error in airport processing) and fixed Paris and 5 other tiles. This was a top priority fix – it’s been fixed for probably two weeks now.
The Paris DSF is included in the X-Plane 10.02 beta series – that is, it has been available for over a week!
But here’s where things go sideways: since we’ve never updated global scenery before, you need a new updater to actually get the file. And what I am just realizing now is: while you need the X-Plane 3.02 updater to get the file, everyone is using the 3.01 updater, which doesn’t know to grab the Paris fix if you have Paris installed from DVD.
Hang on one second while I bash my head on my desk.
Okay. So there are two ways you can get your Paris fixed.
The Fast Way
If you want Paris fixed now, do this:
- Get the X-Plane Updater from here.
- Run the updater on your copy of X-Plane.
Paris should be fixed, at least I think.
The Easy Way
If you have already installed global secnery for Paris and you do nothing now, but get beta 4 when it comes out, X-Plane will use the latest updater to get beta 4 and you’ll get Paris anyway. I expect beta 4 tomorrow…maybe Monday at the latest.
If your joystick throttle axis won’t move the throttle (but will move in the axis tab) it could be that the autothrottle is on – autothrottle state appears to be saved across sim runs and airplanes in X-Plane 10. I am investigating this and we should have a fix soon, but in the meantime if you’re stuck, you may have to open a plane with an autothrottle on the panel (or use a key command) to turn it off.
Posted in News
by
Ben Supnik |
A number of users have reported “ghosting” with NVidia Windows hardware and X-Plane 10. The artifact typically looks like this:
What you’re seeing there is the scene from last frame being left around where the sky was supposed to be drawn, but was not. As the camera moves, we get a trail of artifacts.
For a few days I couldn’t see this bug on my own system, and this afternoon I tried to reproduce it based a report from a user with the same hardware as my development machine. So after a bunch of failed tries and scratching my head at the German version of the NVidia control panel, I was overjoyed to see this:
I mean, how cool is that! That could be our new startup screen! It’s like a giant 737 is going to pop up out of the screen and eat us all. (Hint: if you are in the pit of a 747 and an airplane appears over the horizon that looks bigger than you from 20 miles away: run!)
It appears that this artifact is caused by turning on full screen anti-aliasing in the Nvidia control panel (with “override application settings”) but not in X-Plane. My work-around: use “application controls” for the control panel and set FSAA in X-Plane itself.
Here’s another fun one:
This shows up with moderate global shadowing. This shows up on the 285.62 NVidia drivers; the 280.62 and (for the very brave) 290.36 drivers don’t have this problem.
I don’t think there’s a moral of the story here; we’re still working through bugs, but I did find the bottom of my in-box, which I hope is an indication that the patches are helping at least some users. There are a lot of different card/driver/OS combos, so working through all the combinations (as Windows X1000-users are finding) will take some time.
A new beta is out – 10.03 beta 1 – release notes here.
I guess people don’t really have .plan files anymore, but here’s what would be on my short list if I had one, now that 10.03 beta 1 is out:
- Crash bugs and artifacts. We’re still seeing some of these, particularly on old hardware; I am still working my way through these.
- Third party compatibility. 10.03 beta 1 starts to fix some problems with older planes, but it’ll take a few more betas to work through these – I still have a long list! Thanks to the aircraft authors that have sent bugs in.
- Performance. I haven’t had a chance to dig in hard on this yet, but I have been logging bugs with some of the complaints that have come in. I hope to be on performance in a big way in the next week.
