tkyler

Well a EFB solution isn't out of the question ultimately, but we don't currently have a pipeline for developing such at this instant. That being said and with the IXEG relatively stable for V12, our dev roadmap does include a retooled graphics library that will enable us to develop more flexible graphics and where we draw those graphics, so I think in the long run, we'll be able to address this. May be for VR users, a less graphic intensive "button list" on the side might be more palatable in the interim? i.e. you give up the fancy pixel-hogging graphics and just have "utility commands" in a vertical button list? Just tossing this out there....I couldn't say what kinds of commands would be helpful if this was viable. TK

if your particular problem is solved with FTSIM+ 'soundpak'....and that soundpak is simply replacement WAV format files...then that would suggest that its not the underlying openAL engine causing the issue and possibly a specific sound file in some capacity. An audit of what sounds FTSIM+ implements vs. ours would be needed. A 3rd party soundpak doesn't have to replace all sounds for example...and since I'm not familar with FTSIM+, I couldn't say what exactly they provide. TK

No need for myself...possibly others for future reference....but I don't think so in this case. I record these instantly as I read them. I admit I haven't looked at those default "in-air" starts much....but its on my list and I will. Starting to turn my attention back to the Moo finally for a bit. -TK

PLEASE See following:

Hi @Bulva...yes, this GUI is a "patch" for the majority of non-VR users and I'm sorry you VR guys are getting 'hit'. Laminar is aware. There is much retooling going on under the hood still with regards to graphics and I am certainly retooling with VR in mind. It will be a while as the retool has implications with future projects, but I'm not going anywhere. Just curious though...does X-Plane's "UI scaling" settig change anything in VR? -TK

This IS the issue. The Main Menu popout can cause issues for multi-monitors and VR users....but I should have it show by default, MY BAD, I'm sorry.....how to correct.... You can access the Settings/Pref GUI via X-Plane's own menu as shown below OR....by the new commands I provided HERE. (See ADDED section) Plugins > Gizmo64 > Windows > IXEG 737 Classic. From there, select the preference panel and UNCHECK the box that says "Disable Main menu Popout"....from there you should be good with the Main Menu Popout. So sorry folks. TK

I completely override X-Plane's fuel transfer, so the transfers you describe are happening "in my plugin"..i.e. "from tank 1 to 3. What is SUPPOSED to happen....is "plugins get the last say". In other words, when X-Plane has its own logic for fuel transfer and then writes to a dataref...then us plugins get the opportunity to write and our values are supposed to be final. ..but clearly X-Plane is writing to the m_fuel datarefs also. This is the essence of our challenge with plugin programming, always 'fighting' with X-Plane as to who has the better logic and gets control. BUT....I did talk to a Laminar rep and we don't believe the base fuel transfer model to have been "redesigned"...maybe tweaked, but not overhauled...so I've filed a bug. -TK

So below are the descriptions in Plane-maker of the fuel tank "role". The tooltip on the left is 12.07...the one on the right is 12.08 Laminar definitely been playing with the fuel code...*sigh...always a fight figured this stuff out. 100.00 bucks says the tooltip on the left was written by Austin 12.08 IS beta....so I'll file a bug report as a start and then use other channels if I have to. tk

Ok...that did NOT take long. I downloaded 12.08 and without a doubt...I see what you're talking about, the fuel transfer is definitely NOT working correctly in 12.08. It is fine in 12.07...just checked before downloading 12.08. I'll poke around with Laminar to see if its a bug or a "new feature" I have to now code around. I know Laminar is getting more and more systems detail, and when they do...it usually breaks our custom stuff...because there's always some aspect to a design their generic implementations can't cover....and if they don't leave us a loophole via plugin....it can get ugly. Thx for reporting. TomK

