tkyler

@Graeme_77I got this mostly fixed. In the one use case where you switch the knob between ADF / VOR, then the needle won't cross the 0º to get on the newly selected bearing....so depending on the delta between the tuned ADF/VOR relative bearings at the time of knob switching, the needle may swing "the long way around", i.e. more than 180º. This specific use case constitutes a special "transition mode" that I'm not in any hurry to fix as it only rears its head for about 0.5 seconds when swapping the ADF/VOR knob position, but preserves the continuity of the animation, which I feel is important for the immersion. -tkyler

Not for some time. The cockpit looks great in XP12, even after 13 years since its first incarnation. PBR effects are applied in several areas of the cockpit already. There is a limit to the resolution of the textures where more does not necessarily equal better and a specific balance was chosen at the onset. One thing that has not changed much over the years is monitor "dot pitch'...with a few exceptions (Apple's retina display). Having chosen a minimum distance from camera to surfaces that we consider reasonable for a good simulation experience....and also in consideration of anti-aliasing algorithms, we have found that going higher and higher resolution results in poorer detail at the nominal viewing distances and there is a 'sweet-spot' balance between resolution and anti-aliasing algorithms. Anti-aliasing gets less effective at 'too high' resolutions and you get more 'jaggies', not less. Sure, when you get the camera right up on the surfaces, they look good then, but if a real pilot had to get as equally close to a surface to see its detail, you would most certainly question his last eye exam. As such, we selected a nominal range of camera distances from surfaces for typical simming activites and developed our resolutions based on those use cases. Going any higher doesn't yield any worthwhile benefit in our experience as of yet. I'm not saying there's not room for improvements in a few areas...but relative to other ares of the 3D, its certainly one of the better textured areas and not at the top of the list for improvement.....and we're quite proud of how good it still looks in XP12 after 13 years. Nils Danielson did an unbelievable job of texturing the cockpit, best I've ever seen to this day IMO, and those who have experienced his work and the immersion it imbues (myself included) know what I'm talking about. We'll keep on eye on it, vs the state of the art technologically, and if there's something we feel we can do that will improve the immersion experience, we'll ceratainly put it on our wish / todo list and try and knock that out. -tkyler

Just reviewing all my notes for MU2 work and revisiting this thread. I've definitely gotten deeper into imgui given the IXEG work in progress (see screenshot) and will revisit these implementations you have provided to assess them for inclusion into a more feature-rich GUI. I'm keeping in the custom gyration for the near term though until I can look at the new pax/weight balance stuff and see how I might could work with that in a more refined GUI. I'm still a little bit wary of X-Plane's default rotational intertias. -tkyler

I've added a new command, "xscenery/mu2b60/lift_both_power_levers_KBD"....for when using the F1/F2 keyboard throttle method. Avail next update.

Thx @Bulva Will fix this. Looks as though (best I can tell from SPZ docs)...is the wheel is only effective when the AP is engaged also. This is somewhat in contrast to the idea of using the pitch wheel to set a pitch target without the AP engaged. (such as before takeoff, which I used to do a lot)...but engaging the AP after takeoff defaults to pitch mode anyhow so maybe this make sense as you just fly to your stable pitch desired and engage. I'll start there pending any other clarifications. At the least, I won't turn on the AP by moving the pitch wheel. -tkyler

@sardilli hopefully I'm interpreting your concern correctly...if not I apologize for the lengthy post and we can keep working through it if need be. First, a bit of nomenclature clarification going forward so we're on the same page.....we have the "course selector indicator/needle (I'll call it the CSI)" and the "CDI", which is the "deviation bar" that is (somewhat) slaved to the CSI mechanics. The LED window shows the numerical value of the CSI setting. When in VOR/LOC mode, the CDI becomes active when receiving a valid terrestrial nav signal and indicates deviation from said radial. With no valid signal, it will align with the CSI. The course selector, being relevant for intercept purposes, primes the circuitry for intercept in the intended direction and the course LED value simply regurgitates the needle CSI setting. When in GPS mode, the XTK error from the GPS path is known by the GPS and a 'proxy/emulation deviation signal' is then fed to the HSI's CDI circuit for display on the HSI. The HSI doesn't know its getting a signal from the GPS, the GPS is simply "talking the language of the HSI". This is a feature of the Garmin units...having the ability to send analog signals and 'talk to' these older nav displays, because the GNS units came out at a time when these analog instruments were ubiquitous and used as primary navigation instruments (vs Glass). When using the GPSS mode, the CSI serves no purpose for GPS DTK tracking, but is still required for intercepting a VOR/LOC while in GPSS mode (HDG mode really).. ..so you don't want it showing DTK information in GPSS mode as you need to know the CSI setting for intercepts. So the LED value never slaves to the GPS DTK value, it.....it simply provides a numerical representation of the CSI setting. -tkyler

