tkyler

I'll look into the RXP control commands a bit more in depth. -tk

EGT model definintely needs work, especially because of SRL, which X-Plane does not simulate.....so yes, the EGT modeling is outside of X-Plane. I've received some excellent data from a MU-2 pilot though and plan to incorporate that during my next MU2 binge session. Now all that being said, I haven't seen the EGT go to 700 except during the engine start sequence, which its supposed to. After the start sequence, I see about 500 with the condition levers in taxi...probably a bit high...most -10 engines run a bit over 400 at idle, but certainly not 700. -tkyler

certainly possible and certainly on my todo list to see about getting all that in. Not too much longer and I'll be back binging the MU2 for a bit. -tkyler

The MU2 is "waiting in the wings" at the moment, while I work on the IXEG V12 process. The MU2 works tolerably well enough in XP12, whereas the IXEG does not work enough in 12 to even fly it....so I need to get those customers taken care of and I'm working towards that atm. As soon as the 733 goes out the door (more than a week, less than a month), I'll go back to the MU2 and make another series of passes to leverage the V12 features and start improving the performance model. It won't get left out in the cold. -tkyler

The liveries for V1 won't work on V2. The UV unwrap for the V2 is pretty challenging and not many have accepted the challenge It is on my 'todo' to just sit down and crank out some liveries at some point...so in due course, I'll do more liveries..but may be a few months. I tend to work "in binges", moving between the IXEG and MU2. More liveries will make it out at some point though. -tkyler

When the condition lever is in emergency stop, it opens what is called the "feather valve", which drains all oil from the prop governor, forcing it to feather. Unfeathering requires oil pressure. Its like trying to fill up a sink with water but with no plug in the drain. All the oil gets pumped into the governor and right back out again through the open feather valve. Moving the condition lever out of emer stop and forward of the taxi position closes the valve (puts a plug in the drain) and allows pressure to build in the prop governor when the engine is running or unfeather button is pressed (with electrical power of course) -tkyler

Those are "lever locks", which keeps the handles from moving on their own due to vibration (in the real thing). If you move them forward to lock the levers in place in sim, you'll find you won't be able to move the levers. I've written some preliminary code (currently commented out) to retard the levers ever so slightly based on vibration/turbulence.....but the real conditions that cause levers to move are a bit more varied based on differing aircaft models and maintenance, tensions etc....so I haven't decided just how I'll go about implementing "lever movement due to vibration/turbulence"...but I will at some point and will document it. At the least I need to document those handles in an orientation capacity. Thx for the feedback. -tkyler

Never seen that one...anything that shows up on the GTN display itself is provided by the GTN plugin and not though me. I just give it a 'window' to draw on and pass the button presses onto the GTN plugin. Might have to query RXP on this one. Can you provide a screenshot with the message on it? -tk

Before the engine starts, you check visually (pilots lean over and look out the window)....and make sure the blades are "flat". (rather than feathered) After engine start...the real MU-2 POH says that if you move the power levers forward past flight idle and you do not see an increase in torque or fuel flow, then the props are on the locks. In this case... its basically like finding out your car is in neutral when you give it gas and it doesn't go . -tkyler

FYI.....still full time on it. still on schedule...still have our same 'target date' not too far on the horizon. Again, more than a few weeks, but less than several months ( minus the weeks since last report) . TK

Thanks John! I'll have an update soon...juggling another project at the moment for a few more weeks, but still happy to be full time on XP and will be chipping back on the Moo again quite soon! Tom

