tkyler

yes, a bug with X-Plane's TPE model for sure...they'll go into reverse eventually, but I've seen it take as long as 10 seconds, quite incorrect. It has been filed and there is some type of fix in the next X-Plane update, which rumor has will be released in a few days; however, until I test it, I'm not sure what the behavior will be. I had a short exchange with Philipp, the programmer of the TPE engine and given the limited exchange, I can't say for sure he understood and/or agreed with how I suggested it be modeled, so I'm not sure what to expect. The reverse should be darn near instantaneous with lever movement...this is due to the way the hydraulic circuit of the 'pitch sleeve' works. I've been waiting on this fix for a bit....fingers crossed. If not, I guarantee I'll be knocking on Laminar's door again. Philipp has actually done quite a good job of modeling this engine, it worked great in V11, but I believe he added a few more accurate features like NTS lockout etc. and somewhere in the last few patches, reverse in the TPE implementation got broke. I used to custom model this stuff myself, but I've known Philipp for a good many years and he's extremely capable and as Laminar adds more accurate engine behaviors, then the more custom behaviors I have to 'pull out' of my plugin code so they don't clash, but in doing so, I defer to their implementation in some areas. Now having worked with these guys in years past though, they're quite agreeable to suggestions and improvements and I fully expect we'll get this one ironed out.....and I do hope its in this next update from X-Plane. -tkyler

@pm_pilot I'm sorry, I don't have much to offer here at the moment, may be someone else has experience with the RXP units? I provide the RXP 3D integration as a courtesy for RXP owners and have no real experience with operating these units. I can't speak as to how they interface with the default X-Plane GPS leg data. My 'tests' for GPSS behavior is to use the default GNS unit flight plans and if you were seeing this behavior with those default GNS units, I may have more to offer. If the exact same route and tracking behavior works with the default GNS units, but not with the RXP, we'd probably have to ping RXP support. I'd recommend trying the same route with those units as a baseline data point for the debugging effort. I do have a possible theory though. In ealier versions of X-Plane, you could enable GPSS and it would simply turn to track the magenta no matter the aircraft orientation relative to the path. Philipp from Laminar mentioned that he was going to implement more stringent "intercept" criteria for tracking GPS and it would not automatically capture the route at engagement in all cases. It could be such 'intercept criteria', either by X-Plane or the GTN simulations could be getting in the way...however, if you were heading in the general direction of your "direct to" waypoint at engagement, I wouldn't expect this to be a problem. What were the particulars of this setup? Departure airport? flight plan routing? waypoint? sequence etc...I'd be curious to see if this happens for all RXP users in the same scenario. -tkyler

I'd say things are definitely settling down for sure.....but you never know. I'm not expecting any sweeping changes. -tk

In the past (long ago), it used to be that any mixture value below 0.5 would cut off the engine. This was Austin's simplified model for "low/high" idle in turboprops...but when that model was created, Austin did not really consider fixed shaft turboprops and was essentially working off of the PT-6 paradigm. Now that has been enhanced to be more flexible, but still the "mixture ratio" really represents the fuel reaching any engine and not necessarily the "mixture lever position"...so it is applicable in the "stochiometric" sense though not so much in the "typical nomenclature" sense. or maybe a broken simulator? If you did this in the same "flight session" without reloading the aircraft, then it wouldn't surprise me if it did not work. I myself have been very guilty of this during testing, forgetting to reload the aircraft and stuff not 'binding' causing me to chase phantom bugs. When a plane loads, a whole lot of initializations and "bindings" take place....and the only way to get a really clean "reloading" of an aircraft is to reload it via the developer menu, or restart x-Plane. The nominal way for us developers is to use the developer menu, but for end users, that's a bit odd and so many times, they just restart "the flight"...which does not always initialize everything properly in my experiences. (which is why the reload aircraft menu item was added I think). I will say I have not seen the "one engine won't start" bug in a long time. IIRC, it happend mostly when attempting to restart an engine after shutdown in the same flight session and every single variable that should be 'set' to indicate a running engine was set properly. It was/is enough for me to think X-Plane has an issue but in order to take that to Austin, it needs to be 100% repeatable and narrowed down to a smoking gun config, or else Austin won't really look at it because I control so much with a custom plugin...and when we do that, Laminar tends to "wipe their hands clean" of any issues. I won't lie, the Bravo hardware has been a major PITA for me. Here's the funny part....hardware setup has been a PITA for Honeycomb too....I spoke with the CEO at Oshkosh last year about it. This is exactly why they provide the profiles they do, in an attempt to alleviate the burden of a confusing setup from the end user, but in doing so, they end up providing "opinionated" configurations that cause issues with the Moo. -tkyler

