daemotron

Don't know if it's just my perception, but the triangle symbol on the HDG selector knob seems to be rotating in the opposite direction of the knob itself (whereas the SEL on the ALT selector rotates correctly):

I have noticed a behaviour of the LVL CHG mode where I'm not sure wether this is inteded or needs some fine-tuning: I usually use the LVL CHG mode for climbing, and as long as IAS is selected, everything works fine; the climb rate decreases with increasing altitude (down to ~1,000 fpm with 285 Kt IAS approaching FL290). The moment however I switch from IAS to MACH (without changing the selected speed, just a switch from e. g. 285 Kt IAS @FL290 to M.74), the plane pitches up, increasing VS up to 3,000 fps and only pitching down once the speed has decreased to M.70, then levelling and regaining speed before resuming a "normal" climb profile. I noticed this particularly during the last two flights where I had significant tail wind conditions. Situation where speed has fallen to M.70 and plane starts pitching down: Speed recovery: IXEG_FMS_debug.txt GizmoLog.txt Log.txt

I just stumbled accross Ventura Sky, seems to be a promising plugin (particularly the METAR interpolation sounds cool). However, it looks to me as there were some similarities to RTH - and this one has been quoted umpteen times by the IXEG team to be a potential troublemaker in conjunction with the 733. Therefore I'd like to ask if somebody already gained some experience with this plugin when used with the 733?

When entering & executing a new CRZ ALT on the CRZ page, the PROG page will lose the FROM reference and just display "----" (step climb performed by N1 + LVL CHG after EXEC on the FMS). I haven't detected any malfunction linked to this, and I'm even not sure what the real FMS would do. In IXEG's version it seems the old flight plan gets overwritten on EXEC starting at the current position (at least that's what the FMS_debug suggests). The subsequent waypoint is then sequenced completely normally: Btw. the T/C displayed on the HSI here is a bit freaky - some >150NM behind the segment where I actually performed the step from FL340 to FL360... IXEG_FMS_debug.txt Log.txt GizmoLog.txt

That sounds really great! Btw. I think FF is picking up this information from the Airports.txt file (belongs the GNS430 data set either in default or custom data). The first line per airport seems to encode TA and TL in the second and third last field (but as far as I've seen it's not really complete, and for most only TA (or TL, not sure about the order) is filled)*. * I love nested brackets - kudos to Lisp

Hehe, the Saab is no racing machine, but running at max prop RPM will not deliver optimum torque (at least in greater altitude). Therefore, reducing the prop RPM in line with performance charts will deliver better climb / cruise power.

@amo63 Cool paintwork, particularly the Lufthansa and LR liveries! Btw. registrations for the Saab in Germany would start with D-C (due to its MTOW classification), not with D-S...

I found a behaviour where in some situations, the cirrus clouds start moving with the aircraft, while "normal" clouds remain stationary, so the aircraft moves relative to them. It's a bit hard to explain; therefore I recorded a few seconds of video where this hopefully becomes visible: The video was recorded with X-Plane 10.50rc1. The behaviour occurred in parallel with some terrain loading issues (late loading of tiles), which is currently under investigation by Laminar. I could make both problems go away by setting the runloop/time_per_frame_usec art control to a sky-high value of 5,000 (only possible with specific debug versions), so potentially there is a link between those two. For sake of completeness, I attached both log files (X-Plane and Gizmo). To be fair (and to prevent criticism), the video was recorded with SMP 3.2.1 (prior update to 3.2.2). So if you say that it was known behaviour already fixed, I apologize - I just couldn't see a link to the published change log, so I assume it's perhaps more related to X-Plane 10.50 vs 10.45 than SMP 3.2.2 vs 3.2.1 (but that's just a guess of mine). Log.txt GizmoLog.txt

