Leaderboard

This is our yearly mission statement and achievement wrap-up post. This continues in the theme of: Discord developments As of December, there are over 2160 Discord Community members. This is up y-o-y from 2021 by 600 contributors. Over 400 participants contribute 5 or more separate messages. From 2020 we can count double growth. The top ten list of Discord contributors is here taken by the MEE bot: One of our two main developers, AppleEvangelist, is almost single-handedly propping up other contributions to the Discord, to show that your questions are answered by a developer (as long as they are answerable and on topic). We are all very grateful for the time he and everyone else that contributes give up of their free time to help. Frank had a clean out of the Intro section and updates the #FAQ and we now have a dedicated Moose Discord bot that parses logs and offers advice when it sees log parses. GitHub statistics Master branch commits 2015-2022 (green) File size December 2022 - 8.7MB File size June 2020 - 5.9MB Over 4600 commits, 46 releases, to master branch from 33 people Yearly over 1MB of growth in code. 1MB = over 1 million characters a year! Thats a lot of fingers on keyboards! MOOSE is a community project, the code is open source and we very much appreciate all participation. We have participants in many ways, by committing code or documentation updates, by responding to people's questions in Discord and online, by providing feedback and suggestions and even just asking questions to stimulate interest. MOOSE was originally created by Sven (Flightcontrol) in 2015 and is now over 7 years old and we can see from above that maintenance of it continues regularly. For interest, Flightcontrol ceased development at the beginning of 2019, FunkyFranky began developing on MOOSE in 2018 and AppleEvangelist began in 2021. We welcome any new developers, no matter how small the contribution. The above statistics are relevant to the main branch. There are two main branches, Main and Develop and the primary difference right now is that the Ops AUFTRAG hierarchy classes are only available in Develop (more on that later). This slightly distorts figures as the commit rate to Develop can be higher due to the extra classes. These are the commits for this year: As you can see, if MOOSE is dead, it's going to need a stake through the heart at the very least. Class developments 2022 was an excellent year for innovation! New classes, additions and fixes: Ops.FlightControl. This class provides Audio Air Traffic Control just like AIRBOSS class, to land installations. We've iterated on basic sound files to utilise @Ciribob's excellent Text-To-Speech and deliver audio messaging via SRS direct to your ears. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/OPS.FlightControl.html Ops.Playertask. This class supersedes previous Task classes by providing a framework for players to have a task system give them things to do in a mission based on automatic discovery or manual provision on any single unit or group of units and including scenery. This amazing class also uses our modern, localisable, Text-To-Speech system from Google. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Ops.PlayerTask.html Ops.AWACS. This class can guide and direct both AI and player clients together, in multiplayer, to intercept trespassing enemy planes in defined friendly airspace using Google TTS over SRS for the messaging delivery. We use NATO brevity as much as is possible within the remits of simulating a Human controller (anchoring is nigh impossible and simplifications to process are required). This would typically replace crude text to screen for BRAA and attempt to provide realistic engagement using human like voices for targetting allocation with a number of reality and era options. Whilst it won't exceed a human attempting to provide a AIC job, it better than any other scripting solution out there and represents a world-class solution not seen in any other simulation to date. Ops.PlayerRecce. Inspired by Gazelle helo scripts used on MP servers, the Recce class simulates optical detection by the Player which is otherwise impossible to script (because a computer doesn't know what you can see). The class features a number of hooks that can be used to link to other scripting actions - passing the target, for instance to AI for prosecution. Ops development. We are now at the end of the second year of Ops development. The Ops classes comprise of the AI Tasking system of "Auftrag", a three tier hierarchy of land, sea and air controlling classes. Over the top are two classes, COMMMANDER for direct execution to a subordinate class, and CHIEF. CHIEF represents the automation of spawning and attacking by an AI commander. These classes have been actively developed and refined since 2020 and represent MOOSE 3.0 in the evolution. SSE API additions (ToUnit) MOOSE will incorporate most API functions if they work and are useful. Additions from time to time are made by Eagle Dynamics. Fixes/enhancements: A great deal of work has gone into reducing on-screen messaging and migrating to Google Wavenet voices via Ciribobs TTS executable in the SRS installation. The future of DCS scripting is communicating via radio, not via imaginary writing on your canopy. L10N: We have begun innovating localised options for language in our code since we have embraced TTS. MOOSE Usage in DCS Missions Moose is used by 4YA and Enigma servers and many more, representing many of the large MP servers or 30% of the top ten populated individually named servers. This is quite an achievment given the Administrators are often already technically adept. Offline, MOOSE is used by @deadlyfishes very popular Through The Inferno (TTI) representing over 82,000 downloads and most of the top ten downloads. A vast number of administrators discuss MOOSE every week in Discord across the world, even in heavily firewalled countries like China. It is fair to say that MOOSE has had a huge impact on DCS whether realised by the individual consumer, or not. Legacy classes and supportability statement 865 closed tickets, 19 open Since many of the MOOSE classes were written by FlightControl it is fair to say that after he ended his contribution in 2019, we were left with a large support deficit that was not feasible to sustain as a hobby. Frank created the OPS classes as a result and we have concentrated development on fresh ideas, because sustaining someone else's hobby is hard enough at a code level. Here is the current list of "class health". Use the documentation to understand the class names (develop is used here) https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/index.html All Tasking classes - Deprecated (known issues) Superseded by Ops.PlayerTask All AI - Deprecated (known issues) and superseded by Ops.Auftrag and related Ops.Chief, Ops.Target combinations. No parity with the originals. All Cargo classes - Superseded by Ops.OpsTransport Functional classes (the mixed bag) Functional.Detection was superseded by Ops.Intel - Intel is simpler and has groupings and decay but not threat. It also hooks. Functional.MissileTrainer was superseded by Functional.Fox several years ago Functional.Escort was superseded by Ops.Auftrag (and appropriate task) Functional.ZoneCaptureCoalition superseded by Ops.OpsZone Functional.PseudoATC - Developer has indicated that using Ops.FlightControl is prefered Functional.Suppression - working, best effort support Functional.Movement - Deprecated, does not work, do not use Functional. ATC_Ground - limited repairs being made - best effort support All Ops classes have an active developer owning them. Wrapper, UTILS, Core are always supported Sound is supported with a nod to more effort going towards converting sounds to Google Text To Speech as static sounds are less scalable. Supportability definitions Deprecated - The guidance is to no longer use this class due to one or more known issues. (We never remove classes from Moose) Superseded - There is an equivalent class that is performing functions that are the same or close enough in design. "Best Effort" - The owner of the code is no longer supporting this and any volunteer dev is probably going to spend limited time Troubleshooting. Supported - The developer is active and answering questions. There are no guarantees or Service Level Agreements on what constitutes "supported". You may check the MOOSE Discord class channel and the history of discussion for a better idea. Future MOOSE continues to grow, evolve and innovate. MOOSE and it's community thrive based on the principle that a free community has no barriers. We are agile, useful and relevant to DCS World with a huge majority of DCS customers using MOOSE without even knowing. If you want to help, please use the code and talk about it here: https://discord.gg/gj68fm969S FAQ MOOSE has two main branches (master and develop). master: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/ develop: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/ Download MOOSE (save as a file.lua): Release version: https://github.com/FlightControl-Master/MOOSE/releases Master branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/master Develop branch: https://github.com/FlightControl-Master/MOOSE_INCLUDE/tree/develop As the documentation of MOOSE is created via luadocs on-the-fly from the respective Moose.lua, every class that is in the docs is also in the Moose.lua. User Guide A good place to start is the MOOSE User GUIDE: https://github.com/FlightControl-Master/MOOSE_GUIDES Youtube Even though a bit outdated, FlightControls YT channel contains a lot of useful information on MOOSE https://www.youtube.com/channel/UCjrA9j5LQoWsG4SpS8i79Qg/featured Especially the MOOSE for Dummies series is a good way to get your scripting juices flowing https://www.youtube.com/watch?v=ZqvdUFhKX4o DCS Scripting Environment All scripts including Moose eventually use the DCS API or Simulator Scripting Engine (SSE) to interact with DCS: https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation DCS Version Info: https://updates.digitalcombatsimulator.com/ LUA Resources - Learning LUA YouTube videos : https://www.youtube.com/playlist?list=PLxgtJR7f0RBKGid7F2dfv7qc-xWwSee2O - Programming In LUA (First Edition): https://www.lua.org/pil/contents.html - The Implementation Of LUA 5: http://www.lua.org/doc/jucs05.pdf "The best things in life are free"

