tkyler

You are correct that the command is NOT in the list of custom commands on the docs. sorry I missed that, I will get that fixed promptly. The command is: xscenery/mu2b60/manips/ap_button and that command will also turn on the Yaw damper at the same time. Here's a few others on that AP panel also: xscenery/mu2b60/manips/ap_yaw_button xscenery/mu2b60/manips/ap_soft_ride_button Seems I have several "manipulator interface commands" not present. I generate that list automatically via a script as there are so many commands in my code and my parsing script missed a bunch of these "manipulator" commands. Perhaps its time for a dedicated manual perusal of that list. Thx again for pointing this out. -TK

I actually did adjust the screens a bit for the update. Here's the GTN 650 and 750 UV mapping for 2.0.4. it all looked to fit in the bezel. The 650 header wasn't "cut off"...it was obscured by the Avitab black screen...with that fix, the 650 screen is fully visible now. That being said, I still did adjust the UV Mapping a bit to make it cleaner. -TK

Avitab / GTN screen conflict fixed. GTN "save config" preference fixed. Map light fixed. Checking a few more things, but I expect to get a 2.0.4 update out asap. TK

Thx. will look at that cabin VVI needle business; however, I have zero custom particle effects applied.,,,so that is default X-Plane particles. I will be doing my own particle effects soon enough though and hopefully we wont' see this kind of trouble. -TK

Thanks for reporting, that's still good info to know. I didn't expect something like that, so I'll look into this specifically. Thx Again. -TK

A total mismapping of the cockpit texture on my part....indeed a simple fix, but will need a new 'export' on my end. I'll get a fix out right quick. Sorry about that.....lot of options this guy. -TK

It does not....though the changes implemented in 2.0.3 will carry forward into the XP12 version yet to be released. I'm actively working the port to XP12 though and there will be a dedicated announcement when its ready. -TK

FYI, X-Aviation is located in Florida, USA and a hurricane is bearing down on them....MU-2 2.0.3 patch may be delayed as they prep and rush to evacuate. TK

This is by design. HDG isn't one of those modes that couples to any 1/2 configuration, so they're sync'd. As far as the copilot knob not being able adjust the HDG, that too was simply a design choice to avoid possible confusion that the pilot/copilot HDG adjustments were indendent of one another, but simple enough to implement...certainly for any shared cockpit functionality it would be necessary. Also, I'll peek at the copilot HSI course indicator / CDI issue. TK

The solution here the Marquise employed is the TCS mode (Touch Control Steering). This is documented for the 2.0.3 update which should go out soon...its in X-Aviation's hands, but they're also working through multiple product transitions to V12, so it should hit soon enough. The TCS is an effective way to alter IAS and VS values without having to look down or change/disable AP modes...and once you get used to it, dare I say somewhat preferred (by me anyhow) over a knob based solution...you can keep your eye on the instruments at all times while holding down the TCS button and changing the VS or IAS values. -TK

was a bug on my end Bulva. I tested for the "nav type" and accounted for VOR and ILS (LOC + GS), but "LOC" is its own separate "enumeration" in X-Plane when GS not present...in the XP radio ...and I simply forgot to add that to the list of navaids to test when the NAV is pressed. working for the 2.0.3 patch which I'm packaging up for X-A distro, pending their schedule...but at the least I plan to send it their way later today. TK