Reference: IXEG 737-300 Classic version 1.0.7 X-Plane 10.50rc1 NDP AIRAC 1608 rev 1 Route flown: LEPA MERO2A.MEROS UN853 LUMAS UM976 SOFFY UQ208 MOBLO UZ662 LAMUR Z67 KORED UN871 DITON T163 ZUE T125 ROMIR UN851 KEMAD P605 AGATI.AGATI2K EDDH Departure: 24R Arrival: ILS 23 Effects observed: The VNAV profile proposes a ToD only 70NM from the runway threshold for a descend from FL360: On a second attempt (the one for which I attached the logs), I modified the ALT Constraint for PISAS from 3000A to 3000 (as 3000ft would be the GS interception altitude at PISAS), but this did not change the VNAV profile. The constraints in the Nav Data (at or above) are OK (apart from PISAS), but the computed VNAV path is way higher (and steeper). At one point, the ND even claims the VNAV path to be at negative altitude (saying I'm 16,600ft above VNAV path while flying at FL125): In real life, the ToD would be somewhere shortly before DLE... Log.txt GizmoLog.txt IXEG_FMS_debug.txt

This one is really minor, just a visual thing without impacting functionality: When moving the plastic bugs at the speed indicator back to the beginning of the scale, the position of the bugs depends on the last bug moved, not on the first one. Think as if the bugs were numbered one to five, with one being the most left, and five being the most right when all five bugs are moved to the beginning of the scale. Now move all five bugs out of position and scatter them. If you now move bug number one back to the beginning of the scale, it will move only until the position where previously bug number five was. Now move bug number two back, it will take bug number one's previous position, pushing this one to bug number four's original position, and so on. I tried to record this behaviour in a simple video capture; maybe this helps illustrating:

Hi Tony, What I'm saying is that I had no issues with SMP 3.2 and X-Plane 10.45 (and neither the IXEG 737 nor the PMDG DC6-B, both being my current favourite planes). With SMP 3.2 and 10.50b4, I did have an issue, but it was specifically happening only on very long flights, and I had it in conjunction with terrain loading issues (tiles loading only when crossing the border right into it). Very hard to reproduce since I had to fly for 4-5 hours before it happened, so not exactly a good receipe for reproducibility. I was not able to narrow down where exactly the gremlin was hiding; I even don't have a proof that the suspicion of VRAM leak or fragmentation holds true; it was just Frank's (however very plausible) conclusion by looking at the symptoms. When SMP 3.2.1 was released, I installed it and intended to re-test, just to discover that Ben had meanwhile pushed 10.50b5a to the servers. Since I didn't want to run two flights of 6 hours each, one for seeing of SMP 3.2.1 brings any change, and one for checking that b5a fixes the tile loading issue, I upgraded to b5a and did a check ride just beyond the risky threshold - nothing odd happened, the tiles are now loading as expected, and I didn't see any drop of the frame rate, even with really evil(tm) scenery loaded. Conclusionwise, it's somewhat intricate - It could be that a change in SMP 3.2.1 prevented the issue from occurring again, or - more plausible, a change in X-Plane's beta (maybe even just a compiler flag or whatever and not even the code itself) cleared off the problem. Or maybe (and that's one I also cannot exclude) the problem is still there, and I missed reproducing it for whatever reason (could be it now sets off later, after 7 or 8 hours of flight, or I didn't have the "right" terrain tiles loaded, or METAR was more gentle today, or ... - well I think you got my point there...). As only factors I can rule out, there's the Nvidia driver version (didn't change it for a couple of weeks now), and heat (water-cooled rig, custom fan profiles, and constant monitoring of the temperature, so I would have known if it had increased beyond thresholds set clearly below manufacturer-indicated thresholds). That's why I said I would keep an eye on it just in case it occurs again, but I will not deliberately try reproducing it by flying the same 6 hours leg again and again - it just get's boring, and after all, there are more obvious bugs to go looking after in the beta

Just chiming in again as I lauchned the topic: First of all I was never talking of a thing I experienced with 10.45 (and I had a couple of hours there, with heavy stuff loaded). So most probably what I described in the first post is not (or at least not directly linked) to what other users experienced outside X-Plane beta test. Second, I re-tested, and with SMP 3.2.1 and X-Plane 10.50b5a the drop is not reproducible, no matter how hard I try (over-)loading the Titan X. VRAM consumption stays well in a range of 5 GiB, so there's plenty head room. I even could extend SMP to full range coverage (whatever the slider does when pushed all to the right) and use some very heavy scenery tiles (Spain UHD, UHD Mesh, w2xp stuff... all at the same time). So for me it's plausible that it was something in 10.50b4 causing it - however I'll keep an eye on it, just in case...

I will drop a line to Ben Supnik about that. Indeed it had never happened before, and I never managed to consume more than 50% of my VRAM with my settings. As I said, there were some funny things happening with terrain tiles long before the frame rate collapsed. Maybe the new code in X-Plane introduced with b4 causes problems with tiles becoming residual in VRAM. I will keep on testing and keep monitoring what VRAM is doing... Gesendet von meinem SM-G920F mit Tapatalk

Hello Maxx-Xp Team, I tested a bit with XP 10.50b4 (using SMP 3.2 and RWC 1.0, standard X-Plane weather engine, no third party data injection). On shorter flights (~2 hours) I didn't notice anything worth reporting, SMP simply seems to work fine. However, this evening I did a somewhat longer flight (~5 hours), and I noticed a weird behaviour: After ~4 hours of X-Plane running (probably a bit more), the frame rate went from normal (~60 fps) to total crap (<10 fps). This seemed to not just be a problem with graphical rendering, since also the map screen took nearly half a minute to produce any reaction upon input. I do have a very strong rig (i7 6700K @4GHz, Titan X) and was flying over water, so I think it was not a scenery playing me tricks. Indeed, I am quite sure I can narrow it down to SMP or RWC: testwise, I disabled SMP and RWC through the plugin admin menu, and instantly my frame rate was back up at 60 fps. Even more funny, after re-enabling SMP and RWC, the frame rate stayed up at 60 fps. However, clouds looked completely different after switching SMP off and back on - before, I had something like an overcast just everywhere (hard to see on the screenshot since it probably was too dark, but it was distinctly visible from inside the cockpit). Some twenty minutes later on the same flight, I entered the area around LLBG with lots of heavy scenery stuff installed (LLBG in conjunction with Real Land Israel), and the frame rate stayed within expected corridor (around 40 fps) - this just being mentioned to give you a reference what would be normal frame rates I usually have. I use SMP with nearly unchanged standard settings (except for dense particles - ah and yes, don't consider the elapsed time displayed; X-Plane was running for more than one hour before I started the timer ): I know 10.50 is still a beta, just thought I'd leave my observations here. Not sure if this means anything after all, I encountered more funny things en route that seem to be linked to Ben Supnik's attempt of fixing the handling of hair cracks in scenery tiles. As far as I can see, the Gizmo log doesn't provide any useful information; the standard log will show you when I disabled and re-enabled the plugins. Log.txt GizmoLog.txt

@Pinky Ponk EGPF - EGCC is a transatlantic now? I might be wrong but I think this route could just be within limits for the 733 Hm, could have been also KGGW - EGCC, but that one is >3,600NM and definitely out of range for a 737, no matter which model... So I guess you were referring to EGPF - KMHT... Technically, a 733 can cross the Atlantic on most common routes (e. g. EINN-CYQX is just 1,700NM, which is not much more than EGCC - GCTS). Unless I'm much mistaken, the 733 modelled by IXEG would not be allowed to do so - it simply lacks redundancy for the FMC, which would prevent you from getting an ETOPS-120 clearance...

You hit the point - normally you would go for multiple threads or even spawn a child process to do the dirty work (threads are a lot quirkier when working for several platforms). However, from inside X-Plane that's not perfectly easily done. It can be done if you work on the C/C++ API directly, but you have to use standard library stuff (semaphores etc.) to control it (there are no xplm_ functions that would do this for you) - and these are platform-specific again, so you will end up with a lot of #ifdef in your code. If you go with Gizmo (like IXEG) instead, you can use multi-threading by using the Lua coroutine feature; however I'm anything but sure you really end up with parallel thread execution (not being a Lua programmer myself; I only know there are some limitations in other scripting environments due to stack tracing or similar technologies).

Thanks for this super-fast reactivity. Tom, hopefully you can have the rest of the week-end off

I updated to 1.0.6 this morning, and since the update, the FMS has become unusable due to various Gizmo soft crashes. For Ref: I use NG AIRAC 1607 - used it already yesterday with 1.0.5 without any issues Number 1: After takeoff, the TAKEOFF page should switch over to the CLB page. This switching triggers a soft crash (idem for selecting the CLB page manually): After that, the CLB page is shown, but wiped blank: Number 2: Subsequently, LNAV does not sequence waypoints anymore. Trying to "up" the next WP by C&P via scratchpad triggers another soft crash, locking down the CDU for good: Before this occurred, I tried exporting a debug output by the famous four dots. Entering them seemingly had no effect (no message on CDU shown), but I found a file IXEG_FMS_debug.txt in the aircraft's folder (cf attached files). However it seems to no longer follow the previous naming convention including an increasing index, helping to tell which output was which. Log.txt GizmoLog.txt IXEG_FMS_debug.txt

Pilot: "the plane simply didn't want to land there, it told me it doesn't like English fuel."

If you copy from the route editing page and not the flight plan document, there's no step climbing to be cleansed. Gesendet von meinem SM-G920F mit Tapatalk

You can copy the route in PFPX (go to the route edit window, it's in the lower left corner). Just don't copy SID, STAR and transitions. Paste into notepad and add departure and arrival airport, save file as .fpl and that's it. The same holds true for Simbrief.

That's interesting, never had seen that before. When I had WP misses, usually I was also off the magenta line, and the FD started maneuvering wildly to recover (usually "goin' round in circles"). In that case however it would have been hard to miss the wp; the last turn before (at IZA) should be just a 20° RT, and I didn't have any wind-driven offset. Oh it did, but not before next WP was sequenced. Maybe this also has to do with how this STAR is implemented in the nav data. The original STAR as published by ENAIRE (former AENA) looks like this (chart available here): So this chart suggests to me the STAR is "fly HDG 88°, then intercept MJV R232". However in the nav data (at least NDP AIRAC 1506) this STAR is modelled differently; instead of intercepting MJV, it uses artificial fixes (IZANB and X232) which are both defined as "Normal" type WPs with long/lat. Digging into the nav data provided, I found that both, IZA and IZANB do have the same geographical coordinates: IBIZA IZA NDB 38.915472 1.470417394.00N (extract from wpNavAID.txt) <Star Name="IZA1P.24L" Runways="24L"> <Star_Waypoint ID="0"> <Name>IZANB</Name> <Type>Normal</Type> <Latitude>38.915472</Latitude> <Longitude>1.470417</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> [...] (extract from LEPA.xml). I think I didn't notice when checking the route and just had the RTE DISC fixed by moving IZANB directly after IZA, which is pretty much unflyable (unless the FMC is able to spot that two subsequent WPs are the same and just sequences them both). Thanks a lot Jan!

@Litjan that's unfair, now I have this in my head, seing you with the first usable development prototype, and one of the first things you tried setting the engines on fire

Sorry for the title of this post, I didn't find anything more suitable to describe this experience in just a few words. So here's what happend on my last flight from LEMG to LEPA, using this route: LEMG 13 ROLA1H ROLAS UN851 IZA IZA1P LEPA 24L (IAP: ILS Z 24L, MJV transition) Navigation data used: NDP AIRAC 1605 I started descending some 25NM before the calculated T/D using V/S mode (VNAV mode was not used during whole flight, but the FMS was completely set up so it could have been used, even including ISA and wind). Lateral navigation was done using LNAV mode (engaged shortly after TO and maintained for the whole flight until final). Passing waypoint IZANB (first fix of the STAR, comes after the T/D), the LEGS page got "stuck" on that waypoint - i. e. it continued displaying it as the active waypoint. Also the VNAV path indication showed its deviation based on that waypoint, as if the aircraft had never reached it. At the same time however (remeber I was flying with LNAV) the flight director continued tracking perfectly the magenta line to X232 and SABAS without any issue (despite two HDG changes on these segments). Usually when missing a waypoint, LNAV will make you go round in circles until you alter the routing or properly intercept the missed WP. So to me it seems the VNAV part of the FMS and the CDU "lost" the route progress, while the LNAV part of the FMS correctly followed the route - the HSI consequently however did not highlight the waypoint LNAV was flying me to. Maybe this screenshot helps illustrating the situation: Next thing I tried is recovering VNAV and the legs page. Directly after having passed SABAS, I activated MJV (next waypoint after SABAS) by coyping it to LSK1 and EXEC. The legs page was then updated accordingly, however the VNAV deviation was still stuck at IZANB, and the HSI was still not highlighting MJV as active waypoint (however LNAV was not much impressed by this, it tracked the WP anyway): After the aircraft passed MJV and started tracking MJV11 (next waypoint after MJV), without further intervention from my side, the situation recovered: the LEGS page updated automatically to MJV11 the VNAV path deviation shrunk to something plausible (MJV11 has an at or above restriction on it, so the FMS estimation was not visible at that moment - therefore just "plausible", but correct with high probability) HSI shows MJV11 as active waypoint (magenta highlighting) Attached the log files (Gizmo will show you the mandatory soft crash for me having forced a debug output on this, but since it seems like a VNAV/LNAV story, I thought it could be useful...)

Thanks for clarifying!