@BulvaWhat were your flap settings? You can't silence the horn with flaps deflected > 5º -tk

@BulvaDo you have the pref ("Save control positions on exit") enabled? I'm still trying to recreate this, which I'm sure is some combination of prefs/settings. Whenever I start C&D given your example condition, my "pull" dataref is already at 0.13 so it all animates fine, so I'm still trying to recreate a scenario where that dataref initializes to 0, which would cause your issue. -tk

Thank you for the input. Yea, that reverse should be immediate....as fast as you can move the levers back, there should be no lag. I've found the pitch time to be variable...on one landing, it took over 8 seconds to reach full reverse pitch and I lost a good 900' of runway waiting for it. Hopefully we'll see an improvement in the next version of XP. -tk

So spoke with Laminar and as it turns out, their TPE model is off currently in this area. The 'missing piece' (for the mechanical prop-governor nerds out there) is a "recalibration of the prop governor to 105%" when in BETA mode, which guarantees that what is called an "underspeed condition" ensues. An underspeed condition then facilitates a "wide open" oil port that provides maximum oil pressure to the prop pitch control tied to the power levers. This is so you get immediate control of the prop pitch at landing for reverse...you don't want to be waiting on the delayed response of a prop governor (which is what is happening now) . X-Plane currently limits the prop governor to 100% (*cough..PT6), which keeps their code path out of the 'underspeed' state and basically "governs the prop" (with a slow response) towards reverse pitch, which isn't the way it works. In BETA, the prop governor does not influence prop pitch at all. It worked well in XP11, but Laminar improved the TPE model in many other areas, rewriting the governor code and missed the "105% calibration" detail. So hopefull we'll see a change in the next update....but even then, unsure how well it'll perform across all regimes. -tkyler

Hey guys, is anybody else seeing very slow prop pitch rates when going into reverse? i.e you slam the levers into reverse and it takes anywhere from 5-10 seconds for the props to actually reach fully reverse pitch..... in XP 12.05r1? If so...are you aware of when this started to change? In XP11, the prop pitch in BETA mode is near 1:1 with the levers as it should be....and if I recall, in early V12 runs, it seemed the same. Being on the IXEG for a few XP versions...I took a look at the Moo and ran into this issue right away. I've ping'd Austin about, but curious if anybody is aware of what version of XP it started to go south. Thx for any inputs. -tkyler

Preview of X-Plane's window icing effects, in case anybody hasn't seen it. This was my first time seeing it https://www.dropbox.com/s/o261awvzn9rotog/thermal_inertia_opt.mp4?dl=0 DISCLAIMER: This is Laminar's default window icing effect and in-sim developer tools....I'm only implementing it. They did a good job! It has been thought through fully. Without it, the IXEG 733 would have to be retired. You want some shock....ICON aircraft was 'selling' their aircraft at an estimated 140k about 5 years before it hit the market (and taking deposits against that estimate too)...it ended up hitting the market at over 350,000.00 (over 400k now maybe?) And their board of directors consisted of a prior Google CEO, Boeing executives, etc. The point is things change and you adapt as best as you can. We're not looking back, just forward. -tkyler

No. The paint kit is a 1:1 match for the 3D exterior model, and until I change the physical 3D model and create the new layouts, the livery layout is fixed and so there's nothing new to release. We will release a new 3D exterior at some point (and paint kit), and that will be a lengthy process. I expect to work on that after some of the higher priority FMS items and FMOD sound work are completed. -tkyler

I might could make that work. I see no technical reasons why not....just the development time. I'll keep it in the back of my mind as a work and if a time opportunity presents itself, I'll see about squeezing it in. If Garmin can design it to 'be an easy swap' with existing instruments....should be the same for me -tkyler

