Search the Community

Hi @BIGNEWY i know you closed a topic like this quite recently, but i thought i would post this. In stand corrected, the throttle part of the horn logic is correct as it is now. Facts from a fresh DCS Mosquito flight: When flying with gear fully retracted at 3000 rpm (any setting for the matter of fact) and throttling down to below +4 lb boost or what is equal to about 1/4 of throttle application looking at the throttle quadrant - The undercarriage warning horn will ring Here the undercarriage warning horn sounds (and the red lights turn on in the undercarriage position indicator. Note throttle position. You have to believe me when i write that the undercarriage WAS indeed retracted even though screenshot does not say so. So far i believe we agree on the current DCS Mosquito's undercarriage warning horn behaviour? Now lets look at what the lecture says about the behaviour of the undercarriage warning horn ("me" scuffles and brings out manuals). In the Mosquito Mk VI Pilot Notes (and in all 4 of the different ones i have found) is stated the following in Part 1 Description, section 15 Undercarriage position indicator and section 16 The undercarriage warning horn. From Mosquito Pilot Notes - FB6 (A.P.2019E-P.N.) From Mosquito Pilot Notes - FB VI & FB 26 (AP2019E,L&T-P.N.) "when the main wheels are not locked down and the throttles are less then 1/4 open" IF the electrical service switch for the undercarriage position indicator is a two way switch then the DCS warning horn behaviour would be understandable and likely correct, but as it can be seen in paragraph (II) of section 15. Undercarriage position indicator, the electrical service switch is three ways. And this is what was confusing me. 1 - wheels locked up - no lights 2 - wheels wheels neither locked up or locked down - RED 3 - wheels locked down - GREEN But then in paragraph (ii) the sentence "Main wheels locked up but throttles less then 1/4 open" - which is where the position indicator light gets the red light from. So that the red light is on in the screenshots is absolutely correct behaviour in my opinion. And its safe to say that the undercarriage warning horn follows the lights, and thus MUST be correctly modelled. Now in further support to this, the Mosquito Pilot Notes - FB VI & FB 26 (AP2019E,L&T-P.N.) holds a section (that the newer Pilot Notes - FB6 A.P.2019E-P.N. does not) regarding "Operating Data". Below is an extract from that section describing Maximum Range: As you can see maximum range is achieved by flying at +4 lb lb./sq.in. boost with the Merlin 21 or +7 lb./sq.in. with the Merlin 25 (the DCS version) and around 2650 rpm. Further findings on the subject has been done in the "D.H.98 Mosquito VIII_IX_XVI_Operational Performance Notes". Though the document describes "..the performance and economy of the Mosquito (Mk's VIII, IX and XVI)" there are some hints on how to fly the plane most economically in all models. Cruising Rule 1. - Cruise normally at the highest attainable boost (not exceeding +4 lb./sq.ft.) ---set +7 lb./sq.ft. here for the DCS Merlin 25 powered Fighter Bomber model Cruising Rule 2. - Control IAS entirely by adjusting the rpm between a minimum of 1900 and 2650 rpm Cruising Rule 3. - Put the supercharger gear change switch to "AUTO" 20.000 ft. is the most economical altitude where maximum True Air Miles Per Gallon (AMPG) is reached. Close the shutters in level cruise (or loose around 8% IAS). At medium and low altitudes fly at 1900 rpm and highest attainable boost (not g +4 lb./sq.ft. boost) And from the performance test from 3. july to 16th august 1943 of Mosquito FB Mk. VI aircraft HJ679 Maximum cruising is stated as +7 Boost @ 2650 rpm As for stories and other accounts of cruising at minimum boost, to me must be either on a one of the bomber or PR versions or a matter of having operated at high altitude where boost naturally falls off. Below table is from the performance test mentioned above and it can be seen that +7 boost is not achievable at fx. 24.000 ft. @2850 rpm. (and less so for lower rpm numbers) So.. all in all a big thanks to Eagle Dynamics for having modelled it correctly and especially to @BIGNEWY @NineLine and @Yo-Yo

As I am now educated on the Street and such, I realize that this is Working as Designed. Thanks to all. v 2.7.9.17830 Setup steps: Mission Editor: new Syria/PG/Cauc mission 1. Place CVN-74 Stennis (though Lincoln and Vinson exhibited same issue) 2. Place a F/A-18C on the carrier and setting WP0 to be 'Takeoff from Ramp'. Results: 1. In ME, the graphic shows the plane at the CAT1 position, cannot unsnap it from that position to any parking area. 2. Plane spawns in center of deck. Deleting both Carrier and Aircraft and recreating does not resolve. Able to reproduce on Syria, Persian Gulf and Caucasus. Able to reproduce with CVN-74, -71 and -70 (stopped testing there).

So I wanted to try out the new RWR sounds and noticed that some search radar does not seem to be picked up by the viggens RWR at all and some search radars seems to be solid tones (that is possibly intended with the new sounds, but being in the area with sams would mean constant tones) However, I placed some SAM sites and some of them did not give any indication of radar until the tracking radar got a hold of me, I placed a lone search radar to test, in this particular test "flat face" and tried first with F18 and it's RWR picked it up almost instantly, then I switched to Viggen, same location and same path, but not a single search radar tone. Since it's a new RWR sound system things are a bit uncertain what is intended or not.

Hi, I know that this was mentioned in some thread, but I coudln't find a dedicated bug thread or official response to it. GMT can detect and track through dense forests. In probably close relation to it, the land.isVisible() scripting function also seems to ignore trees when raycasting for LOS, as you can see in the attached track. gmt.trk

I locked a friendly and he showed as yellow square. Is this a bug?

Hi ! When you use Combined arms and try to move a tanker to another position (for long missions) when flying, the new waypoints lost the "tanker" property. Therefore, we cannot communicate with the tanker anymore (the option is removed from the communication menu). Steps to reproduce : 1) in the ME, add a plane as "player" 2) add a tanker (kc 135) and create 2 waypoints. In the ME, on the KC135, there is a specific property "Tanker -ref" (Type : Start Enroute Task, Action : Tanker) 3) Play the game. 4) communicate with the tanker, it works -> the communication menu is available 5) With combined arms, change the path (Set Path) of the tanker. 6) Try to recommunicate with him -> the communication menu is unavailable. Is it possible for tankers only to keep this property?