Hextopia

I'd put in a pull request on the HDS github if you've got a bug (and fix) that applies to 2.01: https://github.com/Auranis/HighDigitSAMs

In a technical sense, I believe the way units in DCS still work is that night only gives penalties to a unit to "spot" a unit, but once any sensor on the unit "spots" them, the 'Mk1 eyeball' sensor can take over and maintain track of the unit (assuming it is a valid sensor to provide guidance for the weapon the unit is using). So the Tunguska can pick up a unit on radar, and 'pass' the track to the visual tracker, since it's a valid sensor for the SACLOS missiles it has.

Another approach that would help validate the approach used to interpolate aircraft performance from these listed procedures is use the same method to generate a rough flight model for another aircraft with much better documented performance (like say, an F-16 variant, or better yet, another delta wing aircraft), and then compare the model's issues with the known flight test data for it and see if those same complaints are being levied against the Mirage. If there's an underlying issue in the procedure used to build the flight model, it would likely show up in both.

I humbly ask that you really press this issue home with the team and make sure that they understand this is going to be another PR stick in the eye if you simply lock a change like this behind IC without doing something to address the underlying issue its trying to fix. Taking some time to examine this mod in detail and potentially including it as a temporary improvement over the current single pixel system would go a long way towards making the community feel heard when they bring up issues that are low cost to fix and implement but they go unacknowledged by the team at ED.

Just had a crash while flying a mission where, as we used PAL to lock a Mig-23, the DCS crash dialog popped up. Crash log looks like it's related to an access violation with F-14 avionics.dll (log is attached) Haven't had one of these in a long time, so I assume it's related to the latest patch. dcs.log

I've got voice attack, and I'm just not a huge fan of it. I'd rather use buttons/keybinds than try to get voice attack working correctly and not interfere with my SRS/Discord comms.

Is there any chance we can get jester menu axis bindings? It's a pain to use sometimes in VR, and i've got a thumstick axis sitting around collecting dust that'd be perfect for controlling the jester menu.

If this is how you're simulating it, do you think it's possible to either detect bad mulltiplayer tracks (and clamp onto them until they stop lagging and behave) or do some light "fuzzing" of their location when in MP to expand what the WCS will allow to correlate and reduce some of the erroneously dropped tracks?

Is this mod fully integrated into the base game now? I seem to remember reading an update saying that in patch notes over the past couple months and just wanted to verify.

The seeker on the RB-15 almost certainly isn't built to deal with the vastly different environment on land vs a ship on water, so you'd have no idea what it would end up targeting. It might hit a building or bridge or something, but it also might just hit a random tree, car, rock, etc. No way to know what it'd actually hit.

I'm wondering moreso whether any jammer in the FOV of the AIM-7MH should be causing it to go into HOJ. I had an instance where I fired an AIM-7MH at a target at ~5NM away, but the missile turned off target to track a friendly with their jammer on ~10NM away. I'm fairly certain, even with an automatic HOJ logic in the missile, it'd still target and follow the much stronger radar return from the AWG-9 illuminating a target at 5 miles versus the lower power jammer further away. If anything, it just seems like an additional check to look at relative radar return strength should happen to see if the original track is lost and HOJ is entered.

