virgo47

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

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.

+1

Thank you, guys, for the info. It's easy to get it all confused, but in the end, anything under 46"/2700 RPM should work "indefinitely" (numbers used in many posts here and in both tables, on p30 and p128) and cruising at 42"/2400 (manual p128) should be perfectly safe.

Ah... so the table is for the engine (the section is), with some stuff not specific for the plane? Is that right?

I'm a bit confused about the last row in the table from manual p30: I can't find anything relevant about that AL combination. Originally I thought it was some other switch (AR/AL) as there is no other reasonable position on the 3-way lever itself. Then I assumed that AR is "auto rich"... which would lead to a typo explanation?

Yes, you're right, thank you very much. I can't find the info in the manual, but knowing what you told me, one can see the drop in the fuel pressure and if RPM is higher it doesn't happen. Also confusing... this is still marked only as reported, so it's easy to latch on that information. However, there seems to be some fuel in the tanks... with a bit higher RPM. It works with less than 1500 as well, but 1500 seems to be a good minimum value showing the fuel pressure in green. Thanks again!

I've just created a simple mission with full fuel and drop tanks and noticed the engine cough when trying the external tanks on the ground. I was just following advice to check each tank for 30s or so on the ground if they feed properly (based on Reflected's video, actually, although he didn't mention drop tanks). I checked manual for details, couldn't find any. I checked forums and found various fuel-related bugs with drop tanks going back to even 2013. Is this still a thing, or is it something new? If it is a known limitation, is it mentioned somewhere (including manual) in an obvious manner? (I know I don't NEED drop tanks for a typical DCS mission... but they are there, it was one of the first things I wanted to try.)

Without the explanation in the first answer, I'd have no idea how to operate this without bindings just with the mouse clicking. There is a green cue when you go around it, but I'd not figure it out on my own and there is nothing in the manual about how to click-operate it. The switch is distinct from the cover when you open it, but clicking it does nothing (or toggles the cover instead) and the tooltip doesn't help you at all, so from purely UX perspective it is quote poor. You have to know somehow. There is a benefit, of course, it is easy to click on what you want. The cover acts a bit strange in Auto position though, if you click at the upper part where the pin is - it toggles between the closed position for Auto and Normal (different "depth" of the closed state).

I check the thread and I don't believe this is the case. The mission starts immediately. I'd say these are forgotten tracks that can be cleaned.

OK, I don't know about tracks usage, thanks for the additional info - but embedded snapviews make player's snap views useless (just like forgotten ones), which is probably not good.

I randomly chose an Instant action mission and was puzzled by the snap views that were not mine... so I went to look into the mission files. It seems that from all the missions, three Instant action missions contain Config with snap views, tracks and other unwanted stuff. The affected files that should be cleaned up: QuickStart/P-5125 - Caucasus - Train Strafe.miz QuickStart/P-5130 - Caucasus -Train Strafe.miz QuickStart/P51D-IA-Caucasus-Low Level Hell.miz

I don't know what I was doing... I know about stick forward to unlock, I tried in the morning and the wheel is just fine. How sometimes the single most important step gets out of the way of the experiment, I have no idea. Sorry.

I'm testing P-51D and whenever I look from the outside (F2), the tail wheel is straight. Shouldn't it rotate, even quite extremely, when it is unlocked? I can make circles in place, but the tail wheel sits straight. I can't find any bug report about that (perhaps wrong wording), so I rather ask first how it should behave.

This is exactly the thing we need to wait for now. After the major upgrade in TouchPortal, this plugin does not work correctly. You can't work with the actions, you can't change the value (ON/OFF, etc.), you can't drag'n'drop it. We need to wait for the update for the DCS-COINS plugin, hopefully sometime in this quarter of the year.

I'm now waiting for @xoomigo to come alive and have time to update it. I'm a programmer, although no .NET expert, but I'd definitely spend some time trying to make it work if it was on GitHub, because right now I don't use this at all because of the breaking TouchPortal upgrade. I loved this option because it's a flexible and cost-effective alternative to HW panels. The integration is also much better than just plain key-bind emulation, not to mention the feedback to the panel so it can also show stuff or blink. So I hope it will be updated or, at least, eventually published. Fingers crossed.

Thanks for the info. I wasn't sure originally and another thread misled me (and this happened on other module forums too). I've eventually noticed there is no way to mark the solution here. I'll better myself.

Yes, I couldn't find anything wrong in the mission. Your linked thread sounds like the problem, there is the zone check and OR. Thanks a lot. And reportedly, it's fixed internally. Great, can't wait for that!

Kinda +1 for the whole sentiment. I've not been very long with DCS, but most of the time nothing frustrated me more than bugs I encountered only to find out they were reported years ago. Things like long hand on L-39 with pilot body shown, flaps/canopy controls in TF-51D (thankfully fixed recently!), Yak-52 toggle binding not working, minor but annoying Caucasus ATC bugs, etc. There are many other bugs other people care and I don't. I know bug fixing is not fun and you need also to bring in new stuff, but I'd have no problem having a slower year with more bug fixes. Of course, other people (and perhaps most of them) see it differently. I'm really just voicing the sentiment. I wish DCS had fewer long-standing bugs. With or without a public tracker, I'm fine with the forums. In retrospect, I also see some fixes, sure. But I'm not sure the debt is decreasing - especially with all the new stuff coming out. That must mean more maintenance in the future.

Whow, I don't go so long back... Good point. Of course, I don't really care which one is the default as long as it works properly and consistently. My speculation seemed logical, but I'm proven wrong. Thanks for the info.

Or, the issue is RWY 33 with 0 wind. If it was 15 for 0 wind as well, Gudauta would be perfectly OK aerodrome that prefers 15 and switches to 33 when the upwind for it reaches ~3 m/s.

Yeah, I'd also think 33 is preferred for landing (and no problem for takeoff as a default), those mountains are really difficult to ignore on landing. In any case, the current situation is suspicious at least. I don't understand why the default map in DCS has multiple long-standing ATC issues.

When investigating... ...it started to be obvious, that Gudauta acts strange. So I've done some wind-related investigation and the results are: With 0 ground wind, RWY 33 is used - this would suggest that this is the "default" runway unless the opposite wind is too strong. But with any wind along the runway less than ~3 m/s in 151° direction (meteo 331), the RWY 15 is used. Now THIS also suggests the runway 15 is the default one - except for no wind at all. I tried various crosswinds - from either side, RWY 15 is used... of course, unless 0 m/s was set. (0 speed ignores the direction, which makes sense.) This really looks like the "default" runway for Gudauta is RWY 15 and there is a bug which surprisingly uses 33 with 0 wind.

So I've done some investigation and the results are: With 0 ground wind, RWY 33 is used - and this suggests that this is the "default" runway unless the opposite wind is too strong. With any wind along the runway less than ~3 m/s in 151° direction (meteo 331), the RWY 15 is used. Now THIS also suggests the runway 15 is the default one - except for no wind at all. I tried various crosswinds - from either side, RWY 15 is used... of course, unless 0 m/s was set. (0 speed ignores the direction, which makes sense.) What this suggests is that the true "default" runway for Gudauta is RWY 15 and there is a bug which surprisingly uses 33 with 0 wind. THAT SAID... the mission still uses WPs for RWY 33, so the wind should be set to 3 m/s.

So this now seems to be reported as a part of: I guess this is a duplicate now.