tkyler

No closed beta, and no plans to call it an open beta at this time. While its been a lot of work porting things over, its been more about calibration of the flight model, flight testing and accomodating some new datarefs than a massive overhaul of the entirety of the system. We'll be on 'rapid standby' after release to address obvious issues though and get critical patches out quickly. -tkyler

I'm campaigning for this to Laminar.....the ability to exclude light sources from reflective surfaces...but as of this moment, I don't believe we can. I'll squeeze in a quick report here also. Just completed all the interior cabin texturing....at least 99.5% of it....and now I'm working on the lighting for the rear galley. Lighting for cabin/front galley already done. Next week some time I'll begin the final punchlist items list and we'll start looking to wrap things up to package for release...that's not an overnight step, lots of checks have to be made, but we're definitely coming to the end of this V12 port + process. I'm going to start calling this the "V12 compatibility patch + (plus)"....becuase its exactly that. A port of the existing V11 functionality to V12, PLUS a few extra 3D stuffs thrown in. I want to make sure people understand this isn't some "V2" with all new 3D throughout, revised FMS/VNAV etc.....that work comes after this release...this is to get folks flying the 733 in V12. Here's a update screenshot of the new cabin/rear galley....the works that's been going on the last 4 weeks. -tkyler

Yes they will. -tk

Well the MU-2 detour work didn't help.....but beyond that, in the world of custom engineering / design work, there are unknowns in the process. Perhaps the results we are able to get out of x-plane might not be what we want and we have to backtrack and try different techniques, or we make conscious choices to implement things we didn't plan on implementing initially. May be the software we use is giving us fits (*cough Substance Painter). In estimating efforts for stuff like this, I like to call such targets, "personal carrots" we dangle in front of our own faces to keep us moving and motivated. I can reel off a large list of custom efforts that went well beyond time and cost estimates ....by Boeing, NASA, Icon aircraft, Cirrus, Space-X ...really smart folks with billions of bucks to work with etc...so it just comes with the territory. We're happy when we get it right...and just keep our heads down when we don't. One example though....we have working cabin doors. You can open these doors via the GUI by clicking a checkbox to have the doors open/close. BUT....I guarantee some folks will want to open these doors more like the real thing, by grabbing the handles and rotating them. So....I put that feature in, and it was a bit more work than clicking my heels together 3 times....and when I did that, now the checkboxes via the GUI need to reflect the door state if opened by mouse first. If you open the door halfway with the mouse and then open the GUI dialog....what do you see then, what should the checkboxes show? What feels natural and logical? This disconnect between possible actuation methods caused animating 'jumps' and I had to run a bunch of tests to see what worked and felt logical and natural, and add custom code to handle all that and it just added some extra time, etc. But in the end, I know that the customers that like to move stuff with the mouse will be happy and those that don't care can still use the checkboxes. But until I tried it, I wasn't exactly sure what worked best. I have to view the interactivity in this example from the perspective of a LOT of customers with different preferences and expectations. In the end, its a win-win for all customers, at the expense of my time estimate being delayed because I decided to add in a feature I didn't before, etc. There's been a few other areas regarding lighting that didn't quite work out like I hoped, eating up too many FPS and I had to backtrack and make some changes there also. Until I tried it though, I wasn't sure what the performance cost would be..and the alternative method turned out to be quite a bit of work. So...its stuff like this that stretches the time estimates. Your comment though, that you love the product gives me confidence that my choices when doing the work are mostly the right ones, and taking the time to do it right, even if it goes past my estimates, are usually worth it. -tkyler

slow but steady on the lighting...this is cabin emergency lighting. XP12 has really opened up new opportunities with its lighting engine, though a learning process. Trying to balance lighting effects for a natural look across multiple x-plane 3D objects with multiple light sources is an exercise is patience for sure, but as a simmer since 1981, I can't say I mind. It fascinates me how far these graphics have evolved. -tkyler

They should. if you put them in the "locked" position, you will find you won't be able to move your controls. I know this because I spent 15 minutes trying to debug why my hardware throttles weren't working one day....until I realized I had move the control lock levers to forward. Frustrating and a relief at the same time. What I have not yet simulated though, ergo has no effect... is the alteration of lever position based on 'vibrations' or 'loose rigging'. I"ll put this in eventually...and can't wait for the bug reports when I do. -tk

Status report, I just got my hands on V12.06....and the reverse seems only marginally better, still not right IMO. I expect a back and forth with Laminar on this one...and hope we can see eye to eye. If not, I'll have to overwrite and rewrite my own prop governor...not my first choice as it'll take a bit....*sigh -tk