I know I said I wouldn't comment one way or the other; however, we specifically dismissed this one in other forum posts earlier., so no new info here. No 747 from us, sorry. ..at least not from where I can see today.

Yes....sort of. This question requires a bit more explanation. IXEG as a team, had four developers, two of which do not actively develop any longer as their families/lives/careers moved in other directions. Currently I am the only one of the original team pursuing X-Plane development full time. Jan, as most know, is a 747 captain now, which keeps him busy, but he also is still active in XP development when not flying. So its fair to say, that I myself, have not only thought of a future project, It's well far along (chipping on it in spare time over last decade). Whether or not it is branded under the IXEG name I cannot say, because I respect the work of all my IXEG teammates, and I would not release a product under the IXEG name without all the original team member's blessing. TBH, I haven't thought about the branding much because for me, its the same no matter what, I still click the mouse a lot and put the same level of workmanship into anything I do, whether on IXEG or TOGA Simulation work. So the future work may be branded under either TOGA Simulations or IXEG, depending on conversations yet to be had. In general, its the same developers for the most part. So....the future projects. Once the IXEG for V12 is out the door and any initial round of bugs squashed, I expect to make an announcment regarding its development. Until then, I will neither confirm nor deny any guesses made. For anybody "nervous" about the IXEG development suffering, I will drop a hint and say that the FMS work on the IXEG will have about 90%+ similarity with next project's FMS, so both will be getting worked on at the same time in essence. -tkyler

I will point out...that once this XP12 port is stabilized....the FMS / autoflight is the highest priority, and not just for the 733. Other projects already in progress require FMS work as well, so it behooves us to really develop a flexible and reliable FMS infrastructure and by focusing on this, I am essentially working on multiple projects at once without sacrificing any one timeframe, so thats a max efficiency use of time and a big motivator to focus on it. -tkyler

and that's the way it should be. Never more complicated than that. Best any of us can do is 'hope' when we're not at the wheel. -tkyler

That's not quite right, at least not for the next XP12 update (in the singular sense). Subsequent updates (in the plural sense)... later down the road will see redone external visuals of higher resolution. That is quite a heavy duty job and will probably take a couple of months...so I'll address that after the FMC work most likely and everything else is working well, but certainly that will be the time to look at the workload for the 400/500 variants. Thank you also for the well wishes. -tkyler

As a data point, I'm not seeing any conflicts on my end with 12.05b2, the MU2 seems to be running OK. I don't keep any plugins other than the ones required to run the MU2 though. -tkyler

on some level.....yes, but I'm not sure how good the effect will be just yet. One reason I've held off on wing "motion" is I've always wanted to do it right, rather than just code up some randomized motions or simple Flex = f(airload) behaviors. By 'do it right' (for the engineers out there), I mean implement both flex and vibration, which are different, and furthermore, flex/wing weight (fuel) changes the dynamic modes of the vibration (long and slow vs. quick and short moves) . While coding up free vibration is easy, the bigger challenge (unknown) is integrating some impulse (force input) into the mix, more specifically WHEN to do so. In severe weather, those impulse inputs take the form of drafts and micro-changes in densities as the wing moves through the air, and on the ground, undulations in the terrain/taxi speed. I have no idea yet how X-Plane quantifies 'bumps in the pavement', turbulence or severe weather (in XP12), simply because I haven't looked into it fully yet. How might X-Plane simulate random "drafts and density pockets" that would serve as an impulse forces on the wing?....Are they periodic based on some function? Randomized perturbences etc? Is there some dataref that says "im in a cloud"? (I doubt it). Certainly I'll be asking Austin directly first So while simple wing flex based on airload is very easy and is a better effect for long flexible wing products...on the -300, wing flex isn't as much fun to look at as 'vibration'....particularly in turbulence and those slow oscillations as you taxi with fuel in the wings...but 'forced vibration' is the more difficult situation to simulate. So.....wing flex will be simulated for sure, but that particular effect will be quite small on this relatively short wing...BUT vibration....yea...thats the one we want, especially me. The MU2, with those big wing tanks are just crying out for it also. I just need to determine how to best implement the perturbances, the magnitude and timings of them. Best case, X-Plane will provide some sort of dataref that represents the perturbances directly and those will be adequate... worst case, all I'll get is some "turbulence level" number and I'll have to determine my own wing motion timings somehow....and thats where potential "evolution of the effect" may come into play, where we release with a more basic effect and then refine it based on experimentation. I can tell you I want this one to be 'just right' pretty bad! and will work on it until it is. -tkyler

