X-Plane 12.06 beta 1 is here! And it contains a lot of changes. Here’s a few of the bigger things we changed, and a few notes about the beta process.
Clouds and Weather
Since X-Plane 12.0 shipped, we’ve been working on the clouds and the weather system to improve performance, accuracy and quality. 12.06 ships the first two steps in this multi-step process:
- The cloud shaders are now faster and have fewer artifacts. Daniel rewrote the way clouds are marched, fixing zebra stripes and generally making things less pixelated and ugly.
- The cloud shaders also contain a dedicated path for cirrus clouds that should look better than what we had in 12.0 (“really thin stratus clouds up high”).
- Alex and I rebuilt the noise functions that build each weather type to get better looking clouds of all types.
While there are a few real weather fixes included, we have not tried to comprehensively update real weather; my thinking was that without proper rendering, it would be impossible to tell if real weather was actually getting better.
Coming soon: “Minecraft clouds” (e.g. square cubic clouds, especially with real weather) should be fixed in beta 2, so enjoy them while they last. Thick prism-shaped cirrus clouds should also be fixed, and we’ll be tuning up the presets and METAR parsing.
The future: we are looking at putting a 2-d “cloud shell” behind the 3-d clouds to handle orbital view and make the planet look less silly, and we’ll be going over real weather with a fine tooth comb.
Lighting
X-Plane 12.06 fixes some constants for sky colors but is not a lighting update. We have a bunch of lighting fixes internally, but the plan is to measure twice and cut once, e.g. make one patch to update lighting once we have all of the changes.
Improving dark cockpits is high on our todo list, but we also don’t want to tweak the light levels in the cockpit over and over and over, thrashing third party developers each time we do it.
My expectation is that when we recalibrate cockpit lighting, minor aircraft updates will be needed, but third parties who have chosen to “fix” cockpit brightness themselves (by adding extra light or hacking materials) may have to undo their hacks. I’ll try to provide clear guidance and early builds when we get to this point, but lighting is still “in development”.
Rendering and VRAM
The biggest change to X-Plane 12.06 is not one you can see: we’ve converted the main rendering pipeline from 12.0 (which was hand coded) into a rendering node graph.
Rendering graphs are all the rage today; if you’re curious about this you can look at something like AMD’s Render Pipeline Shaders. But here’s the why behind this change:
The render graph allows us to double-book VRAM used to render the main frame. X-Plane 12 has a lot more stages and processing in its pipeline than X-Plane 11, and that was consuming VRAM.
In 12.06 we treat VRAM more like an AirBnB and less like a second home – at different times in the frame different parts of the pipeline are using the same chunk of VRAM, which means we need less VRAM in total for effects. This change wasn’t possible in X-Plane 11 – you can’t double-book VRAM with OpenGL.
But it also would have been too tedious to hand code aliasing – the rendering node graph automates most of this and prevents bugs.
Coming soon: we have a performance optimization for beta 2 that should help CPU-limited users.
The future: in the future the rendering node graph will also let us render different parts of the frame using different CPU cores, for better CPU utilization and higher FPS for CPU-bound users. We still have a lot of work to do on this front, but once again the rendering node graph makes it possible.
ATC and AI Aircraft
12.06 has a lot of ATC improvements – months of Jim’s work went out in beta 1. I’ll try to get Jim to write up a detailed blog post on the details.
One big improvement to ATC: Austin fixed a lot of problems with the AI pilot. This affects ATC because the AI aircraft fly more reliably and are less likely to crash and bring airport operations to a halt. We’re expecting stability improvements because numeric instability from AI aircraft crashing into mountains would sometimes crash the entire simulator.
The future: Jim has more ATC fixes coming and is working on SID/STAR support.
What Comes Next In the Development Pipeline
X-Plane development works as a pipeline: as I type this…
- 12.05 is shipping
- 12.06b1 is in public beta
- 12.06b2 is being internally tested before going public
- 12.06b3 is in development – about half of the beta 3 bugs are fixed and we’re working on the rest.
- 12.07 development is almost finished – a mix of development and testing are going on right now.
- We’re working on features for 12.08 and beyond.
Third parties: I believe all of the known third party compatibility bugs are scheduled to be fixed in beta 3, and most of them are fixed already. But these fixes missed the cutoff to get into beta 2, which was a few days ago. We’re hoping to get beta 3 out early next week.
We try to not hold up a beta for fixes that are almost ready – if we did the betas would never ship because there’s always one more fix that’s almost ready.
The future: Pawel’s been working quite a bit on the networking stack, and his first changes will ship in 12.07, primarily targeting pro-level customers. We also have more graphics changes coming, and some of Austin’s flight model improvement are in test right now.
I’m sure the FB post mentioned OpenXR too…?
OpenXR is available in 12.06 via a command line flag; you’re welcome to try it via –open_xr. Right now we’re just gathering early feedback – once we have some testing under our belts in a future patch we’ll make a UI option for it.
WOW..thats a surprise to hear.. however it doesnt seem to work Ben
using that command line
“E:\X-Plane 12\X-Plane.exe” –open_xr
It launches into Steam VR ….
also tried –open_xr still launches to SteamVR…any ideas why its not working?
Probably a typo in the command line option. It should be two single dashes and then open underscore xr. MY guess is WordPress made a single wide dash cuz English.
I think iOS and maybe even macOS both automatically convert two dashes to that stupid long dash in some text fields. It annoys me to no end when I’m on Slack in bed on my phone and it decides it knows CLI options better than me.
Ignore that last comment…it didnt work for me with Varjo Aero in 12.06b1 (it actually CTD rather than launching steam VR ( I had made a typo in the command line) ) but 12.06b2 seems to be working beautifully GREAT stuff
Not working for me right now because there’s no mouse onscreen in the game when I run it with open xr. Bummer! Otherwise, it looked real damn good!
That’ll be fixed in beta 3.
Im sure you guys have seen by now, but there is a major bug with the new OpenXR flag …the mouse disappears in VR , and apparently controllers are also gone (I dont use those)
would be great if you could look into this as the NewOpenXR is GREAT apart from the fact there is no mouse (which is a bit of a showstopper ! )
Its been logged already
XPD-14269 — No VR mouse with OpenXR, any headset.
XPD-14255 — No controllers with OpenXR, only for the Vive Index
Yeah, we already know about those – you can tell because they have XPDs. 🙂
I have built a hardware cockpit of the default Beech 58.
Flying is only in VR, wich, depending on steamvr, was somewhat cumbersome.
12.06 b2 solved all that for me.
“X-Plane 12\X-Plane.exe” –open_xr switched off all my problems.
Stuttering is gone, blacking out, when moving head rapidly is gone, fps are up by around 10 fps, visuals look more crisp.
All that with higher graphic settings than i had before.
I am very happy and want to say thank you for the exceptional work you do and also for the open communication about the state of development. Keep up the good work!
Those are GREAT news!!
The moon illuminating the clouds at night was a great addition, in my opinion. Will we also have the city lights illuminate the clouds?
City lights: not any time soon – in their current representation they don’t cast enough light to do that. We do have that on our long term road map but it requires computing a generalized area-wide “light pollution” map, which we want to do anyway to make urban light levels more realistic.
On the shorter list is getting landing lights and lightning to light up clouds.
On the shorter list is getting landing lights and lightning to light up clouds.
This would be WONDERFUL!
Hi Ben,
Are you planning to redo the lightning effects in general? They are very old now and “clash” more and more with the ongoing graphics improvements… And is volumetric lighting also coming with the volumetric fog and precipitations that were mentioned at FSExpo?
Thks for your time!
We do plan to upgrade lightning, yes. Volumetric rain obscurance is being worked on intenrally.
Moon seems to cast light on clouds, but not on the ground scenery. Is that correct?
Probably yes? I have a branch that casts moon light internally but it doesn’t work well because the real life moon light is not strong enough to be seen at X-plane’s current minimum low light exposure (an EV100 value of 5). IRL your eyes can make several stops of adjustment just by looking around, so you can see moonlight on the ground in unlit areas even with artificial light interference. We’re debating what to do about all of this internally.
Maybe exposure fusion / local tone mapping could solve both the moonlight and dark cockpits issues?
Is there a plan for the clouds during sunset/sunrise, or night? I meant because these become black during this time and in real life clouds don’t become totally dark, they keep their white color as much as possible, even very few.
This issue is tied to the overall ambient level of clouds e.g. when they are in shadow too – there’s internal work being done on this.
So for any engine then, the primary benefit to rendergraph is VRAM usage? Is it otherwise performance neutral? Seems like more of a GPU benefit than CPU side, other than opening the potential for more generous threading. Mostly a huge shader rewrite task?
Will VR get its own blog post? There’s lots of fuss about openXR that could use some clarification.
Render graphs have a bunch of other benefits, one of the really big ones besides making it easy to alias VRAM is to re-order the order in which the scene is encoded and making memory barriers static. It’s mostly a tool that makes internal work on the engine much easier because it’s no longer a huge list of hand coded dependencies and putting everything in just the right order.
There were actually 0 shader changes for the render graph, it only changes how the CPU encodes a frame. The AMD SDK which makes use of HLSL as their domain specific language is just an example of what exists, we don’t actually use it internally for our render graph.
Ha! I was way off. This whole time I thought you folks were switching up the shaders and pipelines. When I came to that conclusion a while ago, I was excited for Mesa’s GPL implementation, so that’s where my uninitiated brain was hanging out. But this isn’t a shader compile or pipeline ordering situation.
My pleb brain tried to pick through a themeister.net blog post on this but it was too ‘in the weeds’. Is it safe to say that the previous hand-crafted renderer was too unwieldy at this point in life, especially when considering the additional non-render compute tasks in the mix now (e.g. fft water)?
Seems that the rendergraph is essentially a resource tracking/sorting mechanism (buffers, fences/barriers, transfer/compute) that’s going to fill the commandbuffer with a much better optimized ‘execution dependency chain’ and do so without triggering thread races on the CPU side?
While I was reading, I wondered if this would also eliminate the beloved ‘swapchain acquire’ hang that sometimes likes to raise its hand in the microprofiler, but it looks like I can still trigger that one if I try to… Overall though, the sim does feel more smooth. Less hitching.
Very very nice update here.
“resource tracking sorting thing” is pretty spot on. The swap-chain acquire hang may not be fixable, because it’s not necessarily a bug.
You have two computers working in tandem – a CPU and a GPU. The CPU produces instructions and the GPU consumes them. It’s like a pair of masons – one is slathering mortar onto bricks handing the ‘buttered’ bricks to the other to place into a wall. Only three things can happen:
1. They go at EXACTLY the same speed like a well oiled machine – every time the stacker finishes, he reaches over and there’s the next buttered brick. Perfect!
2. It takes longer to slather the brick with mortar than to place it, and the guy stacking waits a little bit after each placement for the next brick to be ready.
3. It takes longer to stack the bricks than to slather mortar on them, and the guy buttering the bricks has to wait for the stacker to _take_ the first brick before he starts another – his hands are full and he has to wait for his hands to be emptied.
In this analogy, the slatherer is the CPU and the stacker is the GPU.
In case (2), this is a case where the CPU is slower than the GPU – you see this as “low GPU utilization” and if you could view the GPU timeline you’d see a big gap after the frame when there’s nothing to do.
In case (3), this is the case where the GPU is slow and the CPU _cannot_ produce more frame instructions because the GPU hasn’t finished what has been sent.
The way we experience this is: when we go to acquire the next swapchain image (the buffer that will be seen by you, the user) we find that we already have too many frames ‘in progress’ so we wait for the GPU to finish one before proceeding.
If the system is working, swap chain acquire waits are where the CPU waits for the GPU _on purpose_, so this isn’t necessarily a scheduling problem, it’s a load balancing problem. GPU perf optimization, lower res, or a bigger GPU all ‘fix’ thsi.
XR: probably not until it’s tested enough to be available with a UI option.
Nice to see blog posts resume – I’m spoiled by Slack, but it was clear that you guys have had and still have big plates on the desks in front of your and they’re all overflowing. I presume that the 747 freighter full of coffee probably helped… or was that Scotch? 😉
1) What is the status of the improved autogen announced/displayed in the Keynote? Unless I missed something we haven’t seen an update in 22 months.
2) The carrier has been receiving a lot of love and looks great. Are there any tweaks for the IFLOLS (optical landing system) coming in 12.06 or beyond? The usable distance of the IFLOLS falls well below the US Navy spec of 1.5nm in my testing.
If you haven’t, please file a bug re: IFLOLS – I’m a little surprised it’s unusable past 1.5nm unless you’re e.g. running at 720p; if the screen is small enough it’s hard to do anything.
Autogen is on hold while we solve more fundamental scenery problems – we have the assets but we’re trying to sort out airport flattening, water bodies being missing, bread and butter stuff, then we can re-visit and decide what we want to do.
Generally speaking: as OSM grows more data dense we’ve had more trouble getting OSM data into X-Plane. premek and I spent a lot of effort _dumbing down_ OSM data to fit into DSF, which sucks…everyone would rather have better scenery. So I am considering more radical approaches to the scenery system.
The second part about autogen and scenery really sounds great! 🙂
Thank you for the responses! There should be a bug report on the IFLOLS from Jan 2, 2023 from the same e-mail associated with this post. I have a 1080p monitor and tried testing with 30, 60, and 80 FOV.
//forums.x-plane.org/index.php?/forums/topic/280904-x-plane-12-carrier-iflols-optical-landing-system-visibility/#comment-2483263
I have a WIP scenery object of the Mk14 land based version of the IFLOLS using the default lights.
//forums.x-plane.org/index.php?/forums/topic/280463-wip-shore-based-improved-fresnel-lens-optical-landing-system-iflols/
Hello Ben! This is great news. But I would really like to see is a development of new uptodate assets. the old obj8 and png are from the 80´s, and are soon to be obsolete. So instead of fixing new “intepreters” for this old imagerysystems, isnt it better to start look for a new set of 3D-objects and more efficient imagery systems? Those used in mobilephone today are by our standards extremely efficient. Just a suggestion sir.
This is all excellent news, however I’m disappointed to not see any mention of night lighting improvements, especially extending the night lighting render distance so it doesn’t pop in in chunks while cruising.
Extending night autogen light improvements is not a short term fix because it’s a fundamental limitation of the scenery system, so we need to rearchitect a bunch of stuff. FWIW Austin is bugged by this popping too.
Could it be possible, for a future new scenery architecture, to put the lighting objects in their own scenery files so that they could be loaded separately? You could then load them very far ahead at high altitude or even from orbit…
Basically making the whole thing more granular/modular, to load what’s necessary depending on the situation. Using procedural generation for the terrain would be nice as well. I’d rather see that then pure ortho. Basically using ortho for an hypothetical procedural engine to output the final result.
Just thoughts, not a dev so those are maybe stupid ideas… :p
It is possible, yes.
I definitely love new graphics updates and can’t wait for more!
I’m aware it’s beta, still is it possible to have checkbox to disable blurr textures even when Vram isn’t enough? 12.06 helped my Asus Tuf 3050 laptop’s Vram but still requires me to use texture compressing tools for aircraft cabins and else stuffs so that I can keep my scenery look crisp.
“still is it possible to have checkbox to disable blurr textures even when Vram isn’t enough?”
No. Like, not because I think this is a bad idea but because it’s not technologically possible.
If you don’t have enough VRAM, _where would we put_ the sharp textures? You need one of smaller textures (blurry) fewer textures (less stuff) or more VRAM (bigger card).
Guys, love the lighting in 12.06b1 , looking forward to clouds looking awesome in real weather in 12.06b2 .. but one thing that irks me since even v11, is how the sun shines through the *back* of the cockpit and reflects off the displays (even when its overcast, not that it should do this in any circumstances) Like as if I am in a glass bubble rather than a B737 cockpit?! Hope that can be sorted as some point in the future.
I second this…..but awesome job on clouds and lighting in general! Xplane keeps growing more life like with every update. Thanks Laminar Team!
+1
Regarding lighting improvements, do you have some sort of sun blinding modeling in the plans? That is, huge loss of contrast when the sun is shining around the center of the screen.
That might have some significance in training scenarios as well (e.g. cockpit avionics becoming unreadable) and would allow simulated sunvisors/sunglasses to actually be useful.
I’m still seeing the wall cube type of cloud which is mentioned fixed in 12.06b2.
Please use developer -> dump weather state to log and file a bug with that log.txt.
Thanks very much for these insights, very helpful! The last betas 1/2 were already a big step forward. I have a specific question: is there a chance that you will give access to the full weather-API anytime soon? I am very much missing a 3D-weather-radar. Developers like Toliss plan to implement it but don’t have any full access now. Thanks 🙂
We’d like to, but we’re still working out things about the internals that have to be settled before we can.
That makes sense, thanks very much for your answer.
“The future: in the future the rendering node graph will also let us render different parts of the frame using different CPU cores, for better CPU utilization and higher FPS for CPU-bound users. We still have a lot of work to do on this front, but once again the rendering node graph makes it possible.”
I’m extreme Happy to see that, Best luck implementing.
I will add to this. AS A DREAM.
On “Local Master Machine” without any graphics, runs only physics engine (and plugins)
(plugins with auto transfer commands to/from “Local External Visuals” like changing switch position on displaying something. Changing ex switch position in “local external visuals” transferred to “local Master Machine”.)
Each Monitor (main too) / each Eye in VR, on separate “Local External Visuals” each on different cores. Option for each monitor render different graphics settings would be nice.
(and if be possible, to slice single display, to many “Local External Visuals” then Threadripper needed ;D for dream setup)
if Each Monitor will can run on different GPU that will be Lottery Win. (like I showed in my “Hack”)
3x new RTX3060ti have similar performance vs 1x RTX4090. But three 3060ti combined, cost ~75% of single 4090 (and you will not see melted connectors)
Each monitor on a different GPU is far down the line – besides everything else, we have to have an internal graphics system where resources are shared to all GPUs when needed (E.g. the livery of your aircraft), kept on a GPU when needed (e.g. the cloud history buffer _for that monitor) but shared _across GPUs_ when needed (E.g. the scattering lookup table … is it computed on both GPUs or sent from one to the other?). There’s a lot of moving parts.
Modern game use multiGPU solution in 2023/2024? That will be huge Marketing hit. Every tech YouTube channel will test that, I don’t believe LinusTechTips will not be interested. They tested/game on 16monitor display.
SLI/Crossfire is dead. MultiGPU ONLY on multimonitor setups.
Every gpu renders only own monitor (on “seperate instance” of Xplane).
“the scattering lookup table” will be computed 3x, once on each gpu, in size only for own/connected monitor (on “seperate instance” of Xplane).
sending data between GPU, eliminated as far ass possible.
In my “solution”(point of view) internal graphics system will must be copied entirely for each “Local External Visuals”
(like running another separate copy of Xplane and communicating “through network” {shared memory})
From my experience running 3x Xplane singlePC with 3x GPU, and forcing Windows to use different GPU for each instance of Xplane:
monitor must be connected to GPU on witch is each instance of Xplane running(rendering).
Displaying form one GPU to monitor connected to another GPU, kills frametime.
What I observed ex: CPUtime 100ms, GPUtime 100ms, frametime 120ms when monitor is connected to proper GPU.
but when rendering on one GPU and sending result to another GPU makes
CPUtime 100ms, GPUtime 100ms, frametime !220ms!.
When running only single copy of Xplane but dragging Garmin popout to monitor connected to another GPU, that also kills fps heavily.
If You (Laminar Research) runs under the hood Xplane many times (like 3x) at once. CPU cores/RAM will be 3x more used/”wasted” that is not a problem.
Communicate like today “Master Machine” and “External Visuals” through network (in reality shared memory).
but running 3x under the hood could mean loading data from disk to Ram 1x (not with my walkaround 3x) installing scenery/plugins 1x (not 3x) etc.
Now I learning programming and writing plugin to communicate between each instance of Xplane, through shared memory.
I achieve up today reading value of DataRef each loop and copy that value to shared memory. Inserting new value from shared memory to DataRef and to another instance of Xplane, is front of me (task for Sunday).
I want eliminate lag between “Master Machine” and “External Visuals” in network communication because I run 3 copies of xplane single PC.
(Network tab in settings shows ~35ms ping, but lag between main and side monitors is very noticeable).
List of all DataRefs send between “Master Machine” – “External Visuals” will be extremally helpful. For my plugin/s.
12.06b2 is a huge step forward in many ways.
Some questions:
1) you said that the new VRAM management will allow a fix for water covered by transparent pols appearing inset, is this going to be fixed?
2) FXAA is still working strange. It’s better than 12.05 in some ways, but there still are very strange things. For example, when there are mountains in the background, mountain tops during day time are perfectly antialiased, but at sunset/sunries they are not antialiased. Also, it is not working right on runways and ground lines when the camera view is not straight (a lot of jaggies and flickers).
Water will be addressed in a future patch, but not 12.06.
Hi Ben,
Whom do we have to bribe to get Julian some help to make a wide pass on the gateway scenery? Some areas seem to lagg while others aren’t. Plus I did run into a rather large bug on B1 and B2. HECA, has gone MIA. I”ve bug reported it. So many folks are doing quite good work on the gateway it would be nice to see that reflected in the sim.
While it’s great to see new clouds in 12.06 beta and certainly looks like a major step in the right direction, I’ve a few suggestions which I believe warrant your attention:
1) Humidity and temps on ground should create a light scattering effect below the clouds leading to haze and low visibility which is currently missing in the weather system. This phenomena makes it look as if the clouds are floating on an ocean of haze.
2) Rains should definitely create a low visibility effect which isn’t happening right now. It appears that low visibility is strictly METAR based currently whereas it’s much more common IRL, #1 being one of the prominent reasons
3) Many a times I see rain while cruising at high altitudes (above 25000 feet) with same magnitude and intensity as found near ground. This should be an extremely rare occurrence.
Item two is being worked on internally now.
Is there a way to get the (truly much improved) clouds crisp in VR?
It’s the same issue in msfs, i have no idea why the clouds in VR are blurry in most of the sims….
Fixing dark cockpits is the number 1 job as far as I’m concerned. If you can’t see to fly the plane, nothing else matters much! Thanks for all your efforts.
I must commend the team for this release; I was truly amazed by the remarkable improvements in cloud rendering and overall environmental lighting. The visuals were so stunning that I couldn’t believe it was X-Plane at first glance. Hats off to the developers! and i know this is just the beginning of new era.
Visually, I believe that starting with XPlane 12.06, the competition with MSFS is finally on an even playing field, providing a real match going forward, especially with the ongoing fine-tuning of the graphics.
i have subtle comments:
————————————-
* if you see: //youtu.be/BmuYCXAm69A?t=4628, notice the grass shows on ground as plane approaches, that is sure to save performance, In order to blend and conceal the grass rendering horizon line, I would like the further grass to be more translucent and fade linearly as the plane gets closer.
* i hope you implement mirrage effect, as an extension to the weather system: as you clearly know mirage is an optical illusion caused by the bending of light as it passes through layers of air with different temperatures. When the ground, such as a tarmac road, heats up significantly during hot weather, it can create a temperature gradient in the air just above its surface. This temperature gradient can cause light rays to bend and create the illusion of water or shimmering reflections on the road.
in the sim world, i have not seen anyone implementing this.
I’ll end here for the time being, knowing that there is still much on the to-do list for your creative energy.
Having CTD’s with 12.06b3 –open_xr happening at random places in the load process as indicated in log.txt, mostly nearing entry to VR.
Right now just one in 6 chance of getting to the cockpit.
I think it’s gonna be beta 5 for that fix, but we’ve seen it in the auto crash reporter.
I tried 12.06b2, b3 and now b4 with the graphics option Use Zink plugin bridge enabled. I fails with this error:
OpenXR Call failed, abortingC:\projects\oppenovr\DrvOpenXRDrvOpenXR.cpp 270 SetupSession Error code XR_ERROR_GRAPHICS_REQUIREMENTS_CALL_MISSING xrCreateSession(xr_instance, &sessioninfo, &xr_session_get()).
Whenever I disable Zink VR works as expected.
Please file a bug report and include this.
I am liking a lot what 12.06 is building up to, I had my first flights in XP12 finally where the clouds looked believable also from altitude. I am really enjoying the updates, and it is also good to read again more frequent updates here.
Two issues that I see which I have not seen covered anywhere lately:
1) Nearing sunset at altitude, above the clouds, sunlight stops shining on the plane at and under a given altitude (Solar above the horizon) even though the Sun is not obstructed by clouds. This is immersion breaking also in the cockpit where no more shadow can be seen.
2) Please please please either make the Moon smaller (at least to equal the Solar disk – without the bloom effect of the Sun), or make it user adjustable. It is a 3D object already, so it is really a question of adjusting that object’s size, and the light level does not even need to change, but every time the Moon is up, my immersion is destroyed. I am simming in 2D, but I hear that in VR it is even worse (since the large apparent diameter at realistic FOVs is even more striking). If the Moon was an openly accessible asset in XP I would do it myself, but this is clearly hardcoded somewhere internally (unfortunately).
I just did.
Dear All,
Very glad to read that ” Jim has more ATC fixes coming and is working on SID/STAR support”. Yes, my question is : why not SID/STAR and APPROACH PLATES in ATC clearance request options ? So if SID/STAR support is on the way would that also include ILS and GNSS approaches ?
May I also suggest you to pay attention to following “issues” :
– enroute ATC clearances are often unreadable (even with voice sound cursor to maximum).
– visual landing vectoring : most of time ATC send you away “in the middle of nowhere” except in the circuit for landing. Instead, when I ask AI to fly the (native) aircraft, the vectoring is perfectly performed….
Many thanks,
Best regards.
Armand
Can you touch on your plans for “Networking”?
I know this is a big subject but encompasses many things…
As a multi-pc mockpit builder, an copy of XP12 running on each doesn’t marry with exact clouds, ground vehicles, statics etc
Multi pc in order to drive 3 screens (or projectors).
If flying networked with a friend, not receiving the correct aircraft model etc