That is correct. Four of us originally. Each of the others on the team have graciously reduced their stake so as to allow me to continue work on it and keep it alive. Without their sacrifice, the IXEG would have reached end of life at V11. I'm eternally grateful to them and wanted to honor them openly this way for their wonderful work. Their fingerprints will always be on the IXEG... Jan Vogel, Nils Danielson and Morten Melhuus! Thx guys! -tkyler

Sneak peek for the regulars....and a form of update I guess. All the cabin/galley 3D geometry is done...I'm working my way through the cabin currently, adding / texturing the smaller details and tweaking the lighting. A few more days of this I suspect, then I'll hit the final punchlist and tests with Jan. An unknown....XP12 b06 is hitting us devs shortly with some rendering changes...hopefully it won't affect us too much, if at all. Fingers crossed. -tk

Too easy! Anybody with access to the 717 willing to help..or a friend of a friend of a friend with access.....please hit me up in PM. This is well into late 2024 at best...737 comes first so i won't talk 717 much. Its just out there waiting its turn....but I reserve the right to work on it nights/weekends It doesn't quite work that way...besides, interior mostly done anyhow. The 'standard' is the standard. Immersion is a huge part of the product and many customers enjoy it all around. Lots of folks like replay mode from the cabin etc. Once this interior is done, I won't have to worry about it and can get back to the FMS and such. -tkyler

It would not bother me in the slightest if you did...I have zero pride...I make plenty of stupid errors. I don't spend the kind of time operating the sims as you guys do as I always have some other area of development I have to deal with... and always welcome observations I may have missed. Its a great part of this feedback loop and please don't hesitate to point out whatever....it makes the product better! I couldn't do it without your inputs. -tkyler

it sounds good Frank, and is naturally what any end user would want...less wait time. Feel free to form that group and give it a roll! Seriously though, I could write several pages of why that doesn't work because after 20 years of this, we've seen just about every form of development configuration. In a nutshell, people are the problem... individual goals, life situation, monetary requirments, time availability, individual skill, and relative perceptions of their own value. These factors rarely align for the good of a team effort. I will say that every developer capable of developing complex aircraft have their core code library in place for reuse, that's not the bottleneck. Until one has tried building one of these things, they don't realize the staggering volume of details that go into it. Just today I'm modeling "clip rings" that hold the divider curtain between first/economy. We have a saying....folks don't notice the details, but they notice when they're missing....and there's always one guy...."the color of the anodized aluminum legs on the seats are unique to Lufthansa only....and they're not brushed, they're electroplated...so your texturing is wrong"......thanks man.....you're the best! The longer straw isn't in the coding, its in the 3D, texturing, lighting and now FMOD sound, which is not very reusable. I always get a kick of reading the "airplane development notices" on X-Plane.org and all the starry-eyed folks who have learned how to make 3D objects and believe they can build a complete product. The number 1 thing (IMO) that would help speed up production is an "insider / collaborator". Someone who has regular access to the aircraft...can touch it....take pictures...put a tape measure all over it....play with the systems. This isn't always a pilot. The perfect "resource" for us devs would be a "pilot / mechanic" team for any given aircraft, who can answer questions on very short notice. That would definitely speed up things on new projects. I'll be asking for such folks soon after the 737 V12 release for two future efforts. Super Hint on one project....any Delta Airline mechanics / pilots here who are flight sim fans? hit me up on PM. -tkyler

I'd love to! Whats happening now is simply a matter of "what we are able to do nowadays" increasing the workload. I've been working on the cabin/galley texturing for some time, but with the lighting features we have and such, its just a domino effect. The cabin, especially, having both ceiling and window lighting modes and a combo of the both has been a real challenge. Add in the emergency lighting and it adds another layer. I've been sitting here for weeks saying, "as soon as this cabin texturing is done, we can finish the punchlist and release".....but the results are so cool (IMO)....because I'm a huge fan of visual immersion...I just keep going on the details Darn these video cards and improvements in real-time 3D effects. -tkyler

Thats a correct assumption, the Sperry AP GS is terrestrial ILS signal only; however, I don't currently deflect the GS indicator on the HSI based on a LPV guidance signal.....that's a good question in my mind though... It stands to reason that if the Garmin units can drive the analog inputs of the HSI CDI, it could do the same for the GS indicator....but I don't recall ever coming across that info for the GS, either IRL or within X-Plane, so did not implement it. Id have to confirm with an avionics buddy if the Garmin units can drive the GS needle of an HSI (your experience and logic indicates it probably does)..so it'd just be reinforcing confirmation on my part, but I'll look into if/how X-Plane implements this "GPS driving of the GS needle". -tk

