Torbinator

Thanks guys. I'm curious if you could clarify something that I think I remember reading. If I understood correctly from a previous post, there is a plan to improve the vnav functionality in an upcoming update, and then further in a complete rewrite? Also, was hoping you might be able to clarify the following based on the above... I feel as though as recent as version 1.30 through 1.32 I was able to reprogram the altitude over a fix on a STAR from what was on the chart to what ATC (PilotEdge/Vatsim) asked for, and see the depicted T/D did shift accordingly. Sometimes the aircraft followed the reprogrammed VNAV (about 50% of the time estimated), other times not. Yet with the v1.33, the reprogramming amended restrictions never relocates the T/D and the aircraft VNAV only follows the path as originally calculated. Can you share if this functionality will be restored with the VNAV update or VNAV complete rewrite? Assuming my interpretation that there are two separate phases on this is correct. Thanks @tkylerand @Litjan !

Hi guys, I know mentions have been made in previous posts describing sporadic glitches related to sound, but I managed to record a pretty good example of when it's at its worst. You'll essentially hear the hiss of the cockpit gasper air becoming exceptionally loud (among other sounds) as I open the window. Also highlighted was how the cockpit & local sound effects "followed" my camera position, where normally it doesn't/shouldn't. I'm sharing in hopes these observations help when you get around to shifting the IXEG sounds into X-Plane's FMOD in the future. Thanks for watching... https://www.dropbox.com/s/ynugzzynen53ssn/IXEG Sound Bug Example.mp4?dl=0

Hi @tkyler & @Litjan, If I understand correctly, the V1.33 update included the ability for the CDU to display potential block altitudes at fixes. However, I do notice quite often that when I load STARs in the FMC, the altitude's depicted over fixes on charts don't always match up with what is being displayed on the CDU. My question is, would you like us to post those occurrences here similar to the way we've been posting Gizmo errors? The latest example I can give was a flight with planned cruise of FL320 into KLAS. I set up the SITEE4 arrival out of GGAPP, which the chart lists as at or above 23000 (FL230), but the CDU displayed my cruise at FL330. Another occasional occurrence has been missing data at fixes along a STAR before reaching the runway (i.e., ABCDE ---/-----). I know when all the fixes lack data it's because the FMC was not loaded correctly/completely, but the example I'm describing shows the fixes before and after with the calculated VNAV data. Last scenario for now, should we report erroneous lateral RNAV course depictions? Many times it depicts curved lateral paths as charted, other times not. Example: I flew into KMSO on the RNAV runway 30 out of PIXIE, which takes us straight to ROKNY then WAMIS, then a curved path to TUFFY. This depicted a straight path between WAMIS and TUFFY instead of curved. However, when flying into runway 32 at KMFR via the RNAV out of SAMIE, it did a very nice job depicting the curved path from RURTE all the way to FILPU. Should we report these? Thanks.

Ahhh, excellent tip for now ... I hope you can find that fix!

Hello, there've been a few times on approach when I go to use the VSI mode on autopilot to adjust for the next step down altitude only to find that it will not let me scroll to more than a 650 FPM descent rate. Sometimes this number is varies between 600 and 900 FPM, and other times there is no issue. Is this intentionally modeled in the systems, or is it a bug? The few times it has occurred I was flying with online ATC services such as PilotEdge or Vatsim, so I didn't have time to try to talk troubleshoot it. I have linked a recent episode this happened to me on my way into SFO. Just before the clip I linked, I changed my target altitude from 4,000 to 3,000, then did a quick drag on the VSI scroll wheel to get it going down. As I went to increase it beyond 850 FPM, it wouldn't increase descent rate. I then tried to scroll to another desired descent after selecting a lower altitude, and it at one point allowed for 900 fpm down, then only 700 fpm down: https://clips.twitch.tv/RudeGleamingLEDTheTarFu

@Litjan I wonder if something has changed in X-Plane, because I never had the box checked but the situation in the video above occurred anyway. Interesting.