I haven't tried the Moo in 12.08 yet, but will be quite soon and will check this. ...you're comment though doesn't fully make sense. The engines get their fuel from tank 3 yes, but the fuel transfer system pumps fuel from the tip tanks to the main tank as the main tank depletes.....so you would observe no fuel coming out of the center tank #3 until the tips / outers are all empty (or the fuel transfer system is off). ....so seems fuel transfer is correct for this point (a) you made. Regarding tank 3 being "overloaded"...you're showing 166 gallons in screenshot 2.....and Jet-A at about 6.7 lbs/gal comes out to about 1100 lbs...which is exactly what the main fuel gauge shows....so don't quite understand your point there either. I don't see tank 3 overloaded at all in those screenshots. The only thing I see "odd" about those two screenshots are the outer fuel tanks (2/4) seemingly losing a small amount fuel with fuel still in the tips. Now all that said...I certainly won't put it past X-Plane to introduce some funny business...so I certainly will double-check the fuel systems soon. Thx. TK

There's not quite enough info in that screenshot to make a determination. You can execute an LNAV route without PERF data and when doing so, the route defaults to approx 210 knots (small radius turn) as it can't calculate speeds without some basic info. Now in such a case...if the real FMS...in the absence of "plan data", uses real time speeds / altitudes and adjusts the routing dynamically in real time...that would be new to me and something I'd want to learn more about. ..but I can think of several scenarios where an FMS just can't know what exactly you're doing and doesn't want to take on the responsibility of "guessing". tk

well certainly any patches are welcome if they work. Considering we have over a hundred custom sounds...a custom sound engine and custom code to drive all of those...which we have to now excise all that code while not breaking anything in the process.....and then porting all that code into FMOD params....yea....many many weeks. BUT...it should then be good for many many years. A worthwhile tradeoff IMO. -tk

fixed yes...released no. This is because I have a few more items to fix to include in the next patch. I've been waiting to get through the IXEG upgrade period (which ends in 9 days) to make sure it was suitable and then will immediately take a turn on the MU2....so its on the very near-term todo list. -tk

we've been discussing this internally and while I was planning to work on the FMS / FMOD sounds concurrently.... I believe I'll just do a deep dive on the sounds first and convert to FMOD, which could take upwards of many many weeks...so probably best just to get this solved. Our OpenAL is definitely one of the more 'legacy' technologies we need to move on from asap. -tk

that is exactly it. tk

@Pils When the aircraft is 'populated', the weight and baggage is randomized "per passenger"...in addition, the per passenger contribution to the cargo vs. overhead is also considered and randomized. I do this for all aircraft seats. So the "possible" weight contributions "per seat" are determined first. THEN, I randomize the seating arrangement, and that is what shows up relatively evently on the graphic...but the actual values "per seat" I don't know. THEN...I add up all the occupied seats "per zone/station" and set the masses for those stations. We're still working through GUIs in VR Bulva....there as some headaches dealing with it, but we're looking at the integration for sure. -tk

There is a bell curve randomness to the mass values themselves, to both pax and payload, but not to the seating locations, i.e. thats not a weighted algorithm, so it distributes rather evenly. As Jan mentioned, we discussed this but he said, 'were building a flight simulation, not a payload simulation', and in the end, the result is an overall weight and a CG location, which is settable more easily now. The main goal was to keep users "in the cockpit" for fuel/loading instead of having to go to the XP menus, which pauses the sim/sound and kills the immersion. I may revisit this at some point as a personal challenge, but the FMS/FMOD work are waiting for their turn and that will take quite a bit of time so I'm anxious to get started on that. -TK

I would recommend we hold these reports until after the next patch, which may resolve this. In switching to our new GUI, we began switching over to a new preference system, which tracks settings between runs of x-plane. Because of the depth of our custom programming though, this is a 'piecewise' process we tackle in digestable chunks. When we released the V12 port, we defaulted to X-Plane's fuel setting GUI and in doing so, we disabled our own code that sets the fuel state at sim start. Well just so happens this same code also sets all the radio frequencies and some knob positions. The new "preflight gui" for the next patch "re-enabled" our code to manage fuel and in doing so, this also brings back code that tracks the frequencies. Regarding Jan's observations, if he's testing on our normal dev build (which is highly possible, dare I say probable)....he wouldn't see the issue since I've fixed it and I slipped it in under his nose with the new GUI. I do know that I re-instated code that does handle frequency state at startup...so I'd say lets get past this next patch, see if that clears things up and if not, we'll start debugging then. As of today, Its looking to be within the next 7-14 days for the next patch to release. -tk

