-0303-

Thanks for agreeing. Observed (external view, pause to note rpm) that dust cloud is gradual and proportional to rotor rpm. I think dust intensity should be proportional to both rpm and collective. Multiply rpm * collective: Example 50% rpm * 50% collective = 25% dust cloud etc... making for no dust cloud no matter the rpm given zero collective (as in video). Updated start post. ~ ~80-100 rpm may or may not be a cutoff, that's where I stopped seeing dust. Might only mean I failed to see it. Terrain and ground "wetness" matters obviously but that's different. Should green grass not dust so much(?) belongs to separate thread. This thread is solely about when and how powerful down wash occurs. But imagining terrain & wetness : Multiply rpm * collective * terrain-type * wetness? Then there's snowing, raining... In multiplayer, dust onset also gradual, so not simplified (didn't expect it to be). Should mean all required clients <--> server signalling already implemented. Only the client side "make dust" criteria needs updating.

File under interesting, anal retentive modeling, less than top priority... Video: Luxembourg helicopter trims tree. Before takeoff, rotor clearly fully spun up, near complete absence of dusting and then sudden heavy dusting accompanied by audio change (collective pull?). This real life example may or may not be extreme: Again, almost complete absence of dust cloud until collective pull. Makes sense, only with collective does the heavy down wash starts. All helicopters obviously. Connect dust cloud graphics intensity to collective pull. Checked of course, landed on grass, in DCS ground dust cloud identical whatever collective setting. Update: Observed: Dust cloud graphics is gradual and proportional to (only?) rotor rpm. Fix: Make dust cloud proportional to BOTH rotor rpm AND collective setting. Ie max dust cloud at max rpm with max collective raise. But also max rpm with zero collective would result in minimal to no dust cloud as in video. Video deleted. Same video, cut for time(?) but still shows the point, no collective = no dust, collective = dust. https://today.rtl.lu/news/luxembourg/a/2306561.html

This bug is documented for at least 12 years (by June 1 2025). It affects every "old" plane up to and including the F-5 without exception AFAIK. I personally made tracks for Spitfire, Bf 109, P-51 & F-86 back in 2021. Drift on shutdown might be a real thing (I dunno), though it generally shouldn't because the instruments are deliberately made slightly bottom heavy. The real bug is they never self correct. Shutting engine on/off a few times is the quickest, most convenient way to get the Artificial Horizon (AH) "wrong" so one can rev up and confirm it doesn't self correct as it should. More convenient than flying around half an hour... This is not a minor bug. It makes the AH completely useless. It always drifts while flying. The AH is one of the "sixpack", the six basic flight instruments , not a peripheral instrument. When they fix this (as promised ca October 2024), they must include the "tumbling". Old AH will tumble whenever pitch exceeds typically 60 degrees or roll exceeds 110 degrees. Source Pilot training film (timestamp 2:53). Reason is mechanical stops protecting the instruments. Of course the angles can vary from plane to plane but I won't be a stickler if every plane tumbles at the same angles. I'll be quiet for at least a year before start whining about the Bf 109 tumbling the same degrees as the Spitfire. (maybe it does, maybe it should tumble 10 degree different)... There are (more modern) instruments that only tumble on pitch. I imagine once the basic tumble algorithm is in place, it'll be easy to just insert different angles following plane documentation. In many cases it's easy, Spitfire, Hurricane, Mosquito all use the same AH... Nor does the tumbling need be physically perfect. I'm fine if it's somewhat randomized, though watching real Spitfire tumble video I get the sense the tumble mostly go maximum wrong, taking maximum time to self correct. Makes sense instrument being blocked at a full roll or a full looping at internal mechanical stops and remaining there after leveling out until self corrected. Hmm, second thought. If rolling until just 10 degrees beyond internal mechanical stops and then aborting and rolling back again would the error be just 10 degrees? As opposed a complete roll when the error would be the stops limit (110 degrees)? Assuming it tumbles 180 when it tumbles (and my thinking is correct). If that's true, the algorithm would be "simple" making the post-tumble error "correct". AH tumble Spitfire video. Tumbles a lot. Instrument easy to see. AH Spitfire startup self correction video. Another Spifire AH tumble video. First tumble at 17:01. Unfortunately a film cut at 18:05 but watching from 18:05 (AH shows 90 degrees wrong in level flight at 18:15) there's non cut film until finally self corrected at about 26:30. Tumbles at 17:01, 17:18, 17:29, 17:41 (more times I tired of counting), 27:15, 31:40, 32:40, 37:50, 38:47, 39:08, 39:40. Notice, first and last films, the AH tumbles whenever the instrument hit the stops regardless if the Spitfire is actually close to level. The instrument only cares about it's internal position. A correct algorithm would act like this. Caveat, I don't think AH maintenance is a priority on veteran planes only flying VFR. Perhaps a "good" up to specs Spitfire AH self corrects faster than ~9 minutes.

