m4ti140

The carrier in Mission 2 doesn't have ACLS set up despite Case 3 recovery.

Another relatively small one. During RTB in Mission 8, after AAR Olive doesn't seem to rejoin (not sure cause I somehow die in the track ofc) and after kiss off she flies off back to Romeo 1 before going home. Track, not sure how useful: https://1drv.ms/u/s!ArMDWm49dN3CguAJdRUTREUVBwyQjA?e=7gfCDU

Two issues with this mission, one minor, one major 1. Mother doesn't arrive at WP4 on time, they're around 0.75 to 1 minute late. Using TOT to arrive at WP4 at exactly 08:00 causes the whole sequence to play out a minute too early. 2. The rescue helicopter hovers on the approach path, sometimes almost exactly at the glideslope and course. Although the mission itself is not of "strategic" importance this is a bit of a serious issue, as it causes AI to go around, sometimes several times, and the chopper might cut the player off too. I imagine this mission was created before the ground follow function for helicopters was introduced - this is a good place to apply this enhancement I suppose. Track: https://1drv.ms/u/s!ArMDWm49dN3Cgt9DcYwCKXtaM6MUJQ?e=XtNJGL

Title. Prince just goes on his own and triggers that should fire when we're information fire anyway even though we're 30 miles apart. I imagine this isn't how it's supposed to play out? Track: https://1drv.ms/u/s!ArMDWm49dN3Cgt89KBT9mLvVh1nEOw?e=mpab0e

Title. When the tanker is rejoined at northern point of its track it will end up in Iranian airspace. Maybe it could be moved further south? Track: https://1drv.ms/u/s!ArMDWm49dN3Cgt5YsF77OI0KruFvGw?e=GKYl4i EDIT: Forgot to save the track but Smoke stays on players wing all the way in on final approach. I imagine there should be a moving zone at mother that would set flag when tripped to send him off? Cause if yes then for some reason it didn't trip, and there wasn't exactly any way to send him off manually. EDIT2: To further specify, Smoke was glued to me after choosing Low state - straight to mother at the end.

Title. WP ends up within the 7nm departure distance within 6 minutes from mission start, which might be too little and results in weird behaviour by Saint if they're not in the air by then, they end up circling WP1 at high speed. DCS AI has... issues.

The latest RDI update has removed the antenna elevation axis completely. There's now a radar gain axis, but the elevation wheel on the throttle is not bindable despite working fine before the update. The only way to control elevation now is with buttons. This is not acceptable, it's debilitating for users of Saitek sticks as well as TM Cougar. Why would we have a bunch of simpit wheels for volume, or light brightness and not crucial HOTAS commands?