...and for updating the 'last working XP11 version to similar behavior in XP12?....neither will we....we've said it many times and this is not in debate. It is a bit more of a process because XP12 has changed quite a bit with regards to engine and systems, which means we have to audit everything and surgicaly remove code that clashes with XP12 functionality...and we put in a LOT of customization. As far as a discussion of charging a fee relative to "when its finished"., too subjective......I have enough statistical evidence that says to me that a lot of folks have really enjoyed the 737 for a lot longer than the price of a 2 hour anniversary dinner...(for newlyweds anyhow). To those who would argue about 'unsimulated things', all I'm going to say is Pffff. I've been a software 'consumer' for over 40 years, and not casually, I make my living from using software, 100s of titles over the years....and this stuff is always evolving, always changing...LOTS of software is missing things. I use what I can, enjoy the good parts, don't buy what I don't like and everybody has the same choice here...we're not hiding anything. I could easily argue that a lot of products lack "immersion", realistic lighting....or decent sounds. The flight sim dev community isn't like it was. Its more saturated, the bar is higher and the detail we have to put in is a heck of a lot more than PMDG had to in its early days when it had a monopoly on the airliner market. So what would we charge for? ...I can't say, but its true we have no incentive to keep on working for free in perpetuity. Have you noticed how everything is moving to the subscription model? There's a reason for that...and guess what, I have at least 8 software subscriptions...every month/quarter....how would you guys like that? (hint, you wouldn't). If we charge for any update, its fair to say that it would have to justify the deliverable for a majority of customers (cause it'll never be all). Probably....thinking off the top of my head...., includes more variants, the FMS more complete, animated everything, more robust failure interactions, etc...stuff like that. AND it wouldn't be a full price upgrade either, I never like that idea. So...feel free to discuss as much as you like, but I just wanted to throw out some of my thoughts for folks who haven't gotten to know me over the years through other posts. TK

quick update. Last week was a wash for the Moo XP12 conversion....the AP docs taking a bit longer than anticipated (but 95% done) ....and a few "transition obligations" were called in last week by companies I severed ties with but pledged "transition help" to not leave those groups hanging....including Laminar. I fully expect to have the next 2.0.3 patch out in 2-3 days with the GTN option for the windows guys...and will roll right into the MU2 12 update. -TK

...and today also.....almost done TK

I'll dig into this pretty quick Bulva. Working on the AP docs today so this is good timing. I put it on the todo list so I don't forget. Was dealing with some family stuff last few days. -TK

Thx Pils, that's a good list, will definitely give those procedures a try..

Hello all. Those who have followed know that the IXEG 737 develoment has been stagnant for a long time while I've worked on my MU-2 project and stabilize it after the release. That stabilization phase is nearly done. XP12 is imminent and I'll be porting the MU2 to XP12 beginning next week...and it should not be terribly long (I hope). After that, the 733 will move back into rotation as the primary focus of development with the port to v12 being the first priority. The IXEG is minimally operable in V12, but that's all we can say. We obviously had to make it baseline flyable in order to test/develop it with all the XP12 changes, which have yet to be addressed. As such, our official position for those who wish to try the V11 IXEG in V12 is "VFR joyriding only". I expect we'll set up a 'volunteer forum' where folks can give feedback as to their V12 observations as its better to have more eyes on this stuff; however, we request that nobody report any shortcomings of the V11 733 in V12. We are keenly aware of a lot of things that have to be changed....so we'll want to wait until we believe we've caught all we can find before other folks chime in; otherwise we'll end up with a massive stack of the same reports. So, certainly keep XP11 around if you wish to fly the IXEG seriously until we get it ported over. I've always kept "old version / new versions" side by side on my computer for these transitions. Long-time XP users know that after a major release to X-Plane, there is an inevitable debug period that goes on for some time, though many other devs have begun already, we're behind. ....but nice to have the process underway.....Below screenshot shows what the cockpit looks like in V12 daytime. -TomK

I have not officially begun to test / port the MU-2 to X-Plane 12; HOWEVER, I have been testing it regularly in X-Plane 12 and the good news is that it seems at first glance....to be mostly functional....FOR.....daytime flight. I say this because the biggest change in X-Plane 12 is the new atmospheric and lighting engine..and this requires new "directive commands" for lighting that were not present in X-Plane 11. The nightlighting is practically non-existent until I make the required changes. Also I have to make some notable changes to take advantage of the rain effects....so the V11 version "in V12" will not have the new windshield effects. So....daytime and dry seems to be mostly OK using the V11 version in V12. I know there are some turbine engine changes also I have yet to test...so unsure what their effect will be. The plan is to get the next release patch, 2.0.3 out for V11 (relatively imminent), and then begin the official port / testing process for V12. Probably will begin the work next Monday. I do not expect it to be terribly long. Chances are XP12 will go through some growing pains anyhow and I'll be right there alongside the process testing/tweaking the Moo. Experienced XP users should know to keep their XP11 versions around until they're fully happy with V12. Here's a few screenshots of the Moo in V12. Not terribly bad, but I may tweak it after I get going. Things tend to look a little bit shinier in V12...but also brighter, which is good.

