NeedzWD40

Yes, you can configure the radar to scan a narrow arc repeatedly or once, twice, etc. depending on requirements. Most of the settings are related to existing settings for the TADS as they overlap (FCR selected will use TADS FOV to adjust scan zones, etc.) There's a lot of complexity behind it and the things it can do would make it the most advanced radar in DCS; it's for this reason that I wouldn't blame ED for simply doing a NR/WO version alone (although do note that we should get that version either as a mission option or separate airframe for a variety of reasons). At the basic level, you get a wide 90 degree arc that can be narrowed down and scanned within that 90 degree forward arc. The radar can also be linked with TADS and IHADSS to display what it sees as icons in 3D space.

Counterpoint: AH-64D demonstration: https://www.youtube.com/watch?v=zzKYogDjagw Not really. The ASE suite on the AH-64D is faster at alerting to (and responding to) threats than on the older AH-64A. Data linking also makes it far easier to get a picture of the whole field, which includes both what friendly ground units have observed and what other aerial units have observed. Your primary flight instrument will remain IHADSS. As a pilot, your MPDs will be used to cross reference what you IHADSS is telling you, the same as the steam gauges do on the AH-64A. For example, you might set your right MPD up to the engine page while your left MPD is set to the flight page. Or you might put a repeater of the PNVS camera on one MPD and cross reference it with the flight page. It's all entirely up to the crew and their preferences, along with the situation at hand. Most AH-64D functions are on the collective and stick, not the MPD bezel buttons. You won't be messing with the MPDs in critical situations. The CPG's primary purpose is to operate the sensors and weapons, with secondary navigation and communication (note that the AH-64A's EGI/GPS is located in the CPG's right console). The AH-64D allows more task trading between the two crew, so it's possible for the pilot to hand off control to the CPG to do something and vice versa. Presently, the closest analog is the F-14A/B, though it doesn't have the ability for the RIO to fly the aircraft, but much of the tasking in the AH-64 is similar. The only reason the front seat is the CPG rather than the back seat was routing the TADS feed (particularly the DVO) to the back seat would've been unnecessarily complicated.

As a point of reference, the AGM-114L does not require the FCR to operate. It's basically an INS-ARH missile to put it plainly; tell it the general nature of the target and the approximate position to go and it will try and match the signature of what you told it to find. The FCR just makes it easier to find and prioritize targets; without it you would just use the TADS (or another data source entered into the systems) to tell the missile where to go and what target to look for. The FCR itself is a complicated little gizmo so it's hard to narrow down everything about it. I'd personally just keep it basic with A/A, GMT, and terrain modes, but I realize such a solution might not be palatable to all parties involved.

Yes, the disco ball (ALQ-144) was considered the primary means of defeating IR guided missiles. Effectiveness of this IR jammer is suspect against modern IR threats, which is why you see gradual removal of it over the years. As noted, it's not that they couldn't, but that they didn't need to until the past 20 years proved the necessity of it. By that point having a MLWS was also in the cards so flare buckets were just thrown in with the CMWS upgrade.

CMWS didn't start getting common until post 2008 and it wasn't until 2010 that the majority of the fleet had the system. TXARNG AH-64As were upgraded with the system until they were retired in '12. So, the old single chaff bucket at the port side of the tailboom actually had a setting for flares, with an associated selector in the AH-64A's cockpit to set the bucket for them. The AH-64D carried this over, so on a pure technical basis it would be possible to carry flares... However, in practice this never occurred and flare usage was relegated to the introduction of two dedicated flare buckets at the base of the tail with CMWS. I would also like to point out that it's not a certainty that a 2002 year AH-64D is what we are getting as the teaser has the M-PNVS assembly, which was not common until 2010. M-TADS was also slowly rolled out during this period, so you'll see from 2007-2011 a mix of aircraft that are essentially Block I standard to Block II.

