daemotron

I know it doesn't really impact functionality of the aircraft, but I just noticed v1.0.2 ignores entered decimals for the reserve fuel on the PERF INIT page (simply always puts a zero after the decimal point):

Don't know if it has been reported already, but the POS INIT page remains blank on FO side, where it perfectly works on the captain's side. This has been reproducible with all versions so far:

Hanging around at Molokai My FO hanging out of the window (enjoying the view) Check captain missing the flight This runway is short and bumpy! Very funny for approach practicing (I cheated, got there by the Let L-410 ) Just got off - that's something for low GW, flaps 15 and full TO thrust... Molokai showing its rough side Molokai hiding behind SkyMaxx Pro

Thanks, that was it. Back at ~60fps

Hi all, I'm encountering a very strange behaviour of X-Plane: It locks itself always to 30 FPS, no matter what rendering settings I apply. Also disabling all plugins does not have any impact. My computer spec: Intel Core i7-6700K (water cooled) 32 GB DDR4-RAM (4x Kingston DIMM 8 GB PC4-17000 Non-ECC) NVIDIA GeForce GTX Titan X I'm running Windows 10 (Pro, 64 bit) and X-Plane 10.45r2 at a resolution of 2560x1440 I also played around a bit with the NVIDIA driver; my settings for x-plane.exe are: Triple buffering: on Power Management Mode: prefer maximum performance Multi-Display: singe display performance Texture filtering - negative LOD bias: Clamp Threaded optimization: Off Vertical sync: Adaptive (half refresh rate) It's like somebody nailed the frame time to 0.033, no matter what I do - cf. screenshots where I applied heavy settings, but the framerate looks exactly the same with minimum rendering settings: Does anybody have an idea what could cause this? It's really annoying (30 FPS is still usable, but there's not much margin when clouds are being redrawn etc.) P. S. GPU temperature is not an issue, it stays below 70°C (I applied a little more agressive fan curve) ...

The CG is not given in the ground service pop up menu, but has to be set (default is 20% MAC). I think HerrSchwarz's question is more pointing at "what CG would be realsitic for a GW of X tons". To illustrate that, I have emptied the aircraft of all payload and fuel to demonstrate that the CG still points at 20% (unless you change it - cf attached screenshots). If I remember correctly, this was already discussed during development phase - there's a thread about load mgmt somewhere, concluding that IXEG will not take care of the load management, since this is normally not the pilot's job. Remains the (very valid) question what is a good value to set... The CG is not directly depending on the GW. When the aircraft is empty (no fuel, no PAX, no cargo) it does have a distinct EW and CG (which is individual per aircraft, not by type, so usually you get this information alongside with the aircraft from the manufacturer). Adding fuel normally changes this in a characteristic way (since fuel is normally always distributed the same way when fuelling - wing tanks first and balanced, then center tank). So fuelling to an amount of x kgs should always result in the same CG (as long as there's no other payload). As soon as you change the ZFW (i. e. add PAX or cargo), the story starts becoming interesting: normally the CG impact is calculated based on seat row population and assignment of cargo to the FWD and AFT cargo compartments. Since you don't have most of this information (neither the neutral CG, nor the fuelling impact nor the redistribution of PAX and cargo), you cannot calculate the correct CG (even if you have a load mgmt software for a 733 at hand), you can only set the CG to something convenient. Something resulting in a TO trim of between 2 and 5 (i. e. valid TO trim range) is technically ok - just keep in mind that the CG is travelling forwards during flight (fuel is being stored behind the CG), so if you already take off with a very low CG (e. g. 4%) you will have a very "heavy nose" on flare... The proposed standard value (20%) is well chosen by IXEG - althoug you will rarely have such a nicely balanced aircraft, this hits quite the middle of the allowed TO trim range.

@cmbaviator It's explained here: http://airlinerperformance.net/installation/