Simple explanation. If I were to say, "we won't update the 737 until I have the FMS working like I want to", then I would not be here, I'd have taken another job and the 737 would be retired at Version 11 of XPlane and the IXEG would be done and I would be done with XP development. The workload to address those items you mention exceeds the workload for the items we have chosen to update for XP12. That is why those are getting addressed at a later time. The reasons those items weren't addressed have been explained previously and at this juncture, it doesn't matter whether folks (myself included) like it or not. I have to move forward from today. It is important for me to convey that "later" in todays context, with me working full time on XP, isn't as vague or as far on the horizon as "later" was a few years back when even we didn't know how much "later" we would find time to work on things with our other work schedules. I made a decision to not pursue other jobs and try to make X-Plane development work for me full time... put a plan together with the consult of some other folks whose opinions I respect, and am now executing that plan. The MU2 was a springboard to the IXEG update and the IXEG update will springboard to the 733 upgrade work we all would like to see....and dare I say.... future products. This is the path required to keep my X-Plane development work going and not let these products die out. It was simply a cost/benefit strategic decision that dictated the order of work. -tkyler

I do have my limits Bulva no flushing toilets and opening luggage bins. I'm not modeling the lavatory interior either (yet). Us flight sim folks are a diverse bunch and we each gain our own individual pleasures from elements of the simulation in differing areas. Some folks just like being in and around planes/cockpits and how it pleases their eye, some like "button pushing", some like the cognitive elements of navigation, some like the "visual pleasure" of being at altitude and looking down and others the sounds. There is one particular youTube reviewer who likes to get the camera about 5cm from objects and if the textures aren't high-rez at that distance, he laments it as some kind of product deficiency...so there's all types of consumer prefs. It has always been my philosophy to "evolve towards reality in all areas", except that all areas can't be achieved at once, hence the prioritization based on our experiences with customer feedback. As you point out, adding more and more possibly eats into performance and until we push the limit, we don't know how far we can go. We don't want to leave 'money on the table', if we don't have to, thats comes with risk of falling into obsolescence as others push forward. But we do go into these areas with strategies to address 'what ifs'. Using preferences to kill heavy FPS suckers is one option.....downsampling the textures yet another...providing alternative, low resolution objects another, etc. You can be sure that good performance is high on my list, and we'll have strategies in place to manage that. I'm a huge fan of configuration preferences...and hence one reason we're moving to imGUI. it will allow us to more quickly and easily impelement interface options for users to manage all that stuff. -tkyler

Thanks for all the sentiments and kind words. I myself am happy to be working on X-Plane full time and will strive to continue to do so. I can 'partially' sympathize with those who are...lets say...."on the fence" to put it nicely, regarding upgrade costs for software development, as I myself am one of those old-timers who came from what I like to call the "golden age of software" where it would obviously be great to buy it once and get upgrades forever, but as it stands, I now have at least 4 software subscriptions to software, billed every month, that is constantly evolving and some don't have the 'obvious features' I want and I understand it now as a developer. It used to be we could model a few polygons, slap a photo texture and we're done, because that's all the technology could handle. Now I have to model a few million polygons, slice them up and lay them all out neatly and texture them all and it takes a lot longer than it used to. I never had to worry about detail lighting before because X-Plane didn't have it, now its a whole "lighting pass" by itself. Same for sound engineering, etc. The technology has expanded a lot faster than the market. For those of us who remember playing Sublogic / Microsoft Flight Sim in 1981....we've come a long way technologically and I for one love it! The growth comes with some pains. I'll note that X-Plane dev requires more specialized knowledge now and finding folks with that knowledge and time is quite hard to find so its a challenge to execute what we now have the ability to produce. After nearly 20+ years of messing about with X-Plane, the important thing, I believe, is to keep moving and there've been some 'not insignificant' sacrifices in the background so that we can keep moving on this X-Plane work...as niche as it is. Its defininitely a labor of love and we all have to live with who we are. I figure if I can do what I love, I'll never work a day .....but I do need a paycheck to keep at it. I appreciate everyone out there who understands that. Thanks again. Back at it. -tkyler