Leaderboard

Hello all. I will endeavor to support and address issues on the MU-2 as rapidly as practical. The period after a release is always fraught with bugs and challenges, frustration and impatience. I have been there myself and please ask for your patience. I'd like to think that those who know me know I'll continue to support this product for many years to come and provide you a great value for your money! I am located in the GMT-6 timezone and work reasonably normal daylight hours. I generally don't work Sundays (though may converse on Sundays).

Thank you Tom for bringing us this awesome new version of the Marquise. I'm toying around with it now for a couple of hours, and I simply love it. Had to leave this statement here so you don't think I'm just poking for bugs

Two things I've noticed right off the bat, 1. Toe brakes using default toe brake controls with saitek pedals don't really seem to hold at all. They will grab but not hold after the plane stops. 2. Default flaps axis assignment on a saitek throttle quadrant doesn't move the flaps. Any note on this? Fantastic airplane so far, only played with it for about an hour now but it sounds and flys (and looks!) amazing! Thank you!

No...this is definitely a bug on my end. ...verified. Glad you have the parking brake in the meantime till we get this updated! This is what I get for applying toe brakes during testing.....seeing the brake value go up and down and then walking away and going "ah, it works"...because I still have 1000 more things to test that day Great catch and definitely on the bug list. Thx for reporting. -TomK

No worries daemotron....and glad you're enjoying it. Getting my bug management system and features/TODO system going. Right back at it! -TomK

Better don't copy folders manually; there's an installer for the G500. Just follow the instructions provided in the manual

glad to see the white livery came in use quick. I figured it might be easier for some just to have that quick blank canvas. Thanks again Ither. Have to retire for the evening, but of course will be up soon enough looking to get right back to work. -TomK

I think I'm customer #1

I'm having this problem as well. Changing the throttle assignment to only one axis worked for me too.

I've been corrected somewhat on the whole ARM librain thing; however, I do recall looking into this earlier and there being some kind of issue that caused me to cease for some reason I can't recall now... I may look into this again, but because the effect will be default in XP12, and in my long experience in X-Plane....new versions tend to leave old in the dust relatively quick, I can't say exactly when I might look at this again for V11. Its in the back of my mind just the same.

Put on the short list Marco. Thx.

As the title says, when retracted, the MLG wheels clip through the fairings and the MLG doors (detected on 5 blade GLASS version):

Man....I fooled everybody on version 1.x so I wouldn't have to model that complex front gear door!

OK....shame on me for not thinking this one through. Each of those switches (left/right) don't do anything by themselves of course...so the only reason I included the command/animation was so that users could move them individually when inevitably poking around the cockpit, since I want to make all the controls actuable. But I didn't bother to think folks might actually have hardware that have two trim switches and need to move them both. Guess I need deeper pockets for fancier hardware.....wife is gonna love that! I'll defintely make a pass at mapping the trim functionality to the broader range of trim commands by XP and also my custom ones above.

danke, fixed for update!

DOH...too many variants! Thx daemotron! "On the list" though if any are so bold, a little photoshop work on ....VAR_Cockpits_ALB.png.... (paint/clone over the text on the G600 panel variant towards the lower left of the texture) should fix it. XA installer update will overwrite the file of course, but it'll be fixed on the next update anyhow. Fix at your own risk until patch -Tom

I did look into this; however, I have a Apple Mac M1 with ARM architecture and librain isn't built for this processor and I'm not equipped to do so unfortunately. X-Plane 12 will include the effect by default so most folks are looking towards V12 as the future of this kind of thing......though I know this doesn't help on V11, sorry. I don't have plans to integrate it into V11 unless librain magically falls into my lap, compiled for my processor.

maybe someone stole it? JK...on the list. thx daemotron...you're a great asset to improving the Moo! -TomK

The data ref sim/cockpit2/controls/parking_brake_ratio is used by FSEconomy (and probably other VA / ACARS clients) to determine whether a flight can be reported. Unfortunately, the MU-2's plugin seems to overwrite the data ref with every cycle, making it's value oscillate heavily between 0 and 1 (cf. video below): Also setting / releasing the parking brake seems to have no impact on the status of this data ref. To provide better compatibility with FSE and probably other flight tracking plugins, it would be nice to have this data ref reflecting the state of the MU's parking brake. Current behavior: after initialization of the aircraft, the data ref oscillates between 0 and 1 actuating the parking brake doesn't change it after tapping the wheel brakes with the parking brake released, the data ref stops oscillating and reads 0 while the parking brake lever moves, the data ref increases / decreases correctly with the parking brake set, the oscillation starts again with the parking brake released, the oscillation stops and the data ref reads 0 Behavior I hope for: data ref reads 1 if parking brake is set, and 0 if not set data ref increases / decreases while parking brake lever is in transition

