Leaderboard

Atlantic Conveyor on RAZBAM Discord SA map:

Adding to the list of assets with functionality issues, thanks to relentless testing efforts from a dedicated tester. These assets are a separate category through, but will also need tailored solutions: AFT-10 HJ-10 CV9050 Spike LR2 RBS 58 FGM-148

Hopefully fixed in the next patch

v 1.2 (actual) DOWNLOAD LINK https://www.mediafire.com/file/0jfmq1akxec3q4x/Cold+War+Assets+mod+v+1.2.rar/file 24.06.2024 Tu-126 AWACS aircraft with Liana radar (predecessor of A-50 Shmel). Detects ships and aircraft at a distance of 200-300 km Tu-128M Long-range interceptor, works in pair with Tu-126 R-4TM and R-4RM AA missles, IR and SARH, 25-30 km range. Added simple collision shell for Tu-95K and Tu-126 so they could be shot down with a gun. KSR-2D decoy missle by Beldin for Tu-16. Readme in Doc folder. KSR-5 speed corrected B-58 wing tips position fixed No new liveries and numbers BANO and landing lights for Tu-126, landing lights for Tu-128 Material names are now unique for Tu-95K, Tu-126, Tu-128 18.06.2024 Tu-95K Kh-20 (AS-3 Kangaroo) long range AShM/Pinpoint attack missile B-58 Hustler Bombing and recon tasks. Mk-83, B-43, B-53. Yak-28 Interceptor and bomber role AA missiles, unguided rockets Various FABs and tactical non-conventional weapon No gun for now Tu-16, Tu-22KD, Tu-22D Shaders/Normals 3D issue fixed (thanks uJeka forum user) RDS-37 H-Bomb added B-47 Bomb bay with Mk-84 and Mk.53 H-Bomb added Textures improved slightly recon task added v 1.0 11.06.2024 Tu-4K KS-1 Comet (AS-1 Kennel) missile Tu-16 KS-1 Comet (AS-1 Kennel) late KSR-2 (AS-5 Kelt) Antiship and anti-radar missile KSR-5 (AS-6 Kingfish) Antiship and anti-radar missile FABs from 250 to 9000 kg Tu-22KD Kh-22 Antiship, antiradar and anti-surface missile FABs from 250 to 9000 kg Tu-22D FABs from 250 to 9000 kg RN-24 and RN-28 munitions B-47 work in progress GAM-63 AS missile Note: for antiship tasks use both antiship and anti-radar missiles. Credits Tu-4K based on DOL's B-29 and Stonehouse Tu-4 Scripts based on Currenthill's, Hawkeye60's, JSN64 mods. FAB-9000 model and texture by Marco1985_IT.

Here we go... It must be really Two-weekTM away!

The lighting was too good to pass up throwing one of these together.

Drawing this

Thank you! That is exactly what we’re trying to say all the time. It should be zero oscillation. The only reason why this aircraft could be a subject of PIO is because it doesn’t have a «variable ratio» between stick and stabilator which along with the aft CGs and thus a high effectiveness of the stabilator makes it hard to precisely control it at a high IAS. Next gen of jets have eliminated this problem by implementing this stick to stabilator variable ratio based on speed. Of course, inertia of bob weights counts but I believe the major part of it will be damped out by the system itself and the rest will handle the pilot. I also believe that damping conditions are underestimated by HB, because even removing a viscous damper later on, to reduce the system resistance and thus increase speed of trimming, couldn’t be felt by pilots. But nevertheless the small one/two time (one/two period) osciillation or fluctuation is expected when position of the stick is changed, because pilot needs to readjust his pulling/pushing strength wile also dealing with the inertia. But it will happen anyway, even you're using a simple spring joystick, you can see it from the latest FusRoPotato's graph. So no need to bother to fake it through the simulation of flight controls. It would be absolutely great if we can get the same opportunity as @FusRoPotatoshowed here, but with possibilities of old fashion trimming. As I’ve showed in my video, the range of required positions of stabilator required for the horizontal flight throughout the whole speed envelope is very narrow and basically ones trimmed you barely need to touch it again, might be just slightly for the comfort purposes when stabilized on speed in landing configuration Don’t get me wrong I’m talking about light spring loaded joystick. Real aircraft you will need to trim, because forces are not the same. But it applies almost for every aircraft

