tkyler

It is now (thanks Pils)...and I'm still making my way back home. We're pretty much done with the issues list for deployment and only have to get though technical infrastructure and deployment prep, but as mentioned before, that's not an overnight thing, but it is the 'final leg' of this route. The plan is to get this 'port + compatibility patch' out, which I'm sure will result in plenty of issues reported, but then immediately begin addressing those issues and start the road towards our planned improvements. The obvious 'improvement roadmap' consists of converting our sound work to FMOD, improve FMS operation and finally a new 3D exterior, these are the things to bring the IXEG into 'modern times'. I'm sure this work will roll well into 2024 and the goal is to just keep going. After those obvious items are addressed is when will think about any other 'options' to the product. Its enough of a heavy lift job to overhaul this thing from 2009 tech as it is. -tkyler

I haven't checked it yet TBH. It could be. I set all the requisite datarefs as you've noted and never thought about it much because it always worked, but certainly possible X-Plane changed some things I didn't catch until someone reported it and the yaw damper isn't one of those many take a peek at so it didn't cross my path much. It will be fixed in 'two weeks' probably Yes, its absolutely on my TODO list to look at before the next patch Frank. I am on the final push to get the IXEG out the door and the MU2 will get is turn in rotation again and I'll make another pass over the issues...we'll get this one sorted out. -tk

It was corrupt preferences! One of the more nefarious causes of unexplained behavior. Deleted them and Owen is back up and running! -tk

@Tomlinson Sent you a PM. We'll take this private for a bit. For others curious, will report back. -tk

Thx for that. Next, turn on the "IGNITION CONT" and try that. but beyond that, a few qustions also? Version of X-Plane? Operating System? Do you have any other plugins installed. XEconomy, etc. Are the engine intake covers removed? Are all the fuses pushed in? Are you familiar with the DRE (Data Ref Editor) plugin? we use it to debug X-Plane datarefs. You will need this to debug further. -tk

Thx. Two observations. 1) I can't see any of your engine gauges, so I don't know whats going on there...I need to see those. . and 2) your trim wheel is "twitching", which suggests you still have hardware attached to your computer. Make sure you disconnect your hardware for this test, and then show the engine instruments in another video so we can have some feedback. Do not move the condition levers though (ignore my moving them below), leave them where they are. Show me something like this. mu2_start_opt.mp4 -tk

could you please post a screen recording of your steps using the mouse? -tk

Lets try this again. "WHAT was the result of that troubleshooting test I suggested above"?

@Tomlinson Did you see my post above for you? What is the result of that test? -tk

Sorry, I should have clarified more. What I meant to say is that sometimes hardware levers are mapped to "mixture" when they should not be at all. If they are, then 'noisy' hardware, which is super common, can set the fuel flow to 'zero', thereby keeping the engines from starting. So yes, the condition levers should be assigned to props as documented, but then NO levers should be assigned to mixture. If hardware ships with configuration files that have pre-assigned the levers to parameters , then they have to be expressely set to none (or not mixture at least). -tk

Do you have a Honeycomb Bravo hardware per chance? The most common culprit is hardware that is mapped to "mixture" and this hardware sets the mixture value to 0. The Honeycomb stuff sometimes have preset profiles for their levers. This 'mixture' value in X-Plane, doesn't really mean mixture in the 'recip engine' sense, but rather "fuel flow to the engine", so its applicable to turboprops too. The second most common culprit is a lack of fuel in the center tank, which feeds the engines. For a first troubleshooting test, I recommend you remove all hardware and try to start the aircraft using only the mouse, making sure you have fuel in the center tank. If that works, then we can focus on hardware. -tkyler

That is very possible, not terribly difficult or long to implement actually; however, I'd have to give the full implementation some thought. If I don't get that implemented by the initial release, I'll look at it fairly quickly after though....Its not a bad idea at all. I know there are lots of folks like yourself who only view the IXEG from the cockpit and external views. I'm unsure the FPS savings though, but will test. -tkyler