Quick update: I found the root cause - it only happens when the chocks are deployed. As soon as the chocks are removed, there's no issue with the data ref. Since flight reporting in FSE usually happens before chocks are applied, this is a non-issue and can be ignored.

No problem - this plane is well worth a bit of effort helping to test and identify any issues

Have you looked in the documentation directory?

PDF Export is planned for sure, but I'm still evaluating multiple options. Some exporters did not quite work as advertised. That being said, the docs are avail as a downloadable zip file at the link below. NOTE that this download is NOT a PDF however, but simply a folder and you open the "index.html" file (in screenshow below) in your browser and you can use them offline, but still in a browser. Again, the PDF will make its way in at some point. As the docs mature, the PDF/zip file link will make its way on to the docs site. http://www.togasim.com/mu2_docs_offline.zip -TomK

The documentation is still Work in Progress

Noted on this, added to bug list. Thank you. Regarding the click zone, This is indeed a tough philosophical discussion. I'm on the fence about hiding the manips when hardware is present. I've heard arguments both for/against. I think this will evolve into an "options" where you can choose your preference but doing so requires a bit of coding infrastructure on my end....so hopefully we'll get everyone accomodated soon. I am not terribly happy with the 'unfeather test' / condition lever situation myself...its a fight against X-Plane...I fought this more than I would have liked. The only reason I accepted it for now is its a small part of the overall experience, but I won't be happy till its perfect. -TomK

Note that it won't show over 2500' either. Reflected radar signals generally get too weak at that altitude and so the display blanks out. So on the ground and over 2500' blank....in between should show.

Uninstalling and reinstalling did not fix the issue. The radar alitmeter window is blank. On videos I have seen of this aircraft, when on the ground the readout should read "0", zero.

On the ground or in the air there is no reading on the radar altimeter. I just uninstalled the aircraft and reinstalled and will see if that helped.

Same issue regarding the toe brakes. zhe plane stops, then the brakes loose their grip and it accelerates again.

You should NOT move that folder! Use the installer as @daemotronhas suggested.

I hope somebody produces this beauty!

Not at all. There is just a lot of logistics with regards to deploying a release. Its a process and we have a checklist and are working through it. Release is always an exciting time...but also a time to wisely 'slow down' just a bit and make sure we dont' miss something. We don't want to take off with our fuel valve set to OFF. -Tom

Quick note: IRL the use of ATS during go-around is technically prohibited (AFM limitation). The expanded language states 'pilots must manually set thrust to override ATS. ATS may be used to trim final N1 once manually set. Advance thrust levers to the predetermined go around N1 setting (this target should have already been set to TO) while simultaneously pressing TOGA and ATS DISC. Note: ATS must be disengaged as thrust levers are advanced. If ATS is NOT disengaged and the pilot overrides the ATS as the levers are advanced, the ATS may advance to the forward stop - triggering an exceedance. Flight Spoilers (if extended) RETRACT Rotate smoothly at a speed not less than Vref towards command bars Set pitch attitude to achieve a speed not less than V2+10 as the flaps are retracted in next step to 20 Flaps 20 When climb is positive - Gear UP (there is a note that if a turn is required in MAP, delay this turn until gear is fully retracted) Retract flaps 'on schedule' (At a safe altitude not less than 400 AGL and speed not less than Vfto-5, flaps UP) Thrust Reversers OFF Continue normal climb procedures These are from the FCOM. This should be practiced and accomplished as a combined set of actions. You commit to the GA pressing TOGA, and then in a series of coordinated steps you press ATS DISC and advance the thrust levers as you're pitching up into command bars. You're verifying the spoilers are retracted and calling for Flaps 20. Things happen quick - you're going to see positive rate pretty fast and you'll ask for gear up. You'll be fine tuning your N1 manually to the TO thrust target. If you were flying green needles on the approach you'll also be asking for your Nav source to be switched back to the FMS (or doing it yourself - I have a button mapped for this) so you'll have the appropriate lateral mode available to fly the MAP. You'll then ask for (or select) NAV and VS. (If you prefer you can press sync to select PITCH, or select FLC but see note below) As you're climbing away you'll be asking for or selecting "AP engage" and setting the speed target to a procedurally appropriate speed - typically the same as a normal climb profile, 190-200 knots. At this point you can engage the ATS as part of the 'normal climb procedures step. Note, Selection of FLC mode during GA is prohibited unless the altitude pre-select is set higher than current altitude when ATS is engaged. This is small gotcha that can bite you on a GA if you don't sequence things correctly.