Recently, while trying to figure out why the altimeter in the M2000C doesn't zero-out at listed QFE, I discovered some extremely concerning issues with how DCS presents data to the user, how altimeter settings are defined and how third party modules handle altimeter modelling. I've realized there are extreme (even thousands of feet) inconsistencies in altimeter indications in almost all 3rd party modules whenever sea level temperature doesn't match ISA, possibly stemming from an omission in the briefing screen and the mission editor. When setting up static weather in ME, the mission designer is required to set real sea level pressure and temperature. These settings are obviously valid only at sea level, with pressure and temperature at most airfields being appropriately lower. The changes in pressure and temperature lapse rates depending on sea level conditions are appropriately modelled in the platform, however the sea level pressure is listed as "QNH" in both the Mission Editor and the briefing. This is incorrect for sea level temperatures other than 15°C. QNH, by definition, is calculated by reducing station pressure to sea level elevation, assuming ISA lapse rates and disregarding temperature offset. Since most barometric altimeters are calibrated for ISA, setting QNH results in the instrument reading a correct field elevation despite the temperature offset. This means for static pressure distribution across the map, the QNH will differ from real sea level, the difference increasing with field elevation, and therefore needs to be calculated from station pressure for individual airfields. In case of ED modules, all altimeters seem to be replicating these effects correctly, whether it is by using pressure as input and replicating real altimeter's scaling to it, or by correctly applying error to known altitude value. That means they behave correctly when using QFE listed in briefing (they show 0 elevation) and a QNH correctly calculated from the QFE (they show field elevation, barring small measurement errors, even at maximum temperature offset allowed by the editor). This also means they show wrong elevation when set to QNH listed in the briefing (which is correct, since it's that QNH that is wrong). The inconsistencies are apparent in 3rd party modules. Out of all modules I could check (Which included all 3rd party fixed wing jets), the only module where the altimeter behaved consistently with ED modules (and realistically with relation to pressure) were the C-101 and AJS-37 modules. Other 3rd parties seemed to each have a unique systematic error: Razbam - all modules (MiG-19, Harrier, Mirage) completely disregard changes to lapse rate with temperature. When set to the real sea level pressure (listed as QNH in briefing) they show their real altitude ASL regardless of temperature offset. Consequently, setting the QFE listed in briefing or given by ATC results in non-zero indication. In the stock campaign shipped with the Mirage in particular, setting the ATC QFE results in an error bigger than 200ft. Necessary 0 elevation setting is obtained by calculating QFE from "QNH" listed in briefing. Heatblur: AJS-37 - Viggen has 2 altimeters. Backup altimeter is consistent with a real altimeter as well as with ED modules. Main altimeter appears to be deliberately temperature corrected and shows correct field elevation when set to real sea level pressure, shows 0 when set to briefed QFE, and shows real altitude above station we set QFE of. Given how Viggen's weapons system works I assume this is a feature of the aircraft and was done deliberately. F-14B - the altimeter displays correct field elevation when set to the real, computed QNH and wrong field elevation when set to the QNH listed in briefing, which is consistent with ED modules. However, when set to the QFE listed in briefing it displays the same altitude error as Razbam modules, suggesting that altitude is being calculated from pressure, but additional correction (possibly duplicating existing one) is applied to it. It requires further investigation, or input from HB. Magnitude 3 - the MiG-21 displays an equal in absolute value but opposite error from Razbam modules. All Razbam modules show elevated altitude when set to QFE at positive temperature offset, and a negative altitude at negative temperature offset. MiG-21 shows a reversed relationship. Why it works that way is a mystery to me, either way indications are wrong. Deka Ironworks - same issue as with Razbam modules. It should be noted however that testing was done at standard pressure, disregarding any further errors - and the altimeter modelling in in the JF-17 previously displayed a disregard even for sea level pressure, always showing real altitude at 29.92. The recent changelog seems to indicate this part, at the very least was fixed, but it wasn't tested. Temperature offset is certainly disregarded, indicating altimeter simply shows real altitude read from platform. AvioDev - C-101 altimeter was consistent with ED modules. These inconsistencies have severe impact on usability of altimeters. Although in some cases they make them more accurate, that is not what is expected in real life, because it's hard to achieve in real life conditions - therefore altimeters need to be consistent, and baring instrumentation or reading errors they should indicate the same measured altitude at the same real altitude with the same altimeter setting, regardless of aircraft. As it stands, that is not the case unless mission sea level temperature is 15°C. If there's any offset, there will be substantial differences in indication from module to module, regardless of what pressure setting is used as reference. At 50°C (which is expectable on some terrains) differences are in the order of 10%, making altimeters useless for altitude deconfliction, and forcing reliance on INS/GPS or even on the info bar. The following measures are suggested to resolve the situation: Correct the terminology used in briefing and in ME. Sea level pressure should be listed as such, or as QFF. QNH should be calculated individually from QFE for player's spawn airfield and listed in briefing, next to the QFE value, for all 3 units. Release clear guidelines for all 3rd parties on altimeter modelling to ensure consistency. Ideally, pressure should be used as input rather than altitude, to ensure altimeter indications are consistent with atmosphere modelling within the platform.

When using the "Police light toggle" switch on the throttle from HOTAS section, the police light should turn on when both this switch and the police light switch on the left console are on, and it should turn off otherwise. What happens instead is bizarre: 1. When the police light switch on the left console is ON, the police light toggle on the throttle turns off the landing and taxi lights. 2. When the police light switch on the left console is OFF, the police light toggle on the throttle turns on the landing lights. 3. The police light is controlled entirely by the switch on the console, disregarding throttle switch. It looks like the binding is assigned to a completely wrong switch in the cockpit. policelight.trk

The launch rails for RB-24/J and RB-74 are reducing drag when carried empty. This reduction in drag is most observable at high speeds. Around SSL conditions the maximum speed with 6 empty launch rails is 1788 (Ma=1.46 on indicator) kph at 5% fuel and 1777 (Ma~=1.455) at full tank. With 2 empty rails and otherwise clean config (happens when rails are jettisoned in flight as well, with aircraft rapidly slowing down after jettisoning 4 rails, see track files) the maximum speeds are respectively 1651 (1.35) and 1638 (1.34) still significantly above maximum sea level speed in clean configuration. The reduction in drag is also observable at low speeds, with RPM held by autothrottle with full tank stabilizing at 82% for 6 rails and 83 for 2, indicating higher thrust required. Steps to reproduce: 1. Start a flight with 6x of any sidewinder missile 2. Launch the missiles without jettisoning launch rails 3. Observe the performance changes with empty launch rails Track and acmi files demonstrating the behaviour are attached to the post. Screenshots: https://imgur.com/a/SzwxZ6r 5% track viggentest260521.trk 100% track viggentest260521fulltank.trk acmi tracks Tacview-20210526-202016-DCS-viggentest.zip.acmi Tacview-20210526-204827-DCS-viggentestfulltank.zip.acmi

I have a better idea: if wiring is there then allow 3 mavs, but actually model the chance of stabilator damage. Granted, this isn't something you'd risk in peacetime but I can see a situation like that during WW3. And DCS doesn't even have proper mechanics in place to simulate peacetime operations accurately, at least not yet.

This. Having ability to ferry them would still be of use, since we have warehouses in DCS.

I wouldn't agree that 9M119 has a higher PK than M1's main gun in conjunction with ballistic computer, if anything I'd say M1 is slightly better. The missile suffers from the same issue Vikhr does, if you fire it at moving target it will oscillate around LOS and hitting target turns into a lottery. Sometimes it will hit, sometimes you do the exact same thing and the missile will miss. Sometimes you fail to track the target smoothly and the missile hits anyway because it just happened to yeet itself that way. And you only carry 3 of them. The only time I had hits against helicopters with it was when they were literally hovering motionlessly. Against Abrams it's at major disadvantage as long as the Abrams player is proficient and knows how to use the tracking system. Cannon rounds are faster than missiles, and 9M119s have lower PK on hit against the Abrams than the other way around - 1 APFSDS is all it ever takes in the game pretty much. Put skilled players in 1 Abrams and 3 T-72s and the Abrams player has a good chance of turning it around and winning. I understood it the same way Shadow did and I assume anyone else would. It sounds as if you were defending invalid Ka-50 tactics and since I've literally heard you telling people on server to hover and scan on a couple of occasions, when 99% of the time it's the worst thing you can do in environment like this, so forgive me for assuming you were defending those tactics. I had reasons to assume that. You've only jumped to explanations after Shadow did a very thorough explanation why that's a bad idea.

What do you expect him to do? Not fire at an attack helicopter that's hunting for him? Red armor on this server is typically 2gens behind Abrams version we have in game. It doesn't have fancy stuff like this.

This is perfectly balanced lol...

+1. Also there should be an ability to spawn neutral flights for a country that is a part of a coalition, for the same reason, as civilian traffic wouldn't be targetted.

A is a significantly different aircraft, so much that the Mirage is a better approximation than the CM block 50 stripped of weapons. What you suggested has nothing to do with a real early block A. If they were to make one the only thing they could keep would be the external 3D model and even that would require significant changes. The flight model, the engine model, the FCS, the avionics, the cockpit, everything's completely different. The cockpit is more reminiscent of the Mirage or F-14 versions we have in game than the F-16CM. So what I'd like to see is US assets from the same era they're adding Russian/Soviet assets from, rather than modern stuff with no counter other than giving both sides the same aircraft. Yes. I'm not gonna buy any more modern stuff cause there's no gameplay for it. We have no hope of getting modern opfor stuff to match so what's the point? If they release a new cold war airframe I'd get it.

Mi-24 is such a cultural icon worldwide, be it the east or the west, that I refuse to believe it wouldn't sell, people might get it just to have it in their library even if they're only gonna fly the Apache. Every second US action or cold war movie set in the east features the Hind. It's the first thing that comes to people's minds when they think of east bloc military aviation.

On Warthog you could map the china hat as modifier and set it up so if it's in forward position you hold the forward grip, if it's in aft position you hold the aft grip. Then map front and aft grip inputs to respective layers.

Regarding heading, I think it's not as much of a bug as a consequence of sim's simplifications: the map is flat and is only visually "bulged" when rendered to look as if there was a horizon. This results in massive heading errors that grow as you move away from X=0,Z=0.

When trying to copy a flight that has any AGL waypoints in it the AGL waypoints break: despite still being set to AGL upon inspection their altitudes are being reset to a value corresponding to 30m AGL converted to MSL. Attempts to set previous AGL altitude fail and upon switching waypoints, the waypoint gets reset to the aforementioned value. To restore AGL functionality it needs to be switched to MSL - upon which the value does not change as it should, confirming it was being treated as MSL despite being set to AGL - and then back to AGL, which resets it to 30m. This bug is extremely debilitating when trying to get multiple flights through a long terrain masked route, since having one template flight and copying it as a base for the others does not work anymore.

Yeah, it's screwed. The controls are still the same as for single-player Huey, and they just don't work anymore. We either need a separate tab or have the pilot controls recognized when input by the copilot. Having a separate radio trigger and weapon release button when they should be mappable to the same inputs makes no sense.

It's in game, read the manual. You can add your own modfiers. I have the exact same controls layout on my X52 in DCS as in the other sim. In fact you can do more in DCS, cause you can have as many modifier keys and buttons as you want, you can have latched modifier keys (I mapped caps lock that way for A-10C to swap between normal controls and keyboard CDU input), you can mix button and keyboard shift keys, you can shift keyboard with buttons and vice versa. The posibilites are endless and once you run out, you can edit the input .lua files to get even more advanced functionality than UI provides. The Warthog has one additional stick input compared to the F-16 stick, which is CMS z-axis. You can map everything on that stick to its real F-16 functions and still have an input to spare for shifting.

This. If it's outdated then it's quite possible it could be declassified if you know who to talk to (and assuming it even is classified, just because it's not floating around web doesn't mean it is, remember about ITAR). And they have Wags. This isn't Russia, it's easier to get info if it's not an immediate safety issue.

This should be officially added to game at this point IMO