All I can do is dream...

By Polychop Sven We made a statement about it in our Q&A. The AI is perfectly stable yes for gameplay purposes for single player. The Ai will counter any CG shifty immediatly, because it is AI. If you want it to fly with the full sense of motion, you have to trim it out with force trim, hover by yourself while you do all the work in left and right seat. Can be done, have done it and as far I remember even in the pilot flightschool you have a task where you fly and operate the aircraft from left seat, but my memory can serve me wrong on that one. when you fly the aircraft without AI you will defenately feel the CG shift when a Hellfire goes of the rail, promised, even if you have it trimmed out as much as you can same goes for the gun or any other weapon. lateral and longitudenal cg shift are a real thing in this dcs helicopter

Dear friends and pilots. We apologize for map update delay, this will be a good lesson for us in the future. We are confident that the update will be released soon, we are working hard on it. But rest assured that we read feedback and look at new bugs and improvements from users. We are preparing not just an update that will fix most of the bugs, but massive map improvement that provide more flying options and adds new visual content. We have already finished modeling airports and unique objects that were announced before. Now we work on unique scenes and map optimization. Most of the time is spent on small improvements and bug fixing, although globally it already seems that everything is done. For every small update, it is necessary to build the entire project and update must be approved, then users need to download it, this is inconvenient in our opinion. That's why we decided to release Phase 3 along with the bugs fixed, but we didn't take into account the time factor, which goes by very quickly. Thank you for your patience and support.