No there won't. As we've said many times and I'll reiterate here to keep expectations in check for the next release. This is a port of V11 to V12 features with a few extra items. The extra items are outlined in a bullet list in the first post of this thread, otherwise, most of the features in V11 will the same as in V12. The paint kit is the same, the FMS still needs additional work for VNAV / holds, etc. This V12 release; however, is the foundation to springboard work towards a new 3D exterior and paint kit and improved systems. We will begin that phase right after things from the V12 release settle down, but this release is mostly about getting the IXEG flying in V12 with some enhanced (mostly interior) visuals. -tkyler

I'll agree with you this one partially, I don't get rides in MU2s anymore . I partially agree with you in that I'm not sure exactly the RPMs vs condition lever position in reverse region because I never really confirmed it numerically or asked my pilot buddies to do so either. I am mostly going off of sound and "to the letter" of the documention for reinforcement....I did record sounds on one flight from engine start all the way through takeoff and there is really no noticable rise in RPM pitch when going into reverse with condition levers at taxi, only the change in timbre of reverse pitch... and this is what I based my behavior off of. I have about 30+ right seat flights and it seemed, IIRC, that this was consistent behavior. I did pay attention to sounds. In addition, all MU2 docs say the condition lever "commands engine RPM", and does not distinguish whether or not the engine is in reverse pitch or not. So at taxi...I'd expect the engine to remain around idle speeds, even when in reverse...and the recordings I have corroborate this "with squinted ears"....BUT, the MU2 docs are pretty darn general about a lot of things so I wouldn't bet my house on the behavior. A slight rise in RPM is logical though, as I'd expect increase fuel delivery with the prop load of reverse; however, the final variable is the fuel controller. Not all TPEs use the same one. Most have Woodward controllers, but some retrofitted...and I recall my buddy telling me he didn't like flying the old Woodward units for some reason I can't recall, but it did insinuate differing engine behaviors. Anyhow... What videos / time stamps are causing you to have your conclusions? We can assess that here as a group -tkyler

don't hold your breathe on this one! A configurable panel is practical when you have differing "presentatations" of a given configuration...however, each of the Moo variants have differing, underlying equipment options that must be set in the ACF file and are not quite suitable to reconfigure the panel dynamically in sim. I simply can't see the ROI. -tk

I don't think it was directly between V11 and V12...I think it got borked somewhere within the V12 run, in the last patch or two. Also I'm not not sure its on the PT-6 model. I think it could be as simple as Philipp's misunderstanding of the TPE BETA hydraulic circuits. This isn't a knock on Philipp, he's tasked with a large number of areas of development within X-Plane and so he can't sit around reading TPE and Hartzell manuals for hours on end like I do....plus he has to also deal with the PT-6. I print out section drawings and have to hand color the components and circuits to help me understand the design and behaviors....I mean, this stuff isn't always easy to interpret .

yes, a bug with X-Plane's TPE model for sure...they'll go into reverse eventually, but I've seen it take as long as 10 seconds, quite incorrect. It has been filed and there is some type of fix in the next X-Plane update, which rumor has will be released in a few days; however, until I test it, I'm not sure what the behavior will be. I had a short exchange with Philipp, the programmer of the TPE engine and given the limited exchange, I can't say for sure he understood and/or agreed with how I suggested it be modeled, so I'm not sure what to expect. The reverse should be darn near instantaneous with lever movement...this is due to the way the hydraulic circuit of the 'pitch sleeve' works. I've been waiting on this fix for a bit....fingers crossed. If not, I guarantee I'll be knocking on Laminar's door again. Philipp has actually done quite a good job of modeling this engine, it worked great in V11, but I believe he added a few more accurate features like NTS lockout etc. and somewhere in the last few patches, reverse in the TPE implementation got broke. I used to custom model this stuff myself, but I've known Philipp for a good many years and he's extremely capable and as Laminar adds more accurate engine behaviors, then the more custom behaviors I have to 'pull out' of my plugin code so they don't clash, but in doing so, I defer to their implementation in some areas. Now having worked with these guys in years past though, they're quite agreeable to suggestions and improvements and I fully expect we'll get this one ironed out.....and I do hope its in this next update from X-Plane. -tkyler

@pm_pilot I'm sorry, I don't have much to offer here at the moment, may be someone else has experience with the RXP units? I provide the RXP 3D integration as a courtesy for RXP owners and have no real experience with operating these units. I can't speak as to how they interface with the default X-Plane GPS leg data. My 'tests' for GPSS behavior is to use the default GNS unit flight plans and if you were seeing this behavior with those default GNS units, I may have more to offer. If the exact same route and tracking behavior works with the default GNS units, but not with the RXP, we'd probably have to ping RXP support. I'd recommend trying the same route with those units as a baseline data point for the debugging effort. I do have a possible theory though. In ealier versions of X-Plane, you could enable GPSS and it would simply turn to track the magenta no matter the aircraft orientation relative to the path. Philipp from Laminar mentioned that he was going to implement more stringent "intercept" criteria for tracking GPS and it would not automatically capture the route at engagement in all cases. It could be such 'intercept criteria', either by X-Plane or the GTN simulations could be getting in the way...however, if you were heading in the general direction of your "direct to" waypoint at engagement, I wouldn't expect this to be a problem. What were the particulars of this setup? Departure airport? flight plan routing? waypoint? sequence etc...I'd be curious to see if this happens for all RXP users in the same scenario. -tkyler