OK, I have invested some time in testing. From my side, I couldn't find a specific issue with SMP or RWC. Instead, I discovered that my GPU load went up to 100% when running X-Plane, entailing a rise in CPU temperature to up to 85°C (still within TDP limits with a max of 91°C, but mind, I have a new computer with a Skylake i7 CPU and a Titan X) - so of course I was wondering what's causing this. With a lot of monitoring data recording and a round dozen of CTDed flights, I finally found out that there seems to be an issue with ansiotropic filtering. Once I disable it, the GPU load stays within "normal" limits and the temperature remains below 80°C, even when using RWC with a coverage of ~10k sqkm. I don't know what exactly the problem is (on an older system with a GTX 780 Ti and five years old Xeon CPUs anisotropic filtering did work, so possibly it's either it's a problem specific to the GeForce 900 series or an issue with the current 364.72 driver version).

No, no overclocking, just working with default hardware configuration. The crash itself is a classical CTD (no specific message, just Windows telling the application doesn't work normally anymore). It did not happen with SMP 3.1 (without RWC); I will play a bit around to see if RWC is involved. Gesendet von meinem SM-G920F mit Tapatalk

Hmm, I'm also experiencing crashes after running X-Plane for ~30mins (every time, so not random). The last entry in the logfile always reads SkyMaxx Pro: Coordinate system changed; recreating weather. I'm using SMP with RWC and NOAA. To me this looks as if it always happened when METAR.rwx is rewritten (not MAXX_METAR.rwx - at least from looking at the time stamp of said file, but this could of course be a coincidence...) Btw. for me I can exclude a VRAM limit issue; I have a Titan X and X-Plane tells about using ~3GiB out of 12 available, so there should be more than enough margin...

Same here. The islands available as of today are simply stunning, and such a great project deserves recognition. Btw. I like the vivid colours, gives a feeling of a very much "alive" landscape!

Hi, seems there's a bug or something similar in the download section - whenever I try accessing one of the files listed (I mean not yet downloading, just going to the presentation page of the file), I receive this error message: I double- and triple-checked I was logged in (otherwise I wouldn't have been able writing this post...)

Nah, you can't steal the fuel truck - here you will need the key

Airports have security classifications. I'm not much aware of classifications in U.S., but around Europe, most public commercial airports do have a classification allowing to park your aircraft without Denver boots The only means for airports with lower classification I am aware of is putting seals on the doors, so the ground crew will be alerted of potential manipulation when entering the aircraft in the morning. Effectivity of this is however certainly disputable... there are other ways to manipulate an aircraft (anybody ever tried setting a marten loose in 90VU?)

Oh, good to know. I always thought the paint-stripe on the spinner was some PAPI equivalent for birds, so they can properly aim at the fan...

A DHC-6 300 Series (equipped with floats) crashed into Kalamalka Lake in the Canadian Rockies, 3NM southeast of Vernon (CYVK). The aircraft was operated under VFR. The crash happend during an attempted landing at CVW2. The aircraft was in correct water landing configuration (wheels retracted, flaps full). When touching the water, the sudden deceleration let the aircraft pitch nose-down, forcing the float tips to plunge. Subsequently, the aircraft overturned. While IAS was within the limits of a water landing, GS was not - apparently the pilot had forgotten to check the METAR and attempted to land with a tail wind component of approx. 25KN. Second accident: A DHC-6 300 Series (standard gear variant) crashed on a VFR flight from CYRV to CYKA, 9NM west of Revelstroke. After takeoff from CYRV RWY12, the pilot followed the Trans-Canada Highway towards Mt Griffin, climbing to and maintaining 4,500 ft. The weather at the time of the accident provided dense clouds between 6,000 and 11,000 ft, prohibiting proper VFR operation at or above minimums (8,100 ft for this area). 9NM down the highway, both engines failed. Being low AGL in a narrow valley, the aircraft collided with terrain before the pilot's attempt to restart the engines succeeded. FDR data analysis prove that the double engine failure was caused by the crew shutting down both fuel pumps. OK, quick version: I forgot sitting in a DHC-6 and not in a EMB-110 (where you actually shut down fuel boost pumps at cruise, but in the DHC-6 I accidentally caught the main fuel pumps switches). Plus I ignored minimus, doing a canyon ride to keep visual contact with the terrain. Both together = very bad idea...