Hello everyone, My name is Krzysztof Sobczak (some of you may know me as “Grover”), I am the Technical Director at Heatblur. Although I haven't been very involved in direct communication with our users because I have been focusing on working hard on our projects, today, I am excited to share some technical insights about our latest release. As some of you may read from me for the first time, I'll start with a short introduction: I am originally a physicist holding a PhD in particle physics. However, most of my professional life has been dedicated to developing flight simulations. I have had the privilege of working with companies like A2A Simulations and Metrea. In 2018, I joined Heatblur Simulations to work on the F-14 Tomcat. During this project, my areas of responsibility included the communication and navigation systems, the LANTIRN targeting pod, and JESTER LANTIRN. In 2021, I became the Technical Director to create a new core system - codename Anvil - a genuinely new-generation simulation platform. Having been involved in creating several flight simulation engines throughout my career, I have gained a deep understanding of the requirements for such engines and the shortcomings of existing solutions. This extensive experience has been invaluable in shaping the form of our new flight simulation platform, which we present today through the release of the Heatblur F-4E Phantom II. Our users may already be familiar with the innovative approach we applied in the F-4E Phantom II, particularly the concept of the components system. For those with programming experience, this might initially sound like a marketing trick, similar to object-oriented programming and using objects through composition in different contexts to build complex structures. However, there is much more depth to the system we created. Our approach goes beyond simple object composition and reuse. What sets our system apart from other solutions and programming techniques is its orientation around data flow. This focus is crucial for creating a system that is both reusable and granular enough to build entire aircraft and reuse components in other aircraft or systems. The challenge in making such a system lies in the uniqueness of many aircraft devices, so to achieve true reusability, we had to reach deep to a level where components can be generalized - the level of individual switches, relays, lamps, amplifiers, actuators, valves, and all other kinds of low-level components. By focusing on the components and the data flow between them through the connections, we managed to move all non-simulation elements outside the components and let Anvil handle them. The first core aspect of our F-4E Phantom II, driven by our engine, is its multi-crew capability. The component connection approach allows our developers to focus entirely on creating the simulation part of each component. At the same time, the system handles the communication between different components and distributes it over the network. From the developer's perspective, there is no difference between developing an aircraft simulated entirely on one computer and an aircraft whose simulation is spread across multiple computers. The second feature unlocked by the component system is multi-threading. By strictly separating components from each other and not allowing them to access other components directly, we ensure that the simulation part of each component can run concurrently. This approach means that developers do not have to worry about the complexities of multi-threaded development and can work as if the simulation of each component were entirely single-threaded. The connection system governs the rest — it de-conflicts multiple simulation threads seamlessly. It is important to note that while our system is designed to support multi-threading, this feature is not enabled in the version that users are receiving today to limit the risks of the adverse effects for the premiere of such a complex aircraft. However, multi-threading will be enabled in future updates, offering a significant boost in performance for everyone. Also, note that this is not the same as using the multi-threaded version of DCS - the multi-threading part of our component system adds another layer of parallelization, effectively offloading the aircraft simulation from the main DCS thread. The component system is oriented toward providing developers with the tools to create new components quickly and efficiently. With those tools, we can focus on recreating components' real-life properties and giving them an organic feel by adding imperfections, individual characteristics and failures that can occur as a natural result based on the treatment of the components. Later, we use those components as bricks to build the aircraft in a fully synthetic way, while Anvil makes each airframe unique and each flight a new adventure while giving virtual pilots an incentive to not mistreat the aircraft. Finally, we plan to use Anvil and the same library of base components in all our future products, retrofitting them to the already published products where applicable. Sharing the same code will ensure that all our future aircraft will be automatically updated with our latest achievements and changes introduced to the system while developing any new product. This means that from now on, our simulation can only get more profound and more realistic. After introducing key features of the component system, let's delve into some statistics about DCS F-4E Phantom II. The total count of components used in our simulation, as in the final build provided to Eagle Dynamics, is 6,389. We used 14,627 component connections. Out of these, 2,297 connections are synchronized in multi-crew. The total number of properties across all components is 34,964, with 25,032 of these properties synchronized in multi-crew. Many of these properties are randomized and depend on the wear and condition of the aircraft. Finally, the total count of all damaged states in the aircraft is 1,562. While this number is already high, we plan to implement many more new failures during the early access period. Some of you might be concerned about the costs of creating detailed products like our F-4E Phantom II, which could negatively impact the entire market. We never intended that, and we are confident this won't happen. First of all, our goal was to make the development of complex modules less expensive by improving the reusability of the code and offloading most of the low-level and repetitive development to Anvil, which will handle it automatically. Furthermore, we are part of the flight-sim community and want the study-level flight simulation to thrive. From the first days of this new platform, we shaped it in the form of SDK, which we want to offer our partners. This includes the entire library of components and JESTER. We believe that cooperation and fostering synergies is more creative and profitable than non-amicable competition. As you will be able to experience the F-4E Phantom II for DCS yourself, I hope you will enjoy every minute spent in our recreation of this magnificent aircraft. On behalf of the entire team, thank you for the support and excitement you express daily through all communication channels. Have fun!