I'd say things are definitely settling down for sure.....but you never know. I'm not expecting any sweeping changes. -tk

In the past (long ago), it used to be that any mixture value below 0.5 would cut off the engine. This was Austin's simplified model for "low/high" idle in turboprops...but when that model was created, Austin did not really consider fixed shaft turboprops and was essentially working off of the PT-6 paradigm. Now that has been enhanced to be more flexible, but still the "mixture ratio" really represents the fuel reaching any engine and not necessarily the "mixture lever position"...so it is applicable in the "stochiometric" sense though not so much in the "typical nomenclature" sense. or maybe a broken simulator? If you did this in the same "flight session" without reloading the aircraft, then it wouldn't surprise me if it did not work. I myself have been very guilty of this during testing, forgetting to reload the aircraft and stuff not 'binding' causing me to chase phantom bugs. When a plane loads, a whole lot of initializations and "bindings" take place....and the only way to get a really clean "reloading" of an aircraft is to reload it via the developer menu, or restart x-Plane. The nominal way for us developers is to use the developer menu, but for end users, that's a bit odd and so many times, they just restart "the flight"...which does not always initialize everything properly in my experiences. (which is why the reload aircraft menu item was added I think). I will say I have not seen the "one engine won't start" bug in a long time. IIRC, it happend mostly when attempting to restart an engine after shutdown in the same flight session and every single variable that should be 'set' to indicate a running engine was set properly. It was/is enough for me to think X-Plane has an issue but in order to take that to Austin, it needs to be 100% repeatable and narrowed down to a smoking gun config, or else Austin won't really look at it because I control so much with a custom plugin...and when we do that, Laminar tends to "wipe their hands clean" of any issues. I won't lie, the Bravo hardware has been a major PITA for me. Here's the funny part....hardware setup has been a PITA for Honeycomb too....I spoke with the CEO at Oshkosh last year about it. This is exactly why they provide the profiles they do, in an attempt to alleviate the burden of a confusing setup from the end user, but in doing so, they end up providing "opinionated" configurations that cause issues with the Moo. -tkyler

I note you mention both a 750 in the title, but a 530 ...and I do not provide a 750/530 panel combo, so I assume you've tried multiple flights/configs, which means settings could have been differing between flights. So...I'll just ramble here a bit in general in case you find a useful nugget of info. I am by no means a GTN750 expert, but IIRC, it still interfaces with default XPlane GPS behaviors. Also, The HSI does not display any GPS information, except for the CDI needle deflection when the GPS CDI button is set to 'GPS' and a GPS leg is active. So no course or range information related to a GPS waypoint/plan is displayed. The HSI only displays course/distance information from radio nav aids, i.e. VORs/ILSs. I'm not fully sure of your navigation config regarding the GPS/VLOC issue, so I'll just speak generally. This button only changes the CDI needle signal source on the HSI, and so won't do anything unless (in the case of VLOC mode) you are tuned to / receiving from a navaid....and (in the case of GPS mode), you have an active flight plan leg. I'm not sure if you were tuned to navaid when you tried the GPS/VLOC button, or had entered a flight plan in the GPS and were on an active leg. Either/or, the only thing you'd observe from pressing this button, assuming you were tuned into to a signal/active leg is the CDI needle on the HSI move a bit. Again, not knowing your full config, I couldn't say what's going on here, but I can say its not related to the GPS/VLOC button at all. This has zero bearing on the autopilot tracking and engagement. For practical purposes, only the GPSS button really changes the "SOURCE" signal the autopilot follows. I've never seen the autopilot not follow a GPS flight plan in GPSS mode when 1) AP is engaged, 2) a GPS flight plan leg is active and 3) the GPSS button is in GPSS mode. With these three items, the aircraft has always tracked the GPS flight plans for me. Not seeing the entirety of your cockpit and settings, I couldn't comment exactly what you were seeing. -tkyler

Hi Medway, I have noticed that too. I expect to see tkyler at FS Expo 2023 this year and I'll hound him about fixing that! Its been driving me nuts too. -tkyler

I assume you're referring to the hardware settings? I don't have any recommendations, its a bit subjective and differing folks like to adjust those for their feel and hardware. I myself prefer everything nice and linear, but that's just me. -tkyler