Litjan

Running out of lua memory could be pretty random - happening one flight, not the next one. We haven´t changed any code that would increase load on lua memory, so seeing it now may be total coincidence. Or you have added stuff to your installation recently that increases the load. Other products may not rely on lua in the way the IXEG 737 does, so you wouldn´t see it with them. Try to clear out at least some of your (many many) plugins when running the 737, there are a few that you won´t need when flying it (like extra FMCs, etc) Cheers, Jan

The same goes for this one.

Hi and thanks for the nice words. I am sure you have seen this video, where I answer the question you are asking in detail (it has been up for a few days...)

You have run out of memory, your last line in the log says: G64:1177.568: Memory Allocation Error: Run(timer): xs_sound_engine: not enough memory You need to reduce the number of add-ons you run, especially other plugins that compete for lua memory allocation. Cheers, Jan

No way on the delete - I am in favour of leaving posts like this up as they can provide valuable guidance to people with the same issue. Thanks for confirming the fix - this makes these threads even more valuable. Cheers, Jan

We say "Cargo kotzt nicht, Cargo motzt nicht" (Cargo doesn´t puke, Cargo doesn´t complain) Or "Paletten statt Purseretten" (Pallets instead of Purserettes). We sometimes used to fly cargo at night with our 737 Quick-Change versions...and we also had one D-ABWS that was actually a cargo aircraft. We take pride in our ability to fly idle-power smooth descents (well, the Boeing pilots do) - the ideal way is when you don´t have to add power (or use the speedbrake) until 1000´ AAL. It takes a lot of experience, planning and some luck to work out - everyone has their own secret formulas and special way of doing the math. It usually involves aircraft and airport altitude, weight, speed, wind profile, expected remaining distance, ATC constraints, other traffic - and also strength of nerve, tide of the seas, phase of the moon, and the current position of the Dow Jones index . Cheers, Jan

It reminds me of the "no cockpit" bug we saw with the "show vortices" option enabled... which was a semi-legal OpenGl hack ;-) Cheers, Jan

I have never seen that. Strong suspicion that its one of the shader hacks you mention. Cheers, Jan

Hi there, not sure about the avitab. It should be on - at least for the "turnaround" and "ready to fly" states... Make sure you use the little "power" button on the EFB, maybe you turned that off? I know about the temp on the PROG page (and wind readouts!), but there is also a temperature readout on the instrument panel that you can use...you just have to switch between SAT and TAT to see the right temperature... which is a bit of a pain, I agree. While you wait for us to implement the PROG page temperature, you can use this "rule of thumb" to calculate SAT: The difference between TAT and SAT is roughly the Mach number - 50. So for .76 the difference would be 26. It TAT is -20, SAT is -46. Works out pretty well... The PROG page is WIP but we will fix it up for sure! Cheers, Jan

Well, for the bleed air I could say that it works - the engine isn´t putting out any pressure anyway so there is no way to really confirm this ;-) Chees, Jan

Mostly. The reverser will be disabled and the generator breaker will be openend. The bleed air off is not implemented yet... Jan

Nope.

Hello Roberto, the terrain can only show on the left (CPTs) side of the EHSI. You have to have the WXR SYSTEM switch to ON, and the Terrain Pushbutton as well (unless there is a terrain warning, then it will pop up even without that). It will also only show terrain when you are BELOW the terrain elevation - otherwise it should be in "peak mode" and only show you the highest peaks around your plane, plus in green the highest and lowest terrain elevation on your EHSI map. Cheers, Jan

Hi Enrique, please don´t take this as an excuse that our VNAV is not working very well - it should be and we have full intent on fixing it. But I flew the 737 for 10 years, another 6 years of 747-400 and too many years A320... it is a very rare circumstance that I have descended (or seen my FO/CPT use it) using VNAV. Most of the time your routing is not predetermined (vectors, shortcuts) or you are subject to ATC limitations (early/late descent, advised rates of descent). So for me (and many of my fellow pilots) VNAV is a gadget that serves very little practical purpose. I think VNAV is so important to many flight-simulator pilots because they lack the ability to make accurate descent calculations in their head and they also think that it is "cool" to watch the plane glide down all by itself (and then autoland!). I think that is about as cool as using a Tesla´s autopilot when playing a car racing game . Oh and yes - we do eventually plan on making a cargo variant for the 737 (I see the pattern!) Cheers, Jan