You can copy the route in .fpl format from PFPX in the route editor window (lower left part). Just omit SID and STAR to get a generic route. But I agree it would be nicer if such a file could be exported directly, without resorting to a workaround.

Can anyone explain to me why there's such a negative attitude towards Airbus aircrafts? I don't speak of Jan who's A320 type-rated and knows what he's talking about, but I sense a lot of negative commentary coming from people who most probably never set a foot into an Airbus cockpit...

Hehe, no offense taken, don't worry Jan. Another captain I know once expressed it that way: the FMGC is actually doing a good job, but is terribly poor in letting the pilot know what's doing and why...

Ah, it's more than code behind that. It's the algorithms and their parametrization you want, since you'd have to transform it into a plugin anyway (i. e. recode in C++ or Lua against X-Plane's API). And as Jan stated in another post, this is the warp core, the holy grail of any aircraft developing company. Airframes can be replicated (anyone seen the Comac 919 ), engines are bought from 3rd party suppliers (RR, GE, PW, ...). I can't image we would give the FMGC algorithms and implementation away; not for any money. There are however cases where we grant (licensed, limited and NDA guarded) access to this knowlede (e. g. for full scale training sim manufacturers).

I think you can do something in between. Some things are common (e. g. LNAV related stuff), some share at least a common model that can be parametrized (e. g. available autopilot modes), and some are individual per aircraft, engine and installed equipment. Saying that, I'm fully conscious this would not be something simple to plan and implement. QPAC took many years of development (and is still not completed in terms of FMGC features), and adding a new model to be supported is not done by simply waving a magic wand. Nevertheless it supports A320, A321, A330-300, A380 and A350-900, despite the huge differences between the A320 family (first generation FBW, relatively simple FMGC) and the A350 (3rd generation FBW, new gen FMGC).

OK here's how it works (but bear in mind this is not officially supported, you're on your own here): Download and install xJoymap (for Windows users, you can use the pre-built Python interface installer; xJoymap is bundled with this one). You should now have a file named <x-plane 10 folder>/Resources/plugins/PythonScripts/xjoymap.ini Open it with a text editor and paste the configuration given by tomcat357 above at the end of this file (including the section name in square brackets): [Saab Condition Levers] axis=4 dataref=LES/saab/CL/manip_common(float) drl=0.90 drh=0.50 Of course you need to change the axis number to whatever your condition lever axis is (I changed the example to match for a TM Warthog throttle quadrant). Very important: This will make your assigned axis move both condition levers of the Saab in the range between Min and Max only. Below Min (e. g. for engine start procedure or cutoff), you will have to handle the levers by mouse. If you try to control also the range below Min, this will interfere with the engine startup logic and your engines won't start. Quite logical - I can't think of a case where you'd move both condition levers below Min together (except perhaps for engine shutdown).

The QPAC plugin is already living up to this concept - at least five commercial Airbus models are currently powered by this plugin. Btw. when talking about "FMS", one needs being conscious about the fact that something like a "universal FMS" can hardly be programmed: the FMS is not a stand-alone system; it's always coupled with other avionics components. You could do a base FMS for a certain family of aircrafts (e. g. Boeing classics, i. e. 733, 767, 757, 744) which use similar avionics concepts. So if you replace "universal FMS" (which could only be a least common denominator) by a QPAC-equivalent for Boeing classics, this actually could work.

Looks like a good one for the classic North Atlantic route - via Gander to Shannon. So bad weather practicing already included on the route home

I can't, they won't allow me landing a Boeing at my home airport