Jump to content

X-Scenery MU2 v2.0 Progress Report 3 (General Update)


Recommended Posts

Hello all!  Since last report, things have been moving very steadily towards release. Work completed includes night lighting, extensive systems programming, documenation and general GUI interactivity refinement.  Sound work is mid-process and the last thing remaining.

Night Lighting
The cabin and baggage areas lights can be actuated from the rear of the cabin, just aft of the door.  The cabin light can also be turned off from the cockpit.  This is so you can flip on the lights entering the cabin, and turn them off when you get to the cockpit. The baggage light; however, can only be turned off from the rear of the cabin.

night-1.jpg

night-2.jpg

As you move through the cabin, the reading lights are also implemented, as well as the cabin flood lights. Table settees and privacy doors are actuable of course.
 

cabin_floods.jpg

reading_light.jpg

 

The cockpit panel lighting is controlled via 6 rheostats on the overhead, and also, there is a cockpit flood and map light control, also on the overhead.  The yokes have map lights on their undersides as well.  These yoke map lights are controlled via rheostat sliders on the yoke.
 

cockpit_lit.jpg

 

Exterior Details
Outside the  aircraft, more detail was added, including ground support equipment.  The ground support equipment affects the relevant systems as expected.  If you leave the engine intake covers in, for example, you won't be able to get the engine spinning for lightoff as the airflow into the compressor will be severly restricted.  In addition, this will eat up battery charge a bit more quickly as well.  With the front chocks on, taxiing and wheel control is restricted, and of course leaving the pitot covers on kills the pitot system functionality.

outside_1.jpg

outside_2.jpg

 

@tkyler tossed in a 3D pilot so things don't look too funky from external views; however, you can disable this option if you like via a preference.  I've tried to add a bit of lifelike behavior to the pilot and will expand on this more over time to be more immersive and natural.  Here's a quick video link of some of the pilot animation:
 

https://www.dropbox.com/s/m0t6c5qxhjep0xj/taxi_opt.mp4?dl=0

 

Online Docs

Also, the documents are moving to be browser based.  They are in a simple static HTML format and so can also be viewed locally as well as online.   This makes them searchable, and a bit more reader friendly, as well as more readily updated. Illustrative graphics and animations will also be more easily implemented in this way and PDF exports of the online docs will also be available for folks who like hard copies.  Sprinkled throughout the docs are a few The Real Deal technical tidbits.  These are descriptive details about real MU2 system behaviors and quite informative in understanding the how and whys of some aircraft operations.

online_docs-2.jpg

online_docs-3.jpg

 

Systems simulation

The systems simulation is relatively straightforward, but indeed customized quite a bit over default X-Plane.  The MU2 isn't the most complex aircraft systems wise, being an older aircraft, so Tom has focused quite a bit on the accuracy of behavior of the simple systems that are there to enhance immersion and have a more natural feel. As it turns out, this is quite a bit of work. 

All the electrical busses and switchgear are simulated.  Most all the fuses work and feed their connected equipment as expected.  The autopilot system is working very well and quite accurate per the Sperry SPZ-500 system that is installed.  I essentially refer to the real procedures, step by step and ensure that the simulation works the right way for the right physical reasons.  

The engine have received the most work.  The TPE-331 has some interesting nuances that have been challenging to simulate, particularly during engine start, which is automated by the SRL computer and affects the EGT and FFs, but there are also other unique features, such as fuel purge on shutdown, NTS test and lockout, overspeed governing and temperature dependent start behavior that come into play as well.  The manual discusses these system in more detail.

 

What's left
At this juncture, the sounds and small pieces of polish are all that are left; however, the polish work can drag out as many folks know.  With three variants to test and so much reloading of X-Plane, it takes quite a bit of time to ensure each user will get the experience they are expecting. But things are definitely winding down towards release.

day_cockpit.jpg

  • Like 9
  • Upvote 1
Link to comment
Share on other sites

XP 12 definitely has a lot of "under the hood" changes will affect the Moo; however,  immediately after release and stabilization, I'll begin to test/tweak it for XP12 also.

 

  • Like 7
Link to comment
Share on other sites

I'm looking forward to the next general aviation aircraft that I can learn intimately. I want an aircraft that will hold my attention exclusively for months. I am hoping this MU2 will fit the bill.

I have no doubt it'll port to XP12. It looks awesome.

Edited by VirtualGAaviator
Grammar fixes
Link to comment
Share on other sites

1 hour ago, Shalomar said:

