tkyler

Thx Pils! Looks like indeed its not wired up to ON...just STBY. well that explains it. Seems ON=MODEC...easy enough. On the list for fixing. (Starting that list first thing tomorrow morn)

adding a bit more...cause that above was rapid fire from a Starbucks. The "big problem" for us is that several Plane-maker behaviors like EGT are governed by a single variable in X-Plane, from which X-Plane derives the EGT over certain ranges of operation... and when we change this variable to affect one engine, then it affects the other engine in an adverse way and cause the opposite engine state to change. The only way to truly get independent control is a full override, which means discarding X-Plane's engine model almost entirely and that is a sizeable job. Honeywell isn't exactly mailing me all their performance data...but again, it is on the roadmap. I'm particularly sensitive to the start/shutdown procedures and really want to get these right.

This is a quick response (at Starbucks) will look at videos more in depth later and reponse below this one. That does not sound normal for sure and will take a look. Certainly the start behavior should be reasonably similar each time the engine starts. In reality, EGT sensors probably would not reflect residual heat to that kind of a level from a recent shutdown simply due to the dynamics of the process. The 950ºc spike ceratainly is worth a look on my part. There is certainly room for improvment in the start/shutdown process. My only long-term recourse to get time-dependent thermodynamic behaviors is to fully override the engine model and this is absolutely on the roadmap but a sizeable job. Right now, I 'override' then 'relenquish' control of the engine in various regimes and this does create discontinuities that are difficult to overcome with this hybrid control method. Its not ideal I agree but I will address it in the future. I'll look at your videos more in depth though for "obvious bugs" as those could exist....because certainly the EGT spike should not precede the fuel flow. This is a known bug and actually the last one I was working on before release. I just could not get it to work satisfactorily without potentially breaking things and at the 11th hour, that's not a wise idea. THAT being said...neither did I find a solution and as of now, believe that full override is the way forward. What I expect...is that over the next several weeks, the glaring bugs will diminish, we'll get through a patch or two. I'll do the GTN variant in short order and then as I begin to port to XP12, I'll start looking at more robust overrides of X-Plane controls. Once that happens, I expect the behaviors of the engine in start/stop to increase in accuracy dramatically and then as I get the failures/GUI developed over time, I'll start looking at the time-dependency and hot start conditions etc.

I did actually take a look at this. Does it work with the GTX330? I ask and here's why.....I couldn't find any representation of "mode C" in the X-Plane data. All I have is the datarefs from below. The GTX-330...when hitting ALT, sets the transponder mode to '3=TEST' as shown below, BUT to me as a developer, that doesn't mean anything. Its just an number that is not OFF/ON/STBY...and so was useful for me to light up the ALT annun. If X-Plane actually interprets that as "mode C", then lucky me cause the description "TEST" is about as clear as muddy water. If another application (like X-Pilot) also needs to differentiate Mode C from OFF/ON/STBY, same as me, then I can't be sure they also chose the 3=TEST setting to represent ModeC. Now if X-Pilot does so (confirmed with test of the GTX), then this is a no-brainer and I'll easily make the change for next patch. If, however, X-Pilot uses some other data to represent ModeC, then we'll need to figure out what that is or if I need ot create some custom data. BUT...I suspect they too may have used the 'TEST=3 also'...hoping anyhow. I'll probably set this up to use '3=TEST' so its at least consistent with the GTX...at least until something else suggests otherwise. -TomK

DOH....sorry about that. "VR testing" is a special session test for my process.....and is on my action list after addressing any big bugs. That being said, VR testing or not, I will absolutely put the manip controls on the yoke (and provide a pref to hide it...cause it s a big manipulator) and I'll get this in for the first patch, preferably later this week. I'm heading to Oshkosh on Thursday and want to get some basic things in before then. -Tom

The ultimate goal is to rewrite the fuel controller. Once all the big-wig items are out of the way and things settled, I'm going to turn my attention to writing my own fuel and prop controller and overriding X-Plane fully. This will set the stage to eventually implement the ghost throttle methods by IXEG/Hot Start. In the original Version 1, I 'buffered' the lever animations a bit...probably a bit too slow as some folks complained they 'lagged' the hardware movement, but I can tell you that animating them directly from the joystick input has proven to be a nightmare with hardware noise. I'm going to look into bring that 'smoothing' back and maybe provide a tolerance zone setting like we did in IXEG. Anyhooo.....definintely interested to see what you might come up with. -Tom

That's good news...it means there code is working properly and you just have to wrangle your hardware comfort zone....because behind the scenes, the hardware ultimately ends up driving those levers the same as the mouse cursor does. So the mappings of the hardware + commands is just a process to work through. -TomK

A favor....to help me understand user cases better. I was laboring under the assumption that if a user had "dual levers" intended for a common function (power or prop), then they would logically map those levers to "1 and 2" (throttle or prop). So if you have multiple prop levers as mentioned in the previous post, then why would you not map those to 1 and 2 to begin with?....i.e what would you map the 'left' and 'right' ones to in another circumstance? -TomK

apparently I am the one going crazy. My sincerest apologies.....NO clue what I was thinking (or not...probably about pizza). So noted and on my list to look at. Again, really sorry. -Tom

