Graeme_77

I can’t say I’ve ever seen either issue, although I’ve heard of pitch issues with aircraft damage. I’m sure the developers will be along soon, but in the meantime can you post a screenshot of the PFD and MFD when you have the pitch up problem?

As you mentioned it’s worth checking both the payload and maintenance screens. If the flight control surfaces are damaged then you will have issues. Also, what was your indicated airspeed when you experienced the steep climb out of nowhere?

Ozz, the usual cause of a "snatch" during AP engagement is the X-Plane flight director handing. Do you use flywithlua? If so, perhaps this little script will help you. It creates a keybinding called "Smooth AP engagement on Torquesim Islander". It works best with a long keypress, around 0.5 - 1.0 seconds. On the keydown it activatesthe (hidden) flight directors and resyncs the VS target, then on key release activates the autopilot - you should get a smooth engagement with ROL/VS every time. If it snatches, make sure your are in trim before attempting to engage the AP, and hold this keybinding for just a little bit longer. function activate_BN2P_autopilot1() command_once("sim/autopilot/servos_fdir_off") command_once("sim/autopilot/fdir_on") end function activate_BN2P_autopilot2() command_once("sim/autopilot/vertical_speed_sync") end function activate_BN2P_autopilot3() command_once("sim/autopilot/servos_on") end create_command("FlyWithLua/autopilot/BN2P AP On", "Smooth AP engagement on Torquesim Islander", "activate_BN2P_autopilot1()", "activate_BN2P_autopilot2()", "activate_BN2P_autopilot3()" )

Thanks Ozz, I had the Carenado B58 in XP10 with the REP - I'm afraid to say I hated it - the logic was nowhere near realistic. The Islander is at least trying to do something like what the real thing does, the Carenado was behaving like a modern fully digital autopilot. The AP engagement logic isn't right at the moment as it remembers the previous VS rather than syncing. If you bind "Autopilot VVI Sync" and use than just before engaging the AP with "Servos toggle" the behaviour is acceptable. This has already been fed back to Torquesim - and all it really needs is a pitch mode engagement, then everything else would be more or less as per the real thing. In the absence of pitch mode "Autopilot VVI Sync" then "Servos toggle" immediately does the job. Further work on the ROL/HDG mode on approach shows the AP will drop from NAV mode to HDG when there is a VOR/ILS tuned, and from NAV to ROL when there is no VOR or ILS tuned. This is not correct, it should simply go to ROL when swapping between GPS and VLOC CDI. However, I feel that as the LR 530W does not show the required prompts that Garmin put there specifically for the KFC225 that the most useful behaviour may be to work on the basis the "swap and ROL" shouldn't be there, and allow the AP to maintain NAV mode provided there is a valid VOR/ILS source. This, after all, is what Garmin were trying to achieve anyway, within the limitations of the KFC225. Alternatively, if Torquesim would implement "external GPSS" where the AP would use the HDG mode (with a switch to swap between HDG bug and GPS) and simulate a fully analog control system then that may be more practical and more realistic given the constraints with the LR 530W.