This is true. AH-64D handles a bit worse than AH-64A. Some of the power was regained with engine upgrades over the years, but that was offset by additional gear added in Block II and later III/E. AH-64D still operates like this when utilizing TADS. The FCR can track vehicles and prioritize them as well as slave the TADS to a target position (or vice versa), but SAL missiles will still need to be lased via the front seat or buddy laser. RF missiles can be launched by the pilot, however. Control of the TADS remains firmly in the hands of the CPG despite this. On a pure technical basis, the CPG in the AH-64A could do everything but start the aircraft and configure rocket zones. In the AH-64D, the CPG can do everything but start the aircraft. The workload for doing so is incredibly high. FCR usage happened early on in OIF on a limited basis, then was removed as soon as the armored threat had diminished. The primary utility of all AH-64s (the A model was not fully retired until 2012) after the initial fighting was primarily an on-call CAS asset. Thus the use of SAL missiles, gun, and TADS primarily. In event of a conflict on more even footing, the AH-64D would be used in a different capacity. Despite this, the D-NR/WO would rely on either a FCR equipped aircraft for target prioritization or the TADS for engagement. RF HELLFIRE does not require the FCR for use. Agreed that on a historical basis, the AH-64A offers many possibilities, but don't mistake the AH-64A into being some kind of lesser, hardcore airframe compared to the D model. The differences are primarily in data linking and sharing. This did not happen much in reality as the OH-58D was markedly slower than the AH-64A. Cooperation as part of a team will depend heavily upon scenario design and circumstances, whether it is the A model, D model, or working with a Kiowa. The FCR is also not far more capable than any optical device; it has strengths and advantages like any other sensor. Agreed on this point. The data for a mid 90s-2005 AH-64A is more widespread and easier to implement, with far fewer problems associated with the MPDs and features. All the pages do is relegate previous functions that had separate controls throughout the cockpit into a paged MPD format. You set the aircraft up for navigation, attack, observation, etc. as mission dictates. They are a tool to make your job easier, but nothing mandates that you use every feature (and most of us likely will not). If you desire to use TADS and SAL missiles as your go-to, then you will operate the same way as you would with an AH-64A, simply ignoring all the data link features (which probably won't be implemented for years down the line). The AH-64D addresses shortcomings found with the AH-64A post ODS, in particular the lack of data linking and knowing where friendlies are located as well as what they are doing. The technology leveraged allows it to be more flexible in missions so it can do more than raw attack; ie, spot, relay, and guide artillery. Features greatly vary depending on block and generation as well as timeframe and unit. In essence, the AH-64D is capable of working with a team far more efficiently than an AH-64A, being able to coordinate with ground forces as well as other aerial assets. It will be up to players (and the scenario) whether or not to utilize those capabilities.

So here's the mission (requires Nevada map): F-14A AIM-7 Failure.miz The mission has the IL-76's start head on at 35,000ft while the F-14A slot is 25,000ft. Head on shots always seem to miss with the MH, while tail on shots seem to be picky about range and altitude launched at. They act like they're extremely G limited and can't seem to pull enough lead even though the target is well within energy parameters. They seem to drop an extreme amount downward before finally deciding to get up to speed and accelerate into the target, which comes too late to score a hit. Right up until they pass the target, they're trying to pull into it, with just not enough G available to pull right into it (too high velocity? too low air density?) I've trialed tail on shots from 10nmi down to 2nmi and they all result in the above scenario. PAL, Jester, and boresight mode all achieve the same results.

Have you tried tail-on launches? That was where I suspected there was something odd going on with where the guidance position, as launches between 2.5-5nmi would result in the missile shooting up behind the target.

I've noticed inconsistent performance from all AIM-7s launched in the F-14; the M model works the best but still has some teething reliability issues, while the MH and F models flat out miss in perfect conditions. The F/A-18C has none of these issues with any of the same models. This is related to this bug report from October, which I've appended my recent tracks to.

As of the latest patch, this issue plagues not only the AIM-7MH, but also the AIM-7F. The AIM-7M exhibits some similar issues but in testing seems to hit more consistently. In essence, it seems like the 7F and 7MH are aiming at some point behind the targeted aircraft and are either maneuvering too late or not enough. I tested against IL-76s set to no reaction, no chaff or flare, and ECM off. First shots at 25nmi, second at 19nmi, and third at 10nmi head on. All three shots with the F and MH fall behind the target, as if they're lagging behind somehow. Ms will have one of the three hit. Switching to boresight mode and shooting tail-on results in missiles shooting up and behind the target. Unfortunately my tracks go off the rails after the turn so they're only marginally good at showing the head-on results. F-14A AIM-7MH Failure.trkF-14A AIM-7M Success.trkF-14A AIM-7M Success 2.trkF-14A AIM-7F Failure.trk

I thought I'd add that the A-10A seems to be able to utilize the CBU-87 effectively and that the A-10C can get better utility by turning off the rotation parameter with the 87 and 103. However, doing so results in an always uniform circular pattern instead of the more oval and destructive pattern seen with the Mk20/CBU-99. In addition, the submunitions seem to have both the wrong model and behavior: the model is a PTAB bomblet with no parachute delay characteristics per the actual BLU-97 submunition. This makes me wonder if perhaps a huge part of the issue is the subs behaving like darts instead of parachute delayed as would be correct.