Glad you got it working. Hardware and software combos are really tough to troubleshoot, especially with us not being at the customers computer to really troubleshoot. Cheers, Jan

Your thoughts are noted. We are working on that. In addition to the description on the website you mention, we also have this post up - ever since the plane went on sale first: Jan

Hi Enrique, VNAV descents are really quirky, still. We are working on that - it is not your fault! You did the correct thing - intervene with FL CHG or V/S when things don´t go well. Cheers, Jan

I am not aware of that. Keeping the yoke at its "present position" seems to be a feature in VR, rather than a bug. I assume that LR has coded it because VR users can not "feel" the displacement of the yoke or stick, so they have a hard time trimming (and of course they can´t click trimming buttons like they can with a joystick). I think if you memorize the visual position of the yoke at neutral (you can see that pretty well where it connects to the ground) you can center it manually well enough. I flew a bit with just the VR wands on my Oculus and it worked fine - but obviously needs some getting used to. I would probably prefer to use my hardware joystick, throttle and rudder pedals. Cheers, Jan

Funny, I always hear that the most important issues are the doors, wingflex and holding? Can you guys get your priorities worked out so we can start working on that? Cheers, Jan

Yeah, I am not a computer expert, but I gather that the amount of free RAM or VRAM is not the issue - it is the amount of "file calls" that the operating system can handle. It´s like having a hospital with 10 doctors in it. You could easily add a few stories to the hospital, it still couldn´t handle more patients. So the idea is to whittle down the number of things your computer is trying to do at the same time. Running plugins, loading scenery, doing other things (background programs, browsers, etc.) I am pretty certain that other customers with identical hardware have run the plane just fine, so the interesting question is: What is unique about your setup that brings out these errors... Cheers, Jan

No, it is likely related to running the beta version of Gizmo. It may work fine on one day, not on the next, or even the next session. Has to do with memory assignment and such... Unless you accidentially set the option to "hide pop up window" it is likely due to running the beta gizmo. Jan

We need to eventually animate the .5 kHz... Cheers, Jan

Maybe some out of memory condition that won´t allow loading additional sounds. Try to load the plane at TXKF and see if you get the same errors there?

Just wanted all VR flyers to know that I have spent pretty much the last 3 days with Mmerelles (Manuel from Patagonia, of all places!) to get the plane VR ready. We (well, mostly him) made a vrconfig.txt file and Tom is right now converting a lot of manipulators that gave us trouble to modern and VR friendly manipulators. I know that I said in the video that we won´t support VR control of the thrust levers in 1.31, but it turns out that we will - there will be a "clickspot" on both levers (towards that center gap) where you can grab and push them simultaneously. The only obstacles remaining to flying in VR that I see now are: poor resolution (depending on your headset it can be hard to read exact values off the instruments) inability to access the IXEG pop-out menus (need to do your flight setup in 2D) Need for rudder pedals (you can steer by grabbing the tiller, but for real crosswind operation you would need hardware rudders) Inability to "trim" easily in VR (although you can grab and rotate the trim wheel very naturally in VR, no pop-out handles yet, though) Necessity to return yoke to neutral to engage autopilot (it won´t snap back to neutral when you let go as it would in a real aircraft). We will have a dedicated thread for VR when 1.31 ships to collect feedback and ideas for improvement. Thanks again for helping, Manuel and also a big thanks to Matheson from VrLabs who also gave us valuable insight and helpful hints in making this happen natively. Cheers, Jan

It looks like you are still running the "MarginalGround traffic" plugin. From your log.txt: Loaded: Custom Scenery/KLAX - Los Angeles International HD/plugins/GroundTraffic/mac.xpl (Marginal.GroundTraffic.KLAX - Los Angeles International HD). Try without that, please? Thanks, Jan