tkyler

You don't REALLY have to move the levers to reverse at 60% RPM, you can move them to reverse before you move the RCS (Run-Crank-Stop) switches to the STOP position. To shut down, after the plane is stopped, simply pull your power levers back to some position between the ground idle and reverse (or full reverse just to be sure) and then you can move the RCS switches to STOP. That's the way its generally done by pilots. The checklist wording was taken from official documentation, which is not always worded the best. In the example below, the left engine closest to the camera was shut down correctly, the right one was not and the prop feathered on shutdown. The right unfeather pump would have to be used to unfeather that propeller before attempting to start that engine. TK

Sorry for quietness....the MU2 has been sitting at 95%+ done for the next update for a while. I decided last second to tweak the EGTs so as to have a proper crossover from Torque Limited to Temp limited at altitude...and that set off a round of flight testing I need to wrap up. The summer has just been packed full of activities, not all fun, lots of travel and its been a challenge to find blocks of time. Oshkosh is next week and is my last big activity for the year, so in speaking with Cameron, I plan to wrap up this update asap right after. ...and on a hopefully good note, XP12 new weather radar finally drops in 12.2 so I'll be squeezing that into the OEM variants, which along with the EGT will round out my "not done yet" list for the major features and I can then start messing about with improving the performance, systems accuracy and adding more liveries. -TK

Sorry its not getting updated as fast as any of us would like. I wake up every day and have to make decisions about what to work on and balance my requirements against the customers. They never align for everybody and never will. Its not abandoned, it will get updated and updates will be free for many many years to come. -TK

@CptIceman That button is not animated FYI. Are you associating the 'functionality' of the button with its animation (or lack thereof in this case) per chance? -tkyler

Rgr...so it does appear that the TOGA command specifically isn't implemented by the name above. It seems we changed it to hijack the XP default TOGA command, so we'll need to amend the docs. Sorry about that! The following command for TOGA should work. As far as the other commands, they are all there (see video and screenshot below). I've checked with 3 other users who have confirmed the same. Again, I can't vouch for what DRT does, being a 3rd party plugin. commands_opt.mp4

it looks like all the commands are there, every one I searched for from your 'missing list' shows up in XP, both in the keyboard screen and when assigning them to a button on hardware. I don't know how DRT searches for commands (and DRE doesn't display commands) so I can't speak to your DRT results. I 'officially' check for the existence of commands via X-Plane's 'keyboard' search function. If they show up in there, then they exist. If DRT doesn't pick them up, I couldn't say way. I don't use DRT myself.