There is no cabin rate of climb indication. The gauge on the left is "the altitude you want the cabin to be at"....so it won't change (sort off...more below). you set this 'desired cabin altitude to hold' with the cabin alt knob. The gauge on the right shows the actual cabin altitude...it should climb as you climb (well...depending on where you set the cabin alt) In your screenshot the cabin alt should climb to approx 3000', where you have the cabin altitude set..that's where your pressurization will begin and the DIFF PRESS PSI needle will begin to move. The tiny window on the bottom of the gauge at left tells you "We can hold 3000' cabin altitude until 19000' and after that, we'll be at max pressure differential and if you continue to climb over 19,000', then the cabin altitude will too...because we can't pressurize anymore...or we'll blow up the airplane like a popped balloon! How FAST the cabin altitude climbs is determined by the RATE knob on the unit on the left. full left is approx 50' minute, so with that low setting the cabin altitude will generally climb more slowly than your real climb (unless you're climbing at 50' minute)...and full right is ~ 2000 fpm or the rate your climbing if below that of course. Several folks have caught this...Its on my list! Excellent! I'll keep at it! -TomK

looks like your axes are reversed in the first video. Any luck reversing your axes in the hardware setup? Last video looks like some potentially funny hardware mappings. post screenshots of your hardware response curves maybe? Also...just to rule out any thing supernatural. If you disconnect your hardware and go "old school" with mouse and keyboard, can you control the levers with the mouse and get engine response as expected?

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.

Don't forget to set the "detent ratio" value to match your physical dent on your hardware. I use that response curve window and then pull back my levers to the physical detent and then the number on the vertical axis...go put that into the "dentent ratio" field in the MU2 prefs. That setting gets your animation in sim to match your physical hardware for the ALPHA/BETA regions

Put on the short list Marco. Thx.

You're first description, of not being able to control the engine at all with the power lever....I have seen an unexplainable glitch only one time that suggested a corrupted joystick settings file and only happened on the 5B_GNS variant, because no other variant exhibited the issue, which simply made no sense...so its not a bug I care to see again and so want to be very sure I understand exactly what you're seeing. Your other descriptions of spinning and looping RPMs, I have not seen at all and completely unsure of what you're seeing on your end. Perhaps a screen recording if possible? Also, what kind of hardware are you using? Single paddle no dentent/detent etc?

Thanks so much for the input: Altimeter does goes backwards from 99999; HOWEVER (and I forget to implement this...so thx)...it has a NEG flag on the first 3 digits. Clock will get replaced for sure. its subject to sit below higher priority items, but I don't like it either, which means I'm certainly going to fix it (GTX330 graphics too). Engine RPM....I'll check all the "numbers", both physical and FMOD, which of course drives the sound. It could be the values of FMOD are off a few decimal places. TBM900 throttle is excellent no doubt, but unsure if I can implement just yet, I'm looking into a solution with my current methodology. TBM900 completely overrides X-Plane controls/engine giving ultimate flexiblity between hardware and controls where I do not yet. I still rely on X-Plane's TPE-331 implementation for 60% of the functionality and that means fighting X-plane's default throttle joystick behavior. I do want this behavior in though (and indeed my own engine model) and will be giving it a good look see very soon to assess the options; however, it won't go in before the GTN, that's for sure. GUI: There is absolutely an advanced GUI plan with all sorts of goodies desired.... I just got into imGUI, this is my first go-round and once all the other particulars of the plane operation are stable, then I'll definitely turn my focus to "interaction". LibRadio. Not doubt if I can get it running on my architecture. Bug Saso for sure Final words..I've never been the GUI graphics guy in my other partnerships, always the flight model / 3D / systems guy, BUT I'm just starting to poke around with GUI interfaces....and you can be sure that the better I get, the more toys I'll start throwing in. I still have quite a few ideas I want to get into this product....and this Version 2.0 is the baseline! -TomK

If the beta light comes on, then you're in BETA....how FAR into BETA you are is unknown so far. That depends on your response curve mapping. In the sample below for example, my joystick is set so that it goes into BETA at about 25% of the joystick lever travel...and then as I pull further back below oh...about 0.12 it looks like, it goes into reverse. Note I do not use the "toggle_beta/reverse paddle" method in this example. When you have a response curve set up like this, then you will need to set your "Power lever detent ratio" to match the value on the vertical axis (about 0.34 shown below) so that quadrant animation stays in sync with your hardware lever. What hardware are you using BTW? and with detent? As far as the "two handed move" in the video, he's simply setting the "friction lock" for the condition levers. Pilots will loosen the friction lock, move the condition levers and then retighten the friction lock right after.

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

Gonzalo, please try another variant and see if the problem persists. Was this the 5B_GNS variant by chance?

Thank you for the video, very helpful. This is poor writing and a poorly organized/labled GUI window on my part. I labled the GUI window 'preferences' where not every checkbox gets "preference" status....that is not every checkbox value is saved between runs of X-Plane. For cold and dark starts, I always set the pitot covers, chocks, intake covers, yoke lock in place no matter the checkbox settings (which is why they're grouped together), whereas the other checkboxes in the section below are really the "preferences". The first checkboxes are probably better described as "actions". This was a quick, late decision and easily changed. I am a bit on the fence on this one because some folks like those entites "automatically in place" every time when starting cold and dark and others want pure persistence between their sessions with the MU2. My final thoughts on the matter is that I want to give everybody flexibility in their "start state" and I will probably evolve the system to be a bit more comprehensive and flexible. There are a lot of preferences to think through and provide solutions for. For now though...and I apologize, consider the first five checkboxes "actions" and the rest of the GUI dialog "saved preferences". I'll come up with something a bit smoother soon. Thx!

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.

would that preference include being able to set the flaps in any position between the limits of your axis? Because that I probably would not do because of the flap pulsing between 5-20 degrees. If however, you're looking for "tolerance zones" in your axis travel that can be mapped to the 4 discrete positions...and that you feel you could "hit by feel" since you don't have detents...that may be doable.