Art-J

^ That might be the case. I'm on a newer gen card as well, so maybe that's why I don't see it. OP hasn't mentioned what card he uses.

Yeah, you're not the only one who's experiencing it. No clue so far about why it happens, unfortunately.

Although all these new subtle details are welcomed of course, there's one major thing that concerns me - audible blade flap frequency is too high! As if we had a helicopter with more blades in main rotor, or diameter of it was lower (and thus RPM higher). The videos above do seem to confirm it to my ear, but let's take more scientific approach. One can already notice the issue using time deceleration to 1/8 and seeing that sound is out of phase with rotor movement (sound is faster). It's easier to do it in F2 external view. Actually, using stopwatch and counting the audible blade "chops" we can calculate their frequency as 2.5 per second when slowed down, which is 20 per second in real time, which in turn for a 5-blade rotor means 240 RPM. The problem is - real Mi-8 rotor at 95% setting rotates at 192 RPM (that would be 16 "chops" per second), maybe getting closer to 200 at full takeoff power, but certainly not higher. Incidentally, I've found that the smaller diameter Mi-24 rotor speed is 240 RPM in cruise, which leades me to assumption that these new Mi-8 sounds are conversion of Mi-24 ones, which is obviously not quite correct given the hefty RPM differences between both helicopters. I don't own Mi-24 module so can't compare. @btd Can you please comment?

OK then, do you use any frame-generation gimmicks on gfx card driver level? In either case, perform the usual DCS "troubleshooting trinity" and see if it helps: 1) disable and remove any unofficial mods you might be using (including the ones located in Saved Games location); 2) empty the "fxo" and "metashaders" folders in Saved Games location; 3) Run DCS repair & cleanup command to restore the game to vanilla state.

You've ben answered in the other thread you started: If you launched DCS at least once, then there is a folder created on your system partition here: C:\Users\[your windows user name]\Saved Games\DCSworld\ It might be hidden by Windows, but it's certainly there. Un-hide it if needed. You have to go there, create \Mods\Aircraft\ sub-folder manually and extract A-4 archive over there. It's the only way to make the A-4 mod work.

Probably because OP is new here and can't find his way around this forum (I don't blame him, because from navigation point of view, it is a mess for newcomers). Admins will move the thread if needed. Back to OP. Once again read what Winter wrote - DCS resides in TWO folders on your PC: a) One where the game itself is (in your case steamapps/common/DCSworld); b) the other one is in Saved Games location WinterH typed 6 posts above. A-4 Skyhawk mod has to be extracted ONLY into the latter. There cannot be any files of it left in the former.

No, not experiencing it myself in 2.9.2. If you see it on other warbirds as well, it will be more of a global issue then rather than module-specific. Kind of reminds me jittering problems people reported when DLSS, FSR, DLAA and TLAA were implemented. Do you use any of these new 2.9.xx features? I only use DLAA by the way.

Pt.1 it is then! Oh, no worries, I plan to use them as intended .

Reflected already confirmed that in the "last minute" change before the 2.9.2 went live, Ugra messed up parking positions on the map and thus in some missions you're not spawning where you're supposed to. It's gonna be fixed in the next patch, hopefully. Look around in the campaign forum section for more info: https://forum.dcs.world/forum/1208-dcs-p-51d-debden-eagles-campaign/

Ah, yes, there it is allright! I didn't plan to install all of them so was only checking the unit number. Just have to figure out now which livery it takes tailwheel and wing textures from, cause they're missing - I use only a couple of skins chosen from each pack. But I know that description.lua will give me relevant clues.

