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

I'm a bit confused, you said "during the flight", but also, "on the ground"? trying to understand exactly the sequence of events here. Did the instruments freeze "during the flight" and then you landed "on the ground"? Did this happen with two successive flights? every single flight? The first two things that come to mind are a potential conflict from another plugin...and the 2nd would be an "initialization" issue with regards to setup of hardware, Some folks buy the MU2, load it up, configure the hardware and try a flight immediately without reloading the aircraft and this can cause initialization issues for that first flight. The 'symptoms' indicate that MU2 code isn't running, the question is why. -tk

it is. see MU2 docs, section titled "Prop Locks" http://togasim.com/mu2docs/systems_descriptions/engine_prop/engine_prop.html specifically.... Definitely takes a bit of getting used to compared to other 'free turbine' engine types, but quite natural once you're comfortable with it. -tk

it is NOT as expected, it also should be backlit. on my list for next patch.. Thank you. -tk

I'm not sure what is going on...there should be no mixture assignments anywhere in your setup and it should work fine. Note that some cockpit switches set the mixture "per event" in some cases, that is when the switch is actuated, rather than 'polling' the switch position every flight loop. This is a coding choice on my part. So if you set your mixture assignment to NONE, but your joystick had set it to zero before hand...and you did not actuate any other switches or reload the aircraft, and simply tried to start it, it wouldn't start in these cases. I make the assumption that any hardware axis is never assigned to mixture, which is the logic behind my suggestion to ensure no axis is assigned to mixture, then reload the aircraft and try again. -tk

Thanks for the kind words Manolo, I'll keep working to improve it, I can still think of lots of cool things to do. It will probably always be a work in progress. Thanks all for the Xchecklist work..I haven't used it before, but will have to check it out, it looks quite handy. -tk

The quick answer, don't set any hardware to mixture, only NONE (more below)....and save the Moo joystick config so you don't have to reassign every time. You of course mentioned you set it to NONE, but the engines did not start....in this case, I suspect some other input is not set (fuel valve or condition lever position, RCS switches to RUN, etc.) or perhaps some funky initialization situation if you were trying all these changes in a narrow span of time during the same "flight session". I would ensure no hardware is set to Mixture, and then double-check any other lever assignments against the setup docs, and just for good measure, reload the aircraft (best using the 'developer' menu)... and retry the engine start per the checklist. The term "mixture" is generally associated with piston engines and not typically used with regards to turbines, which are controlled through FADECs or other fuel controllers for which the pilot has no input to control "the mixture"; however, in X-Plane, the "Mixture" dataref does indeed control the fuel to the engine......any engine.... piston, turbine, jet. Its one of the oldest and earliest X-Plane dataref variables and when that sucker is 0, engines are not going to start/run. As such, I manipulate this variable several differing ways to simulate no fuel to the engine, i.e via the fuel valve, the condition lever position, or whatever else can keep fuel from reaching the engine. So any hardware that is assigned to the mixture will be "fighting" with my own code and cause issues. -tkyler

C-FHMA 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/27/2023 Category General Aviation Livery For https://www.x-aviation.com/catalog/product_info.php/toga-simulations-marquise-p-226