Hi guys, @rkuhlmann is right about communication...guilty as charged for being too quiet. The 733 isn't dead. We will continue to work on it as able, and best I can tell, probably have free updates for as long as I can foresee (whenever those may be). For my MU2 customers who have watched me keep the MU2 relevant through X-Plane versions 7, 8, 9, 10, 11, and 12 over 19 years, you know what I'm talking about. (even though its been a while since the last update and I'm literally 99% done with the next one but need to get it out There have been things beyond our control that have made update efforts challenging (shit rolling downhill kind of things)...which you guys don't see, nor will I talk about, nor should you care about, but we have to deal with just the same. Not an excuse, an explanation. I acknowledge that communicating is something we could do better and I'm sorry about that. As I've said many times, my committment has always been to keep facing forward and never sit down and that's still the case. So ....open communication time.....where's my time at the moment? I'm working for Laminar again. I am rewriting their documentation set for developers to help train and enable more developers for X-Plane. This initiative began in February at the X-Plane dev conference and I've been in the midst of a heavy 'front loaded' time effort to build the infrastructure for these docs and there's some slight pressure to "show anything at FSExpo". For consumers (rather than devs), this doesn't mean anything.... I know that doesn't make anyone here feel better or fix their concerns now, but is the road I had to take to preserve my ability to work on the IXEG in any capacity into the future. I do foresee time to work on the IXEG again after a few more milestones are reached with Laminar....indeed I'm meeting with some folks at FSExpo to discuss ways for them to assist in the effort. I am committed to maintaining the aircraft, even though I'm not sure exactly when updates will be. We have a plan, we try and stick with it, sometimes we slip, but we have never "forgotten about it". I like to say the IXEG is "perpetually in my inbox". Roadmap is the FMOD sound conversions still....and then the system updates. I am sure I'll have to repeat this later, but the "updates" period will also be quite lengthy because of the aforementioned (shit rolling downhill) situation I have to deal with. Getting through this phase is akin to the large efforts required to bring the IXEG to V12 and was unforseen, but its here on my doorstep just the same. Trudging through it, complaints and all, is the only way to ensure the IXEG survives into the future and those updates eventually come. The IXEG still has a lot of old tech and rebuilding it completely anew is a big task. I'm sorry again about the silence. -tkyler

I've added commands for those transponder buttons, as well as a few others. We're getting close to releasing the next update and these commands will be included. -tk

My bad, I accidentally pushed that update log to the web prematurely. Its not out yet...but most of those are done. I'll pull that so as not to cause more confusion. I also implemented CaptainCrash's performance enhancements which was a very big job and that is also done. I'm down to final testing and reworking the GUI before deployement. Tom

You cannot reach that ZFW value (in lbs) with the Preflight menu. We made a reasonable assumption of how much a plane is likely to be maximally overloaded based on Jan's career flying it and allowed that value...beyond which we didn't expect anybody to try. If you max out all the passengers and cargo bays to their limits and set the wt factor to 1.5 (to simulate a plane full of 200+ lbs people) then you'll end up with max ZFW just shy of 126,000 lbs. We made assumptions also about "nominal cargo density"...in other words, we assumed folks wouldn't simulate a cargo hold full of lead. Full fuel with max ZFW via the preflight menu that gets you to 161k, 25,500 over MTOW, which we thought should satisfy users wanting to try some overweight flying.....for at least 99.9% of use cases. Now You CAN achieve that ZFW value through the regular X-Plane weight sliders....BUT....with a caveat. We custom set the weights whenever the preflight menu becomes visible. SO...you can set total payload weight to approximately 70800 lbs (you probably won't be able to achieve 143511 ZFW exactly because of X-plane's slider resolution)....but once done and you "Apply changes", then do NOT open our preflight menu after that...as the total weights will be reset based on where the sliders were last set. This will allow you to simulate your overweight flight....but I suspect you may really have a challenging time with your climb rate and takeoff speeds. I think a ZFW of 143,000+ lbs....were some official to find out that you actually loaded the 733 that heavy...might have a thing or two to say about that...as well as any license or certifications or job security you might possess Now if you were to say, "this is annoying, I like to fly 20,000lbs overweight on all of my flights....then we can up the wt multiplier for a future release, I'll admit, you're the first one to ever ask to achieve a weight this heavy to my knowledge. -tk

Same here, and IMO, mostly for the reasons I mentioned above. In the business sense, they absolutely are. I believe the flight sim market to be big enough and each player to be competitive enough for end-consumers to reap the benefits and ergo, I see the competition between MSFS/Laminar healthy as is. Now the "intra-X-Plane" competition for distributing 3rd party works spawned by Laminar's entry into the store space ....then that is a different discussion regarding the benefits of competition, one I'm not interested in participating in textual form...its just too big of a discussion. If one competitor is so big and formidable as to render the others non-competitive, then there could be undesired collateral consequences. I think the XP community is aware of this and relevant players are working to limit such collateral damage. -tk

Given that assumption, sure, your points would absolutely be valid points of thought. I don't want to use the word "concern", because that's relative to each person. I'm not bent on putting my wares on the Laminar store for several reasons I won't go into here, but suffice to say there's many considerations and factors with regards to product type, quality, market, deployment / support that go into distribution decisions beyond the simple exposure of a convenient insim "store page" that users will see. So while on the one hand, I can see the benefit of our products "easily waved in front of the faces of customers previously unawares of our wares"....on the other hand, and given the types of products I like to produce and my own experiences over the years, I can also forsee a very large range of potential pitfalls that Laminar is less equipped to handle over the long-term...and not completely sure they should try to do so. If I was magically put in charge of "product support" for Laminar's, I would put forth an argument that supporting products over a certain level of complexity could be cost prohibitive and resource draining. Its my opinion that the special needs/support of high-fidelity, "study level" aircraft developers and the customers who seek those out is a niche space in the sim world and better suited to a bespoke distribution and support system like XA and given our experience, do not see this changing in the near term. -tk

Labels are relative to our own points of view, both views can be construed to be accurate depending on the argument at hand. Near where I live, we have two coffee shops within 1/2 kilometer from each other and indeed two starbucks within a kilometer of each other. From the perspective of "starbucks corporate", those two stores don't compete...but ask the managers of each of those stores if they're competing with each other for 'performance bonuses' and from their perspectives they are competing. Regarding the two coffee shops NOT the same company, each has some 'value point' niche they cater to (i.e. the "space") which allows their business to attract customers and be profitable, because the size of the market supports it, BUT, they each do need that 'niche hook', whether it be location, a "convenient driveway" or just plain better coffee. I'll point out that "loyalty" can be a hook too. So while MS / Laminar spaces obviously overlap, it can definitely be argued that there are portions of those spaces of 'the simulation experience' that do not overlap and each excels in differing areas where those markets are big enough to support both. XA has some hooks that I don't think Laminar can effectively cover in a cost effective manner, nor handle the logistics of supporting products of a certain fidelity level as they tend to be 'high maintenance'. In the space XA occupies and we don't see much changing and expect to continue providing high-fidelity products. -tk

I can't help the dissapointed. There is a quite well known phrase, "Disappointment is the difference between expectations and reality". We have tried to be as forthcoming as possible with setting expectations by telling folks it will take the majority of this year getting converted to FMOD and improving the FMS....but beyond that, there are also very big changes necessary 'under the hood'....big and time-consuming. Folks think that its always 'evolution'....just incremental work, but with tech, eventually the patches get too heavy. There is a very major overhaul of the "black box" bits to ensure future compatibility and the IXEG's continued existence....a rewriting of nearly 70,000 lines of code in a new language (that took 3 years to write originally) , stuff you won't see but I have to do to keep the IXEG compatible for the future. Guess what...its going to be silent for even longer while I work on the FMOD and code refactoring / FMS. Settle in...enjoy some other wonderful products for X-Plane, but know that it is not abandonware....and we won't be charging for updates for years to come probably. -tk

I know how you feel Mike....I felt a similar sting reading your comments on Toto's Discord a while back, insinuting a simple swap from your work to mine would "make eveything OK" and I was just too lazy to do it....and clearly my defensive posture resulted in a harsh turn of phrase above..which doesn't make it right. At the end of the day though, we get the customer support emails (a much larger contingent than is present on forums) and as such, I have a broader perspective of my customer base ...and enough experience in this market to know that your changes would result in making several customers happier, but also several more disappointed and I have to answer to those folks. I'm sorry if it stung a bit. What we're dealing with here is a "philosophy of development" given known limitations in 'modeling methodology'. For a good while I've watched us aircraft devs "put in the numbers" and complain to Austin when things don't perform right. But at the end of the day, these are just a big collection of numerical models and approximations, some better than others depending on lots of factors. So as aircraft devs with 'approximate models' in many places, we've always had to determine "which numbers to prioritize" given the state of X-Plane's flight/systems models. If, for example, you prioritize "accurate blade angles and engine parameters per handbooks" but the plane's performance is off in some regime because X-Plane's 'black box models' are off or too generic in places ....then you have to ask yourself, "can a user see the blade twist angles of the flight model? ..... or can a user more easily see the "off-nominal performance" and you make your decision about what to prioritize and compromise. If I said, "I'm putting in all the accurate numbers and will wait for X-Plane to 'come to me' and perform correctly before I release the product....well..you can imagine how that will go, so my philosophy is different. Numerical compromises and fudges are required for more balanced performance across the envelope in my experience. Indeed you have put in a crazy amount of accurate info into Plane-maker, and I do appreciate your work and it won't go to waste. It is not a simple swap and deploy because as you've noted, the X-Plane models aren't perfect so some numbers will have to change to accomodate the ground regime; however, your work is a wonderful springboard that I do respect and will simply have to look at parameter by parameter and gauge the effect against their impacts in a broader range of regimes. I hope I can strike a balance that satisfies enough. -tkyler

in progress. I have the FMOD project file going and some sounds ported over, but there's about 140 of them in total I think....and I'm having to audit each one....look at the code, reverse engineer the "equations" ...with multiple parameters and get those to graphical form, then fashion those up in FMOD.....super tedious work, and sorry for the time, but this will free us up for compatibility for many years to come and was an inevitable overhaul. I for one will be super happy when done so I can get on to the FMS stuffs.

none to speak of. I did spend some time trying out Captain Crashes "fixes"; however, I found out that he only tested in "cruise conditions" to "match numbers", because he had charts with numbers......but in doing so.....using his new prop / engine settings, the plane is completely inaccurate for ground ops, with insufficient thrust for taxi without going well into the alpha region. When I asked him about this he said, "no, I didn't test on the ground"....DOH... This is why I'm generally roll my eyes at community members with "fixes"....their perspective is usually very one dimensional, only regarding whatever it is they are passionate about. but the whole of the system is very inter-dependent. I'm keeping part of his work, and dismissing other parts..and its a parameter by parameter evaluation. So sorry..no news yet, but certainly the work is still in my inbox. TK

shouldn't be too long, within a couple of weeks. Mom's health, holiday time and a much-needed vacation have been a distraction for a good bit...just one more event to get past this weekend and then I'll be back on things regularly. -tkyler

TBH, we can't fully blame them (I'm one of them with the MU2) ....we've been 'crossing our fingers' for a while that XP12 doesn't break our radar display....and the spectre of such still exists. Its like two people walking towards each other and that awkard moment where neither is sure which way the other one will move and you kind of stutter-step....a lot of devs and Laminar are doing that right now IMO. We've gotten lucky in a way that we haven't had to do a darn thing to 'get around' the new weather system..we happen to select a method that has held up thus far..but it is based on the previous weather system pardigm....and as such, we are always 'looking over our shoulder' at it so to say, in case is sneaks up on us one day All that said...I do think the time is coming where it needs to be addressed. There is a XPlane developer conference in February and I suspect this will get discussed. -tk