.....not necessarily. See text clipping below from a MU2/TPE training manual . The taxi speed is more accurate now than it was in the previous versions, I won't be altering it. Its VERY common to move the levers out of BETA and above flight idle to get your speed going or you are an impatient "taxi-er". We did it all the time in cargo ops...with a fully loaded plane, we could barely move in BETA unless we got up a good head of steam first. The guy in the video below goes above FI and back into BETA @ 3:50, 4:30, 4:58...and I've seen other video demonstrating the same behavior...heck I myself with my own hands on the throttles of a real MU-2 have done it. Go ahead and work those levers! -TK

Hang in there...fixes are closed for the next release, but the docs are taking a bit. I'm writing docs on not only the GTN integration setup, but also a more indepth "SPZ-500 autopilot supplement" for newer folks...which I think is needed given this older autopilot integrated with new GPS units, etc. Soon as the docs are done, we'll package up the next update. -TK

I tried a route today and it flew the GPSS fine actually; however, the route shown on the GTNs isn't fully reflected on the RSG500 display. The RSG500 only shows the current active leg, which is to say a straight magenta line. On the GTN, as you turn as pass/clear a waypoint, then the next leg magenta segment appears on the RSG500 and the previous one goes away. I suspect this may be some kind of limitation with regards to getting flight plan data out of the Garmin trainer. I did take screenshots with the intention of putting this info in the docs. That being said, the current leg is always shown on the RSG500 and of couse the full route is shown on the GTN. -TK

I changed my mind after some testing. Whenever a GTN unit is loaded, the GTX330 is now gone. There was some "infighting" between my GTX code and the GTNs...as my GTX implemenation has customization ..and the GTNs utilize the Garmin "simulator" handling of the transponder..and things just were not being consistent with both loaded. So now, you simply control the transponder via the GTN units as you would in reality. The audio panel however...stays up top. On a side note, just need to get the docs updated for the autopilot usage and GTN integration steps and we'll get the next update out. -TK

So finally got this figured out. Originally, I could find no indication or documentation of when the SBY button should be illuminated or extinguished with no other modes active....mostly how do you extinguish the thing at all....so in the interim I tied it to the Flight director..which is of course ON when the other modes are active, which is why the SBY light shows with other modes active (clearly wrong). But the question remained about what powers the thing? i.e. can the SBY light ever be off during normal ops? So it turns out, being part of the SPZ-500 system, it initially illuminates whenever the Radio busses are powered, so its always READY to accept a flight director mode entry. Naturally then, it extinguishes only when the radio busses are powered off or other modes are active. This can be seen in the above video at 8:11 and 8:29, where during rollout, its clearly on (but the AP servos are not)....and when he pulls in to park, its off...but so is the GPS, indicating he flipped off the radio master switches. So during nominal operation, the SBY will always be lit when no other FD mode is active. This will be implemented in the next update patch. -TK

So turns out that these are "options" as part of the Sperry SPZ-500 system...and being an older system, not a lot of the inputs were integrated into small form factor interfaces.... and subsequently, not all of these options were adopted by the manufacturers. Who knows what drove the decisions...weight...panel space, etc. Below is the 'controller' that would allow you to dial in the IAS or VS for the SPZ-500 system....but this option was not installed by Mitsubishi. Because you can simply adjust the pitch wheel to dial in VS or IAS and then "lock that in" via the mode buttons may have been considered enough. Who knows. -TK