nullnull

People in this thread mention look down penalties and doppler notches as the main issues but when we're talking specifically about maximum range of the radar in DCS compared to real life, there is another issue that has a much bigger impact. In real life, the chance of a radar pulse returning to its sender is probabilistic. As an example (using completely made up numbers), every sweep of the radar maybe has a 80% probability to get a return head on at 30nm, while it only has a 10% probability at 70 miles. This is why real life pilots are always saying that STT is much more reliable than TWS, because in real life you get a hell of a lot more radar pulses on target every second in STT than you do in TWS, hence a bigger chance of actually getting a return. This means that even if you only manage to get a single return from a contact at 70 miles every tenth sweep with the radar, maybe 1-2 minutes in-between each return, you could still be able to get a stable STT lock simply because of the sheer volume of pulses you're sending out every second in STT. To use incorrect terminology, you could say that STT has a "longer range" than RWS or TWS, which is why it's so weird that STT has a "shorter range" than RWS and TWS in the DCS F-16C. The radar model in DCS is deterministic. If you're within these and these parameters, you'll be visible on radar 100% of the time and if not, you'll be visible 0% of the time. This is why the "maximum range" is so short in DCS and also why a lot of people use TWS all the time, because with a deterministic radar model the benefits of STT are much, much smaller. So, as long as a future refactor of the F-16's radar doesn't implement a probabilistic radar model, you won't see "maximum ranges" anywhere near to real life. Any kind of improvements to the F-16's radar are welcome though.

