Cameron

Your OS text scaling options are certainly set too high if you are having input boxes drop off screen.

You must have HDR enabled in your rendering settings for that type of lighting to work. Please verify you do.

From your log: D:\X-Plane 11/X-Plane 11/Aircraft/X-Aviation/Cessna 172SP G5/plugins/G5/win_x64/G5.xpl : Error Code = 126 : The specified module could not be found. https://support.torquesim.com/hc/en-us/articles/360057635513-Steps-to-resolve-plugins-not-loading-Error-Code-126-

X-Plane 12 will likely have a way for authors work through this. For X-Plane 11, this will always be a thing.

This is not even close to an error. We'll just leave it at that.

There was an error in the initial update installer. You'll need to re-download.

Hello All, This will serve as a formal forum announcement that we have released the version 1.5.2 update for the CL650. All customers who have purchased the CL650 up till now have been sent an e-mail by X-Aviation with complete instructions on how to obtain your update. We have made this a very simple process! For those that purchase the CL650 from today forward, your purchased download will already be updated to version 1.5.2 for you. What if I didn't get the update e-mail? If you did not receive your update e-mail don't fret! X-Aviation has updated our system to allow all customers to update with ease, regardless of whether you received an e-mail for the update! Here's what to do: 1. Login to your X-Aviation account here: https://www.x-aviation.com/catalog/account_history.php  2. Find your original Challenger 650 download and re-download the file. It will download as the latest version! The following is a list of additions/fixes included: What's New / Changed: New Features: 2690: Add a clickspot for inspecting wing surfaces during preflight 2708: Add support for xPilot’s SELCAL datarefs 2716: Implement FANS CPDLC support 2732: Implemented DEP CLX, OCEAN CLX and ATS LOG datalink subsystems Enhancements: 2691: Redesigned the overnight icing accumulation algorithm to use real METAR data 2688: Add support for detecting POSCON client for disabling realistic altimetry feature 2698: Implement workaround for FMod sound bug when loading the airplane with sound muted 2699: Implement dataref interface for libfail to allow 3rd party software to trigger our failures 2320: User request for dataref to indicate when in “walking mode” Bugfixes: 2683: ABEAM REF distance and time isn't working correctly 2687: V-bar FD vertical deflection & rotation stacking should be reversed so the V-bar rotates around the nose indicator 2692: Reduce landing and taxi light brightness to be a bit closer to reality 2648: KEUG I16R with EUG transition is handled incorrectly for the subsequent leg intercept off the procedure turn 2409: Shrink or hide manipulators for engine fire push buttons so they can’t be clicked by mistake 2685: Manual ENG BLEED setting isn't being cross-talked between FMCs 2693: afm_mgr has a potential deadlock due to locking inversion if a state load coincides with a state save 2694: THRUST LIMIT page 2/2 shouldn't be selectable in the air 2695: Smooth FPLN leg joins should anticipate turn radius changes due to climbs 2697: CPC PID derivative rate was still causing oscillations when reloading a climb state at higher ISA around mid-20 thousands 2487: CTD - CL650[chart_prov_navigraph.c:1086]: assertion "chartdb_add_chart(arpt, chart)" failed 2721: Receiving a ATIS datalink message should show green DATALINK advisory CAS 2730: Reduce initial engine parameter variance a bit to help avoid unusually high ITT deviations 2775: Fix radial are off by a few degrees 2776: ATS posts an FMC ERR when FMS3 is selected as active on the left side 2779: Descent altitude constraints can stick past the waypoint where they are applicable 2780: Compressor stalls should stop when the engine is shut down 2773: PFD SVS rendering distance too short 2768: Changing NAV SRC while OEI causes CTD 2784: Small amount of aileron trim causes persistent monitored AP disconnects due to servo misalignment alarm firing 2769: DCT fix in FMS followed by pressing NAV causes CTD 2767: CTD when attempting to use invalid AFCS data 2749: Hold exit followed by FPL disco. clear = CTD 2785: Newly created airframe has right hand side cabin window blinds closed 2786: Engine hydraulic SOVs were being ignored when determining engine-driven pump operation 2787: Manual date setting on STATUS page results in setting incorrect year 2789: Make tail refuel pump fatter by 1mm to avoid spurious AUX TANK HEAVY CAS messages 2791: PBPB waypoint entry when first WPT SEL has 1 option and second WPT SEL has more than 1, empty WPT SEL shows instead 2792: PBPB waypoint checker should be using the passed selection lookup type, instead of defaulting to database-only 2793: WPT SEL screen should return to the caller's subpage 2777: Fix page missing Lat/Lon Cross small text 2795: FLT LOG fuel used needs to allow entering DELETE to reset the value 2796: TERM WX should allow for non-ICAO station IDs 2794: Add a checklist menu item to manually stop the FO's go-around flow 2797: is_valid_icao_code should allow for numbers in IDs 2798: Invalid ICAO code in FPLN RECALL page isn't generating an INVALID ENTRY error Enjoy these latest updates, and stay tuned to the forum as we continually announce the latest happenings.

