ha5mvo

There is a rather vocal group that had made it their vocation to sing the praises of MSFS whether those are justified or not, so those "different views" hardly ever get underrepresented around here. To the point... the only "slap in the face of developers" as you put it, is coming from MS to the likes of Damian by shutting the door on an undoubtably better weather engine, on a weather radar, historical weather, a user friendly camera system and similar features we all grew accustomed to with non-sandboxed platforms.

Because they are not attached to anything of significance! Suppose the garmin is great. Mount it on a default 172 and its no more than a lipstick on a pig. The list of decent addons for the MS/LM sims is fairly short. Historically it would start with the PIC 767 and include the PMDG boeings, the Labs busses, Lago/LH MD and majestics dash 8 and since V2 the bus from Fenix. The freeware Tu154 for FS9/x also deserves an honorable mention. Might have left out one or two, and there are probably a couple of decent GA planes but personally I have interest only in what I don't get to fly normally in real life. Anyway, the point is, there are very few top quality addons as they require an awful lot of research, labor and eventual refinement. For that reason you can not expect, nor get those out of the box. Historically the default stuff was no more than bloatware and I don't really expect that to change. For some reason I don't foresee PMDG using WTs boeing avionics for their next project. Time will tell, I suppose 🙂

Truth or false will depend on your standards....

Truth is, that anything default is just garbage. This is the case across all platforms and isn’t unique to msfs (and no, inibuilds stuff is light years from being top tier as some here repeatedly suggest). As a matter of fact, there are only a handful of addons that come close to being simulation rather than toys and their developers accomplish that in spite rather than because of whatever genetic tools they are offered. Ideally, a platform should offer flexibility and accessibility instead of requiring hacks and clumsy workarounds as well as a steady stable target. In that regard, msfs has still got a long way to go.

The ideal situation would be an open platform where specialists like Damian will be able to do their thing and MS will cooperate and accommodate.

From the qrh : A320 – CONFIGURATION FULL, LANDING DISTANCE WITHOUT AUTOBRAKE Actual Landing Distance, GW 130,000, Dry: 2,920 feet This is the ALR determined during flight tests, security and failures coefficients apply. Note that landing distance is usually measured from a height of 50 ft to the wheels stop

If you are just interested in refreshing the efb after setting the bg.jpg file, can't you just add the line window.location.reload(); at the end of the previous script and run it as an aircraft automated script?

@Reset XPDR Given that the posts are probably going to move for the next sim update and that the current application can’t connect to the current sim beta ( and that the app is a continuation based on the work of 2 previous developers). How difficult is it going to be adjusting the app after the next update ?

I do just that. What happens in practice though, is that the correct image is turned to into bg.jpg (corresponding with the simbrief data), however it fails to load and is automatically deleted after about 10 seconds leaving the background as it was and no bg.jpg in the folder. For some reason, the tablet won't refresh with the new bg file. If you bring up the remote tablet on http://localhost:8083/ - you will indeed get the new background showing up but not in the VC

I wonder if I'm doing something wrong. I'm running the script and it indeed identifies the code and creates a correct copy named bg.jpg. However, the efb screen itself does not refresh from the default background AND a few seconds after running the script the bg.jpg is deleted. Any clue to what went wrong?

Yes! this was probably the issue. Sorry about the late response but weekdays don't give me too much of spare time. At any case, ticking said option indeed resolved the stutter problem. Strange I never came across this before as I am using the utility from day one.

No. Expert mode on, no Tlod min, no Auto target. I did try though, ticking the various options on or off which did not make a difference. what do you mean by “sim values”? thanks!! // Mike

With the last two test versions I am getting considerable stutters in spite of good frames. Did not happen before. Granted, its a taxing scenario - FT CYYZ/FSLTL/ Fenix a320. I am getting 30 FPS with Vsync on (which is the max cap) with a target of 27 , however, there are stutters at constant intervals (which is to suggest some external interference). If I close the program, the frames do indeed drop to 24-25 but the constant stuttering stops. I had no such issues with previous versions.

Its an external application that changes tlod and olod to trade off graphics for performance and vice versa

That’s normal for iae engines.

McDonald Douglas published an article many years ago called "The High Cost of Hard Braking" where it detailed the cost of each landing with and without autobrakes and where it discussed the lead-footed pilots that cost the company more money by their inappropriate braking technique. It suggested that accurate final approach and touch-down speeds as well as prompt use of reverse thrust often meant that braking use could be minimised. In other words the skill of the pilot in reducing braking to a minimum. The speed at which the brakes were first applied was an important factor in the cost of braking. The higher the speed the more wear and tear. Autobrakes are applied on the instant of touch down (high speed) although they back off to maintain a specific rate of deceleration with use of reverse thrust.There may be occasions where a turn-off at a specific taxi way is needed operationally but even then judicious combination of reverse and manual braking means braking is at a minimum. Often braking is not needed until below 80 knots where energy requirements, and thus wear and tear, are less. Again, observations in the simulator have shown that pilots addicted to autobraking for whatever reason, when asked to use manual braking, tend to get quite rusty due to lack of basic skill required of manual braking techniques. They overreact by hammering the brakes manually causing jerking and oscillation of the aircraft as they try to maintain the centre-line.Is this just another example of automation dependency where pilots have lost the skill and finesse of careful considered manual braking? Repeating the FCTM opening advice on autobrake use: "Use of the autobrake system is recommended whenever the runway is limited, when using higher than normal approach speeds, landing on slippery runways, or landing in a crosswind." Are pilots getting lazy or has the accent on braking automation led to pilots being apprehensive of their own ability to use manual braking? I suspect the latter...

How do you select 4k? seems that only 8k are currently being offered

You need to understand a simple truth, and yes, I have been flying airplanes in the real world and teaching others to do so for more than 20 years now but this doesn't mean a thing in this context. The simple truth is that in the real world you fly by the seat of your pants - this applies across the board, from a cessna 152 to a jumbo 747. It is something you can never achieve neither on a multimillion level -D simulator and certainly not on a desktop one. So what you're left with is something to correctly fly by the numbers. Those numbers remain the same regardless of whether you are a type rated pilot or a complete amateur. Granted, 99.9% of the users will use the sim flying from A to B on autopilot following the magenta line....In this scenario the FM is of little importance. For those who wish to simulate abnormals, an accurate FM is quite crucial.

Would you be so kind and elaborate how did you determine it's on "a different level?" (you've heard so on youtube won't count). Did you test its pitch\power curve at different weights? perform Airspeed Unreliable checks? How about turn rates?

There are better ways to evaluate the fidelity of a FM than examining the landing. There are just too many variables involved, too few of which can be reliably quantifiable! A better approach would be to run easily reproducible tests with published set of data. A good example can be the unreliable airspeed procedure for instance. Climb or descent rates under standardized conditions can also provide objective and reproducible information to be compared against published data. If, for example, a loaded airbus is pitching to 20 degrees on takeoff then you know something's wrong - even if you've heard some youtuber pilot telling you it's "great"!

No, as I said - didn’t touch it.

Not sure that's the culprit. I never touched that stupid expansion and still managed to get all the profiles messed up.

Al'lo Davar!

Either switch to developer mode or look up on flightsim.to the shift z addon that brings you that functionality into msfs - quite handy

I guess that's why Fenix are still struggling with it, PMDG had been quite open with their frustration and A2A defenestrated it altogether. Those are the top dogs in the industry. I suppose it's ok for those who are fine with something generic. If you're aiming higher then the platform should provide with something more flexible and persistent. The same applies, by the way, to the weather engine.