Here, mortals, enjoy some interesting material: If English is all you can do, these are good books: (Piotr Butowski, while being Polish, is among the top writers on red aviation. He is a prime investigative journalist, writing for "The Warzone") (Not the average Jane's stuff. It's a more specific and correct lecture.) (Also pretty good, albeit from export models (Warsaw Pact.). (For pure pictures and general history - certain things are off, esp. on the details.) And something more specific and interesting: (True, it was "stolen" per se, but then Sukhoi exceeded the initial cobra by reaching 90* - 120* AOA, and by that, derined their own maneuver. Su-27 is inherently unstable, whilst MiG-29 has inherent neutral stability (most people don't know that). This is also why in regards to sheer AOA-banging ability, Su-27 does have the edge - also, for a limited maneuver. The AFCS inhibits a good degree of the AOA advantage so as not to enter unrecoverable and destructive AOA regimes.) Finally, pleasantry at its best:

Haha, yep, the SAM issue looks pretty hilarious.

folks we understand you want more news and we have passed it on. OnReTech is still working on the product and you will need continue to be patient. Early access and development does take a long time for many reasons, please keep the feedback constructive. Thank you

I don't have "space problems" but fictional liveries have no place in DCS imho. Off to the User files.

If you buy all the regions separately you get exactly the same product as if you buy the complete map, just at a higher price.

Paradise Lost

I didn't say that. Win 10 is still fully supported.

The real question is how for God's sake AGAIN there is a new feature introduced, that hasn't been tested in MP. For years it looks like any new patch was tested on SP only.

This is the critical point here that I made earlier. When producing compensation for non-FFB users, the general outcome of control smoothness and accuracy should be similar or better than the outcome of users flying with FFB. Otherwise, you end up simply punishing a user for not having expensive hardware. The strength and dampening effect from the arm of the virtual pilot needs to be able to hold the virtual stick firmly as would someone in the real aircraft, or in the sim with a correctly recreated FFB system. According to mil standards, the forces produced by that stick, including those by momentum of the weights, cannot exceed certain values to prevent control difficulties like this, and thus, the aircraft doesn't kick back very hard. What we should be feeling is approximately what we feel in DCS simulated with FFB, and we are able to hold the stick quite firmly in that case and the sim correctly represents that. The problem is the weak pilot arm for non-FFB that cannot hold the stick as expected. The loose grip allows for a larger expression of the force feedback without the expected compensation. Based on a little bit of data logging at various speeds showing consistent and smooth response frequencies at all deflections including center, I assume most all of this reaction is coming from reaction-torque about the bob weights. As you shove the stick forward, you are not just attacking the force of the weights, but also adding rotational kinetic energy. Bringing the stick to a stop while in motion thus requires extra torque. This is easy to feel and counter with and FFB stick but the non-FFB simulation lets it pass and this is what turns into the unwanted oscillations you see that you also can't easily counter. This is also why those oscillations occur at every position, not just center, but are likely exacerbated near center due to how most non-FFB sticks "snap" as they hit center. For people with extended sticks, this may be less apparent as the stick may often not be moving as fast, thus less kinetic energy stored before coming to a stop. The drop in oscillation amplitude I'm seeing after turning on FFB drops around 90% ish, even though my accuracy to bring the stick to a perfect center with FFB is a little more difficult. That is a big difference. The fix for this problem is straight forward: Fly the aircraft in such a way you can enable and disable FFB, record the pitch response, Increased arm strength and dampening when FFB is disabled until it starts to match the results recorded with FFB on. I grabbed stick position and recorded data with and without FFB enabled in the game settings. This can be done through export lua using the code testfile = io.open("B:/Users/username/Saved Games/DCS.openbeta/Logs/FlightRecord.txt", "w") if testfile then testfile:write("Log Start") end function LuaExportAfterNextFrame() local Controls = GetDevice(0) Controls:update_arguments() local pitchCommand = Controls:get_argument_value(2) -- was 3002 local pitchmessage = string.format("%.4f\n",pitchCommand) testfile:write(pitchmessage) end function LuaExportStop() if testfile then testfile:close() testfile = nil end end And this is the compared result: I start at 400 kts IAS conditions and simply pitch forward and back over and over. Notice how the squiggle at the end of each pitch command change is much smaller when using FFB. This is because I can fight the force response physically. Without FFB, I am not allowed to do it and the pitch oscillates.

VoiceAttack for the F-4E Phantom II has been released: https://www.digitalcombatsimulator.com/en/files/3338091/ Enjoy!

I built the A-10C cockpit years back, and recently also built the F-15E and started a youtube channel showing the steps to build the latter. After accumulating much experience building the first cockpit, building the second one was much faster, especially using FreeCAD and 3D printing panels instead of drilling holes, creating recesses etc. The 3D printer is also very versatile in creating other things like knobs, levers etc. whatever you can dream up and create in FreeCAD. I started with FreeCAD and Arduino basics before showing the first panel build.

They seem to have increased noticeably for me as well after the latest update. Loading time of the game itself, missions loading times might be comparable I think. I excluded folders in Win Defender back when Spud did his video on the subject, but that didn't really help with loading times or stutters (albeit they were acceptable for me on my PC anyway), so removed exclusions after short tests. Will try them once again now and see what happens.

In the very early days of the KW (1992ish), we did have the hook. It was part of the larger MPLH (Multi-Purpose Light Helicopter Package). When the aircraft were delivered I remember they did ship with them. It attached to the bottom of the aircraft with quick-release pins. I believe the release was a manually operated pull handle. I never flew with one because I don't think we had tasks developed for our Aircrew Training Manual. The litters were also envisioned to mount on the side of the aircraft in similar fashion. I never saw the litters or plank seats. Maybe off topic (sorry), but couple of other cool KW development footnotes... - The Prime Chance AH-58D could mount guns on both sides with ammo cans of 800 rounds. The right side ammo can blocked the refuel port, so it was not implemented in the production KW. -The larger can developed adverse airflow conditions over the horizontal stabilizer and once caused the left side stab to break off at the weaker folding hinges we had on the PC birds. Result: much beefier hinges on the KW and a smaller can with better aerodynamic profile (hence 500 rounds). - We often flew the AH-58D at 5500 lbs. IIRC, this was the initial design requirement for the KW, but during testing, autorotational performance was deemed unsafe above 5200 lbs. Perhaps they were planning on using the extra 300 lbs as useful load during the MPLH development? - We only had 6 waypoints available in the first CDS software. That changed pretty quickly though. I really enjoyed my time in the 58D. It remains my favorite aircraft of the many types I flew across 20 years, 2 military services, and the airlines. I'm so pumped about getting back in the KW! Thanks, POLYCHOP.

Shaw (and any BFM discussion) is a snapshot in time, an example relevant for that particular moment. A BFM engagement is a moving picture, rapidly changing. Its impossible to say "Do a yo-yo in the Phantom or the opposite". The difference between primary flight maneuvers (rolls, loops, etc) and BFM is the former is an airshow and the latter is done in reference to the target (bandit). Your choice of BFM has to be based upon what the bandit is doing, is capable of and will likely do next. Every maneuver is in your arsenal, ready to go, when appropriate. The goal of a BFM engagement is to arrive in the WEZ long enough to employ the weapon. You do what is required to get there while denying the bandit from doing it to you. We have a long list of maneuvers with names in BFM but there are really only two, roll and pull. Every "named" BFM is a series of those two things hooked up in series. If you arrive on the bandit turn circle with lots of closure, rolling to point the lift vector out of plane up and pulling will kill off that closure and allow you to align your turn circle with his and then rolling to put the lift vector in lead and pulling will keep you there as the nose comes down. It works for that situation and got named the "high yo yo", mainly to function as a brevity word for a long sentence. Doing the same maneuver without lots of closure is doomed to fail. You really shouldn't think in terms of specific maneuvers in the fight. Your thinking should be much more granular and aimed at solving your immediate range, angle and aspect problem while monitoring how the bandit is reacting.

Выпустил аддон Ту-4К для Кольского https://www.mediafire.com/file/ogtasawng09lfp5/Tu-4K.rar/file Тушка честно взята у DOL, ракета и пилон мои.

I have converted a transport shoot down scenario from Viggen for A2A practice. The player is not being shot at, so one can take time to try using the radar, interacting with Jester, employing sparrows, sidewinders and gun. If you like to have a go, please let me know. Edit: Attach it here: Note the missiles used, IIRC, are of the M variants to ease things up. There are 4 IL-76 instead of the original 5. Have fun. F-4E Paratroop intercept.miz

ED temporarily made the missiles from the mod inaccurate, there is a Missile Technology Control Regime in our world)) It seems they are getting feedback from different players and creators of mods and modules, they will probably fix it.

Hermes getting some ASW support from HMAS Melbourne And CVS-16 USS Lexington. Hopefully the S-2 will be available soon.

IIRC there is some overlap between the different regions, so there are likely airports that included in more than one region, so they'd be double or triple counted in the region counts. If you buy the full map you'll get everything.

I want to chime in and say I've been experimenting with detection of a long line of Mig-21's and have been noticing a lot of strange artifact in the returns of the Mig-21's and what appears to be a lot of clutter and noise existing where it isn't expected. I switched to full-screen mode and this noise went away. Targets were generally much cleaner and easier to spot. Windowed Mode Fullscreen Mode DT bombing mode also has been significantly more accurate in fullscreen. Otherwise they behave like in the video, nowhere near close.

It worked. I set the curve in the options to 19 low and that brought my trim to roughly center. I then recorded it. However, flying like this is a little impractical because there is no way to trim when there is no trim force. The result was, zero oscillation. The virtual stick matched my non-FFB stick exactly. Eve though there is a little pike present at the end of every change in position, that was my fault physically trying to bring my stick to a sharp stop and over correcting. Pitch Response non-FFB with FFB option enabled for F-4E release @ ~ 400kts ISA

Daily MiG-29 Fulcrums and Friends

You need this https://github.com/Quaggles/dcs-input-command-injector And this https://github.com/Munkwolf/dcs-community-keybinds I use it and I have an axis for the wing sweep lever...

null null

Funny, I'm on Windows 10 now, and DCS Runs fine, and as A tester I was never told it's not supported, so I don't know where you are getting your information from. You likely mis-read something, because Windows 10 is very much supported and still in use, ED would also not drop support for an OS that has 68% Marketshare. The only topic of Windows 10 and unsupported is discussion of Microsoft is pushing Windows 10 to LongTermSupport status, which ends in 2025. Also, Prior to upgrading due to a power surge, I ran a FX-8350 w/ DCS as well. So the information you're posting is more of "You Opinion" than "Facts". You're an interesting user who registered a week ago, has come here to argue, trying to say you saw conversations that don't exist and attempt to dis-credit others. A. I Develop Software. B. I Build Gaming Rigs. C. I Do 3D Art Composition. D. I test not only DCS, but products for half a dozen other companies. I have Credibility, and I'm removing myself from this conversation, as I have more important things to do than continue this repartee.

Thank you @Abburo and @Timex3 - and everyone else supporting the development! Status update Weapon issues with DCS 2.9.5.55300 As you remember, there are currently two issues at hand. 1) Affecting all SAMs using TVC - making them go haywire and flying everywhere All affected missiles in all the affected country packs have been fixed. We are running final tests now. 2) Affecting all missiles using the old DCS missile parameter set - making them fall short of the intended target As I mentioned before, this issue is a bit more tricky as it can't be reproduced with DCS core units (as ED has migrated all their weapons to newer parameter sets), and therefore we can't submit a proper error report to ED. I'm working weapon for weapon to see what I can come up with. I'm currently working on the guided 155 mm shells and think I have a viable solution. Here's the preliminary list of assets affected by issue #2: HIMARS ATACMS HIMARS PrSM HIMARS PrSM antiship HIMARS GLSDB HIMARS GMLRS M270 GLSDB M270 GMLRS M270 ATACMS M777 Excalibur B-21 AGM-88G DF-21D PCL-181 GP155 Type 055 YJ-21 Iskander 9M723 Grigorovich Frigate RBU-6000 Artillerisystem 08 Excalibur PzH 2000 Excalibur

