Glider, sailplane, soaring, please! [Feature Requests]

This is fantastic Keith, just the sort of imagery we need to help promote gliding in MSFS.

Yup, Mt Fuji :slight_smile:

3 Likes

Mont Blanc in Aerosoft Discus
20 Kt S wind, out of Sion heading West
Enjoyed it so much I made my first ever Youtube 🙂
https://youtu.be/WPdnXJlJE4Y

Apologies for poor quality!
Cheers
Keith

1 Like

Wow, dude.

More videos, climbing Mt Cook in New Zealand and South Downs, UK :)
All my MSFS videos will be in MSFS Gliding Playlist

Cheers
Keith

1 Like

@SleetingPipes @PaulFalke can you confirm that Winter vario in the Aerosoft ASK21 is working in “total energy” mode? Test would need to be in still/clear air, no wind/clouds.

Fly >80 knots and pull up - the needle shouldn’t go positive. This is the main test, showing the obvious difference between a “TE” gliding variometer and a simple rate-of-climb instrument.

More detail, all of which was programmed into the instrument for FSX:

As you pull +ve G pulling up into the climb, the needle should briefly indicate a little more sink as the wings are loaded. As you ‘push over’ at the top of the climb and unload the wings, i.e. ~ zero G, the needle should briefly approach zero before showing the normal amount of sink as you return to +1 G at the top of the climb.

In steady flight the gauge should do a reasonable job of allowing the L/D / polar of the glider to be checked - the TE compensation should work completely independently of how accurate the flight model L/D is, but at the moment I don’t know if the ported flight model for the ASK21 has turned to ■■■■ in MSFS (I did these FSX instruments some time around 2008 (?), and have long-since lost the Aerosoft downloads).

Can you look at the behaviour with gusts? TE instruments are inherently sensitive to gusts, and those tend to be really badly implemented in flight sims - a gust on the nose of the aircraft in reality represents an injection of energy into the aircraft, and the simulation of gusts tends to be too large, too rapidly changing and too sharp edged compared to RL so the TE instruments have to be hacked to compensate for that (i.e. the ‘programmed’ gust filter has to be more aggressive, so the response of the instrument is consequently slower). The good news is Asobo have already discovered their ‘gusts’ were ridiculously overpowered so they’ve dialled-down their impact in the prior patch, but it would be a miracle if they’re correct yet - the setting where you must have at 50
100% gusts is nonsense, I don’t know why they don’t allow 0
100% gusts.

Behaviour during the pull looks right, less good for the push though I might have been too gentle - I’ve added a video showing this.

The flight model isn’t particularly good on a simple imported model - need to do a lot of tuning yet.

The vario responds very rapidly to gusts, pretty sure something is broken in gusts - maybe the simvars? All of my videos prior have been with gusts at minimum and the TEvario is frantic. The netto vario is good but over-reads I think


Gust test video - https://youtu.be/nhImXpuL0EI
Cheers
Keith

Hey it feels like we’re doing serious science! Thanks for the test video. The winter vario “total energy” compensation is definitely working. You are indeed a gentle pilot - I was expecting the pull-up to be at 80
120 knots at maybe +2G and the effect on the vario would be much more noticeable - then a firm push-over at the top in RL would lift the dirt up off the floor of the glider so I assume that’s negative something G. Without gusts, the vario is accurately giving the sink rate (say 2 m/s i.e. ~4 knots) at a forward speed of ~50 knots, i.e. a glide ratio of maybe 13, which is about half of what it should be, but at least we know.

I feel a bit smug that I guessed the gust behaviour would be bad, but really hope Asobo fix the gusts as a result of implementing a TE vario in their own glider.

For the record, in case a miracle occurs and Asobo read this, my open-source TE calculation in the absolutely awful FSX XML reverse-polish programming language is:

   <Comment><Value>*******************************************************
                CALCULATE TE (sink is negative)
     **********************************************************************
     </Value></Comment>
    <Element>
        <Select id="Select">
            <Expression id="expression te">
                <Minimum>-5.000</Minimum>
                <Maximum>5.000</Maximum>
                <Script>
    				(A:AIRSPEED TRUE, meters per second) d * 
    			 	19.62 /  			
    				(A:PLANE ALTITUDE, meters) + 
    				0.25 * (G:Var2) 0.75 * +	
    				d (G:Var2) -			
    				(E:ABSOLUTE TIME, seconds)
    				0.25 * (G:Var1) 0.75 * +			
    				d (G:Var1) -			
    				r (&gt;G:Var1)	
    				/			
    				r (&gt;G:Var2)				
    				0.05 * (L:B21_302_te, meters per second) 0.95 * + 
    				(&gt;L:B21_302_te, meters per second)
			    </Script>
            </Expression>
        </Select>
    </Element>

Or also open-source in Lua for X-Plane (“–
” are comments):