My own experience with the CBU-87 and CBU-103 suggests that the largest problem is the spread of submunitions is not uniform like they are with CBU-99/Mk20, which leads to cases where the subs do not hit or do not hit in quantity to do damage. Having said that, the BLU-97 submunition should not be totally useless on armor and should be effective against APCs and older tanks as it does incorporate a shaped charge. Armor penetration should actually be the same as the Mk118 submunition in the CBU-99/Mk20. Sources: http://www.designation-systems.net/usmilav/asetds/u-b.html#_BLU97 https://www.wk2ammo.com/showthread.php?8097-BLU-97A-B-BLU-97B-B-CEM-for-CBU-87-USA https://bulletpicker.com/bomb_-heat_-blu-97_b_-blu-97a_.html

The only news I have is that I have another scenario that has the same bug. osiris_theatre_pg_ob255v0.miz

I can confirm a similar issue, but I get no radar control outside of locking; azimuth, elevation controls are completely unresponsive. fa18c_radar_stuck.trk

Here's what I found: If the scenario takes place in 1995 or later, there are no issues. Alignment works just fine, no problems with CCIP or CCRP. If the scenario takes place prior to 1995, then starting on a carrier will result in CCIP and CCRP being off, even though INS is normal. Starting on a land base will present no issues. However, for the carrier, if one does the automatic start, everything works as normal with no issues in CCIP or CCRP. I tested with years set to 1989 and 1995 on the Syria map, on the CVN-72 and Beirut airport. Stored heading and full headings in both years and starting locations, only going to the NAV option for INS after alignment. I tried to see if the autostart was doing anything different but there was nothing obvious that I could see.

Alright, so prior to this update, uncontrolled red side jets were fine; nothing happened. Now, anywhere from 60-120 seconds after the mission starts, every uncontrolled red jet at Shiraz, Kerman, and Lar will explode. Attached is the mission without the blue jet present at Shiraz and the same mission with the blue jet present (v0 is the one with the fix applied and vEXP is without). For me, at approximately 98 seconds in, the uncontrolled red jets explode. This has been verified by others. New groups, deletion and recreation of old groups has no effect -- they all suffer the explosion. jenas_pass_pg_ob256vEXP.miz jenas_pass_pg_ob256v0.miz

Yes, I've been having a similar strange issue, but only on the Persian Gulf map and at Shiraz, Lar, and Kerman airbases. Uncontrolled aircraft set to red Iranian side will mysteriously explode 75-90 seconds from mission start at these airfields, regardless of date or time. I cannot recreate the effect with a new mission, only with some older ones. What seemingly fixes it for me is adding an uncontrolled blue plane to Shiraz airfield, after which nothing explodes anymore. I'm playing around to see if there's any other avenues outside of starting from scratch.

Just found this out today when I unchecked the "Load LAU-138 with Chaff" option for certain F-14 slots. The ALE-39 starts off with the mission editor selected load, but the radio menu option for ground crew loadouts does not work and the countermeasures are not reloaded in any capacity within a mission.

I was able to get a track of this warping issue; the first vehicles destroyed are fine, but subsequent hits with cannon results in the vehicles skipping around upon death. Track is ~6 minutes long so I have to link to it: https://www.dropbox.com/s/7bx2f4cinehrq85/Warp_AI_MP_trk.zip?dl=0 Around 4 minutes in demonstrates the behavior.

