tkyler

@rosseloh Thx for that report. After quite a bit of investigating...it may be X-Plane didn't 'break' anything. As the sim evolves, Laminar puts in more detailed models and for older aircraft where those details didn't exist, then Laminar has to toss in some default values. In some cases, those default values provide behavior counter to the way things used to be...so while it seems X-Plane BROKE something...they really didn't I think that's the case here. X-Plane has refined their fuel transfer and 'tank types' a little ways back, but since I wasn't affected, I never bothered to look at their new system and try and leverage it...I just let my old 14 year old fuel transfer code stick around. I think they might have "tightened up" some code, which closed holes in their own code. I've been able to manually set up a fuel tank / dataref config that seems to work, but need to tie it into the cockpit controls. If it works in 12.08, the that will be a good thing and I'll move focus to the Moo for a bit and get out the next round of patches. TK

Just an update on the fuel transfer....there has definitely been some "wonkiness" in the latest update with regards to fuel transfers. The report is in their system so we'll see. Whether or not a fix "comes up short" or exposes other issues we won't know till it comes out. One of the things we see with X-Plane is "new systems paradigms" coming online as XP evolves....and the fuel tanks / transfer sequence is one of these things that have evolved when Austin worked on the F4 model. So in some cases, it may or may not be a 'bug' per se....but an 'evolution' that requires us 3rd party devs to reconfigure our ACF files. The MU2, for example, doesn't yet integrate the new "weight stations" and so this can cause some funny business in some cases and isn't really a bug, but my needing to research XPs latest features and make sure the MU2 integrates them properly. So we'll see what comes of this fuel thing....but at the least I have some input with Laminar. -tk

Hi all, with the upgrade transition finished, I thought I'd report on whats planned to help set expectations for the future and into 2024. A high priority is weening off of technologies that may cause "show-stoppers" for customers or in danger of causing conflicts as XPlane and computers evolve. This means the transition to the FMOD sound engine is first up...as we've seen some issues for customers and is a sign that things aren't going to get better. This is a pretty good sized job as we have quite a few sounds we have to port and we also have a LOT of code we have to excise without breaking other things. A port to FMOD easily sets the stage for many more years of compatibility. We don't work completely linearly...so in interstitial gaps in time between FMOD work, we'll also begin integrating in the XP11 Navdata format. Users won't see this for some time as its a big under the hood change. This is necessary not only to improve the IXEG FMS, but is also necessary for two future products with FMSs and as with FMOD...ensures forward compatibility...so this move to the XP default is also quite important. Third, we'll also begin work on the FMS VNAV / holds / performance predicitions. This work depends on the XP11 navadata to some degree, but not competely so we'll be able to make strides in this department while working on the XP11 navdata format transition also. Also, we're refactoring (rewriting) an enormouse amount of code for future-proofing and developing a new graphics library along the lines of what the RSG and TorqueSim folks are using. This will open the door to more engaging graphics for GUIs and value-added interfaces such as failures and EFBs etc. and Finally, we'll work on a new, high-resolution exterior model with new paint kit. We expect this work to take most of 2024....but it very much has applicability in the other projects we're doing so the end of the road isn't just some "under the hood" stuff on the IXEG, but also new models. Thank you for your support, we'll continue to keep working. -Tom Kyler

OK. Thx for sharing.

It was? That's pretty incredible because the 737 Classic doesn't have an altitude ladder display. ..never did. Check out Jan's old videos ...looks exactly like your screenshot.

you have winglets option on? There are no logo lights with the winglet option. Logo lights work fine for me with "no winglets" -tk

The list of bugs and anomalies I'm hearing about and seeing with 12.08 are significant enough for me to not quite trust 12.08. So it could very well be...we'll have to let it stay in the wild a bit to see what else crops up. Certainly Jan will be checking over things on his end as well. TK

That is not version 1.5.2, which introduced the PREFLIGHT menu. That is representative of version 1.5.0 / 1.5.1.

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