tkyler

well..I should have clarified...its at "load of the airplane", whether first start, reload, relocation, etc.. I suspect you could simply go "change location > new flight" and it probably wouldn't appear again. just the same, I'll track this. Thx

usually see that one when relocating or reloading with sim paused? anything like that?

Thx Alec. Its a process for sure. Being 'solo' on this particular project makes it a bit tough in that I have to spend time on the 3D whereas in the team scenario, someone could "improving the interface" during that time etc.. So my methodology is to get everything that is "tactile"..stuff you.see / touch / hear / operate.....get it so folks can fly it with their hardware....and then when all that's stable, I can start throwing in "luxuries".....GUIs...more prefs...failures....weight/balance stuff. etc. I mean...I love this thing..it'll get plenty of attention going forward still.

I'll see what I can do. The reason its not an instant 'sure', is it was too fast in my original testing and I slowed it down. So if you "click on hold"....that'll be one rate...but if you use the mouse wheel...it'll be another depending on your OS scrollwheel settings. For sure I can speed up the "click and hold" value, I agree with that. Scrollwheel can move it quicker? Just out of curiosity, what method do you use?

Thank you for yours Joe. Post release is always tough until we all sort of get it figured out for all parties involved and the configurations / preferences and that knowledge can disseminate. I'm glad for all those who are participating here as it'll make the Moo much better! -Tom

Well we're working for the TBM style...which would probably work for you...you could bump that switch, its go into reverse and you could advance the lever to reduce the reverse if needed.....that's the goal.

Ither is your use case where you "hit the button" on the bottom of your Bravo (back of the lever throw) and thats when it goes into reverse?

FWIW, I've already provided a preference to "expose manipulators" with hardware....so they'll always be exposed if you choose. I'm pretty sure we can get everyone accomodated with time. I just have to work through each of the use cases and my uses cases are probably much more limited than consumers.

providing the command to move the condition lever to emergency cutoff and back should be no issue....I'll see about working it in for the next patch.

It absolutely is. All it takes is dialogue so the "specs" become clear. I'm noting this request and working it into my investigation. hardware is important and I'm actually working on it right now. I kind of knew this would be the issue...the engine management and quadrant is the heart of this beast and so getting everyone's hardware working in a natural way for them is priority. TBH, my unfamiliarity with all the hardware is part of the issue....honestly haven't seen that "button at the back" situation of the honeycomb. Now that I know its there, I'm sure we can come up with a solution. I mentioned elsewhere that I am re-implementing (because its in Version 1) the animation of the quadrant levers. What I mean by this is I'm going to decouple the hardware input from providing the actual value that the animation uses...this way, the levers will always move smoothly between positions. So if you do use a command to send things into reverse, it will animate the lever there naturally...and it will allow me to squeeze in a nullzone configuration, because my levers are shaking like they're naked at the north pole.....not exactly precision flight controls....though thats the name on the box -TomK

yea, its default. I actually have all the code I need to customize that in the GTX-330 since it has all the chrono functions in it also...I just need to parlay that to the chrono graphics.

known issue with hardware brakes. update coming. parking/key toggles work in the meantime. cold and dark? engines running? props off the locks? hardware mappings? several situations will affect the state of the engine/prop. Just need a bit more info and we'll get you in the air.

well the first thing I'm giong to do (which I did in Version 1) is separate the animation of the levers from the raw hardware value...they get jittery and jump around. This will allow for continuous animations between positions, so they wont just "transport". That doesn't mean they won't move around on their own if a bug is present, but at least they'll animate there. Also, I'm not showing the drawstring feedback, FWIW. Thx for this Ch.Cole.

will definitely give this a look see. The 'custom command' for an axis is actually a bit new to me (since I haven't dev'd since before 2016) and my recollection of trying it the first time resulted in some kind of delay IIRC (and I may not RC)....which precluded my using it. Perhaps I should revisit it.

well...there IS a '2' in the code......and it IS at the end of the code also....but only cruises at about 110kts....seats 4...has a high-wing....rhymes with Messna. ...and I get to sit in it for about 10 hours one way. WHOOHOO

Very first thing to check...and please don't be insulted because I borked this myself the day before release and didn't catch it for a bit...and it resulted in the described behavior......is the beta/reverse checkbox checked for your "throttle 1 & 2" response curves? If so and still have a problem....was this with more than one variant Joe? I have encountered a rare gremlin one time where I would move the levers and they would move in sim, but did not affect the engine at all....this one spooked me because it didn't make sense. I ended up deleting the joystick preference because it made no sense at the time when looking at all the hardware input values...and the hardware worked on all other variants. Deleting the prefs joystick prefs fixed the issue in that case......maybe. I say maybe because I wasn't being very disciplined about tracking the changes i was making at the time as I was a bit angry... and I can't be 100% sure I didn't bork the hardware settings to cause the issue in the first place.....THOUGH having the hardware work on all the other variants definitely made me go HRMMM. This is one bug I do not want to see anybody have to deal with if its truly a bug because without the ability to reproduce it on comparable variants, (4B/5B) its really difficult to diagnose. Completely bypassing X-Plane's throttle and prop is on my todo list...and will take a bit of work, but when done, should stabilize things for a long time. Hardware has been the most difficult thing to deal with when using any default X-Plane mappings.

If Austin implements "per engine" max values like EGT for XP12 and such, then that would improve things greatly for devs not attempting full overrides, indeed I could probably make the Moo quite a bit more accurate if so; however, I'll probably still head down the full override route for the things I can't foresee.

EDIT: @JPL19 Perhaps read the post below first in case that's what you're seeing...the information below is for anyone else who may be having issues with configuring their hardware and seeing issues. Do your power levers have physical detents that you want to use? IF no detent, then how do you want to use your power lever? Old school where you "toggle beta" and move your power lever forward for reverse? OR like the real thing, but with no physical detent. Can you please post a picture of one of your power lever axis settings and its response curve settting If none of the above apply (because it was mentioned that there is a "button" at the back of the power lever travel?) then how would you like to operate the levers? I ask because users may have differing preferences based on similar hardware and we want to get it working the way you want it to.

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