Thank you!

Just as a small update, we are currently refactoring the Hornet radar, and once complete, we'll revisit the Viper radar. Thanks!

I'm waiting for drivers, MT and Vulkan before I put it in my main DCS System. AMD bailed on DX11 long ago, so even though they did a DX11 Perf. Patch for the rDNA1/2 GPU Drivers, I doubt it applies to rDNA3, I have been working with a local streamer that does OCing, and we were able to get his reference AMD 7900XTX to within 5-8% of a RTX4090 in non RT Synthetic benchmarks. he asked for my help, as I was overclocking GPUs back when we had the 8800GT/GTS/GTX and they had a similar Core/Shader Clock setup, And we all know, you can jump shader clock pretty easily on those GPUs for a nice performance boost. 1st stage: OCing out of the box, we were able to get 10-15% higher shader clocks, with fan curves and no voltage changes. 2nd stage: additional 5% Core clocks with slight mV increase, however hot spot temps on GPU were concerning 3rd stage: removed heatsink, replaced thermal goo, with some better TIM, also removed the 3 MM thick Pads they had on the ram, and replaced with copper shims and better TIM. the RAM Pads were horrible, also, there was NO TIM on the rear VRM Array, the forward array had the same thick pads as the VRAM modules. (replaced it, and added TIM and copper shim to the rear array, also, the VRM only used a plate to pull heat, the plate was directly cooled by fans, and not attached to the vapor chamber, sinks or pipes.) 4th stage: increased mv, hotspot on vrm was cooler as result of cleaning up stock heatsink. at this point we were also getting a consistent 12% higher boost core clock at stock voltage, due to lower GPU temps (again, they had an insane amount of thermal goo on the Chiplet package, and those super thick pads on the VRAM modules.) We got halfway into to that point before we realized we had to replace the cooling solution. as the 7900XTX with this cooler was only designed to dissipate 375w, and we were pushing 400w about -20% of the Rasterization of a RTX4090 (Stock/NonOC) We replaced the air cooler with a AIO 360 water unit, and attached larger heatsinks to the VRM and VRAM arrays, and had to mount fans blowing on them. 5th stage, at this point we were able to increase power to the GPU some more and the boost clocks well over 3GHz on the shader clocks and 2.9~ on the core clocks, once we got that stable it was ~18% behind the RTX4090. 6th Stage, we finished this yesterday, we replaced the AIO 360 with a custom loop, GPU was water blocked, and we utilized 3 custom ram water blocks attached to the VRAM Array, (Modified MOSFET water blocks), and then we added MOSFet Blocks to the VRM Array as well. this entire loop was external, as it was simply built for testing. Loop was Reservoir, Pump, MOSFET/VRAM Blocks/ 240 RAD / GPU / 240 RAD / Reservoir. The Reservoir was also cooled (in a small desktop minifridge modified w/ tub ports.) 7th Stage, added more voltage and was able to push core clocks to 3.2 and shader clock to 3.4 ghz At this point we are 10~% behind the RTX4090. 8th stage, adjusted core and shader clocks to allow more rasterization while not req. more power, lowered shader to 3.25, increased core to 3.35 and gained 2% (-8% of RTX4090). At this point the 4090 would be pulling 520~watts, the RX7900XTX was pulling 425~w, Any further power increases caused stability problems, likely due to the limit of only 2x 8Pins, we were pulling 10% over the PCIe Connectors and PCIe Slot specs as well. So, the performance is there, some AIB Partners are showing their 4090 sized coolers on their RX7900XTXs w/ an additional 8 Pin Power connector giving them up to 525w ceiling. Younger system builders, if they weren't around during the nVidia G80/G90 days, dont understand how to manipulate the de-coupled frequencies. Also Video w/ results is coming, it's being edited from 49 hours of footage. we also told our findings to other reviewers, so