Thx @OneOffRegistrationUser (love the name...don't like typing it) ....for others.... these types of changes will be in for the XP12 update; however, what OneOffRegistrationUser has provided are effective patches for those interested in making the manual tweaks until the update comes out. I'm currently making a hard run at the IXEG, but the MU2 is hard on its heels and nagging and will get more love relatively quickly....thanks again to OneOffRegistration user for providing some stop-gap options until then. -tkyler

Thank you for the kind words Ian. We are certainly excited to be working on the IXEG again. On the one hand, the initial port to XP 12 is a bit more labor intensive than anticipated...but on the other hand...getting everything ported to modern workflows and features is ceratinly a welcome change on our end, ensuring less development pain once we get this initial infrastructure change done. -TomK

@OneOffRegistrationUser Thanks for those. (got a nickname? :P) So a more comprehensive GUI/interactivity is in the planning for the Moo. I had to learn enough imGUI to get basic Moo prefs in, but couldn't spend a whole lot of time on the GUI design as it can be its own monster. For the IXEG, I'm having to get a bit deeper into imGUI as we're dumping the old, custom GUI.....and as I do, my comfort zone with it evolves. My thought is that once the IXEG is ported and more feature complete...I'll turn my interest into GUI development for just these kinds of things. In the meantime, I really appreciate your efforts and contribution! TomK

We've learned better than to give dates; however, we have a very well defined 'todo' checklist and are working towards this every day, full time, whereas in the past that was not the case. As such, it'll be more than a few weeks, but less than several months, there is a LOT of stuff to test. We customized a whole lot of things that have to be audited, assessed and in many cases, 'removed and patched over'. We are very committed to this guy though and definitely have improvements coming not too far down the road.

Thx for posting. I'll catalog these and check them out soon! -tkyler

well definitely to improve it where it needs it ...Regarding the 750Txi, that's more on Garmin probably as RealityXP just 'ports' their simulator. As far as other plans...David has kindly offered to provide some performance data, which I'll seek to incorporate into the Moo. I see my imminent Moo 'todos' (things I'm unhappy with) to be...in no particular order or priority: Flight model improvements (chasing numbers), EGT, Fuel Flow, SRL behavior, performance, etc....more liveries, and the first 2-3 seconds of the engine starting sounds (gear whine). To me, those are the basics at least. Not quite sure what I'll look at after that just yet. As far as timing, I am indeed full time on X-Plane...but the holidays and IXEG work have taken precedence while Laminar has gotten XP12 stabilized. I'll tend to rotate every few weeks between projects and 'binge' the work and the IXEG is getting the binge treatment atm; however, the Moo's turn is coming back around quite soon....and I have a 3rd project in the works also that gets chipped on 'nights and weekends'....but won't take on any more than 3. Better to have a few quality pieces that I can maintain for years than get all strewn out with new models. -TomK

For the most part I myself have too. The lighting even looks pretty good...but there are some areas that need touch-up due to X-Plane's new lighting system...but I'll admit even for stickler like myself, they're minor. My real "todo" before declaring this 'XP12 compatible' is the flight testing, i.e. dynamics, trim and AP behavior. It MAY be that those are all "in line" with the XP11 version and after verifying such, I'll just declare this 'XP12 compatible'. Of course XP12 'compatible' doesn't mean 'optimal'. I still want to get back to 'chasing the numbers' with regards to EGT/ SRL/FF/performance, etc. I encountered this myself just yesterday the first time and put it on my bug list; however, I have not been able to repeat it yet. I've started / shutdown / restarted the engines several times now with no issues, BUT....it did happen ......... I just don't know the circumstances or sequence causing it yet. Can you not start it under any circumstances ever? A fresh load of the aircraft for example? -tkyler

Looks like you're right that I accidentally broke this. Its always the first thing I put in (mouse operations); however, with the number of people using the bravo hardware, I really reworked all the "lift lever" commands and ended up adding 'joystick criteria to the lift commands'. Really sorry about this and putting in a fix (new command) for the next update. With XP12 final, I'm going through and tweaking the lights and some basic flight testing and will include this in the next path. Sorry about that and thx for reporting. -tkyler

Thx for the report. Can't say I've noticed it, but then again, haven't been looking for it. I've noted it for examination. This may be a Laminar issue...as they are fiddling with the rendering settings quite a bit and camera views involving the prop have, in the past, presented some challenges. -tkyler

So after a bit more research...the Autopilot maintenance manual does NOT mention the 20nm restriction, only the official "pilot manual" for the autopilot. I find it possible that the pilot manual may be erroneous (or ambiguous as to other criteria not elucidated) and more inclined to follow the maintenance manual wording. As such, I'll remove the 20nm restriction in the next update....unless I discover a reason otherwise...or some other operating mode where the 20nm limit has applicability. -tkyler

OK, I found it. its from the SPZ-500 operating manual of all places. (I was looking in the MU-2 manual supplement previously). So yea, you need to be more than 20nm from the station for NAV mode to engage. (See excerpt from Sperry docs below) This is documented in my MU-2 docs on autopilot usage. http://togasim.com/mu2docs/supplements/spz500.html#fd-mode-control-panel-mcp

For some reason I cannot remember, nor find in the Sperry AP docs, I have prevented NAV capture within 20nm of the station. I cannot, for the life of me, remember why I might have done this. I will look over the docs again. -tkyler

that was poorly worded, sorry. "I have already put it in place in my development work, so as to be part of a future update for V12" It is not in place in the currently available version. With X-Plane's RC4, released today, I think X-Plane is in a good place to resume Moo tweaks. I'll probably release updates in two stages. 1) Visual changes, i.e. the rain effects and tweaked lighting...which just looks nicer. 2) Flight model refinement. I separate out the flight model refinement because it performs reasonably well in XP12 and most users, (me included) enjoy the more visual and sensory aspects of simming rather than 'by the numbers', i.e "we put in gas....we fly....make sure no needled go red, and enjoy the ride" Chasing numbers always involves more in depth tweaks, longer testing period, and frustrations fighting X-Plane's default models and I don't want to withold some of the cooler XP12 visual features while flight testing/refinement takes place. -tkyler

Its already in place. you can see it in THIS VIDEO. (if the link is working...seems to be down atm)....anyhow, the effect is a bit exaggerated for testing purposes. I may put in a preference that lets you set how "much" rain you want on the windshield...its pretty subjective on how much rain one expect to see on the glass for a given level of rain. -tkyler