Sensing the gravity ie... Flown gliders in real life. Flying "fast" G load shifts are instantly and powerfully felt with even minute stick movements. I imagine feeling the G shifts operating the collective could be equally distinct useful input, especially while landing. Like sitting on an adjustable height chair and moving the lever. One continuously, subconsciously, feel and balance the G while approaching ground? Akin to riding a bicycle or flying planes, once trained, muscle memory replaces thinking actively about every move. On second thought this probably applies to cyclic as well (though not as much), while hovering if nothing else. A helicopter, in ways a plane doesn't, can quickly change direction in all 3 axis and the pilot "feels" the inertia.

Same problem UH-1H & other modules. Nothing to do with FFB since I don't have one. Fast logged response suggests not USB or stick hardware problem either (my tests, scroll down). Question to 3rd party developers. Ping fat creason. Do you (or DCS) model "realism delay" and could this be a reason? In Bf 109 the pilot couldn't wrestle full deflection at high speeds. The F-86 has no direct stick to surfaces connection, they're moved hydraulically at whatever pace. A simulated "realism delay" wouldn't be improper. But regardless, the delay seen on ground in Spitfire, Bf 109, I-16, P-51, UH-1H etc is wrong. I know I can slam the stick to the side instantly in a real life small plane (glider). It doesn't take close to a second. Question: Is it the 3rd party developer that implements a "realism delay" (if that's a thing) or is it DCS? If 3rd party develops the flight model doesn't "realism delay" belong to the 3rd party developer? Could this just be delayed animation regardless if a "realism delay" is implemented or not? My tests: Thustmaster (TM) Warthog joystick, throttle and MFG Crosswinds pedals. IR head tracking. No FFB stick. Instant movement in TM Device Analyzer but stick animation and controls indication delayed. Tried connecting only the joystick to USB (1 device instead of 4), no difference. No difference running the CPU at 1.2GHz or 2.4GHz. No difference springless FFB stick mode or default (the UH-1H "special" setting). TM Device Analyzer logfile (five attempts): 226 ms 186 ms 173 ms 147 ms 203 ms ie how fast I could move the stick full throw left (X = 32768 -> 0). Example 16 datapoints 147 ms (X, HH:MM:SS:sss): X,32696,11:50:07.721 X,31876,11:50:07.731 X,30672,11:50:07.740 X,29148,11:50:07.749 X,27442,11:50:07.759 X,25540,11:50:07.768 X,23354,11:50:07.779 X,20894,11:50:07.788 X,18244,11:50:07.798 X,14864,11:50:07.809 X,11948,11:50:07.820 X,9150,11:50:07.828 X,6590,11:50:07.838 X,3928,11:50:07.848 X,1948,11:50:07.856 X,0,11:50:07.868