Hi guys, What is the protocol for the experimental flight model with IXEG v1.33 and 11.50? Is there a setting in plane maker to apply the Experimental flight model with this particular airplane only in 11.50 final? Do I remember correctly that Laminar was going to give developers/users this option in Plane Maker? One of things I find challenging, as simple as it may sound, is too remember to turn on and off the experimental flight model when switching between airplanes. Given that the simulator can take several minutes to start up, it can annoying when you have limited time after work/dinner to squeeze in a flight and you realize the experimental flight model was left on or off incorrectly. It would be nice if this would happen automatically when switching between airplanes, which I thought I vaguely remembered reading would occur if it was specified in a future version Plane Maker. Thanks!

Hi Mark, Attached is a screenshot of my failures menu. As you'll see I have the time between failure unchecked. I assume this means that random failures will occur if left unchecked, but checking it active gives more specifics? Example: I flew over the summer with the box unchecked about 3 times a week, usually about 2 - 4 hours each time. Some flights in the IXEG, some in the FlyJSim (w/ their maintenance menu off). I had about 4 failures in total, IIRC. One can also click the box and type in a value, and it will tell you how many systems there are and how many average failures per hour it may create, but I haven't played with that much yet.

Would you consider portraying the version that does chime at 900 and 300 ft? Bells and whistles are fun!

I know in previous threads it was mentioned that IXEG has a custom sound system due to earlier versions of X-Plane having limitations. I have been noticing a lot of issues that I would like to report (as of 1.21 - 1.33), but I know it will be rather challenging to demonstrate my observations. I wonder if it's better off to wait until you complete the FMOD conversion with the thought that it might resolve the issues? Please advise. Thanks!

@Kopelent I noticed that SAM (version of autogate) caused this for me. I went in the plugin manager and unchecked the AOS plugin (SAM), and the stutters during panning greatly reduced. I also found SAM 2.0.7 to be less stutter inducing than SAM 2.1.0, but not perfect. Stairport Sceneries software manager lets you roll back to prior versions of SAM.

Well, I'm assuming @janis22 might have been simply trying to provide confidence that the issue is specific to IXEG/Gizmo. I know I've shared bug & performance reports with developers here and other products in a similar fashion. Here is an example that I never got around to sharing here or with Laminar, but this post reminded me of the situation: I noticed around XP 11.32(?) that a change in engine indicator behavior in the 733 became apparent. Prior to XP 11.32, I was able to watch the oil pressure rise while waiting for the N2 to rise to 25%, as per described and instructed in FCOMs. IIRC, we are supposed to avoid flipping that fuel lever to idle if we don't see a rise in oil pressure before reaching 25% N2. However, as of XP 11.32 and beyond I saw the oil pressure stay at 0, then suddenly "kick in" noticeably above 20% N2, which seemed kind of late based on what I read. At first I wondered if it was IXEG's engine simulation was no longer compatible with a change made by Laminar, but then I saw it on the FlyJSim 732 and Rotate Sim's MD-88 aircraft. Given that it occurred with several planes and not just IXEG, some of us laymen might begin to ponder whether Laminar's tweak was faulty, and therefore not bother you folks by sharing that here. Although, one could cautiously suspect that all three aircraft devs planes are now faulty because Laminar refined their engine modelling and the devs needed to adjust. Anyway, I think the observation of whether or not it's happening in other aircraft can be valuable in many end-user's minds given that many of us lack the coding insight you guys deal with when creating these fine digital replicas. However if there's a better way to convey whether or not we see it in other aircraft, please share. Thanks!

Hi, I'm not sure if this is the right place for this, so feel free to move it. I am receiving a "this scenery might not look correct - check log.txt" box popping up in X-Plane 11.50r2. I even did a reinstall of the scenery, but no luck. Might this be a Vulkan compatibility issue? Log.txt and scenery.ini files attached. Any help would be great, thanks. Log.txt scenery_packs.ini

Hi guys, So I don't practice emergency procedures and failures too often, and it shows in this video! The link takes you to the point where my descent starts and the initial fusion begins. Unfortunately I had shut off my structural failures the night before, it would have been interesting to see if this overspeed would have resulted in a crash. One thing that struck me was my own delay in realizing I should use the stby ASI to confirm which side was failed. This delay was no doubt very dangerous. At first I thought the overspeed was coming from another browser tab I left open! Then I mistakenly thought the FO side was the issue. I felt I did OK in utilizing ATC to confirm my speed. Anyway, it was an interesting and eye opening event! https://www.twitch.tv/videos/712226145?t=01h16m20s