I note you mention both a 750 in the title, but a 530 ...and I do not provide a 750/530 panel combo, so I assume you've tried multiple flights/configs, which means settings could have been differing between flights. So...I'll just ramble here a bit in general in case you find a useful nugget of info. I am by no means a GTN750 expert, but IIRC, it still interfaces with default XPlane GPS behaviors. Also, The HSI does not display any GPS information, except for the CDI needle deflection when the GPS CDI button is set to 'GPS' and a GPS leg is active. So no course or range information related to a GPS waypoint/plan is displayed. The HSI only displays course/distance information from radio nav aids, i.e. VORs/ILSs. I'm not fully sure of your navigation config regarding the GPS/VLOC issue, so I'll just speak generally. This button only changes the CDI needle signal source on the HSI, and so won't do anything unless (in the case of VLOC mode) you are tuned to / receiving from a navaid....and (in the case of GPS mode), you have an active flight plan leg. I'm not sure if you were tuned to navaid when you tried the GPS/VLOC button, or had entered a flight plan in the GPS and were on an active leg. Either/or, the only thing you'd observe from pressing this button, assuming you were tuned into to a signal/active leg is the CDI needle on the HSI move a bit. Again, not knowing your full config, I couldn't say what's going on here, but I can say its not related to the GPS/VLOC button at all. This has zero bearing on the autopilot tracking and engagement. For practical purposes, only the GPSS button really changes the "SOURCE" signal the autopilot follows. I've never seen the autopilot not follow a GPS flight plan in GPSS mode when 1) AP is engaged, 2) a GPS flight plan leg is active and 3) the GPSS button is in GPSS mode. With these three items, the aircraft has always tracked the GPS flight plans for me. Not seeing the entirety of your cockpit and settings, I couldn't comment exactly what you were seeing. -tkyler

Hi Medway, I have noticed that too. I expect to see tkyler at FS Expo 2023 this year and I'll hound him about fixing that! Its been driving me nuts too. -tkyler

I assume you're referring to the hardware settings? I don't have any recommendations, its a bit subjective and differing folks like to adjust those for their feel and hardware. I myself prefer everything nice and linear, but that's just me. -tkyler

The "XP12 ported" version will not have this for the initial release. Its exactly that....ported for V12 'as it was in V11' but with the aforementioned extras, i.e. new 3D cabin/doors, wing flex and replacment GUI...but nothing else yet. Because we're putting in a few new items though.....I do think many folks might then wonder what else may be new for this XP12 compatible version and perceive it as a "next patch", but that is not the case yet, its been an enormous amount of work simply getting it to ported to work in XP12 reasonably well. After the initial release, then we'll start the 'patching process' to improve things in many areas. ...and we're looking forward to doing so. So if you want this feature in the initial 'XP12 compatibility' upgrade Bulva, then you should be worried......but if you're willing to wait a bit, then there is nothing to worry about -tk

probably easier to synthesize as its most likely "electromagnetic interference" signal noise in the audio. Doesn't mean its not cool though. Can't say I ever heard anything like that in all the flights in the Moo I had. -tk

its definitnely loud. The motor sits right under the cockpit floor practically and turns the floor into a bit of an soundboard style amplifier. About 18 secs in, you can hear that oscillating motor sound. -tk

I'm sorry Owen, that does not tell me anything useful. I don't know if you tried it with the mouse or are just telling me what you told me in the first post. Can you take a screen recording of your problem possibly? This information is contained in the documentation under 'GPSS Operation' http://togasim.com/mu2docs/supplements/spz500.html -tkyler

Not very likely pm_pilot. "CDI mode" is only an indicating mode and has no input as to the flight path. I couldn't say what might have caused the path you observed without seeing all the autopilot settings and also the flight plan in the GPS. -tk

I'm unsure as of this very instant. There are some unknowns I need to get more info on, but am currently focused on the dev work atm so I haven't thought about it terribly much. Certainly we'll be working towards that native support asap and I expect I'll probably turn my attention to that in about a week or so as part of our final punchlist and QA work before deployment. -tkyler