In this DCS world video we will be taking a look at the Onboard Defence System for the KA-50 Black Shark 3 which is releasing soon!

For the release I'm permanently improving small stuff and therefore I never want to release it aha I think around christmas would be a nice moment. I'm working on this on my side so once it's over i will probably release it Real tankist may like it, it'll bring back some memories For those of you who don't have any real weaponry culture ;), this is a tank rudder. The kind of system which is used to drive a tank turret. The sole difference mechanically whith a real one is the left grip which is used as an accelerator grip, like a motocycle.

Please do share your findings. For me, the biggest question between 7900 XTX and 4080 is now how it's going to perform in DCS / MSFS VR. While we might get some 'big boys' to test in MSFS, for DCS performance it's impossible to rely on anymore, but fellow community members

Sounds negative.

if the discussion is purely about the strenght of the radar it might even be correct as it is, however the limiting factor to finding and locking stuff at reasonable ranges is the excessive lookdown penalty and how this is applied to the radar in DCS. no point listing it all here, all data and evidence of how absolutely borked it is can be found here: and here: instead of saying "correct as is" dear Newy, and therefore cause even more discussions, maybe list the items that are currently under investigation. by far it isnt correct as is and the evidence is there too.

Ok so the to do list for the upcoming 5.0 "Cold War" update : - AMX-30B2 - AMX-30B2 "Daguet" - AMX-30B2 BRENNUS - AMX-30 AUF1 - AMX-30 Roland - AMX-10P - AMX-13 DCA - AML-90 ... - Crotale NG as a bonus Those are the only vehicles I'm both motivated to add and for which I have enough datas. Sorry for the Caesar, the AUF-1 will do the job. Though one wants it he can provide me accurate blueprints and photographies. 5.0 will be released by the beginning of january.

Yes, it will be released on December 24th ... looking forward to it.