I'd like to add some additional information on this issue: I'm attaching a WWII Normandy scenario that is scripted to last for 6 hours with AI aircraft groups respawning only, no ground vehicle respawns, and AI aircraft set to respawn every 5 minutes. Some groups have waypoints that change depending on objective status, but other than that they fly in a linear fashion. There's a master script that runs every minute to check the time, objectives, and aircraft group status, then adds groups to a table if it's time to respawn them. A flag is then tripped and a separate script attached to a continuous trigger runs the actual spawning script. Through this mechanic, I keep track of how many groups are spawned via the script. Now, the interesting part is after approximately one hour of activity, I start to get out of group errors, even though my spawn counter has only gone up to 13 groups. Assuming the IDs error applies to units, that's only 26 units, as there's two aircraft per group (except for two groups that only spawn every hour, where there's four aircraft in these groups). Groups still spawn, but the out of groups error still spams the log. Using env.info, I track various script status messages: 2020-06-05 21:44:10.734 INFO Lua: Lua CPU usage: metric: average mission execution: 4.4816 % 2020-06-05 21:46:10.603 INFO SCRIPTING: bFZAb Air spawner OFF 2020-06-05 21:46:10.603 INFO SCRIPTING: bFZAb Masterloop Heartbeat Time: 66 Total spawned groups: 12 2020-06-05 21:47:03.033 INFO Lua: Lua CPU usage: metric: average mission execution: 4.3806 % 2020-06-05 21:47:38.584 ERROR_ONCE DX11BACKEND: texture 'p51d_spec_fuz_rear' not found. Asked from 'NGMODEL' 2020-06-05 21:47:42.338 INFO SCRIPTING: bFZAb Blue aircraft spawner 2020-06-05 21:47:42.338 INFO SCRIPTING: bFZAb Inserting B_P51DCAP01 to build list 2020-06-05 21:47:42.338 INFO SCRIPTING: bFZAb Air spawner ON 2020-06-05 21:47:42.338 INFO SCRIPTING: bFZAb Masterloop Heartbeat Time: 67 Total spawned groups: 12 2020-06-05 21:47:43.349 INFO SCRIPTING: bFZAb Running Air Spawner 2020-06-05 21:47:43.559 INFO SCRIPTING: bFZAb Spawned air group B_P51DCAP01 2020-06-05 21:48:11.294 INFO Lua: Lua CPU usage: metric: average mission execution: 5.2583 % 2020-06-05 21:49:06.735 INFO SCRIPTING: bFZAb Air spawner OFF 2020-06-05 21:49:06.735 INFO SCRIPTING: bFZAb Masterloop Heartbeat Time: 68 Total spawned groups: 13 2020-06-05 21:49:59.306 ERROR SOUND: can't load wave: "speech\eng\common\atc\callsign\carpiquet" 2020-06-05 21:50:06.732 INFO SCRIPTING: bFZAb Air spawner OFF 2020-06-05 21:50:06.732 INFO SCRIPTING: bFZAb Masterloop Heartbeat Time: 69 Total spawned groups: 13 2020-06-05 21:50:42.764 WARNING EDOBJECTS: RegMapStorage has no more IDs 2020-06-05 21:50:42.764 ERROR EDOBJECTS: Failed assert `false` at Projects\edObjects\Source\Registry\RegMapStorage.cpp:42 "Masterloop Heartbeat" measures the current running minute of the script since it started, "Air spawner" indicates whether or not the group spawn flag has been set, "Inserting X into build group list" is indicating what group is being added to the spawner array. The spawner script then indicates it is running and what group(s) it spawned. Note that this script will run only once per minute, so if multiple groups are to be spawned, they will have to wait a minute for the next iteration. Finally, "Total spawned groups" is exactly what it says on the tin, though this value tracks how many groups have been added to the spawn array/list rather than spawned groups directly through the spawning script. This scenario was ran for 108 minutes in singleplayer (testing new P-47 groups replacing P-51s), so this particular issue doesn't seem specifically constrained to multiplayer situations. It also seems to be more pertinent with WWII assets versus modern ones. I've attached my (quite large) log from this run for analysis. pegasus_gamble_nm_ob256v0.miz dcs_log_pegasus_gamble_060520.zip

Per the title, attempting to rearm on any FARP object results in a game crash. 2020-05-20 19:58:35.013 INFO EDCORE: try to write dump information 2020-05-20 19:58:35.015 INFO EDCORE: # -------------- 20200520-195835 -------------- 2020-05-20 19:58:35.015 INFO EDCORE: DCS/2.5.6.49314 (x86_64; Windows NT 10.0.18362) 2020-05-20 19:58:35.016 INFO EDCORE: M:\steamm\steamapps\common\DCSWorld\bin\Flight.dll 2020-05-20 19:58:35.016 INFO EDCORE: # C0000005 ACCESS_VIOLATION at D64AB077 00:00000000

[WIP] Came across a bug with the Type 052C destroyer: after taking heavy damage, it loses the collision model, so no weapons hit it and aircraft can clip right through it.

I can confirm this, turning off the dispenser makes things run as normal, while having it on results in a slowdown.

As of Open Beta 2.5.6, destroying a search light at night when the search light is on will cause a game crash.

Confirmed, same happens here as of 2319UTC. Worked approximately 2 hours prior.