Hi guys, In the attached picture you'll see the window frames are pulled open on both sides. However,, the first officer's side shows the glass still closed even though the window frame is open. This happens in all liveries.

Hi guys, I have noticed that in flying v1.32, it seems that the depicted crossing restriction on many STARs are not matching what is calculated by default in my CDU, and also if I modify an altitude at an existing fix, the top of descent (T/D) does not seem to reposition like it used to in the past. A few other folks I communicate with who fly this aircraft seem to be experiencing the same thing. For example, I was flying from KAVL into KMDW, and had loaded in the PANGG3 arrival via the FWA transition. My cruise was FL330. See the attached image for reference. When I loaded the routing before departure, it showed the altitude over BAGEL as FL330, PANGG at FL326, MEGGZ at FL267, AWSUM at FL241, etc. But as can be seen on the charted STAR, MEGGZ is 11,000, and AWSUM is 10,000. Also, as I flew the flight I saw the depicted T/D over PANGG. To remedy the situation, I typed /11000 into the scratchpad and inserted it next to MEGGZ. However, the T/D never moved back to account for a new descent point. Additionally, the fixes now read BAGEL as FL330, PANGG FL326, MEGGZ at 11000, AWSUM at FL241, etc. I feel as though earlier versions (including v1.30 & 1.31?) more often properly moved the T/D earlier in the route and recalculated the altitudes over the adjacent fixes, but it seems v1.32 is having issues here. I know the VNAV is slated to be improved, but I wanted to point out that either v1.32 has either deteriorated in the calculations when asked to modify arrival fixes, or I have managed to coincidentally choose about 4 - 5 STARs in a row that this plane would have had problems even in the previous versions. Thanks for reading this!

I had the hiss sound of the airflow from the gaspers show up for me as I was in an external view a few times as well, along with other oddities... @cantab88 and @lain please report if you see this one linked below on cold & dark starts. I know @Litjan is keeping a lookout as well..

@Litjan & everyone, please keep looking. Today with v1.32 I had the same issue with the delayed avionics fan after hitting the APU GEN switches, only this time it never came on despite waiting 3+ minutes. I ended up applying the turn-around state and the fans sounded normal, then on the next cold n dark it worked ok. However the fan delay issue seems to happen every 3 or so flights.

Doug, are you confusing the FlyJSim 732 v3 with the IXEG 733 v1.32?

Cool, yes unfortunately it's one of those sporadic events so it might take a few tries to hear it.

Hi guys, Here's a video showing two issues related to fixes called STEVS and SAMIE. Fast forward to 1 min 20 sec if you're short on time, as well as 3 min 17 secs: https://www.dropbox.com/s/okco14bou10si7g/IXEG 733 v1.31 Soft Crash INVALID ENTRY.mp4?dl=0 After I made it, I saw this post linked below, I'm not sure if my errors are related to this from a month ago...

Hi guys, With v1.31 & latest Gizmo beta (email notification instal 7.2.2020) I've had this a several times now, but not every time. Basically as the APU GEN power comes available, I flip the switches and hear the relay sound effect, but the fans don't always kick in right away. The delay can be a few seconds, but this delay seen here was about 50 seconds: https://clips.twitch.tv/UgliestSuspiciousRaccoonKeepo

Hello, mine says in the upper right expiration is 3 days. Will it still work on day 4 and beyond? Mine appears in a similar box that one sees when the license is renewed. I can click it away no problem.

At times I have heard in real-time and during replay certain in-cockpit open window wind sounds when outside the cockpit. One example is the wind noise when in shift-4 view about 20-30 ft away. In this linked replay video, you can hear the significant wind noise in this user created wing view. Will this be adjusted when you do FMOD work? https://clips.twitch.tv/FilthyCrunchyTarsierRuleFive BTW, LOVE that the spoiler deploy smooth on replays now!

Thanks for the details Tom. In addition to the above reported altitude restriction blocks on STARS mentioned above, some other odd behavior I noticed on STARs is that despite the speeds for fixes over 10,000 often reading 280 kts in the CDU, I'd often see the speed cursor would set itself to 290 and the engines would periodically speed the plane up to about 300, then go idle till it slows to 260, then engines spool up again till we hit near 300, and repeat this behavior several times throughout the descent. Not sure how others have experienced this, but I figured I'd mention it.