So, I've been meaning to sit down and do this for a few weeks and have just now found the time. I'll try to keep it short, but it won't be, so I'll try to keep it dense. I was an Aeroscout from 1988-1993 flying the old OH-58 A/C. Back then, the scouts were unarmed for the most part, save a M-16 jammed across the glare shield and my .38 revolver in my survival vest. For this reason, we typically operated in a scout/weapons team with an AH-1S following as our armament. The Apaches and 58D were just coming online when I left the Army. I'm loving the DCS Apache and am chomping at the bit, but not holding my breath, for the Kiowa Warrior. I've been observing how the Apache is being employed on several servers and very much so on the Rotorheads server. I have some observations to offer tactics-wise that some may find helpful. This will apply to the U.S. attack and utility helicopters specifically as the Russian helicopters are designed differently and for different doctrine and they are employed more like very low level, very maneuverable, fixed wing aircraft that happen to be able to take off and land vertically. Keep in mind, I was in a very different aircraft with very different equipment and very different times, but I think this advice should still hold true. If there are any Apache or Kiowa Warrior vets here that have anything to add or critique or correct, I welcome the input! 1) Here's the biggest thing: I see a lot of folks just hovering at 800, 1000, 1500 feet AGL for many minutes, lobbing hellfires at bad guys. If you are doing this, you are really missing the advantage of a helicopter which is to utilize cover and concealment to survive. You should unmask just high enough to spot and shoot the threats that are in range. In some threat situations this may be fine but for the most part, the longer you are way up there, the more likely you are to be tracked and shot down. It also leaves you with less evasion options especially when trying to evade from a state of zero or low airspeed (-60kts). 2) Too much hovering. You present a more difficult target to track when moving even if it is at just 30-40kts and you have a quicker response for the aircraft to deploy to cover if you are engaged. Also, you will increase the flight endurance by keeping hovering to a minimum. This is also a great way to avoid settling with power. Also, if you are hit, it is easier to autorotate with some forward momentum and it gives you a better chance of getting to a safe landing location. 3) Unmasking in the same spot twice in a row. This is a cardinal sin! I learned this in my first trip to Hohenfels maneuver area where we war gamed with m.i.l.e.s. equipment. On a night scout mission, we unmasked from cover and saw a OPFOR tank nestled in a tree line. We immediately masked but didn't get a good fix on the type and exact position soooo, popped right back up in the same spot and this time, Mr. tank had his turret pointed right in our direction and shot us down (simulated)! 4) More of a courtesy: Calling "rifle" on comms and coordinating laser codes with others to avoid targeting conflicts and other pilots frantically dumping precious flares and diving for cover every time a friendly Apache fires a missile. Along the same lines, I typically set my countermeasures on bypass, so I'm not wasting flares on friendly fire, and I don't carry chaff. If you have your helicopter close to or down in the weeds, radar guided AA should be a non-factor and then you can carry more flares. Also, if you limit your altitude, and a radar guided weapon is fired at you, you can easily defeat it with cover or concealment. If you are still with me here, my typical planning and profile looks something like this; Before departure-I set a start point in the TSD, and alternate, and then note a point that is about 10K from the FEBA with good terrain relief or concealment, trees or buildings, and set a release point there, in the TSD. Load 50-60% fuel and 90 flares plus weapons of choice. If there are preprogramed CM's or TGT's on the TSD, I make note of them and plan for my ingress from the RP to avoid contact. Countermeasures on bypass, Acq to TADS, left MFD to Vid/TADS so I can see what the CPG or George is looking at. During the day, I will jump in the front seat for a sec to set TV instead of FLIR if I have no CPG. If someone knows how to do that from the back seat, let me know. After takeoff-Climb to about 800ft AGL so I can safely get my head in the cockpit for a minute without driving into the ground. If no CPG, I get George set up and WASed on hellfires and have him look ahead at the next waypoint. Make sure all exterior lights are off, countermeasures on, weapons armed, gun WASed. Set direct to RP and note the flight time. I usually use flight time plus 30 to 45 minutes, depending how far away I get from the RP, for my bingo time. When I'm all fenced in, I head down to treetop height for ingress, around 100kts, using terrain features to mask my aircraft. Approaching RP-A click or two out from RP I will pop up, keeping my speed up, high enough to get a good view over the terrain. I have the CPG or George do a quick look at 10, 12 and 2 o'clock. If nothing, back down to the weeds and because I'm expecting enemy contact but don't know where or when, I proceed a little more methodically. 40kts, quick pop up every couple of clicks, quick scan, if we make contact, back down in the weeds and head that way at 60kts, quick pop up now and then while under way until I'm in hellfire range. Targets in range- At this point, come to a hover behind cover or concealment noting the terrain around us as we prepare to engage. Identify ahead of time the next firing position and where it is safe to break to cover and always know the safest egress. Unmask, just high enough to see the target and either fire if it has already been acquired or, spot, lase and store, then immediately deploy back to cover. Don't get fixated on multiple targets and drift higher and higher in a hover and remain exposed. Fixating is easy to do and I'm guilty of it myself. Hard to resist easy pickings but when that Strela shows up that I didn't see before or it spawns in near me and I'm 1500ft in the air with nowhere to hide...bad news. Kill one, back to cover, I reposition laterally (not actually flying sideways but actually moving to positions to the left and right of me) instead of moving forward, below the tree line or terrain feature then pop up and repeat. A lot of times it pays off to bob up to just do a scan from 9 to 3 o'clock and, from close to far, to identify any threats you missed, just spawned in, or are a greater threat than your target group, without engaging. When all targets in range are cleared, I go back down, 40kts, bounce cover to cover and repeat the above until new targets present themselves. In the thick of it- I stay low, like weed top level, and moving 30-40kts, unless I am actively popping up to search or engage then quickly back to cover. Avoid flying over groups of trees and if I have to, always make notes of clearings to duck into or autorotate into if I get hit. I don't want to have to crash land into trees. Pop up only high enough to see and engage targets and don't unmask in the same spot twice in a row. If that manpad, Zeus monster or Strela, sees me and doesn't have time to fire, he surely will get me the next time I expose my helicopter in the same location. Great thing about helicopters is if one gets disoriented or loses SA, one can just scoot to cover, land and get regrouped. Egress-No matter what phase of the fight I'm in, I ALWAYS know how I'm getting the heck outta there! At Bingo (ingress+30 to 40 minutes fuel time) or Winchester, whichever comes first, I get down and fast, staying in low ground. 10ft AGL is a lot of work but it's a blast! 120kts, 10 feet off the ground feels pretty fast. In fact, all this is a lot of work and a few hours of it is pretty tiring. Often my rear end hurts from clenching, working rudder pedals. I probably actually have a higher "fatality" rate from pilot error than I do from being shot down. But the more I fly, the better I get. Night and other considerations-The dark offers a level of concealment that allows to fly a little higher up, 200 to 500ft AGL. Keep in mind though that the dark only protects you from visual acquisition. The Apache is fully capable of operating down and dirty in complete darkness and I usually don't change my strategy. It does require significantly more focus and SA to do safely. I will usually ingress, egress and land using NVGs and then transition to IHADDs when I'm close to the RP. In situations where the AA threat is non-existent, flying and attacking from altitude is fine but it is a good idea to stay moving. I'll usually do orbits, engaging as I approach and then breaking when I'm close to small arms range. This makes it easier to maneuver if a threat does appear, make it easier to autorotate if the need arises and uses significantly less fuel than hovering. Like I said, there may be some new considerations that I'm not aware of due to the ancient nature of the helicopter I flew in. I would love to hear some thoughts, positive or critical, on this from Casmo or other guys that flew Apaches or Kiowa Warriors. And one last thing, if anyone sees me, Aeroscout'88-'93, on a server somewhere, feel free to hop in the CPG seat and we'll go put some warheads on foreheads!