may be, but not for a long time. This is the same answer given each time this question is asked. And the video does not show "a cargo version", but rather the "cargo hold" for a passenger version. Different things. I'm sure you're quite right Pils...and we'll keep that on our 'nice to have' list to be looked at in the future. Its mostly a space issue atm, given that its integrated into the "main GUI window". So just a matter of redesign and working it in at some point. -tk

Getting close to next patch. As Q8 mentioned, the Preflight menu was a "step back", but I still contend we had to take that step back to take some steps forward. So in the next patch, the following GUI will be avail on the PREFLIGHT tab. From this GUI, you'll be able to set the start state as usual (via the RESTART button + checkbox state). Also the quick "Plan fuel calculator" for quick fuel calcs is back. For loading fuel, you'll now use a "Aircraft fuel request" panel to add your fuel. You can hit the 'typical' button, which uses a common fuel config for most short hauls...or the "plan fuel" button, which takes its fuel amount from the "plan fuel calculator" ...or finally, you just move the sliders manually. Each of these actions constitutes a 'fuel request'. As fuel is requested, then you will see the amount requested below, along with the estimated time to refuel. If you have the "real time fueling" pref enabled, then this will be on the order of minutes normally, but if that preference is unchecked, then the estimated time will show only a few seconds. To actually add the fuel, you hit the 'start fueling' button. The 'meters' on the right show the requested fuel (red lines) as well as the actual fuel. The load sheet GUI is used to configure the weight and CG of the aircraft, by adding passengers and cargo and shifting the cargo around. I don't have passenger shifting atm, they're currently 'well balanced' throughout. You can drag a slider to add/remove passengers. There is also a "weight factor" slider, that defaults to one, which represents 'average weights" for humans / baggage"....BUT if you want to overload the plane, or simulate say, a plane full of Sumo wrestlers, then you can up this slider to add some extra "density" to the passenger cabin payload. There's a pulldown to view the cabin vs. cargo hold. When viewing the cargo hold, there'll be two sliders, one for "additional cargo", which is cargo not related to the passengers, which many airlines do carry...and there'll also be a "bias slider", where you can shift cargo between the front/rear holds to adjust the CG range and get the trim units value. Adjusting the cargo hold loading between front/rear is the preferred way to tweak the CG. Sorry we had to backtrack a bit before we could get this back in, but hope it helps maintain immersion by not having to go to the default XP menus for fuel and payload. Down below is what the cargo sliders look like (more or less...this was a few days back and there's been some slight improvements since then) -tk cargo_slider.mp4

I'm not following. The gold lines on the 2D uv map don't go to the end of the UV map. Are you wanting the gold lines "on the top" to go all the way back to the taillight? -tk

Do you mean a second flight? after landing and then putting new information into the CDU? for a next flight (2nd leg?) Or literally "the 2nd leg of a flight plan route you are currently flying"? Thx.

We're thinking "time is money". My mortgage payments runs on a timeframe...my internet fees...my software subscriptions, my commissions.....special offers in the mail......all time frame limited to encourage folks to act to keep the economic cycle moving. Time and money is inextricably linked. Without this principle, no business would survive and we've have no products...no add-ons, no x-plane, etc. Who is John Galt anyhow. TK

@Pils I can say that the throttles / reverse lever operation, in general are a decade old paradigm and have always bugged me a little bit. As usual a "usability pass' is in order where we evaluate every control / animation and think of better and more robust was to interact with these things. In the early days, we were limited by several "isms" with X-Plane for sure, but I think we have more leeway now and can use PREFs to cater to differing preferences ...so we'll be looking over this again I'm sure. I'm looking to animate more controls over time as I 'weave' some of my library animation code from the MU2 back into the IXEG. -TK

Fixed for next patch.