virgo47

This was originally mentioned in this thread, but I believe it's a bug: Original observations: I've experimented with the drop tanks during the last few days and they are definitely a bit peculiar. I've written a script to see the fuel level in messages regularly (only overall, but better than nothing) to see whether the fuel somehow disappears or what. I always burn a bit of left-wing tank to get around 75 mark and it never gets to F, so I hope there is no problem on this front. The mission is my custom free flight and the stories vary: I've flown ~angels 20 on the left drop tank, I switched to the right tank drop tank and lost fuel pressure within seconds, although there was no chance I spent the whole fuel. Repeated on at least two flights, no idea what was wrong. (I have no info on the fuel level for these cases, it was before I added the script.) I've active-paused the plane after the mission start at angels 6, fuel 157% (100% is for full internal fuel), went over all the tanks, starting with a bit from the wing left, then the combats one after another... fuel pressure dropped when expected based on the fuel %, I switched through all of them and went all the way to 0. The plane "flew" for over 5 hours, no problem. (I used time accel of course.) I went over Caucasus again, ~angels 30, used the both left and right drop tank just a bit, then switched to the right drop tank for good when I was ~140% of fuel. The missing 17% went a bit from the left wing and both combat tanks. Neither of the combat tanks could have been empty by this time, it's mathematically impossible. The fuel reported going down all the way to 92%... it worked like there was some kind of interconnect between the drop tanks, because the moment the fuel pressure dropped, I switched to the left combat tank - and it was empty too! I have no explanation for this behavior, the only normal case seemed the experiment in active pause. I don't know how altitude is involved in all this, reportedly the altitude can make the engine management harder, but I guess you want to use drop tanks first even when you escort bombers in high altitude - and you probably want to fly high to fly further, but I'm not an expert on this. Later test with track and fuel message each 10s: I've made another test, this time at higher altitude, although I'm not sure how important that is. First I went for active-pause test and accelerated time, no problems at all, switching went exactly as expected. Start at 157% of fuel, switch to left combat tank at 152%, then - as calculated and expected - fuel pressure dropped around 123%, so I switched to R combat tank, and then around 95% (first 5% went from the left wing tank) I switched to internal tanks. No problem. Second time I decided to fly actually fly it and also switch more often from tank to tank, but make notes what happens when. To my surprise, things went wrong quickly... again, around 152% I went for L combat tank, then around 143% I switched to R combat tank. I lost a plane for a moment, but I don't believe the maneuvers were that excessive, but... suddenly I lost 50 gals in 10 seconds: There is nothing in the Score window, I wasn't sure about some malfunction... I made and checked the track again, whether I'd see anything in those moments... nothing obvious in an external view. But 50 gals were lost. Strangely, from the gauges it seemed like some internal fuel was lost as well. So, naturally, I suspected the maneuvers. I restarted the mission and tried pretty crazy things... but I couldn't replicate it. Track file is attached. p51d-lost-fueltrk.trk

Yeah, the problem with these things often is that at first one doesn't know whether it's a bug or not. Me, for instance, could not clearly see what and when is what happening and it took literally hours to somewhat replicate it, not to mention writing some internal fuel script output that I wouldn't have written otherwise. I'll try to repost under bugs although my faith is not strong. But without a bug report it's even weaker, of course. I'm on it. Edit - here it is:

It's easy, I tried both, and I could probably manage instant+recenter - and it worked for me 9x% of cases - sometimes I happen to be in such a panic that I didn't properly reset/recenter one of the axes. In that case, the trim simply didn't work for that which lead to a confusing experience. Maybe it was a dead-zone matter as well (I have mostly 0 dead-zones). So I'd not take this option away from people for whom it works, it's a logical option that works great for many. Instant is somewhat great, but it causes crazy maneuvers for bigger channges. And that's where this fade-in/fade-out comes in (the name is probably most meaningful for musicians? ). It simply changes the trim from whatever position to the "center" (at that moment) over some time - during which I can counteract it by moving the joystick towards the centre - but without the need to totally reset/recenter it. That's why it's great. Because Instant is like you snapped the stick suddenly - which may even not be good for some helos - but "recenter with delay" (or fade-in/fade-out) makes it smoothly and I can counteract/anticipate it.

This is a no-brainer. Of course, we can argue whether it's "a new feature for a finished module", but that doesn't make it any less missing and a bit ridiculous that even mod has it and pro modules don't.

I haven't so far, but if you have, it always helps to be specific, screenshots, which modules, which bindings, etc. Vague reports may result in vague fixes.

Fantastic response time! Must have mod for control freaks like me. Thank you guys a lot.