In today's progress report, we discuss the flight simulation experience from the perspective of the cockpit and how we approach trying to maximize immersion in our MU2 simulation. While undoubtedly one of the more enjoyable aspects of using a desktop flight simulator is having the ability to do things you cannot do in the real world, like get out of your plane and look at it from cool angles like you are a drone, or do a camera flyby at 5000 feet... it is the simulation of our experiences from the perspective of the cockpit that takes the highest priority for us. I think it fair to say that the goal of desktop flight simulation is to simulate reality, but those 4 syllables belie the complexity of just what constitutes reality. Remember the "...as real as it gets..." marketing slogan? Well if that was as real as it gets, why is flight simulation continuing to evolve and improve? Obviously it wasn't as real as it gets! So what was missing? The answer lies in noting that the perception of reality is comprised of many co-existing categories of fidelities with respect to how we sense the world. Some examples are: Geometric fidelity - how accurate is the 3D model Color fidelity - how accurate are the colors of the 3D Lighting fidelity - how accurate is the lighting model Aural fidelity - how accurate are sound dynamics Resolution fidelity - what is the depicted resolution compared to our eyes' abilities Dynamic fidelity - how accurate are dynamic events, movements, timings Tactile fidelity - how accurate is your physical interaction with the sim Cognitive fidelity - how close does your brain perceive the sim interaction as being realistic? With so many areas of fidelity for a developer to address, it is inevitable that some areas are addressed moreso than others, and in differing orders or priority. This is why one flight sim user (user A) might think a product is spectacular, while another (user B thinks that it is not. It is simply that user A and user B each have differing areas of fidelity that resonate with them as being important to their simulation experience. For many folks, a deficiency in one area, especially one that resonates with them as important, can ruin the whole experience for them. As to why user A/B have differing areas or interpretations that resonate with them as being important to simulation, who can say. Lets be thankful we're not all clones! It is also why constant improvements are available to be pursued and indeed should be. The first and foremost area to address by every developer is "what you see", that is the geometric and color fidelity...and X-Plane provides the lighting fidelity. This means, thanks to the powerful video cards we have today, that we can model more 3D detail into the geometry, rather than trying to fake it with textures. This is especially important for VR users and in conjunction with PBR rendering methods, results is more accurate lighting and depth, further contributing to the immersion. The screenshots below shows some implementations of the geometric and color fidelity in the MU2 cockpit. Knobs have raised ridges, edges are softened with bevels and roundovers, fasteners have recesses, etc. Such geometric detail is expected nowadays and the end result is a much more immersive experience in sim and in VR. Remaining with the "what you see" fidelity concept. The next area of focus is the dynamic behavior of cockpit elements, which is to say the animations. This area really resonates as important to me. If something looks realistic statically, but doesn't move realistic, then immersion can be lost significantly, but there are caveats in some cases. For example, X-Plane represents many things as "binary state", i.e. a switch position is represented by either a 0 or 1. When developers animate switches using such values, then the switch will just "snap" from one position to the other instantly, which isn't physically realistic. Conversely, if animated fully, then the switch animations can also be overly deliberate and slow looking, which can also seem unrealistic. If we look at an example of a simple 2-position toggle switch, you move the switch about half-way and then it snaps to its opposite position seemingly instantly. To our brains, the act of flipping a 2-position switch is almost autonomic and so to this day, there are many 2-position switch animations in aircraft that just snap between positions and we really don't give it a 2nd thought or view it as detrimental to our immersion in the simulation. This gives rise to the idea of "cognitive fidelity", in other words, what do most minds perceive as realistic behaviors? This is very subjective and as it turns out, we give this a fair amount of consideration in our animations and interactions in the MU2 cockpit. The fact is that our eyes and brains can perceive things quite a bit faster than 60 fps for some phenomenon, and less so for others. Space/time as it were. We pick up movement in our peripheral vision that we don't conciously think about, yet are alerted to if they are not quite 'normal' as our experience tells us they should be. Some things move quick enough that we don't pick up on the physical space they move through to get there, only the results (the 2-position switch). So how do we approach this and what does it all that mean for the MU2 cockpit experience? For animations, it most cases, it means we utilize a lot of physically based animation code to animate things they way they behave in reality. We don't use default X-Plane datarefs for anything when it comes to animations. The animation below shows what happens when powering the DC busses (inverter switch on too). Each instrument has some power on behavior, whether a self-test, or poweroff/poweron position. Some things move mechanically, others magnetically and each with their own unique behavior governed by their physical design. For example, the HSI and RMI compass cards are magnetically aligned/synchronized with a 'comparator synchro' behind it. When powered on, if the compass card isn't aligned with the comparator synchro, the card will very quickly "align magnetically" when energized, resulting in overshoot of the compass card, and some decaying vibrations before settling into stable alignment. Further, notice the comparator synchro is itself synchronizing with the magnetic heading from the flux compass, which happens at a fixed "synchronizing rate". On power on, this results in two dynamic behaviors in reality. 1) The compass card aligns with the comparator synchro magnetic field and 2) The comparator moves to align with the magnetic heading. While it is perfectly feasible to simulate a flight in the MU2 without all this animation behavior, doing so takes away from the immersion and that is the one thing we don't want. For those curious...the RMI / HSI cards can get misaligned whenever the plane is moved-around / rotated with power off. animations_1_opt.mp4 You may note previously I said we animate things physically correct in "most" cases. Why not all? Have you ever tried to flip a switch in X-Plane and you just couldn't grab the manipulator? or maybe you try to open some access panel and you can't drag in the correct direction and the panel won't open? Before long you realize you've taken 10 seconds to do something that in reality would have taken 1? This is an example of physical accuracy undermining cognitive fidelity in the simulation. In your mind, the action should be autonomic, in X-Plane it becomes a comedy show. I won't be too hard on X-Plane or developers here, because the mathematics of moving things "into and out of the plane of the screen" is ripe with challenges and difficulties. In select cases, we draw the line and depart from physical accuracy for the sake of cognitive fidelity. When I first developed the MU2 around 2006, I was getting perhaps 5 hours a week in the real thing for the better part of a year. When operating that aircraft, especially preflight, you're mind can get "in a zone" and things flow at a certain speed. I was finding that in X-Plane, this smooth flow of mental operation was impeded by the nuances of working with X-Plane's manipulators and camera view control in many cases and just did not capture the feel of operating the MU2 with the mental fluidity07 I felt in the real thing. I personally found that aligning certain interactions with the sim to 'cognitive fidelities' rather than 'dynamic fidelity' resulted in a more natural experience to me. In other words, the time it took to "effect something" was more important than simulating the physical movement to do something given the limitation of X-Plane "screen space". Without exception, our first efforts are to align the two paradigms and if we cannot get them to sync up, then we look at alternatives. We cannot escape the fact that we are trying to recreate a very 3D experience in quite a confining way and some departures from reality are acceptable. The good news is that most things are operated in both physically and cognitively natural ways with only minor departures. One practical example is that you cannot move the sun-visors all over the place. I'm not here to show off some XY manipulator wizardry. The real MU2 sunvisor is a ball/socket joint with quite an impressive range of motion that is limited by the limits of the cockpit. We don't do 'collision detection' of our sunvisors with the overhead...sorry! You click spot 1, it moves down, you click spot 2, it moves to the side window and vice-versa. I didn't think about, nor fight with it in the real thing and do not want to do so in the sim either! Again, the overriding goal is immersion and 95% of the time, pursuit of real, physical fidelities results in natural cognitive fidelity, but in cases where one interferes with the other, we depart from the real to cater to the cognitive, which to the philosophers out there, is the only one that matters. Enough with theory of game interactions. A quick word to wrap up on the cockpit variants all that gibberish above has been applied to. There are probably few, if any, MU2 Marquise's out there with original panels; however, it would be a slight injustice not to provide that variant...or to be completely honest, a variant of that variant. We may have mixed early and later model long-body features to better align with the practicalities and limitations of X-plane. So the old-school radio fans have their version. Next up is the GNS 430/530 GPS version. This simulates the most common upgrade to MU2s, and that is the addition of the 430/530 GPS units. A word of warning, upgraded GPS doesn't mean an upgraded autopilot! It is easy to forget that autopilots and that "magenta line" are not the same person. There is a bit of finagling to make things work, exactly as in the real thing. Its not unheard of for pilots to use the GPS to plan their flights and then simply adjust the HDG bug manually to keep the MU2 'around' the magenta line. Finally, for those glass junkies who purchase(d) the G500/600 product by RealSimGear, you get the GLASS version available to you for ultimate situational awareness and the gee-whiz, Captain-Kirk, lightshow. Next report, we'll talk a bit about the systems and engine simulation.