-- calculate TE value from time, altitude and airspeed
function update_total_energy()
    
	-- calculate time (float seconds) since previous update
	local time_delta_s = dataref_read("TIME_S") - te_prev_time_s
	--print("time_delta_s ",time_delta_s) --debug
	-- only update max 20 times per second (i.e. time delta > 0.05 seconds)
	if time_delta_s > 0.05
	then
		-- get current speed in m/s
		local speed_mps = dataref_read("AIRSPEED_KTS") * KTS_TO_MPS
		-- (for calibration) local speed_mps = dataref_read(sim_speed_mps)

		-- calculate current speed squared (m/s)^2
		local speed_mps_2 = speed_mps * speed_mps
		--print("speed_mps^2 now",speed_mps_2)
		-- TE speed adjustment (m/s)
		local te_adj_mps = (speed_mps_2 - prev_speed_mps_2) / (2 * 9.81 * time_delta_s)
		--print("te_adj_mps", te_adj_mps) --debug
		-- calculate altitude delta (meters) since last update
		local alt_delta_m = dataref_read("ALT_FT") * FT_TO_M - prev_alt_m
		-- (for calibration) local alt_delta_m = dataref_read(sim_alt_m) - prev_alt_m
		--print("alt_delta_m",alt_delta_m) --debug
		-- calculate plain climb rate
		local climb_mps = alt_delta_m / time_delta_s
		--print("rate of climb m/s", climb_mps) -- debug
		-- calculate new vario compensated reading using 70% current and 30% new (for smoothing)
		local te_mps = prev_total_energy_mps * 0.7 + (climb_mps + te_adj_mps) * 0.3
		
		-- limit the reading to 7 m/s max to avoid a long recovery time from the smoothing
		if te_mps > 7
		then
			te_mps = 7
		end
		
		-- all good, transfer value to the needle
        -- write value to datarefs
        dataref_write("TE_MPS", te_mps) -- meters per second
        dataref_write("TE_FPM", te_mps * MPS_TO_FPM) -- feet per minute
        dataref_write("TE_KTS", te_mps * MPS_TO_KTS) -- knots
		
		-- store time, altitude and speed^2 as starting values for next iteration
		te_prev_time_s = dataref_read("TIME_S")
		prev_alt_m = dataref_read("ALT_FT") * FT_TO_M
		-- (for calibration) prev_alt_m = dataref_read(sim_alt_m)
        prev_speed_mps_2 = speed_mps_2
        -- finally write value
        prev_total_energy_mps = te_mps
        --print("B21_302_te_mps", B21_302_te_mps)
	end
		
end -- update_total_energy

If anyone wants more details (Asobo?) I will be happy to point to the aircraft that have my instruments in with thousands of lines of additional code (e.g. for Netto and speed-to-fly), all of which is open-source. But as a MINIMUM any glider should have at least a TE-compensated vario.

Hello MSGamerTag01,
this is a complicated test procedure you give me. I will try it.
Why Asobo did this 50% to 100% noise nonsense? Quite simple. The FS2020 weather engine is the FSX weather engine. And to make it hard to detect, they increased the minimum noise level.
But at 0 kn wind speed 50% noise does not matter :slight_smile:

Thanks a lot man for your TE equations. The Lua source code is fine for FS2020 wasm instruments. The programming language is C++, but the target is a virtual stack machine, the wasm.
By the way: I am an old FORTH guy. I love reverse polish notation :slight_smile: .

The variometer is very nervous. I think that is the ■■■■■■ implementation of noise in the Asobo weather model. Like actual_windspeed = (1 + random() * noise_factor) * windspeed. And random() is a number between 0 and 1 and. Every simulator time step you get a number that has no “cause effect” relation. This is wrong. Nothing in real life “jumps”, everything goes slow or fast up or down.

I just started a weather model wishlist-topic because I felt it was sorely missing. Quite a lot of weather related discussion is hiding in this gliding thread. It might get more visibility if it’s also discussed in an appropriately named topic, so please feel fee to voice your opinion over there as well.

Another video , with a 120 KTS pull-up, in the Discus this time as it has both Netto and TE varios.

I think the Netto behaves better

I had a Forth compiler on my old Spectrum but didn’t get on with it
I’m an old assembler man at heart!
Cheers
Keith

do you think its worth to buy a aerosoft discus to convert to fs2020?

Not really, better wait for Iris Twin Astir.
I bought the Discus for P3Dv5 - though its FSX only I knew the K21 worked well in v5. Flew it for just a month then got into the MSFS alpha
but don’t regret buying the Discus now.

Imported FSX aircraft aren’t as good as native MSFS - the gliders get airframe sounds but no vario beeps or airbrake sounds, gear sounds work but loop so need turning off.
The Discus needs texture work on the cockpit and gauges, K21 benefits but not essential.
The flight models aren’t particularly good in MSFS without some work.
Click spots in cockpit are a mess, radio, C4 and PDA don’t work.
Cheers
Keith

Definitely not. The “XML” instruments on the 3D panel work (i.e. all the ones with moving parts like needles) but bits all over the plane will almost certainly never work properly in MSFS. E.g. the original SDI C4 variometer sound is audio/C++ (the real C4 makes a variety of different sounds depending on what mode it’s in, which for most FSX pilots will be like trying to understand a chaffinch). That has zero chance of working in MSFS.

I’m not sure of the gauge programming strategy in MSFS. XML gauge script kinda ‘works’ but no-one in their right mind would use that as a scripting engine in 2020. FS2002/2004/FSX gauges were (are) programmable in C++, which most people used for complex gauges as XML was the only alternative but this introduced compatibility issues (i.e. cryptic crashes, blue screen, whatever) every time some windows programmer added an update to Windows so I sucked it up and used XML.

A modern game should have a purpose-designed scripting plug-in (of which Lua is an excellent example) and it seems to me that the ‘webassembly’ solution from Asobo is more to help people port FS2004/FSX C++ code than the ideal solution for a new scripting plugin.

Maybe Javascript will work as efficient code for gauges and animations, with or without the HTML display. Maybe some Lua bridge. Who knows.

i found the aerosoft k21 on my old hdd and most gauges seem to work.
and it flies nearly as good as in real life. but i need to work on the elevator


Wind without gusts!
Smooth and peaceful ridge soaring ![:slightly_smiling_face:|16x16]

Just create a weather preset file with wind and no gusts 
 how hard can that be?
Cheers
Keith


See More

is it pssible for someone here to make a thermal mod??

It’s easier than I thought
just go into the custom menu and delete the gust speed - don’t put a zero, that gets changed back to 50 , but empty is apparently OK and in the sim there are no gusts!
Cheers
Keith