Yes; GTN 750/650 Puh-lease!!!!

I'm trying.  still can't get a response out of Jean-Luc of RXP.  I've reached out on 3 separate occasions.  Again, after release and stabilization, I'll set about putting in the GTN if I ever get the info I need.  I'm making room for it, I can tell you that.

-tkyler

 

  • Like 2
Link to comment
Share on other sites

not at release no...not beyond default X-Plane.....but a little more explanation is probably warranted.  The code infrastructure absolutely supports the implementing and mangement of failures of lower level components... and indeed I've had an algorithmic model for failures for many years "in my head"; however,  I feel an interface to implementing  and managing failures is a critical thing to get right for the end user. Such a system would require a "repair module" in my mind.  In other words, if you experience what appears to be a failure...how do you know whether its a bug in the software, an omission of a feature, or a genuine "purposeful simulated failure?"   Its not unreasonable to envision some kind of "maintenance inspection report feature" where you could get some kind of report on any thing you feel was not working correctly and wanted to have a virtual A&P investigate further...otherwise, you'll end up on forums asking if anybody else has seen "the problem" you're seeing and is it a bug.  The limitation, for myself, has always been programming the GUI for such a system...which in the past, required some openGL skills, which is not my strong suit.  Gizmo has since introduced the 'imGUI' UI toolset, which I'm just tippy-toeing into on this V2.0 release...but the feature set of imGUI seems to be exactly what I need to get my "failure model" into some kind of "management interface', at least for individual "in sim" management.  I've had "web based online failure mangement models" also in my head for some time. (Any full-stack web programmers     interested?)  So its in the pipeline for sure...the ixeg 737 is built around the same code infrastructure and awaiting a similar GUI interface,  but I need some time to develop the "failure and repair interface module"  to the vision I have in my head that would be sufficiently engaging for users...which includes me.   FWIW, there will be a 'roadmap' documented for the MU2.  Such includes the failure work and expansion of the systems.  There is a fine line between "systems from the pilot perspective",   vs. "systems from the maintenance perspective".  For example, some instruments which users see as "one instrument" is actually many in one.  the HSI/ADI for example.  The ADI gyro uses power from one source, the ADI flags from another and the GS/LOC signal inputs from another etc....so its possible to fail "some" of the instrument, but not all of it.  Simulating these 100% accurately  requires having knowledge of instrument "pinout diagrams", which are tough to come by as many of these instruments are proprietary and folks in legal possession of these diagrams aren't exactly handing them out like flyers....even if these instruments are 30+ years old.  Beats me why this is, but it is.  I will certainly be continuing my efforts to improve the Moo systems to this 100% goal (whether attainable or not)  as time moves on.  After all, I too am a fan of learning these systems at really low levels, if for no other reason than the fun of it.

-tkyler

Edited by tkyler
  • Like 1
Link to comment
Share on other sites

I too would like the GTN 750 incorporated, but in the meantime if you run the 750 in the background and pop it up, anything flight plan you program into the 750 will be reflected or used by the 530. Lots of folks don't know that. I have other planes that only have the 530, but I pop up the 750 from the background (I have a hotkey) and make my flight plan on the 750 and it will show in the 530 and the autopilot will follow it right on the 530 display. 

Link to comment
Share on other sites

10 hours ago, BillOtten said:

I too would like the GTN 750 incorporated, but in the meantime if you run the 750 in the background and pop it up, anything flight plan you program into the 750 will be reflected or used by the 530. Lots of folks don't know that. I have other planes that only have the 530, but I pop up the 750 from the background (I have a hotkey) and make my flight plan on the 750 and it will show in the 530 and the autopilot will follow it right on the 530 display. 

Very good to know.  Thank you for that info!

Link to comment
Share on other sites

RE the GTN.  I believe I found the information I needed from an example *.ini file  provided by timber61 from X-Plane.org....certainly enough to experiement.    I'll set about integrating the GTN; however, the offering will have to wait until after the initial release though  I suspect it shouldn't take terribly long.  My workflow is already set up for handling variants efficiently.

-tkyler

  • Like 2
  • Upvote 1
Link to comment
Share on other sites

The variants I refer to are the "panel variants", not the prop; however,  If you consider the 4/5-blade options, then there are actually 6 variants (3 panels x 2 prop options) and indeed their are 6 *.acf files.......or 8 if you include the GTN-750 equipped one for Windows only owners (developed after the official release).  That's one of the things dragging this out a bit...each one have their own differing set of support files and of course sound files.  Quality control is quite something.