Maybe...if you have hardware connected (not necessarily assigned) but also want to be able to use the mouse, then the pref "Manips with Hardware" should be checked.

I'll assume you're on mac? Its a known issue..and yea, tough to nail down. Always on the lookout for clues on this one. -tk

no, the tank types need to be changed in PM. I've done this for the next patch. There is no "fix" coming from Laminar. If you open up one ACF in Planemaker and set tanks 1, 2, 4 and 5 to type "TRIM", then it might work. I say MIGHT because Laminar confirmed that Austin defaulted the fuel tank draw to be "side based" in the first beta 12.08b....instead of 'ALL' and I haven't tested whether or not the latest update b3 fixes that. Tank type TRIM has no fuel transfer algorithm associated with it, hence my plugin handles it. Any other tank type and X-Plane moves the fuel around per its own algorithms, which is probably what you're seeing. For myself, I simply initialize that dataref now to what I need...TBH, I didn't expect Austin to change that one. SO...if they did initialize the fuel tank selector to 'all' in the latest BETA....AND you set the aforementioned fuel tanks to TRIM, then it should work as it did previously. I've done this already for the next patch. Regarding the fuel flow and torque? Doubtful. A performance 'pass' needs to be done again. I haven't touched it in a long enough time and X-Plane has had quite a bit of tweaks since. I've started on that process...but flight testing takes quite a long time. ...the perf charts have performance figures for something like 10 differing temperatures and different altitudes and torque settings....when all permutations are considered, it could add up to multiple dozens if not 100+ test flights......and still you're at the mercy of the X-Plane model. BUT yea..the perf needs some work. -tk

Yea, sorry about that, I had a senior moment....those files were for the MU2, not IXEG. I happen to be in FMOD at the time and simply forgot which project file I had open... I don't think MU2 files would do you any good here tk

Got this on our list and will definitely take a look. -tk

ah..looks like its an FMOD soundpak....so that is interesting. I will note that I used FMOD 1.1 for the Moo...and Laminar has been using 2.0 for some time. I'm beginning sound work for the IXEG and will see about exporting the Moo sounds to FMOD 2.0 for the next patch...it SHOU......that should be the starting point for any debugging at the minimum...I need to get on the latest and greatest that Laminar uses. -tk