It's a good thorough video. Didn't know, never seen a complete explanation before. He even goes down to the atomic level, explaining the boundary level, very interesting and not nearly as complicated as it may sound (*1). But he says that part is not required to understand the whole video. I think video could be significantly shorter if he repeated himself less. There's three things that all add lift (had just a vague understanding, 3rd factor I didn't know at all): Angle of flat underside imparts force by redirecting a vector of the air 90 degrees downwards. Imagine the incoming air split into two vectors, one of which 90 degree down. Then Newtons law of action / reaction. The Bernoulli thing, kind of, except not really. Higher pressure compressed air in front of the wing leading edge leads to a lower pressure above the wing and hence higher pressure below the wing adds lift. Air stream adheres to the wing topside (and underside for that matter)via the boundary layer. Since the typical wing shape includes a downward slope of the topside, the top air stream departs the trailing edge angled a bit downwards. Again split this into two vectors, one of which is 90 degrees down. Again, Newtons law action / reaction. A flat two dimensional wing angled into the wind would indeed add lift and fly but not as efficient as the classical wing shape with a curved topside, flat underside. But all airplanes do fly with the flat underside angled versus the oncoming air stream. The angle depends on speed, may be very slight at high speeds and larger angle at slow speeds in a intuitively easy to understand relationship. What happens in a stall, if I understand it correctly, the air stream departs it's orderly flow from the topside, completely loosing component 3 and also component 2(?) of lift. *1) Boundary layer description reminded me of the "wind gradient", how wind speed decreases rapidly close to the ground. Stole illustration from here. My glider flying textbook makes the same comparison I noticed picking it up. The reason why there's a rule of thumb formula, stall speed x 1.5 + 0.5 x wind speed (formula from glider textbook) to add landing speed depending on wind. Or else, as the image intuitively conveys, having a good stall speed margin at 10 meters (assume 30 knots at 10 meter ) could mean unpleasantly stalling at 5 meters. ASK13 stalls at 31 knots. Applying the formula: 31 x 1.5 + 0.5 x 30 = 61.5. So indicated airspeed at final should be ~62 knots in this situation. If only 46 knots at 10 meters, it will be at stall speed at 5 meters (assuming 15 knot wind at 5 meter). An embarrassing, or worse, day for our intrepid aviator). Air flow boundary layers at atomic level looks like this except at nanometer, micrometer, millimeter scale. Atoms in contact with the wing doesn't move at all, slightly further away move a little etc.

Steering works fine for me, single player and multiplayer (Hoggit training). Ran both tracks (Red_Camarada), single + multi. Single ran straight, multi veered off left but watching control indicators right brake worked fine. Seems OP just didn't coordinate brake, steer, throttle. Took control of single player track. No problem steering. Never used assists.

Ed/Add: Added two waypoints on a hunch, now it seems to work. File extension insists on being ".miz". Assuming this is correct. Tried again, this time airborne, saved while flying. After: - reloading saved mission (into Mission editor) -clicking the little green "fly mission" icon getting "MISSION OVERVIEW" screen - click start, get this error message: Mission cannot be saved due to errors! Aerial-1: All waypoints (2-2) have locked speed and surrounded by waypoints 1 and 2 with locked time! Wasn't trying to save, was trying two fly, some kind of auto save failed I guess. Mission is as vanilla as they come. No waypoints. Literally only placed a Spitfire "spawn rwy" Batumi took off and saved mission. No "triggers", nothing else whatsoever. ~ summary things learned: - if taxi on ground after spawn, position and damage client plane not saved. -if saved in air, need to have waypoints otherwise error. - not a bug necessarily, just limitation: Noted client plane details not saved: taped gun ports, gunsight on/off, assume we get a pristine plane with a set of defaults settings any time resuming mission.

I tested save mission. Single player. Spitfire. Spawned. Shot all ammo. Taxied some 100 meters, nosed over (broke propeller, tail up). "Save Mission Caucasus2.miz". Quit to desktop. Restart -> "Mission Editor" -> Open Caucasus2.miz Select vehicle (Spitfire) again. Spawned to spawn position (not 100 m meters down, off rwy), fully intact. The only thing saved seemed to be out of ammo. Unless I mistake how to restart a saved mission. But why then would ammo be depleted?