UH-1H, L-39

This seems to be it: https://www.navysite.de/what/bridgewing.htm

I'm puzzled about this thing for CH-47F: Added. Ground detent position for the Thrust Cont Lever. And I'm not alone, obviously (the comment is from after the update): I know what it does when it's checked in Special Options (appearing as ugly GROUND_DETENT). I investigated, why my Ng "needles" settle ~63 instead of 50-55. Only when I press AND HOLD a keybind for "Ground Detent override - pressing" it goes down to normal values. So my laymen observation is, that it disables/offsets the lower range of the thrust lever, but I have no idea how it should work because the manual doesn't say anything about it (at least not when I search in text). If there is a ground detent, is it so coarse that I can't just pull the lever gently above it? Does it always jump to ~63 on Ng indicator? Also, if it is a detent, shouldn't there be more than just a single hold-n-press binding for it?

EDIT: I forgot to point out this uses bash from Git for Windows, it's not a cmd command. No, that command merely detects the missions that have SnapViews anywhere in the mission (but that will likely be under Config/View). In most case the whole Config folder from inside the *.miz file can go away (my experience, of course, somebody more qualified can clarify or point out exceptions). Don't do this for the missions in the DCS installation directory - instead, copy the mission into your Missions (under Saved Games), fix it there and leave the default one be. It would be overridden by the next update anyway. So just play your fixed mission instead of the one from the training.

It seems this was remedied to some degree. I don't have all modules, but the current output from the command above is much shorter: F-16C/Missions/Training/Lesson 20 - AGM-65 Maverick.miz M-2000C/Missions/Training/M2K Training 04 FINAL ILS.miz Su-25A/Missions/Campaigns/CWW-Outro.miz I'm not sure about F-16C and M-2000C, whether the missions were updated, if I don't own the plane and just trialled it in the past. They seem to be as the date on the F-16C mission is 2025-03-19, so it's quite up to date. In any case, it's much better - as for P-51D, it's actually fixed. Maybe the command above can be run occasionally as some part of testing process by someone having all the modules: for i in */Missions/*/*.miz; do unzip -l "$i" | grep -iq SnapViews.lua && echo $i ; done BTW: this uses bash from Windows Git, not cmd. In any case, I thank you for the fixes.

Check the mission file (it's just a zip with a different extension), there may be "baked-in" views under Config/View/SnapViews.lua. Just remove the Config/View folder and the missions will be OK. This often happens in community misions, but even some ED's missions are/were broken this way:

I don't doubt there is a problem. I'm just saying that a screenshot is not enough. Let's say the bug goes like this - this is a hypothetical scenario: I have the following snapviews (file attached to the post). I load the following mission (attached in the post). NOTES: The mission is a minimal mission for practical reproduction - that is, a single Player-skill plane, if that is enough to replicate the issue. If it's not plane-specific, use a free Su-25T or TF-51D. Of course, if it's only with some plane or some map, use those. I do this and this in a mission. (Trackfile is included in the post.) I leave the mission and check my snapviews and see that the modification date was updated. I can also see the differences (tools like diff or WinMerge). And again, the modified file is attached to the post. Now somebody can try it and say "yeah, I see it now" - or, sometimes frustratingly, but happens as well - "sorry, it works on my end". And the process can follow one way or the other. This described scenario, with all the necessary config files provided, is important even if it's not the only one where it happens for you. That's OK. The important stuff is that someone else can confirm or not, and then the hunt can continue, e.g. what are your other options, etc. Screenshots and videos are welcome additions, but not enough. Does the process make sense?

ED will not show signs of life without a reproducible use case. I said previously - there were bugs related to views, some were fixed, but there may still be more. But this thread so far was more confusing than evidence based. It's not like nobody believes there are bugs, but always try to make it easy for the guys to reproduce. Provide tracks, configs, videos, evidence. I can't test any Corsair mission as I don't have the bird, yet I wanted to help originally with other missions you provided, but these were wrong missions (baked-in views) and your replay was "but what about"... It's jsut very difficult to help in such a case. Make the case clear, I know it's sometimes really hard, but it's close to impossible to reproduce anything based on anecdotes. These things can even be different bugs caused by different things, just manifesting in a similar manner. ED will not waste time on a report as vague as this one. They have many more quality reports and then they have their priorities as well, so even totally obvious proven bugs are not fixed for many years. Is it Marians WWII related? Is it F-16C training mission related? Is it Corsair related (is it even ED's problem in that case)? Hunt down a concrete case and document it well.

Cargo. Internal cargo support added for UH-1H, Mi-8 and Mi-24P What exactly does this mean? Is it related to this thread?