From what I gather a lot of the navigators job was to keep his head on a swivel and in particular ensuring there were no fighters diving on the six o'clock position. I would like it if ED could give the navigator (when not crewed by another player) at least very basic functionality such as calling out enemy aircraft that they see/detect. "3 o'clock high!" etc. In much the same fasion as Jester on the F14 does - but I'm not expecting anything anywhere near as complex as Jester.

All- I spent the last ten years in "guerrilla" marketing and memes are big part of that. After the last year of immersion into the DCS culture I have experience/observed many humors and funny things; mostly based on my own stupidity. I thought perhaps sharing some of those experiences might bring a smile or laugh to some of you. I WILL NOT post anything offensive, foul language, or vulgar about anyone in or out of the community or any companies. I ask if you post a meme of your own please follow the same rules. We are wonderful community and have a lot to giggle and laugh about at ourselves. Thanks

before starting all over again, i encourage you to actually take a look and perform the same tests as performed in the comments linked here: https://forum.dcs.world/topic/305171-f16-look-down/?do=findComment&comment=5012201 and here: https://forum.dcs.world/topic/305171-f16-look-down/?do=findComment&comment=5016740 and here is a whole lot of data collection based off of such tests with all sorts of ranges, altitudes etc: https://forum.dcs.world/topic/305171-f16-look-down/?do=findComment&comment=5048120 and please dont take it personal, yet this comment is ruining a lot of work for people who have been actively trying to get ED to fix this over the course of this year now. just saying "it works for me" is not achieving anything without bringing up valid data to not only support this claim (and i doubt you did any of these tests) but also disprove everything else that people have reported.

I don't think it's about being realistic or negative or anything but taking the situation with a bit of humor. So take it easy believe what you want and if you like smile if someone has a funny way of praying

