tkyler

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.

Fixed for next patch. Note that using these commands will "auto-save" the prefs on close if you're on the PREFS tab...so no need to hit the SAVE button when closing/toggling. -TK

I assume you mean a command to "move the landing gear lever to the OFF position"? ...to bind to hardware or a keystroke? I've added this in, using the default X-Plane command you mentioned. -tk

You know Pils, it did cross my mind ....and for the life of me I cannot remember why I did not go ahead and add in the others.....all 15 lines of code of em...probably had tunnel-vision DOH

the fact that you're getting the message at all indicates that things are probably working. There is a course a valid range to enter, and the number value you enter is checked against the "units" you have set in your prefs. I think a preferences file has been going out with the installer....and folks prefs are getting overwritten by the one in the installer. So first thing, check your preferences to see if you are in "imperial" or "metric" as it were. If you enter a number thinking you're in one unit, it will come up INVALID as it will be out of range. If that's the case, sorry for the inconvenience, we obviously need to preserve users PREFS when updating. -TK

yea...when certain texture files have certain pieces of information in them...in the alpha channel, etc..it caues X-Plane to change rendering state and stuff can start drawing weird and not "getting light", etc......and we had an alpha channel where we weren't supposed to....so just a matter of time before it caught up to us. Glad to move past this one. TK

NOTE that the B733_mcp image file (png and dds) will be gone in the next patch. It was a hack of a system from 2010, before the DDS textures...and I've redone it to proper XP standards with modern lights. @maub Unsure how that may affect the text at night....be curious to know..even if that texture is going away. @Bulva replace the two DDS textures with theses PNGs and you should be fine. B733_mcp.zip

Ok this one is fixed for next update. We had really tricked x-plane's lighting system way back when to simulate multiple light sources on a single surface...but with XP's real lighting...this is normal nowadays. The problem was the way we had our assets set up for export...so a small rearrangement was required (typical of remodels), but this should be good for the next patch. Its looking pretty good now, day and night. -tk

Verified...this is attributable to the DDS textures. In 1.5.0, we shipped PNGs...which are more reliable, but take up more VRAM. Laminar recommends DDS for optimization. NOW....the MCP lighting is a bit of a special beast...and we MAY be misusing the DDS textures for this guy. For the next patch, we'll ship PNGs for this object at least. ...in the meantime, I'll talk with Laminar about whether this is in their court, or we misbehaved with DDS and have to find another way. -tk

Was looking into this just now and wondering if there's something more sinister here. I made some changes to the MCP and just assumed it was messed up via your report...but now, testing it in both day/night with all light levels...its looks fine on my end....however....there are some things I can check...clearly someothing is going on for you. For the pedestal..looks like you have the pedestal "panel lighting rheostat" down.?

Fixed for next update. When in AUTO mode, now mode C, so PE should pick it up. When set to "ON", then only mode A -tk

Certainly possible and I've made note of this to revisit. For a little while, I'll be repeating the following info so as to make sure folks know where the IXEG is going. The IXEG is undergoing a remodel, mostly under the hood in code, but the outcome of this work will be integrating the kinds of requests you're making here. -tk

@manguras There will be a temporary compromise here....because of our older 3D exterior at the moment. For now, I've put in a small billboard light source for the next patch. Note that I'm reworking the 3D exterior to be high-resolution and in doing that, will be creating a 'proper' recessed wing light with lens cover. But I hope the billboard suffices for the interim. -TK @cloudfreak1 In your case, you're correct the wing lights didn't show with winglets, a bug. Both fixed for next patch -TK

This is a bug....Note that the IXEG 737 is getting "remodeled" under the hood, to handle future improvements. So some of our systems are "in migration" from old tech to new. Preferences is one of those systems and I obviously missed this pref. I'll be looking to get this cleaned up quite quick. -TK

Let me take this opportunity to ask a question. We get some requests for Cargo. Are you more interested in only the exterior LIveries of cargo? or...you also want a full 3D cargo interor, etc? Modifying the 737 to handle "no windows" is significantly easier than putting in a full 3D cargo interior. -TK

The MU2 autopilot has a "roundout" rate based feature. So it should denote capture on the ALTSEL....but the ALT (hold) light itself won't illuminate until the final captured altitude...50' I IIRC. It it doesn't illuminate at all clearly within 50' of target...certainly that's worth a look on my end. TK

Thx. will try and retune. We had a bug report that the MCP was too dim at night....and the day/night behavior of X-Plane's LIT texturing system is like a see-saw (teeter-totter) where trying to get both day/night texturing looking good is a non-stop battle. I'll keep at it. Thx for reporting. TK