Having done hours (literally - it's 03:55AM!) more research on this, the KFC225 does support a form of GPS Steering. With the GNS530W in GPS mode it signals to the KFC225 to use the GPS ARINC 429 information to steer with rather than the analog HSI deviation, although it must use analog guidance for GPS approaches - see the link below. The KFC225 effectively can work in an analog or digital mode, and that mode is triggered by a pinout on the GNS530W. Now, for reasons apparently from the 1990s, when the GNS530W is changed between GPS and VLOC mode, the KFC225 will, IRL, drop back to ROL mode. So when the GNS530W is used with a KFC225 the auto-switching between GPS/VLOC must be disabled by the installer so it's always a pilot action to change over. You can read about here: https://www.twincessna.org/pdf/KFC-225-Internal-GPSS.pdf In the sim model, the GPS/VLOC swap is causing the KFC225 is going to HDG rather than ROL, but only in certain circumstances, as has been observed in this thread. That's not ideal - however setting the HDG bug to the inbound track during or just before intercept is a really good idea anyway, so by doing this you can mitigate the problem. I've got a bit more research to do and will update my bug report accordingly, but that will need to wait for a week or so.

The GPS should not be able to “auto-slew” a mechanical HSI, the pilot must always set the course bar on the HSI to the GPS DTK value. Likewise flying an ILS it must have the course set on the HSI. The GPS drives the HSI, and the autopilot “reads” from the HSI, not the GPS. The BN2 as implemented currently does not require this (I’ve reported as a bug) but in general it’s a good idea to operate the HSI correctly. (That’s the reason the GNS gives you the next course and a countdown timer approaching the waypoint)

@Goran_M i5-2500k clocked to 4.2GHz, 8GB 1600Mhz DDR3, 1GB Radeon HD 6850. P8Z68-V LE. (It was a good spec in 2012!) Test 1 :- All four sliders on the graphics settings to minimal, 1x AA. Loaded to an airfield outside the available scenery (runway and water everywhere) TBM Cockpit view 14.3fps, External view 23fps IXEG Cockpit view 30fps, External view 40fps Test 2 :- Visual Effects: High(HDR), Texture Quality: Medium, Number of World Objects: Low, Reflection Detail: Minimal, AA: None EGPH Runway 24, default X-Plane scenery TBM Cockpit view 10.5fps, External view: 14.2fps IXEG Cockpit view 27fps, External view: 29fps Default C172 G1000 Cockpit view 33fps, External view 30fps You've built a really, really beautiful model - but at the moment it's very heavy on system requirements.

Thanks @skiselkov - I know your priority is making the model run well on new hardware and these older machines are a fringe case for you. Regardless a low poly model would be much appreciated. What I’ve seen of the model is really fantastic and hopefully in 6 weeks or so I’ll have a new machine to run it on.

Skyguider your GPU is miles better than mine, but your CPU is of a similar age (I've got an i5-2500k 3.3 with a slight overclock). I've tried all the same things you did and can't get a significant improvement. I don't think it's textures as although they are 4K the total texture size is only around 200MB, My suspicion is it's the size of the obj files that is the issue, and perhaps that's loading the CPU rather than the GPU causing the whole sim to slow down. The obj files are enormous. 6 times larger than the IXEG, 5 times larger than Felis 154, 3 times larger than the FF A320 and finally only slightly smaller than the Rotate MD-80 which is virtually unusable on XP11 for me - although it ran OK on XP10 - again suggesting perhaps that the CPU load is the problem rather than the GPU. Here's a extract from an IXEG object:- POINT_COUNTS 7222 0 0 28056 VT -0.7237 0.3741 2.0096 -0.165 -0.439 0.883 0.6316 0.874 and from the TBM:- POINT_COUNTS 470814 0 0 470814 VT 0.00841901 0.09876074 0.00741016 -0.99862665 0.05215613 -0 0.894862 0.79924899 I don't know how the X-Plane engine works, but the sim appears to be being asked to draw a massive amount of polygons apparently to a higher precision with the TBM model. I'd be keen to see how your system performs if you swap the forward view to the X-Plane HUD view? For me this instantly doubles the FPS. No textures are unloaded, but the sim simply performs better without the cockpit view hence my suspicion it's the objects themselves. I've also tried pulling the CBs for all the G1000 screens but that has no improvement. As a last resort, I made a copy of the .acf then removed references to glareshield.obj, seats.obj, cargo.obj and cabin_rear.obj - this improved my FPS from 15 to 18 - a 20% improvement.

Hello Javier, The normal way to do this on a single PFD+MFD G1000 is to use the Bearing pointers for the VOR. Click the "PFD" softkey and click the BRG1 and BRG2 keys to cycle through pointer options until you have pointers for NAV1 and NAV2 displayed at the same time. It's easy enough to fly a VOR "on the needles" rather than with the CDI presentation. Hope this helps!

I've got lot less VRAM than that, but even with textures set to low and most of the internal and external textures resized down to 2048 there was no framerate improvement. I think It's all in the 3D model itself. If I go to external view and zoom far away or view forward with no panel the frame rates are fine and the pages like engine parameters are fine. From the TBM glareshield.obj POINT_COUNTS 470814 From the IXEG fuselage.obj POINT_COUNTS 81633 In the objects folder the IXEG has 137MB of textures vs 149M in the TBM - I don't think that's a huge difference for the GPU, but as I noted initially the TBM OBJ files are 6 times larger than the IXEG. (I completely understand my system is well below spec, and what I've seen of the system sim is really very good!)

I’ve got a relatively old PC, I5-2500 and a 1GB HD6850 Graphics Card - and I know it’s probably well below what the developers had in mind when they developed the TBM so this isn’t a criticism of the product. However, I’m getting frame rates of less than 12 with the TBM, compared with 35 on the IXEG 737 with otherwise identical settings. I had a look in the objects folder and the objects are huge, the largest obj is 45MB for a glareshield. In total the IXEG objects are 56.5MB, with the TBM at 327MB - so I’m guessing this is where the frame rate hit is coming from. Changing the forward view to the X-Plane default HUD view restores the frame rates to 35-40. Before I commit $2500 to a new PC can I ask is any optimisation of the model planned? Thanks, Graeme

Jan, I've had a look in my earth_nav.dat file, and I have two lines for the ROVANI VOR. Line 9997 in the file, with a value of 6.0 before the ROI identifier, and another line 25306 with a value 0.0. At a guess I'd say one was the VOR, and the other the DME? I've checked my charts as well, and the inbound course is the reciprocal of the radial, so as far as the charts go the VOR should be correctly aligned with Mag North. Do you have an example of an instrument approach where the VOR is not aligned to mag north so I can have a look at how it's represented - I'm ashamed to admit I'd not considered that possibility!

As far as I'm aware I'm using default data supplied with the Steam version of X-Plane. I've got the HD Mesh v3 and also the EFRO Scenery Gateway airport. I'll have a look at the dat files.

Hi Kneighbour, Thanks for your suggestions. Flying a circuit in a 737 is not unknown, it's how pilots new to a jet transport learn how to land the aircraft before being released to fare paying passengers. That said, it's a very specialist kind of operation so I'll have a look and see if I can find any information on how it's done on the 737. It's a great idea though, should hopefully make for an interesting video. i've never seen the glideslope fail to capture, the only thing I can think of is it won't capture the GS until after the VOR/LOC has engaged. Also, I have a vague recollection that intercepting the ILS whilst in LNAV is not a good idea on the Classic, so make sure you pick up the localiser in HDG mode, at least until you're sure you can capture it every time that way. Would you be able to show me a screenshot of the flight deck when it's failed to capture? I'll need to see the EADI, EHSI and MCP in the pic. Thanks, Graeme

Jan, Thanks for all your input on this matter. I've been doing a bit more investigation and based on the attached composite screenshot the VOR North value is exactly the problem. I don't see any problem at all with your Mag Vars and understand they're based on a 2020 epoch. Pictured is the default 172 tracking towards ROI VOR on Radial 180, so inbound 360. Nill wind and aircraft stabilised on track for a few miles. Note the Mag Compass value shown in the data output and directional gyro is 354.2, Almost exactly what the VOR North value for ROI is. Now what this means is the VOR "calibration" for want of a better description, is based on difference from Magnetic North, not True North. To fly inbound on Radial 180 I'm using a course from 354 degrees, rather than 360 as one would on a perfectly calibrated VOR. Now, to the root of the matter perhaps. I understand you very kindly updated the X-Plane Mag Var system (as well as all those lovely gateway airports!). As the VOR's are apparently referenced to Mag North, perhaps the values for the VORs were not changed when the MagVar table was updated? It's almost like the VOR North value was being used as a fudge to make the procedures work with the previous incorrect MagVar? If the VORs were referenced to True (i.e. had a VOR MagVar stored in the database) then perhaps this would not have been an issue. If I reset VOR North to 0 then everything works exactly as expected as if the VOR was perfectly calibrated. Thanks, Graeme

Sorry Jan, just to add I tried resetting the VOR North value of the offending VOR to 0 and it seemed to be a much closer match. Is the VOR North value the MagVar? ROI has 10.8E published but the VOR North is around 354. Do you know what the VOR North value is designed to reflect? - the notes I found say it lists the *Magnetic* Heading of the 360 Radial, if this is the case the VOR North value would not represent MagVar but rather the "shift" in real MagVar since the VOR MagVar was last reset? Thanks, Graeme

Thanks Jan, I'm aware of the real life limitations for the VOR system, however for a published VOR approach the stated radials should work correctly. Basically, I followed an overlay procedure cross checking with the radio aids on the published charts, and the raw data was off by 4-5 degrees.

Hi All, I've just spent a frustrating couple of hours typifying to set the sim up for a video on VOR/DME approaches. I'm looking at the VOR 03 approach at EFRO Rovaniemi. To keep it simple I'm looking at a final inbound leg of 23 degrees, nil wind. FMC overlay procedure followed in LNav the aircraft tracks correctly, and with the map navaids selected the ROI VOR is shown exactly on the heading line on the nav display. This is exactly what I expect, the aircraft is tracking directly towards the beacon on a course of 23 degrees. Perfect! Except both the VOR display and RMI show a course of approx 27 degrees to the VOR. I'm guessing this is a MagVar issue. Can somebody explain the relationship between the X-Plane database MagVar and how it interacts with the IXEG database? Can I change the X plane MagVar table? TVM, Graeme

Thanks for all the feedback, I'm really glad you're finding the videos enjoyable and useful. The next video should be out in a few days or so. I'm looking at covering non precision VOR and NDB approaches next, before moving on to visual circling. As always if you have any suggestions for procedures or other aspects of the sim I'd be happy to hear them.

I've only recently got X-Plane 10, and the IXEG was one of the key reasons for getting X-Plane. I've not really flown flight simulators for about 10 years now, but I'm loving flying the IXEG model. I'm in the process of starting off a YouTube channel "Reflected Reality Simulations" with the intention of showing sim flying using some real-ish procedures, but with the focus on enjoying the sim rather than detail-perfect operations. My first video featuring the IXEG 737 is on YouTube now, and there's another short video called "Channel Introduction" where I try and explain the reason for another YouTube sim channel. I'd love to hear your feedback, especially any procedures you'd like to see in a similar style.

There's certainly something happening with the FMC computed courses. A couple of screenshots from the Turin (LIMF) SIRLO7A departure, the key waypoints being MF403 and SIRLO. On the charts it's course 104 from the CSL. I've tuned the CSL and also drawn a fix on radial 104. As you can see from the pic on the ground that fix line parallels the course line on the Nav display, but the FMC shows course 107 rather than 104. In the second pic I've just passed MF403 (odd config to keep the speed low) The heading pointer, fix line, and on the P2 VOR display the actual radial all show the correct thing of 104, and unlike the first pic where the FMC said 107, it's now 103. I'm happy with that 103 vs 104 as one expects a certain error as mentioned earlier in the thread, but it's the fact that the course shown on the FMC changes from 107 to 103 as soon as the waypoint sequences. I understand it may be using source location magvar for the initial FMC display, then actual magvar as it sequences, but it doesn't change by 4 degrees in such a small area.

Thanks, I changed the INTC waypoints to fly over but no luck I'm afraid. It looks like the first INTC is the problem as it's quite far out of position. Debug log and screenshots attached for both the Glasgow and Marseille issue.IXEG_debug_01.txt

Hi, Brand new X-Plane user here after many years of MSFS. IXEG was one of the key factors in moving to X-Plane. I've noticed some oddities with how the planned route is drawn with SIDs and STARs. I'll post them here in the hope I've missed something. Glasgow (EGPF) 05 NORBO1J departure. Should be fly ahead to XEXUS, left turn C247 to ELBAN then PTH R236. The SID is coded with two intercept points but the picture on the ND is nothing like what the departure should be. Removing the Intercepts leaving XEXUS, ELBAN allows the aircraft to make a better job flying it. Marseille (LFML) 31R ILS Z with MTL8C arrival and DOLIV transition. On the missed approach the routing should be basically ahead, MTG, CALAN, Hold. At MTG the ND shows a right hand orbit then out to CALAN. Removing and then replacing CALAN gives the correct left turn though the hold at CALAN is then missing. I'm using 1.0.4 I think - I've done the hot fix but can't see how to verify the version number? Standard Xplane 10.45 with no navdata mods or updates. Are there known issues with the supplied NavData? I can do some more investigating and provide screenshots if required? Thanks.