NeedzWD40

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.

7./JG 4, January 1945. Not 100% accurate as it's based on a Fw-190A-9 scheme and at that it's not a 1 to 1 representation. Dropbox Link

Hi, AI SARH missiles are able to keep tracking a target even if the firing aircraft has broken lock or has been destroyed. Super 530 and R-27 are affected, probably others, but AIM-7 is not. This can be repeated by setting a head-on engagement with an AI aircraft loaded with a SARH missile other than AIM-7, waiting until it fires, and destroying the launching aircraft with a F10 command or other mechanism. Watch the missile in F6 view and maneuver away from it; it will still track despite no guidance information. The vertical axis seems to be the most sensitive and you can see the missile pulling extreme angles to maintain track. AI_SARH_MISSILE.trk AI_SARH_MISSILE2.trk

Sorry, only seems to work on the Persian Gulf in an air start.

I turned on easy communications and that's what fixed my refueling problem.

My understanding is that until the seeker is set to active and acquires a target, they rely upon the launching aircraft's data track for guidance. Thus the reason for the countdown timers with the F/A-18C and F-15C aircraft til missile goes active, or pitbull. If the firing aircraft breaks lock, no more data is sent to the missile and it properly follows the last instructed course (and may or may not begin an active search pattern, but that is beyond my knowledge of the current missile systems). However, the problem is that they know instantly where the previously designated target currently is once they reach their active timer. It's easiest to test with the F/A-18C as it lacks TWS; in the AIM-120 demo mission, you can lock, shoot, break lock, and shoot until your missiles are expended and they will more often than not hit their targets (if launched with enough energy).