^ Hmmm.... I don't know.... The problem is - "our" beta IS the "seperate testing branch". Always has been. Some users are just more interested in testing and reporting properly (they're smaller group I suspect), while the others are more interested in getting access to new content earlier (this is majority I'd hazard a guess). The former will always be active on the forum with more detailed reports, while the latter will not. But that's just a human nature, and In my opinion this proportion will never change. Thus I don't see how creating a yet another, more closed / "elite" separate branch could solve this issue, especially when ED MUST rely on wide scale public testing because of their internal QA resources limitations. I've no idea how to tackle this problem. They have to persuade/force people somehow to submit bugs in a better, standardized, repeatable and more effective manner. Just posting guidlines in a sticky thread on a forum clearly doesn't work, 'cause some player follow these while the others do not. Maybe some sort of a separate "public" bugtracker database, which won't accept a report entry until player fills all the blanks properly (logs, tracks, screens etc.)? As for the original post concerns, let's not forget that switching to current trend of updating stable version with one big patch every few months was direct consequence of a period 3-4 years ago when OB updates were thrown out almost every two weeks and stable updates following almost immediately - unfortunately together with a myriad of gamebreaking bugs, which inevitably had to slip through in such haphazard workflow. It just didn't work. So that's quite a tough nut to crack. Having stable updates more frequently would bring long awaited fixes more frequently... along with higher number of new bugs at the same time. How to find a good balance point?

Awww.... the yellow-striped 2/SG10 didn't make it to part 3 it seems. I was looking forward to that one. Will wait for it.

Oh, youre right, there's definitely something to it (Normandy map I mean). As shown in my replay track No. 1, during takeoff attempt at Normandy Manston, while taxiing from the furthest western parking spot I got a "central / tail strut drive inoperable" failure already before I even started a takeoff roll . Granted, that was a fast taxiing and lining up, but if it happened there and then, it would happen during takeoff roll anyway. Failure happened on the western light-grey section of the runway, but I don't know if that one has a different physical mesh compared to dark-grey section, or if it's only a different texture. There was no such problem during Manston takeoff on Channel map.

MiG-21 is a bit of a special case. It started its life as a private mod made by 1 guy based on FC3 code, then got taken over by 4 other guys (at that time) who created the very first official 3rd party team contracted for DCS, then they reworked and released the plane in 2014 as fully clickable commercial module. Not long after, the team has split into two separate companies to work on other projects. So it's the oldest 3rd party DCS module at the moment and because of this complicated "half-mod, half-team" history, it just is a mash-up of FC3 code, proprietary code and a bunch of duct tape and zip-tie fixes added through the years later. To bring it to modern standards would most likely require a complete code re-write and no company will do it, unless in a form of a payware "2.0" edition like in A-10C and Ka-50 case. We know from Mag3's last year post that some form of a MiG refresh is considered for the future, but at this pont in time it's uncertain how deep this refresh will go and when it's going to happen when they're fully busy with Corsair and Crusader projects now.

OK, will probably be able to do more playing after Christmas, maybe other guys can help in the meantime as well. If you did spend lot of time on Channel already, I think my tests would just be unnecessary duplication of yours because I would guess runways surface properties are the same in your internal DCS version and the public one (?). But sure, I'll try do do some more flying off grass and concrete strips when I can. Channel versions of Detling and Manston seemed to be rather OK, although I only took off and landed on each of them once so far. It all reminds me similar problems that race and rally sim developers face. No matter how good tyre and suspension simulation is, if there are problems with track surface mesh modelling the final effect shows unforseen issues.

Oh, don't get me wrong, I can see the new model is a big step in good direction. I like how both mains behave now, it makes takeoffs and landings more challenging and, looking at these real life vids, mains seem to be quite bouncy indeed. It's just the tailwheel strut behaviour that raises some concerns for me. I'm sure further tweaks will come, but it becomes clear now that it's going to be a combined aircraft and map development problem. I only own Nevada, Channel and Normandy as payware maps, so my testing capabilities are limited.

OK, maybe it's semantics or language thing. What I meant is, in my 2nd replay track I got "Central / tail strut drive inoperable" event registered at 2:23 and the strut was still visually OK when looked outside. Two minutes and some extra bumps later, however, it half-collapsed. Thanks for further testing and cool videos. I understand that tail strut sensitivity is greater and more accurate now, but that leaves us with a wider problem affecting both ED and 3rd party devs - how many airports on various maps should be tested and reworked with better surface mesh, when even some Caucasus runways can cause such tailwheel issues (as my Kutaisi test showed).

Nah, both my tracks are recorded in OB after Tuesday patch. The point I emphasized in my post is, after taxiing, you WILL roll fast at 3-point for a dozens of seconds during every takeoff and landing. So whether you want it or not, the tailwheel assembly will be cumulating damage. My fast taxiing was just simulating beginning of a takeoff roll, or standard roll-out after landing. The strut may or may not fail in a mission where you perform only one takeoff and landing in a row (depending on which map and airbase we're trying), but with more of these it will fail eventually and I'd hazard a guess Mossie maintenance technicians didn't have to fix or replace tailwheel units every 3 missions or so in real life . I specifically avoided rolling over grass-concrete boundary, as this one has been known for causing failures in previous DCS versions already, I also avoided grass strips in my tests, 'cause concrete / asphalt ones should in theory be smoother (?). Last but not least I avoided Marianas map, which also has some rough surface mesh issues at Anderson. Just chose stock mission at Kutaisi for this very reason, not getting beyond the runway. The only grass strip takeoff and landing at Normandy I did once was at Detling and they went OK, but that's obviously not enough reference data. Your observations from other grassy airfield there are interesting, will try them when I have time.

1. What speed the target jet flies is irrelevant, because you both fly together and thus - relative speed between you and your target matters more. Not much more, however. It's going to be within 50 m/s, which is negligible compared to bullets speed of 800+ m/s at impact. 2. Because of point 1 above, bullets fly through target's exhaust for a fraction of a second, which is not enough to even warm them up much, let alone cause any melting... 3. ... which would never happen anyway. Engine exhaust temperature is shown on relevant instrument in every jet plane. For MiG-15 it's typical for all no afterburner engines of the era, which is between 500 and 600 C (900-1100 F) in cruise, closer to 700 C when at full thrust. Meanwhile, .50 API/APIT machine gun bullets had typical construction for any bullets, which is mostly copper and brass alloy jacket with steel core (plus a tiny little bit of other incendiary and tracer stuff). All these materials have melting points in the range of 900-1500 C (1600-2700 F), so they couldn't melt even if kept in jet blast longer.

Nah, I don't think that's the case. In my track I took off on main LH, then switched to fuselage for a while, then tried drops and they seemed to be feeding allright. Did it all in shorter intervals than OP though, so he must've experienced some more wicked glitch in his mission. Maybe I'll try to replicate his exact "recipe" for problem later.

@Yo-Yo, @BIGNEWY Gentlemen, here's a short replay track of a fast taxi test I did in stock Caucasus takeoff instant mission at Kutaisi. In this one, tail wheel bouncing causes some form of an initial strut failure at 2:23 (as reported by post-mission briefing and indicated by audible metallic bang sound which plays whenever gear damage occurs in DCS aircraft), followed by full collapse after I turn around for next taxiing run. Mind you, I was keeping control column straight all the time to avoid any potential extra downward force component imposed by the elevator. Granted, nobody would TAXI that fast in normal circumstances, but I think a few full takeoff and landing cycles in a row, when you do roll at higher speeds for many seconds, will be enough to accumulate damage and cause strut failure eventually. As I said previously, just one takeoff and landing cycle on Normandy version of Manston was enough to do it for me yesterday, but maybe that version is just more bumpy than ED's one. The most problematic thing is - these symptoms seem to be intermittent to some extent. When I tried to repeat the test at exactly the same instant mission to save another track, with comparable taxiing speeds, the tail was bouncing as previously, but no strut failure happened this time. 2.9_Mossie_susp_test2.trk

As BTD said in the other thread, new Mi-8 sounds are WIP. I think the hissing sound is just compressors noise, which is indeed very excessive now with any doors open, while with all doors closed it makes blade flapping and link "chirping" only barely audible. I'm more curious/concerned about higher frequency of blade flapping sound. Just as if the number of blades was higher, or rotor RPM was higher. That might be more accurate, I don't know. Will have to listen to some onboard recordings of the real thing, maybe even try to measure it in-game with stopwatch and decelerated time. All and all, I think I preferred 2.9.1 sounds overall, even if they were too quiet. Balance in 2.9.2 seems to be all over the place.

I see, better than nothing then. The Russian one is 138 pages, though.

Thanks. I'll test some other airbases on various maps as well.

^ Understood. I was thinking more about damping coefficient in general, separately from what the source of it is, oleo component or not. That being said, could you please take a second look (or ask the dev responsible) at how the tailwheel simualtion works in current public version? As shown above, we're getting tailwheel collapses even from simply rolling on the taxiways and runways. Mine happened at 60-few % fuel load, standard ammo, no bombs. It might be related to surface modelling of chosen airbases (Normandy Manston is suspicious at the moment), but shouldn't happen in either case.