@Moonshine Thank you! We have definitely noticed this. Just now someone of our group sent me a screenshot, flying at 27K, target at 10, cold at 22K at 15nm and the target does not even appear on the FCR. Like i said i am not an expert, i also do not have the time to test this all myself but the general feeling of the radar as it is now is that its unreliable and very inconsistent, The other issues reported about lookdown etc might be one of those reasons. Im glad for all your work on these topics and thank you for sharing those so we can bundle this into this topic!

Tried the 7900xt last night and was very disappointed. Frames were about the same or worse then my 6800xt. BAR had a noticeable negative impact on frames. Overall about 30-40% less fps then the 4080 I returned. 6800xt=50fps sitting on the ramp in F5 on Caucus however frames seemed to drop more during flight then the 7900 (relatively speaking, frames didn’t seem to drop in flight as much with the 7900 but they were still lower overall in flight as well with the 7900xt) to about 40-45. 7900xt = 42fps dipped into the high 30’s in flight saw high gpu utilization throughout (high 90's with 99% most of the time I was looking at it). 4080 = 60fps rock solid 60 or more in flight, gpu utilization was often below 90%, down to as low as 75% I’m currently running a 5800x3d with 32 go ram at 3400 with g2 in open xr. Cleaned up drivers with ddu after every gpu swap. Also probably worth mentioning that my 6800xt is overclocked/undervolted. I did not change anything for the 7900xt except BAR. On a sub note, the low gpu utilization of the 4080 is weird because if I turned on FRS with my 6800xt in VR and ran a low resolution I could easily get 90fps, which seems to indicate on this map (same for all comparisons) that I am not CPU limited.

I got XTX for 1200 euro from AMD directly. Cheapest available 4080 is 1500 euro and cheapest 4090 is 2300 euro here. If I were flatscreen gamer I think XTX would be obvious choice with these prices. VR however makes things bit different. According to tests from the site that was posted above XTX loses to even 3080 in VR. I don't know how that translates to DCS. I will need to figure out some fairly consistent tests to test it myself. The issue could be driver issue, if I remember correctly 6000 series also has bad VR performance on launch but it improved later. You can't really bet on that however. If XTX fixes either of 2 issues I currently have, screen tearing with ASW on or microstuttering when looking to sides with ASW off then I will probably end up keeping it.

Okay, guys, build walls around my base. I've got 4 monasteries. I'm going to concentrate on upgrading and making an army of monks.

You’ve said it all Pikes. Wow!!! It’s really an amazing achievement especially by Apple and Funky that have really kept the boat afloat in the past years. Not to mention the hundreds of Discord users that constantly keep the discussions going.

Yes I honestly count myself so lucky that the first Phantom coming out is precisely my favourite version, and I feel for our Navy fans. I know for a fact there will be times I'm going to be hurting to use that pulse Doppler goodness that the F-4J or S would bring. Let's hope that the F-4E and early F-14A RWR rework cuts down the amount of work needed to get the USN Phantoms out as soon as possible. That said, you bet your butt I'm going to try a takeoff in the F-4E from the very stern of the boat...

OH-58D develop pics.

Some new pictures from PC discord:

After some experimentation and help from friends, I was able to figure out how to get the group to attack. Instead of using a triggered action to tell them to attack a group or search a zone, I used the triggered action to set their waypoint to one that had a search/engage zone configured. When the initial trigger fired, they broke their orbit to head to the waypoint specified and then followed the search/engage zone to their targets which they engaged. I ended up using AI task push on the trigger, as AI task set wipes their flight plan causing them to rtb. Task push just sets the skip waypoint action to the top of their action queue.

Is that for AS-30L ?

I have reorganized - see this thread for more information:

I am very very guilty of this

Не вижу в обсуждениях ничего не относящегося к теме VR. Память, процессоры, видеокарты и т.д влияют на качество/производительность в VR а следовательно имеют полное право здесь обсуждаться. Выбирайте пожалуйста выражения Уважаемый, здесь общаются очень интеллигентные люди, грубостью (подразумеваю употребленное Вами слово "гадить") Вы вносите диссонанс в тонкую душевную настройку сообщества. Надеюсь на понимание.

You could realistically save yourself some finger stress and leave this thread. I pray you find peace.

I would love having a Tiger!

with the latest bios Asus added the option...so I have it set in BIOS now...just to let everyone known... -30 stable as rock

Great write up. May thanks to the team for their continued support of this invaluable framework. Without MOOSE, the life of mission builders would not be the same.

18 Days.

I just wanted to thank everyone who contributed to this guide, especially Supma! I've got it all sorted and running DCS in Varjo OpenXR Mode with my Varjo Aero and it works wonderfully. My ONLY problem at this time is that, when I start DCS, the main DCS screen seems to be at my feet in the virtual space, which I can fix just by hitting NUM5. I installed openvr_api.dll, and I started DCS with the --force_steam_VR flag. That seems to be pretty much it, all that is really required. OpenVR and OpenXR are both turned on in the Varjo Base app. I don't have the cursor offset in the cockpit that I got in Varjo OpenVR mode, and I don't have to look at the awful flickering that I'd get while loading DCS in Steam OpenVR mode, nor do I need to use the "crosseyes" tool. Framerate is smooth and I can run my 3090 with a lot of options on "high".

Well done Pikey and the team! I don't know where DCS missions and hosted servers would be today without the generous time donated by you and so many others to create such wonderul rich functionality. Huge thanks!

The best way to increase vertical FOV is to wear the headset such that the lens sit close to your eyes as much as possible. What I did was switching the original facepad to something really thin. You might be surprised how much vertical FOV you can gain (wear the headset without the facepad to get the idea).

@_BringTheReign_ I am rubbing my lucky rabbit foot, too.

It's definitely a possibility. But I've decided to start with modern ships.

As @DD_Fenrir said, it is not a Phoenix problem, rather DCS that shows all of its flaws the moment your aircraft interacts with… anything really: ATC, JTAC, AWACS, ground units behaviour, radars, RWRs, jamming, datalink, countermeasures, missiles, and the list is still very long: these are all very poor mechanics realism-wise, and Air-to-air combat is simply the worst offender. One day, when these mechanics are overhauled (and I'm sure ED is already moving in this direction), we will see that building SA will come much more difficult and, consequently, missiles will become more lethal. In the meantime, the only way to get a *slightly* more realistic experience is flying Cold War scenarios (but there are no realistic servers around). Then, tweaking the AI to randomly change how it behaves, from an omniseeing entity to something that can get killed without even defending (more realistic than you would expect), or defending without nailing the overexaggerated notch every time. Lastly, Jester is just an interface to the AWG-9. It is not any better than the pilot controlling it (potential bugs aside, of course).

Just to be clear, no missile gets nerfed. Missiles may go through changes, updates and improvements to make them as realistic is possible. The AIM-54 does have some minor tweaking still to be done, but in no means has it been "nerfed" or is it "trash". Heatblur and Eagle Dynamics work together on these issues, its not about pointing the finger at one or the other. We are both focused on making the AIM-54 as real is possible. If you have a bug or an issue, please reported as required. Thanks all.

Hello everyone. I'm pleased to inform you that the next Open Beta update will include the first set of revisions and updates to the F-16 manual. The manual has increased in size from 318 to 452 pages, and includes a mix of revisions and new content. Below is a screenshot of the most recent entry in the Latest Changes list that illustrates what you can expect in the update. The next edition will also include a greater use of embedded and discrete hyperlinks to facilitate easier navigation. Expandable bookmark entries will be present, however in some cases there may be options to directly click on an entry to take you to the applicable section. For example, if you were to click on the orange box labeled "Data Entry Display (DED)" in the cockpit image above, the manual will proceed to the following page outlining the DED: From this page, you may then click on "CNI", and the manual will proceed to the specific sub-section explaining the DED's CNI page in greater detail. Not all figures will include hyperlinks (in some cases because the sections have not been completed yet), but if you mouse over a word box and your mouse pointer changes to a small hand icon, that will indicate that you may click to go directly to a manual section that explains that item or function in greater detail. Finally, I want to stress that this is just the first set in a series of updates. As you can see in the Latest Changes image above, there is still a ways to go; but the actual progress is further along than what you will see in the next manual version, and work has not stopped since pushing this version for publishing. Thank you to all the virtual Viper pilots out there for your patience. Respectfully, Raptor