You could run the GPU to use the aircraft on external power.

In today's progress report, we discuss the flight simulation experience from the perspective of the cockpit and how we approach trying to maximize immersion in our MU2 simulation. While undoubtedly one of the more enjoyable aspects of using a desktop flight simulator is having the ability to do things you cannot do in the real world, like get out of your plane and look at it from cool angles like you are a drone, or do a camera flyby at 5000 feet... it is the simulation of our experiences from the perspective of the cockpit that takes the highest priority for us. I think it fair to say that the goal of desktop flight simulation is to simulate reality, but those 4 syllables belie the complexity of just what constitutes reality. Remember the "...as real as it gets..." marketing slogan? Well if that was as real as it gets, why is flight simulation continuing to evolve and improve? Obviously it wasn't as real as it gets! So what was missing? The answer lies in noting that the perception of reality is comprised of many co-existing categories of fidelities with respect to how we sense the world. Some examples are: Geometric fidelity - how accurate is the 3D model Color fidelity - how accurate are the colors of the 3D Lighting fidelity - how accurate is the lighting model Aural fidelity - how accurate are sound dynamics Resolution fidelity - what is the depicted resolution compared to our eyes' abilities Dynamic fidelity - how accurate are dynamic events, movements, timings Tactile fidelity - how accurate is your physical interaction with the sim Cognitive fidelity - how close does your brain perceive the sim interaction as being realistic? With so many areas of fidelity for a developer to address, it is inevitable that some areas are addressed moreso than others, and in differing orders or priority. This is why one flight sim user (user A) might think a product is spectacular, while another (user B thinks that it is not. It is simply that user A and user B each have differing areas of fidelity that resonate with them as being important to their simulation experience. For many folks, a deficiency in one area, especially one that resonates with them as important, can ruin the whole experience for them. As to why user A/B have differing areas or interpretations that resonate with them as being important to simulation, who can say. Lets be thankful we're not all clones! It is also why constant improvements are available to be pursued and indeed should be. The first and foremost area to address by every developer is "what you see", that is the geometric and color fidelity...and X-Plane provides the lighting fidelity. This means, thanks to the powerful video cards we have today, that we can model more 3D detail into the geometry, rather than trying to fake it with textures. This is especially important for VR users and in conjunction with PBR rendering methods, results is more accurate lighting and depth, further contributing to the immersion. The screenshots below shows some implementations of the geometric and color fidelity in the MU2 cockpit. Knobs have raised ridges, edges are softened with bevels and roundovers, fasteners have recesses, etc. Such geometric detail is expected nowadays and the end result is a much more immersive experience in sim and in VR. Remaining with the "what you see" fidelity concept. The next area of focus is the dynamic behavior of cockpit elements, which is to say the animations. This area really resonates as important to me. If something looks realistic statically, but doesn't move realistic, then immersion can be lost significantly, but there are caveats in some cases. For example, X-Plane represents many things as "binary state", i.e. a switch position is represented by either a 0 or 1. When developers animate switches using such values, then the switch will just "snap" from one position to the other instantly, which isn't physically realistic. Conversely, if animated fully, then the switch animations can also be overly deliberate and slow looking, which can also seem unrealistic. If we look at an example of a simple 2-position toggle switch, you move the switch about half-way and then it snaps to its opposite position seemingly instantly. To our brains, the act of flipping a 2-position switch is almost autonomic and so to this day, there are many 2-position switch animations in aircraft that just snap between positions and we really don't give it a 2nd thought or view it as detrimental to our immersion in the simulation. This gives rise to the idea of "cognitive fidelity", in other words, what do most minds perceive as realistic behaviors? This is very subjective and as it turns out, we give this a fair amount of consideration in our animations and interactions in the MU2 cockpit. The fact is that our eyes and brains can perceive things quite a bit faster than 60 fps for some phenomenon, and less so for others. Space/time as it were. We pick up movement in our peripheral vision that we don't conciously think about, yet are alerted to if they are not quite 'normal' as our experience tells us they should be. Some things move quick enough that we don't pick up on the physical space they move through to get there, only the results (the 2-position switch). So how do we approach this and what does it all that mean for the MU2 cockpit experience? For animations, it most cases, it means we utilize a lot of physically based animation code to animate things they way they behave in reality. We don't use default X-Plane datarefs for anything when it comes to animations. The animation below shows what happens when powering the DC busses (inverter switch on too). Each instrument has some power on behavior, whether a self-test, or poweroff/poweron position. Some things move mechanically, others magnetically and each with their own unique behavior governed by their physical design. For example, the HSI and RMI compass cards are magnetically aligned/synchronized with a 'comparator synchro' behind it. When powered on, if the compass card isn't aligned with the comparator synchro, the card will very quickly "align magnetically" when energized, resulting in overshoot of the compass card, and some decaying vibrations before settling into stable alignment. Further, notice the comparator synchro is itself synchronizing with the magnetic heading from the flux compass, which happens at a fixed "synchronizing rate". On power on, this results in two dynamic behaviors in reality. 1) The compass card aligns with the comparator synchro magnetic field and 2) The comparator moves to align with the magnetic heading. While it is perfectly feasible to simulate a flight in the MU2 without all this animation behavior, doing so takes away from the immersion and that is the one thing we don't want. For those curious...the RMI / HSI cards can get misaligned whenever the plane is moved-around / rotated with power off. animations_1_opt.mp4 You may note previously I said we animate things physically correct in "most" cases. Why not all? Have you ever tried to flip a switch in X-Plane and you just couldn't grab the manipulator? or maybe you try to open some access panel and you can't drag in the correct direction and the panel won't open? Before long you realize you've taken 10 seconds to do something that in reality would have taken 1? This is an example of physical accuracy undermining cognitive fidelity in the simulation. In your mind, the action should be autonomic, in X-Plane it becomes a comedy show. I won't be too hard on X-Plane or developers here, because the mathematics of moving things "into and out of the plane of the screen" is ripe with challenges and difficulties. In select cases, we draw the line and depart from physical accuracy for the sake of cognitive fidelity. When I first developed the MU2 around 2006, I was getting perhaps 5 hours a week in the real thing for the better part of a year. When operating that aircraft, especially preflight, you're mind can get "in a zone" and things flow at a certain speed. I was finding that in X-Plane, this smooth flow of mental operation was impeded by the nuances of working with X-Plane's manipulators and camera view control in many cases and just did not capture the feel of operating the MU2 with the mental fluidity07 I felt in the real thing. I personally found that aligning certain interactions with the sim to 'cognitive fidelities' rather than 'dynamic fidelity' resulted in a more natural experience to me. In other words, the time it took to "effect something" was more important than simulating the physical movement to do something given the limitation of X-Plane "screen space". Without exception, our first efforts are to align the two paradigms and if we cannot get them to sync up, then we look at alternatives. We cannot escape the fact that we are trying to recreate a very 3D experience in quite a confining way and some departures from reality are acceptable. The good news is that most things are operated in both physically and cognitively natural ways with only minor departures. One practical example is that you cannot move the sun-visors all over the place. I'm not here to show off some XY manipulator wizardry. The real MU2 sunvisor is a ball/socket joint with quite an impressive range of motion that is limited by the limits of the cockpit. We don't do 'collision detection' of our sunvisors with the overhead...sorry! You click spot 1, it moves down, you click spot 2, it moves to the side window and vice-versa. I didn't think about, nor fight with it in the real thing and do not want to do so in the sim either! Again, the overriding goal is immersion and 95% of the time, pursuit of real, physical fidelities results in natural cognitive fidelity, but in cases where one interferes with the other, we depart from the real to cater to the cognitive, which to the philosophers out there, is the only one that matters. Enough with theory of game interactions. A quick word to wrap up on the cockpit variants all that gibberish above has been applied to. There are probably few, if any, MU2 Marquise's out there with original panels; however, it would be a slight injustice not to provide that variant...or to be completely honest, a variant of that variant. We may have mixed early and later model long-body features to better align with the practicalities and limitations of X-plane. So the old-school radio fans have their version. Next up is the GNS 430/530 GPS version. This simulates the most common upgrade to MU2s, and that is the addition of the 430/530 GPS units. A word of warning, upgraded GPS doesn't mean an upgraded autopilot! It is easy to forget that autopilots and that "magenta line" are not the same person. There is a bit of finagling to make things work, exactly as in the real thing. Its not unheard of for pilots to use the GPS to plan their flights and then simply adjust the HDG bug manually to keep the MU2 'around' the magenta line. Finally, for those glass junkies who purchase(d) the G500/600 product by RealSimGear, you get the GLASS version available to you for ultimate situational awareness and the gee-whiz, Captain-Kirk, lightshow. Next report, we'll talk a bit about the systems and engine simulation.

Do you have terrain flattening enabled in X-Plane for runways?

We have not yet finalized the discount or pricing structure. Typically, at least at X-Aviation, we wait until a product is ready for market before assessing a final cost. For now the focus is more about getting the product to that stage.

Copy the scripts folder from Aircraft/X-Aviation/Saab 340A/ and paste it into the AEW version.

Hi Keith, You have the 737 installed here for some reason: Aircraft/Extra Aircraft/X-Aviation It must be in Aircraft/X-Aviation, not 'Extra Aircraft'.