Not sure if this is intended behavior, but AIM-7MH's shot at a target in STT that isn't jamming will guide to a nearby jamming target (even if that target is outside the radar's illumination and further away). I can put together a mission and track if it's needed, but the fundamental question is, should the AIM-7MH be going into HOJ if there's a jammer in the seeker FOV, or is that something the aircraft commands?

It's pretty easy to just compare the EM graphs and see that the Mirage doesn't really have many options against the F-14 (Unless they meet up with a serious payload mismatch where the F-14 is crazy heavy and doesn't jettison stores). The Mirage's only trick is to pull crazy alpha and hope the F-14 tries to get super slow with it, since the F-14 matches it in rate at a much lower speed and tighter radius in a comparable setup. With how much more power and rate the F-14 has though, it's on the pilot to just reject the 1-circle and force the Mirage pilot to the deck, extending on an overshoot instead of trying to get into a scissors where you'd lose to the giant airbrake doing its airbrake thing. tl;dr: The F-14 crushes the Mirage in the rate and radius fight for a similar fuel fraction except at extremely high alpha/low speed, so the only way the Mirage is winning a fight is with a scissors defense that the F-14 commits to, assuming the pilots are of relatively comparable skill.

Compass sync indicator shows perfect alignment when actually unaligned. Most noticeable when taking off from the carrier, I can get it to work correctly by flipping the switch back and forth until the sync indicator moves. Even after getting it to indicate correctly, it will occasionally flip back to perfectly centered while holding the button down to sync the compass. Will post a track when I get a chance to make a short mission to replicate it.

Out of curiosity, why is this such a high priority for you? The HUD and VDI are always perfectly trimmed, so you shouldn't need to mess with the trim knobs.

Bumping to ask for resolution on this bug. Just had another flight where this happened and I was barely able to launch off the cat with only a "light" 3-2-2 loadout thanks to the extra 16k lbs of weight.

This might seem like a dumb question, but was high altitude drag modified in this patch? I was able to get up above Mach 2 at 45k in the F-14B yesterday, and I've routinely had issues sustaining Mach 1.4 before, so I'm wondering if the flight model tweaks that were discussed somewhere a while ago around high altitude drag/speed made it into this patch.

Probably shouldn't have merged these threads until after the problem was fixed, since the title on this thread doesn't make it clear that 4 HARMs is out until the next patch.

Tested a 4 HARM loadout and wasn't able to get the inner pylons to fire. I thought the loadout restriction patch was going to re-enable the inboard HARM pylons?

That may have been a typo, but I want to confirm you meant a feature request for VR and not Viper, since the issue is the full-screen NVG effect in VR, not specific to the viper.

Recoil's IFFCC AAS mod is now broken. This mod is a quality of life fix that adds commonly seen aircraft to the air to air gunsight, and removes friendly aircraft as enabled by default, a huge timesaver when starting up the A-10. https://throughtheinferno.com/mod/recoils-iffcc-aas-combat/ Affects: Mods\aircraft\A-10C\Cockpit\Scripts\IFFCC\IFFFCC_param.lua Mods\aircraft\A-10C_2\Cockpit\Scripts\IFFCC\IFFFCC_param.lua

The A-10 RWR Expansion mod is now broken. This mod adds unique RWR sounds for all threats based on how Falcon BMS models the AN/ALR-69. https://forums.eagle.ru/topic/92508-dcs-world-a10-c-rwr-audio-expansion/ Affects: Mods\Aircraft\A-10C\Cockpit\Scripts\AN_ALR69V\device\ALR69_param.lua Mods\Aircraft\A-10C_2\Cockpit\Scripts\AN_ALR69V\device\ALR69_param.lua

Gronak's ABRIS mod for the rotorheads server is now broken. This mod allows the rotorheads livemap to be pulled into the ABRIS (since datacartridge functionality still doesn't exist). https://github.com/gronank/RotorheadToABRIS/releases/tag/0.3.1 Affects: mods/aircraft/ka-50/cockpit/scripts/devices_specs/abris.lua

English KA-50 HUD/SHKVAL mod is now broken. Fixes a long-standing bug with the KA-50 HUD/SHKVAL and converts Russian HUD characters/language into english equivalents since for some reason this isn't done when avionics language is set to English for the KA-50. https://www.digitalcombatsimulator.com/en/files/607269/ Affects: mods/aircraft/ka-50/cockpit/scripts/materials.lua mods/aircraft/ka-50/cockpit/scripts/fonts.lua mods/aircraft/ka-50/cockpit/scripts/ekran/device/ekran_localizer.lua mods/aircraft/ka-50/cockpit/scripts/hud/hud_nav_common_page.lua mods/aircraft/ka-50/cockpit/scripts/hud/hud_weapon_common_page.lua mods/aircraft/ka-50/cockpit/scripts/hud/hud_shkval_page.lua mods/aircraft/ka-50/cockpit/scripts/shkval/shkval_page.lua mods/aircraft/ka-50/cockpit/scripts/pui_800/pui_800_page.lua

You'll have to excuse me if I'm skeptical when you claim you want it for yourself and to make new users' experience more enjoyable when all available metrics on VR show doing what you're talking about isn't what players, especially new VR players, desire. It's doubly confusing when you're also saying stuff like this: You're literally what I was describing earlier (vocal forum user, DCS WW2, PvP player, who's also worried that other VR users might be checking six through their canopy), and you've already declared your intent is to prevent this because you perceive it to be a significant problem. This is a recurring trend of users who advocate for these head limits, claim the primary issue is an unfair advantage in PvP (a silly argument to even make in the first place, when the playing field is already uneven to begin with between users with different view settings, hardware, the differences in TrackIR vs VR, etc.), and then later claim it's "just for themselves" when they start getting push-back from other people. I really don't want dev time wasted on something affecting a tiny portion of players when we could see actually useful improvements, like mission editor improvements, VR performance improvements, AI work, UI improvements, etc. All things that are higher priority than trying to enforce view restrictions on the VR community because someone's sure the person they were fighting is a cheating VR user. While I will agree there are some players out there who actually want a hard head limit for themselves, I've only personally flown with 1 of the ~100 or so I know, so I'd be willing to believe they're the minority. I can see how It's easy to feel that VR players who don't mind that are the minority though. When you're playing a game where almost every active server enforces it, it's pretty likely there will be selection bias.