-0303-

And F-86. F-86's stick has no direct connection between stick and elevator or aileron surfaces (rudder pedals are still directly mechanically connected). It's funny, the F-86 stick works exactly like a spring loaded game joystick except trim moves its center position. Hydraulics sense the stick position and moves the surfaces accordingly. The only forces the pilot feels are the springs which are there to simulate stick forces. So its stick won't fall over on the ground either. From the pilots point of view he moves the stick and trims as if it were a previous generation "traditional" mechanically directly connected stick. This is mentioned in the manual, maybe not clearly but a DCS'er uploaded the F-86 original mechanical drawings and there one can follow how it works.

When Shinano was sunk, it only carried Ohka's in terms of flying materiel. They really didn't care about tail hooks.

I've flown a dozen gliders... I've never seen pneumatic instruments ASI, VSI, Altimeter be anything but smooth with one educational and a little amusing exception (*1). Common sense tells me if some design error made pneumatic instruments twitchy on the prototype, this error wouldn't be let into mass production. Engine instruments are a different category, maybe those could wobble, I wouldn't know, but developer should not add things without evidence to make things "livelier". I would not want all wobbly instruments on the same "slider". It would be annoying since the pneumatic instruments doesn't wobble AFAIK. Unless they actually have specific information that they do, which I doubt. Googling wobble and pneumatic instruments, bunch of weekend private plane flyers don't expect wobble in Cessna and Pipers, they think it's broken. One suggestion is unplugging static air intake on back of instruments to distinguish if it's instrument itself or tubing. *1) Pulling the stick hard (to hard) while turning the Schleicher ASK 21 , the static air intake comes into turbulence, making the ASI, VSI and Altimeter twitch rapidly and synchronously. Makes sense as all three connects to static air input. How VSI works in two minutes.

You're right. I'm sorry, I didn't read your starting post carefully enough and stupidly assumed an uninformed error.

That is how they are supposed to work. Trim tab moves in one direction, aerodynamically pushing the bigger surface it's inset in in the opposite direction.

I know "Replay" is just streaming recorded commands, not "true" replay. Still I found it surprising that view angle and zoom aren't consistent even within the first few seconds. Does that mean it doesn't record all inputs even when streaming the commands itself? But that is NOT what I wanted to focus on and I didn't call it a bug. Apology for derailing thread. I wanted to highlight that P-51 replay seems qualitatively different compared with Spitfire or Bf 109. Turn, ball & VSI are orders of magnitude worse in "replay fidelity" compared to Spitfire, Bf 109. If one could explain the Turn, ball & G-meter to "twitchiness" of new gear code, what about VSI? Assuming simulation runs exactly the same with the only difference commands are streamed from a file instead of direct user input, how can the VSI indicate climb or descend 1000 feet+ while taxiing on the ground? Raptor also notes AoA while taxiing. Tried taxiing, replay and taking command again during replay. VSI goes sane again the moment I take command, dropping, smoothly quickly to what it should show, zero, and staying there. Why is it screwed up during replay but not under control, only difference being the source of commands? Also this weirdness happened. Right wing pitch up followed by tail pitching up. Didn't touch brakes. Did touch X or Z for rudder though at tail up, coincidence? Skip first 25 sec. Alarm and red lamp on inside cockpit.

Can confirm. Caucasus server with two F4U. First view taxiing, gear down ... stayed down. Second flying F4U, also gear down. Spitfire, gear up. Bug or clueless F4U guys? Saw hatch moving when F4U approaching rwy... so it's a bug I surmised. Kosher install.