We'll need to approach this systematically. First test...disconnect all your hardware, no joysticks at all attached to your computer. Then try and start the Moo using the mouse on manipulators only...does that work? if not, what specifically is not working (i.e. the engines spool up, but don't ignite...RPMs never increase....etc...stuff like that). Then we can proceed to some systematic checks of your hardware config. -tkyler

Thx Saso...I saw it in the dataref list and set it to 1, but it was immediately set back to zero so I didn't realize if it worked or not...I wasn't paying attention to the lighting..just 'poking around'. Certainly if its beneficial during the act of changing a lighting setting, then we'll put it in asap. -tk

I have no idea what that is or what it does It doesn't seem to be a dataref I can change...or I can't seem to change it with DRE rather. is there a discussion somewhere on this dataref, what its for and why its desired to mess with? -tk

Well without a doubt the condition levers play into the fuel flow so a hardware setup could come into play depending on its configuration...the condition lever ratio nees to be about 0.4 or higher for engines start. Not so much the propeller on the locks or unfeather, that really doesn't play into the 'ignition' process. One thing you could try is simply to unplug all hardware and use the keyboard and mouse to move all the levers and see if it starts normally that way....at the least it may be an additional data point. -tk

thx for the report. It seems I myself have come across this is the past, though have trouble repeating it...and in addition, have not seen this for quite some time....so I'm going to start by saying I don't think its "Just you".....but follow that on with "I'm not sure what causes it" either. Historically, its been really rare for me...only once or twice in hundreds and hundreds of starts during development. You mentioned start up then shutdown....and IIRC (cause its been a while since it happened)....it seems it was associated with engine shutdown and restart. This could be a Laminar bug. The key is to find a repeatable procedure that results in the same outcome every single time and I haven't been able to do that yet....but I will look at this again and try and repeat it. When it would happen.....and the reason I say it may be a Laminar bug....is all the datarefs I was monitoring indicated the engine SHOULD have been running...was receiving fuel, was ignited, etc, but it just wouldn't accelerate. If you can find an operational sequence where it happens every single time, I'd love to know and try and repeat it and take a look at it. -tkyler

Truth be told Bulva, I don't have a VR setup (used to, but not for a while)....BUT....will be getting a new one shortly, so yes, I do expect this aspect to be improved. I develop on a Mac and swapping back/forth to my Windows box is a bit of a pain atm, but I'm getting a KVM switch to make things more painless and this should make things much more palatable for developing for VR. -tk

N279MA Livery for MU2, Version 2.0 by TOGA Simulations View File This folder name is prefixed with an integer. It is not required, feel free to change the name; however, beginning with Version 2.2 of the MU2 (not out as of this posting), I (TOGA simulation) will be utilizing a system whereby you can name a livery folder with an integer prefix number, and in a text file, you will be able to associate a tail number with that folder prefix integer. In this way, the tail number in X-Plane an online networks will match the livery tail number. -tkyler Submitter tkyler Submitted 05/30/2023 Category General Aviation Livery For https://www.x-aviation.com/catalog/product_info.php/toga-simulations-marquise-p-226  

noted and logged. not sure how that one got past me, but it did!.... Thx for reporting. -tk

man, that's pretty cool! I'll get to performance at some point and will revisit this for sure (with your permission) -tkyler

Presumably on the MU2? This is an oversight on my part and fixed for the next MU2 patch (for those concerned) -tkyler

Just a rambling blurb here..... The MU2 for X-Plane has been out a long time and I've answered a lot of support questions over the years... and without a doubt, many folks aren't aware of Garrett's/Honeywell's TPE (Turbo Prop Engine) fixed-shaft type of turboprop and its operation and are only familiar with the 'PT6 paradigm'. In many cases, this has resulted in such customers frustration with the product....initially....however, once you get all the controls set up properly, and understand the operation and get a few flights under your belt, that tends to go away and I've seen these same customers really grow to like the MU-2. One document refers to it as "a pilots turboprop"...that is simpler operation, fewer controls, instant thrust, etc" and I am in agreement with that assessment. My earliest memory of a MU-2 was when I was about 8 and one took off from my local airport....and I'd seen a lot of airplanes takeoff, my dad and I were "watchers"...but that MU2 was noticeably faster on climbout....really fast...compared to other turboprops and I've loved it ever since. Its not the kind of flight sim product that sells like an airliner, but I'll probably never stop tweaking on this one, it really is my "personal X-Plane project". -tk