Ok...a little more on the -ish side than the morning side, but here's a peek into the cabin lighting as I tested the functionality.....with the intro showing some cabin door interaction. The video compression is a bit heinous though.

its a fancy way of saying "reprogramming". We use a very old XML data format for our navigation data for the FMS...and we are wanting to move to XPlane's 'V11' navdata format , which is bit more modern with regard to flight plan leg types. So I have to "reprogram" all my code that parses these navdata files. You can expect a new 3D exterior at some point. Its my goal to make the IXEG as 'modern' as can be, similar to the MU2, so that it can be viable for many years to come. It takes a while, but if done right, it also lasts a while. And squeezing in a 'pop-report', I'll be wrapping up the last of the 'port +' visual mods today and focusing on the last few items in our todo list. I have a 10 day break for Oshkosh here beginning in about a week, but right after, we'll start the packaging for deployment process. I'll post a more in-depth video tomorrow morning ~ish (GMT-6) on the visual improvements...till then, here's the rear galley lighting. -tk

Thank you for the encouraging words. Some times it seems like this process never ends. Every finished task seems to illuminate another. ...and to think this is just the "V12 Port +" process. I can't wait to redo the entire 3D exterior and refactor the navdata code . -tk

you and me both. Still working on it every day (except weekends...really need my mental breaks)....there's just tons of little details to tend to, especially with lighting control and tweaks. I just finished swapping out all the old exterior lighting with the new V12 lighting yesteday, so that's the latest thing I worked on. Still moving down the punchlist. -tk

not very likely no. The cockpit texture, being the center of attention and in view for the majority of the time was optimized quite well for 96 DPI monitors IMO and still looks good......assuming a reasonable camera distance from surfaces. Also, since we did this work way back when, before Substance Painter was a thing...it'd be a massive undertaking to try that. Of course if you put the camera quite close to a surface, there will be 'jaggies', but philosophically, I'm not in that camp. I'd rather optimize performance for the 95% use case (pilot-ish viewpoint +/-) rather than the 5% use case (peruse 3D closeup under a microscope after buying). -tk

Thanks for the inputs @rosseloh, this post is logged and very good feedback. Definitely some of those bugs are known and on my list already. I certainly need to go over some of these items again, I do know that XP12 and recent updates have altered some behaviors, particular with GPS stuffs that I expect to have to re-test and adjust. I talked to Philipp at the FSExpo about the reverse issue and hopefuly he'll take another look at that. I'm reluctant to override the engine model as its all or nothing, so if I do that, I have to simualte the entire engine which would be a big job, whereas Laminar is about 95% there, so I really want to get them to fix this on their end. That reverse thing drives me nuts. Thx for your patience, I'll keep toiling away steadily and eventually we'll get all this stuff going. -tkyler

that's correct. And it is because of the older autopilot in the MU-2. Its a lot easier to retrofit an autopilot in a simple 172 than the more complex MU2 and being the 172 market is easily 10x the size of the MU-2 market, gaining certifications for such an AP retrofit is a no-brainer for the 172 market, but never made fiscal sense for the small MU-2 market. -tk

a chink in the armor perhaps? Ok...not 4 yo......maybe 5. I don't think I was cursing at 4.

well now I know the answer to that question. At my age yes. Maybe when I was 4 I could keep up with you. Best I have now is for me to move on.

I find your candor strangely fascinating, like something out of some kind of social experiment....strangely refreshing from typical PC rhetoric; however, you wield it poorly IMO, .... whether intentionally to get a rise out of folks or not I can't say of course. But as you pointed out, we all reap what we sow. both us and you.

Not going to do that, but suffice to say this is all just conjecture and speculation by all of us. ...its just 'conversation', not much more that that. None of us know what will happen, but we all have our thoughts. I myself think XPlane is not in any danger of dying any time soon...just my opinion -tkyler

we've been listening to these type of claims for 20+ years. Granted that differing folks use different words to describe how they feel about things.....to each their own.....but this is simply bombastic IMO. Have you ever thought about writing for CNN or Fox News? Your commentary would be absolutely SHOCKING, the likes of which have never been heard in the history of the world. -tkyler