ED is well aware of what the desync issues are, as the patch notes even say to expect them. The real question is, when can we expect a fix? What does “ASAP” mean in the patch notes? Is there a hot fix coming, or are we going to be waiting for weeks? Your most passionate users, members of virtual squadrons that train and fly together as a PLT and CPG team, are essentially grounded right now with a completely unusable module.

I believe I might have found the cause of this. When you switch the delivery mode to DT, you usually switch through TGT FIND. Now, when you do that too fast, Jester will run into an issue where he sets the DSCG knob to TV for TGT FIND and then skipping the subsequent action to set it to Radar because, at the time of enqueuing the actions, the knob was in Radar already. Ill prepare a fix for this

What does SA-2 on its own refer to in the table? The Shrike's Mk 25 being the only one that works against SA-2 (TR) (i.e. the Fan Song E) makes sense, but the Mk 22-Mk 24 doesn't because the Fan Song we have in DCS is the Fan Song E, which operates in the G band. Fan Songs that operate in the E/F band are the Fan Song A, B and F. Speaking of which, it might be useful to have a threat guide in the manual for the radars in DCS, including their frequency and band where known. A list of what frequencies that correspond to what bands can be found here (you're after the new nomenclature). Though, I guess it also depends on how well DCS models it. The other thing is that some radar systems in DCS are actually a combination of radars which may operate on different bands (Straight Flush, Land Roll, Scrum Half and Hot Shot being primary examples). Also, some radar systems comprise of multiple radars, such as the 1S91 [Straight Flush], whose 1S11 acquisition radar operates in the C band, but its 1S31 tracking/illumination radar operates in the I band. Meaning that the Mk 49 and Mk 49 Mod 1 would only work against the Straight Flush in its track/illuminate mode. The Mk 37 might work (purely looking at the band) In any case, I'll list Eastern Bloc radars below and I'll bold what guidance section is appropriate, based on the frequency, which I'll write in bold. At the moment, for the table in the fusing GUI. 1S91 [Straight Flush] is the acquisition, target tracking and illumination radar for the 2K12 Kub [SA-6 Gainful] 1S11 acquisition radar operates in the C band. Mk 37 EDIT: This one actually has contradictory information, while this says C band, this says G band. If it's the former, the Mk 37 is accurate, if it's the latter the Mk 22, Mk 25, Mk 50 is accurate. Neither cite anything though and there's a non-zero chance the former could be mixing nomenclature (the C band in old nomenclature is G band in the new one). 1S31 track/fire-control radar operates in the I band. Mk 36, Mk 49 As above, while this says I band, this says H band if the latter is correct, it means the Mk 49 (either mod) or the Mk 50 is accurate. SON-9 [Fire Can] is a fire-control radar for AZP S-60 and KS-19 AAA batteries. It operates between 2.7 and 2.86 GHz (E band) Mk 23, Mk 24 SNR-75 [Fan Song] is the fire-control radar for the SA-2. In DCS we have the Fan Song E, which operates in the G band, at around 5 GHz. Mk 22, Mk 25, Mk 50 (Edit 3 - this appears to be the case in DCS). SNR-125 [Low Blow] is the fire-control radar for the SA-3. This operates at around 9 GHz, in the I band. Mk 36, Mk 49 The P-15 Danube [Flat Face A] is an acquisition radar mostly associated with the SA-3 (though is also used as a general purpose search radar, particularly for the Army), in DCS we have the updated P-19 [Flat Face B], which operates in the C band, at 0.83 - 0.88 GHz. Mk 37 The P-35 [Bar Lock] is primarily an EWR/GCI radar, which operates in the E/F band. Unfortunately, it doesn't exist in DCS (though given how prolific and how well it fits in with our maps and aircraft and the fact we have an appropriate model for it, it really should). Mk 23, Mk 24, Mk 50 As for other Eastern Bloc SAMs and radars: 2K22 Tunguska (2S6) [SA-19 Grison]: 1RL144 [Hot Shot]: Acquisition radar operates in the E/F band. Mk 23, Mk 24, Mk 50 Track/Fire-control radar operates in the I/J band. Mk 36, Mk 49 - Note, wiki (citing C:MO) describes this as a J band system, which would put it beyond any of the shrike guidance sections. 9K33 Osa [SA-8 Gecko] - Land Roll (unknown native deignation) Acquisition radar operates at about 7.5 GHz, which is in the H band. Mk 36, Mk 49, Mk 50 Track/Fire-control radar operates at 15 GHz, which is in the J band. None of the Shrike guidance sections can target this. 9K35M3 Strela-10M3 [SA-13 Gopher] This one is quite difficult as some sources refer to its radar as Hat Box or 9S86 [Snap Shot]. The latter allegedly operates in the mmW range which is in the K to O bands (30 - 300 GHz), which is beyond what any of the guidance sections can target. 9K37M1 Buk-M1 [SA-11 Gadfly] 9S18M1 [Snow Drift] SR operates in the F band. Mk 23, Mk 24, Mk 50 9S35 [Fire Dome] tracking/illumination radar operates in the I/J band. Mk 36, Mk 49 9K330 Tor [SA-15 Gauntlet] - Scrum Half (unknown native designation): Acquisition radar operates in the E/F band. Mk 23, Mk 24 Engagement radar operates in the G band. Mk 22, Mk 25, Mk 50 S-200V Vega [SA-5B Gammon] 5N62V [Square Pair] FCR operates at 6.6 GHz, in the H band. Mk 49, Mk 50 At the moment the P-19 and 5N59S are used in DCS (though neither are accurate). The actual acquisition radar used for the S-200 is the 5N84A (P-14F) Oborona-14 [Tall King C], which operates in the A band, below the range of the Shrike. S-300PS [SA-10B Grumble]: 5N59S [Tin Shield B] SR operates in the E/F band (2.85 - 3.2 GHz). Mk 23, Mk 24, Mk 50 5N63S [Flap Lid B] FCR operates in the I/J band. Mk 36, Mk 49 5N64S [Big Bird B] SR operates in the E band. Mk 23, Mk 24, Mk 50 5N66M [Clam Shell] SR - this one has contradictory information, this says it operates in the I band but this says it operates in the E/F band. Mk 36, Mk 49 for the I band, Mk 23, Mk 24, Mk 50 for the E/F band. EDIT: Forgot the ZSU-23-4, its RPK-2 (1RL33) [Gun Dish] operates at around 15 GHz, in the J band. This is above all of the Shrike's guidance sections - none of them should be able to target it. I also forgot the 1L13 and 55G6, but both operate well below any of the Shrike's guidance sections can target (A/B band). EDIT 2: I also forgot the 9S80M1 (PPRU-M1) [Dog Ear] - sorry everyone. That radar is commonly associated with shorter-ranged army systems like the SA-8, -9, -13, -15 and -19 and operates in the H/I band. Mk 36, Mk 49, Mk 50 I haven't extensively tested this however and I am just going by radar band. For later systems (e.g SA-1x, I would assume the later seekers would be better equipped for them, but I'm not sure when which was introduced). EDIT 3: You can check the exact frequency that our radars are defined with, by checking the .lua definition for the unit, which can be found here - if you Ctrl+F for "Frequencies" it should take you to the appropriate line, note that the values appear to be in Hz. As an example, here's the .lua for the SNR-75V of the S-75V, on line 81 you can see the frequencies defined range from 4.91×109 - 5.09×109 Hz (i.e. 4910 - 5090 MHz or 4.91 - 5.09 GHz), which is indeed in the G band as it should be and matches this). See this table for a list of what frequencies correspond to what bands (you're looking for new nomenclature). Note that some units appear to have this undefined, the 9K35M3 Strela-10M3 [SA-13 Gopher] is one such example, some ships also don't have this defined (though some do).