Something is off with P-51 replay. The gauges for VSI, ball & turn, G-meter differ wildly from live (also explodes sometimes). Also see Raptorattacker first video. VSI manages to climb / descent 1000 feet / min while taxiing, ball is whack and turn differ. Spitfire and Bf 109 gauges mirrors replay vs live very nicely, also they don't explode and their wheels don't dig into the ground (alternatively looking momentarily punctured as P-51 does). No comment P-47, Mosquito, don't have them (yet). Recorded P-51, Spitfire and Bf 109 live and replay, made videos. Note, HOTAS is physically disconnected, just keyboard. So HOTAS or USB, not culprits. All video: Batumi Caucasus. Lower left live, three other quadrants different replays, video frame synced to visual cue at start, sound mixed. Interestingly, every replay is different. It's not the live version and then identical replays. P-51 video: Sometimes P-51 explodes (usually at the end but once halfway and another at 3/4). Also damage list after exploding differ between replays (not in this video but often). gear breaks visually differently external viewing angle differs slightly (despite same replay file) wheels sink into the ground differently. Shouldn't sink at all of course, Spitfire & Bf 109 wheels don't. I've seen Spitfire replays differ as well, specifically external view sometimes zoom in closer. I take this to apply to all modules, all input, keyboard or HOTAS. Not calling differing replay inputs a bug, artifact of CPU busyness maybe. Am calling P-51 replay (all three: TF-51, P51D-25, P51D-30) gauge disparity, wheel digging and explodiness a bug. If this affects "new gear" P-51, P-47 & Mosquito, ED should fix it before implementing it elsewhere. There's another P-51 bug, probably unrelated because it's from 2020 at least. I'll post that separately: Unlike every other module, P-51 seem to take damage on spawn (reserved link space). If Youtube defaults to 480, change to max resolution (1440?) for best quality, helps seeing the P-51 wheel digging. Also external view data strip in middle very readable at full-screen (Speed, G's for example). Attached P-51 track. Setup completely kosher, no mods, verified install ("repair DCS"), fresh Saved Games. P-51: Spitfire: https://youtu.be/kh6BRNLgQ8Y Bf 109: https://youtu.be/h3d9BO5KWG0 20250608 P-51D-30 taxi replay no hotas Batumi Caucasus test.trk

Just noticed the four downwards sticky pins and suddenly grasped their purpose (or so I believe). The compass "sticks" at any significant bank or pitch preventing compass accumulating spin momentum. Real (glider) compasses I've seen, spins on turning (a glider turns all day long...) and keeps oscillating after straightening out. It's unreadable while turning and 30 sec or more after. But whenever the Spitfire turns (banks) the P8 compass sticks", doesn't gain spin momentum, it then unlocks at straight and level, making for a more sedate settling. Made a video, external view and compass splitscreen (two DCS Replay recordings, frames synchronized). Video White cross is north. Compass is free on takeoff, sticks on ascending left turn, unsticks at level [1:37], sticks (flips twice) while rolling. Sticks/unsticks intermittent right descending turn before landing. Funny it doesn't stick at -43 bank, but giving benefit of doubt to modelers, it's more complicated than angles, there's also acceleration. Note, pitch and bank are very readable center of video for comparison (after YT gets focused at 15s). Note to self (and interested) making the video Command line FFmpeg is a very versatile free open-source Swiss knife software for video editing. One would think GUI packaging of FFmpeg like "Handbrake" would include menued templates for common things like splitscreen. It doesn't. FFmpeg is the simplest, if not only, free tool I found for this. It's akin to linux or dos scripting, powerful, terse, complicated, incomprehensible... Anyway, found templates online to adapt. Recorded DCS Replay with Xbox Game Bar [Win + G]. Used click "Fly" scene-shift to synchronize, that's why they're staggered. Obviously couldn't click "Fly" at the exact same millisecond both videos but single stepping MPC-HC video player to scene-shift and then go "MPC-HC -> Navigate -> Go to..." gives the current video frame (and millisecond). 43 - 36 = 7 frames. Also, Right-click MPC-HC time display "High Precision" gives milliseconds. Found (adapted) command online: ffmpeg -i video1.mp4 -i video2.mp4 -filter_complex "[0:v]null [left];[1:v]tpad=7:start_mode=add [right];[left][right]vstack" Spitfire_compass.mp4 The relevant part is "vstack", stack vertical and "tpad=xx", delay XX frames. I'm sure this includes redundant syntax. Just: ffmpeg -i video1.mp4 -i video2.mp4 -filter_complex vstack video3.mp4 will vertical stack videos ("hstack" horisontal) but what's the correct syntax to add "tpad" delay? I copied and adapted something that works including redundant syntax.

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.