anyhow, the panel variants are 1) OEM Radio panel   2)  Garmin GNS/GPS Radio Panel   3)  Garmin G600 PFD/MDF with GNS/GPS Radio Stack.   Note the 3rd option is only available for owners of the Real Sim Gear G500 /600 product from X-Aviation.  Below is a screnshot from the docs regarding the panel/prop variants.

variants.jpg

Edited by tkyler
  • Like 2
Link to comment
Share on other sites

On 5/29/2022 at 4:21 PM, tkyler said:

I'm trying.  still can't get a response out of Jean-Luc of RXP.  I've reached out on 3 separate occasions.  Again, after release and stabilization, I'll set about putting in the GTN if I ever get the info I need.  I'm making room for it, I can tell you that.

-tkyler

 

Hi, if you were talking with Steaven Mckenzie in order to get the awesome G500 working in the outstanding MU-2 V2 virtual cockpit, he has got the RXP GTN 750/650 integrated in their entire torquesim/afm fleet, so i think he can give you the propper information to achieve the avionics working on..

Link to comment
Share on other sites

8 hours ago, tkyler said:

I've since made contact with Jean-Luc, have the GTN-750 and required info so I'm good to go after release.  Thx Raúl.

Thanks for a lot tkyler!!.
I take this opportunity to ask you if the RealityXP devs are working in order to get their GTN 750/650 working in XP12, any news or did you ask the devs?

Take care!.

Link to comment
Share on other sites

I see no reasons why it should not.  The way the Reality XP integration works is not really part of the significant changes for X-Plane 12.  It uses a "pipeline" that is largely untouched by XP12.  I expect there to be little, if any issues.

  • Like 1
Link to comment
Share on other sites

The sounds are finally coming along well.  I've been 'worried' about...and playing with the engine sounds for quite some time,  being that you can't just record a MU2 engine and handle all the possible ways a user may interact with the engine in a sim....and I've had to also learn FMOD along the way.  If you want to simulate "cranking" or a hot start, or a shutdown, or a slow start,  you have to accomodate the engine RPM at any given time and for any given duration.  This means you need a relatively complex "looping" setup of sounds that only play when their "physical source" is in play.  You don't find many videos of MU2s of cranking....or owners willing to 'crank' their engine several times for you and kill their battery while you record sounds.   You may recall X-Plane firing up a turbine and playing the "lightoff" sound even if the engine doesn't lightoff.  That's unacceptable to me. ....so the challenge has been to mix and synthesize the various components of the engine sounds to try and recreate the real thing.  Well the engine is finally starting to sound realistic IMO...not perfect but not bad.....and the better it gets, the more I keep playing with it and why things keep dragging out.  That being said, I think the wait will be worth it.  I can honestly say that after 17 years from the first time I started building the MU2 for X-Plane....its finally shaping up to be the simulation I wanted it to me.  Check out the engine sounds WIP video below.

https://www.dropbox.com/s/8puz1xi88fvcbla/mu2_sound_opt.mp4?dl=0

Edited by tkyler
  • Like 7
Link to comment
Share on other sites

12 hours ago, tkyler said:

The sounds are finally coming along well.  I've been 'worried' about...and playing with the engine sounds for quite some time,  being that you can't just record a MU2 engine and handle all the possible ways a user may interact with the engine in a sim....and I've had to also learn FMOD along the way.  If you want to simulate "cranking" or a hot start, or a shutdown, or a slow start,  you have to accomodate the engine RPM at any given time and for any given duration.  This means you need a relatively complex "looping" setup of sounds that only play when their "physical source" is in play.  You don't find many videos of MU2s of cranking....or owners willing to 'crank' their engine several times for you and kill their battery while you record sounds.   You may recall X-Plane firing up a turbine and playing the "lightoff" sound even if the engine doesn't lightoff.  That's unacceptable to me. ....so the challenge has been to mix and synthesize the various components of the engine sounds to try and recreate the real thing.  Well the engine is finally starting to sound realistic IMO...not perfect but not bad.....and the better it gets, the more I keep playing with it and why things keep dragging out.  That being said, I think the wait will be worth it.  I can honestly say that after 17 years from the first time I started building the MU2 for X-Plane....its finally shaping up to be the simulation I wanted it to me.  Check out the engine sounds WIP video below.

https://www.dropbox.com/s/8puz1xi88fvcbla/mu2_sound_opt.mp4?dl=0

Outstanding job, those engine sounds are really really good!!!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...