The bug is 11 years old at least and affects not just Warbirds but all old planes up to and including 1959 F-5 (reportedly, myself confirmed the bug in F-86. Attention NineLine. Besides the Artificial Horizons (AH) not self-correcting to the gravity vector it also doesn't tumble on roll exceeding 110 degree or pitch exceeding 60. It spins around smoothly 360 degrees and it shouldn't. Compare the AH in a real Spitfire below. Recently discovered this video showing this very clearly again and again and again... Watch the "roll angle" indicator (DCS manual name) along the AH lower instrument periferi. Every time it exceeds ~110 degrees the AH tumbles. This Spitfire just keeps rolling and looping never giving the AH the time it needs (10 minutes?) to self correct. While being and staying "wrong" after the first roll, one can still observe how it tumbles any time the indication reaches 110 degrees to the left or right. The indicator looks like it "bounces back" while the horizontal line rapidly moves up or down. This happens a ~dozen times. Real Spitfire video notes: 0 - 28 seconds. Intro, Chris Hadfield sings (ugh) rolls twice and the AH tumbles because it encounters the mechanical stops at 110 degree roll. 6:35 - 6:50. Engine start. AH at rest is about 45 degree roll misaligned but spins up and self corrects in 15 seconds (much like the P-51 AH here, 12 seconds). 7:41-7:46. Taxiing, Left turn. AH misaligns slightly, 1-2 degrees. This AH error is caused by the centripetal effect on the inertia of the pendulous vanes and the slightly bottom heavy instrument housing (see educational video, timestamp 9:10 - 11:22). 8:25 - 8:35. Taxiing, Left turn. Same thing, more pronounced. 10:28. First roll. Hard to see but at 10:31 when it reaches ~110 degrees it tumbles because of the mechanical stop. When we see it again at 10:34 it's wrong but stable until ... 10:36 when AH again reaches 110 degrees and it tumbles again. Hadley keeps rolling and looping, one can see how the tumble coincide with 110 degree indication again and again. Some of the tumbles caused by 60 degree pitch as well I'm sure. Ed/add: A nice touch would be the AH randomly misaligned on spawn and then rapidly self correct on engine startup (like above and just about every Warbird video engine startup I ever seen...) ~ Adding boilerplate" for Artificial Horizon (AH) bug threads. Old "classic" AH needs minimum two functions to work correctly. DCS AH lacks the second. Hence DCS AH doesn't work at all on any old plane up to and including the F-5. 1. A spinning gyro that provides "rigidity in space". 2. Pendulous vanes that constantly corrects the gyro towards the gravity vector. There's also a third attribute which DCS does not model at all. AH tumbling whenever roll exceeds 110 degrees or pitch exceeds 60 degrees. This because of built-in mechanical stops that protects the mechanism. Source educational video timestamp 02:52. A simple test if any AH works correctly: - Airstart - Bank steeply - Cage, uncage, roll level. - Fly some minutes straight and level. If AH doesn't self correct it doesn't work correctly. If uncageable, like the Spitfire, just do above after noticing misalignment, the AH **always** self-corrects it's part of its basic function. End "boilerplate".

AI Zero? One of the best videos about the Mitsubishi Zero I've ever come across. Drachinifel, invited a very knowledgeable guest.

Artificial Horizon bug still here, 11 years and counting.

Used the Win 10 Start -> Eagle Dynamics -> Update Beta. Ie I didn't start the game to update. Got prompted Restart now? Chose No. Started the game without rebooting. Took a hop in the Spitfire, worked fine. Seems restart not required. Crafting a signature: "Artificial Horizon all old planes as bugged as it's always been, At least 11 years and counting."

My throttle seemed to be fixed possibly just by restarting DCS. Having the same issue with P-51. Restart is required but not enough. Must clear and reassign throttle too. Fixed Spitfire, I-16, P-51, T-51, Bf-109 throttles by Clear, reassign and restart DCS. CLEAR every place throttle axis is assigned, reassign to throttle & restart DCS. https://forum.dcs.world/topic/353264-patch-discussion-july-2024/?do=findComment&comment=5478652

Restart DCS seems to have fixed both missing FC3 validation and throttle issue on Spitfire. Edit red font. After restart I spawned a Su25 and A10A. Assuming all the other FC3 also present (no warning window after restart). FC3 probably present first start as well. The Mission I spawned includes FC3 planes, I just didn't try to spawn any FC3 until after restart. Thrustmaster Warthog throttle. First start Spitfire missed the throttle. Got the red "!" someone took a (P-51) screenshot of up thread. Did a short takeoff land using +- keys for throttle. Did CLEAR on throttle, reassigned throttle, detected it fine but still not working. Restarted game, throttle now works fine. Only thing now I get the message I can install the FC3 planes, but they're already installed and working. Maybe if I accept reinstalling FC3, I'll get the message "already installed" Accepted reinstall in Module Manager and restarted twice over. Still get the message I can install FC3. After clicking OK (Module Manager) restart happens so fast it's obvious it doesn't try to install anything. Module Manager still insists I can install FC3. Oh Yeah, noted Spit Artificial Horizon is as incorrect and useless as it has been for at least 12 years and counting...

15 minutes rare high quality footage of Hellcats taking off and landing. Also the batsman / LSO is shown a lot, something I've rarely seen. Also Corsairs and one other type but mostly Hellcat. The paddle wheeler (really) USS Wolverine 1945 on the Great Lakes.

Came here because I recently learned about the "Dustbin", the back-to-the-carrier navigation system for British carriers and would the British F4U use that? Of course we'd need a British carrier for that and of course the Americans had their own system. ~ Never heard of "Hayrake" until this thread. Found a very accessible description of Hayrake here. The "Dustbin" like Hayrake sends a narrow directional signal. It rotates at 1 RPM. At zero seconds past the minute it transmits due north, at 15 seconds past it transmits due east etc. The pilots synchronizes their watches before takeoff. Going home, if a pilot hears the signal at 15 seconds past the minute, he knows the carrier is due west. The antenna is a round, hence pilots called it the "dustbin". The "Dustbin" gives an exact bearing, not Hayrakes 30 degree slices. Dustbin reaches out to ~100 nautical miles, Hayrake to ~275. ~ Have yet to find a description other than Drachinifels. This video below at timestamp 16:00 - 18:40 describes it. Trivia, same video at 31:35 he Drachinifel describes an Avenger with an air-to- surface radar as the 1944 "prototype AWACS". It used its radar as air-to-air to coordinate the strike force.

Though all documentation supports DCS AH being erroneously modeled, all the proof one needs is simple common sense. The DCS AH lacks self correction, it drifts and therefore it's useless. Doesn't matter if it's cageable or not (manually correctable in clear skies). In zero visibility neither is correctable. Unless doing acrobatics one never need to correct the AH because it self corrects. Even after acrobatics it'll correct itself, it might just take a few minutes. I think the vast majority of DCS users fly in clear skies and ignore the AH because they never need it. The AH behavior annoyed me from the very beginning but for the longest time I thought I was missing something, that I just didn't "get it". I couldn't, didn't want to believe DCS had modeled it wrong. Until I thought about it and realized this behavior is stupid on it's face and can't possibly be correct. ED team can not not know this, the AH function must be 101 elementary for any professional or serious pilot because the AH is one of the six basic flight instruments. I'd prioritize this bug over hundreds of minor graphic flaws.

To unbury the lede the DCS AH does not work correctly in any old plane up to and including the F-86. This because a key modelling of Artificial Horizon (AH) self correction is completely missing rendering the DCS AH useless for any real world simulation. It drifts and it shouldn't. ~ It is not true that WW2 Artificial Horizon (AH) technology lacks correction. The correction mechanism is the pendulous vanes that continuously self correct toward the gravity vector. Bench example of actual P-51 AH self correction. Un-mute. It's true that small momentary errors are induced by a 180 degree turn (for example). But adding an additional 180, ie doing a full 360, the opposite error will cancel the first error out. So forever turning will not skew the AH erroneously. The actual error is caused by the centrifugal force acting on the inertia of the free-hanging pendulous vanes. If one performs a 180 turn and then flies straight and level, the small AH error will quickly self-correct by the pendulous vanes. Actually it's wrong to think of it as having to fly straight and level to self correct. The pendulous vanes works continuously at all times though they can be momentarily overcome by violent maneuvers. It's obviously insane to have to fly perfectly straight and level for AH self-correction. An additional important limitation applies to WW2 era AH (and in to the 50's). For mechanical protection the AH has built in mechanical stops at +-60 pitch and 110 roll. In practical terms the AH will go bananas, coco-for cocopuffs at every roll or looping. DCS AH doesn't do this. It should. This real life Spitfire video shows this. Roll at 17:01, 27:15, 31:40, 32:40, 37:50, 38:47, 39:08, 39:40. Also note self-correction (full 90 degrees) over 9 minutes from 18:05 - 27:00. This video training video explains much of this. How it works, momentary errors caused by turns (180, 270, 360), by acceleration or deceleration. Also mentions the 60 and 110 degree mechanical stops. First 11:25 minutes covers vacuum driven (WW2) AH. This bug is more than 10 years old (in that thread read kablamoman). Not just P-51 as mentioned, every old old plane up to and including F-86. Testing this is easy in a plane with a cageable AH: Cage AH, roll 30, 60, 90 whatever, uncage, roll level. Fly straight and level for some minutes (10 min should be enough). If it doesn't self correct it's wrong. Tested P-51, Spitfire, Bf109, F-86 myself. All fail.

I just managed to drain the P-51 battery. When battery drained (propeller stopped spinning) the gear indicator green dims to near nothing on pushing starter. Also fuel pressure goes to zero, meaning pump looses power when starter engaged(?). Adding ground power & hit starter prop spins, gear lamp dims very slightly. Nice. I made a video three years ago about a Spitfire ground power bug. Comparing with P-51. Insert texts explain. I just repeated the video steps. Everything works just like three years ago. P-51 good, Spitfire gets no ground power (unstartable). Last version Open Beta 2.9.2.49940. Ed/add: Re-verified (Spitfire) with drained battery doesn't start with Autostart nor after a repair command. It doesn't repair. Maybe if I prang a wingtip to force repair? ... maybe some other time.

Low resolution and settings got ~7% fps improvement. Maybe more outside cockpit. Would need to downgrade / re-upgrade to make more than an approximation.

It's green in the DCS Spitfire manual. It's green in my video from 2021. Pilots notes says green: Pilots notes, IX, XI & XVI Not just me ... Recycling NineLine's screenshots from the "oil dilution" thread.

Is it just me seeing this? ~~~ Turned yellow after the October 19 Beta update "DCS 2.9.0.46801 Open Beta" "Updated cockpit textures" I believe. Recycling old screenshot from November. Latest version "DCS Open Beta 2.9.1.48335" still yellow.

Obviously it's ridiculous to have to maintain a high rpm on the ground in order for the Artificial Horizon (AH) to work correctly in the air. If it works, it's just a band aid to prevent AH going wrong even before the wheels leave the ground... ~~~ ~~~ Ye olde classic or "steam gauge" AH have two functional attributes, the lack of either makes it useless. DCS lacks the second. I've run tests for hours without self correction (Spitfire and/or P-51). 1) A spinning gyro to keep it rigid in space. 2) A self correcting mechanism that continuously corrects it towards the gravity vector (pendulous vanes). A misconception I struggled a bit with: Centrifugal force of continuous turn will bias the AH. No it won't. A 180 turn will bias it. An additional 180 to full 360 will bias in the opposite direction, canceling the bias out. ~~~ ~~~ How to test A proper test is simple. Whenever you notice the AH is misaligned just fly straight and level for 10 minutes (enough for a real Spitfire). If the AH hasn't substantially or completely corrected itself, it's wrongly modeled. Using speedup (CTRL Z) is fine. A plane with cageable AH is quick and easy to deliberately misalign for testing purposes: Bank, cage, uncage, roll level. An uncageable AH is more work. Either fly around for 15 - 60 min until it's misaligned or ... A quick (somewhat) and dirty test. Spawn runway, shut engine off / on until AH is misaligned "enough". Four cyclings is often enough for 30 or even 60 degrees off. Now, lock brakes, open all cooling flaps, set RPM enough for good suction, use speedup, run and watch for 10 minutes or hours. Any properly functioning AH will correct itself within minutes. See any number of real life videos. ~~~ ~~~ As Kablamoman says, this seemingly is a problem with every DCS "steam gauge" plane. Just re- tested the Spitfire. Engine cyclings took AH to 45 degrees off. Running two (2) hours, it did not self correct, it got worse, nearly 90 degrees off (see pic). RPM held at 2000, but engine broke and quit at two hours, hence zero RPM in pic. Test start at 8:36, note clock left 10:36 'ish. I got the Spitfire reported 2 years ago. spitfire AH test 2 hours from 45 to near 90.trk

Confirm, I see this on Spitfire. Spawn engine off twilight. Kosher installation, no mods.