Here lads I too have experienced petrov going into "stevie wonder" mode when flying on grayflag I have created a simple mission if u lads want to try it out, there are targets to the north and west they will NOT shoot at you so no be scared of them null Petrov_test1.miz

@ViolentNomad She's looking great. We appreciate the love going into this. A note to the potential testers. It's more than just flying it around and being the first to have it. True testing involves knowing the full procedures and noting what works (or doesnt) with various combos and situations. And some reversion testing to ensure it doesnt break other parts of the sim.

I think there's misunderstanding. I thought you were creating/building some initial community keybinds lua files for the F-4E since you mentioned the InputCommands folder, these lua files just define what you can bind with ANY device. Your specific devices are in a different folder and get bound after that separately. The purpose of the Quaggles input command injector and Munkwolf community keybinds is to add binds that didn't exist before. What users do with their hardware against these is really trivial in comparison and not something that we need to share really. I managed to get some time today and created an initial template, with a few binds added: HSI Heading slow and very slow options HSI Course slow and very slow options Reticle Depression slow and very slow WSO aspect switch added to the front seat https://github.com/Munkwolf/dcs-community-keybinds/discussions/75

Thanks, Rustbelt also rexommended those exact mods- guess i will just havs to bitw the bullet and go with them.

It's from their website, I talk to the developers daily, so ...

Thank you for the headsup and the previews look great as always. The main reason people are upset is because before and after release Q1 2024 was supposed to have wrapped up Phase 3 and even 4 and the map be out of EA. Now we are almoszt in June 2024 with 0 updates since release. Thus the frustration. I still think Sinai has the potential to become the best DCS map so far.