Search the Community

Issue Information ⦁ Issue ID #000025 ⦁ Issue Type Issue ⦁ Severity 0 – None Assigned ⦁ Status 21 - Fix Coded ⦁ Version 2009.082 ⦁ Fixed in 2009.083 Visual detection by deep subPosted by Grumble on 30 June 2013 - 02:29 AM : To Go 13:07:38:30 New contact: ZYS Slava: Slava from AHU Birmingham at a bearing of 250 degrees and a range of 39 nm Method: VISUAL Probably related to the fix in 082 Tony pointed out as: - Chg:B176 GE A platform with sonar of type active only could not detect anything. This has been fixed but the fix impacts all types of detections so thorough testing would be good. This is a larger problem as well affecting all detections. The code uses unit->emit (unit has this sensor type) and unit->detect (unit can be detected by this sensor type) inconsistently. The issue is reproducible with the HDS2 5.0 save game file attached, at To Go 13:07:38:30 AH000 SSN Birmingham (deep) detects ZY005 CG Slava. The detection is consistent with 082, does not occur with 076. Issue-025-Visual-detection-by-deep-sub.pdf deepvisual.zip VisualSonar.zip

Issue Information ⦁ Issue ID #000019 ⦁ Issue Type Issue ⦁ Severity 0 – None Assigned ⦁ Status 12 – Working as Intended ⦁ Version 2009.076 ⦁ Fixed in 2009.076 Standoff jamming does not modify missile PhPosted by Grumble on 21 May 2013 - 04:12 PM I was thinking whether to post this as a question for the General or open an Issue. Common sense says that escort and standoff jamming both should influence radar guided missile hit probability, I finally decided "Issue" after I found this post of Tony http://harpgamer.com...e-notes/?p=6008 Test scenario is in HDS1. Two flight of bombers are loitering just NE of Kinloss. ZXA 4 x Tu-16 Bmbr + 1 x Tu-16 J EW ZYA 4 x Tu-16 Bmbr The two groups are on top of each other, ZXA at High, ZYA at Medium 4 F-14s are ready to assist with the test just 3nm S of them. (savegame: EW) Firing 4 x AIM120 at ZXA000 (the escorted Badgers) yields PH 45 101455 combat3.c:1477 - AirToAirResolution Ph: 45, Roll: 38 101455 combat3.c:1477 - AirToAirResolution Ph: 45, Roll: 98 101455 combat3.c:1477 - AirToAirResolution Ph: 45, Roll: 89 101455 combat3.c:1477 - AirToAirResolution Ph: 45, Roll: 29 101455 effect4.c:5176 - CheckAirMissileHits 4 x AIM-120 AMRAAM against RED 4 x Tu-16 Badger G, 2 hits As far as I can tell that is 40 DPh for AMRAAM + 30 - 20 for escort Tu-16 ECM - 5 for Tu-16 Bmbr DATA Firing 4 x AIM120 at ZYA000 (the "standoffed" Badgers) yields PH 65 101462 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 27 101462 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 3 101462 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 57 101462 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 58 101462 effect4.c:5176 - CheckAirMissileHits 4 x AIM-120 AMRAAM against RED 4 x Tu-16 Badger G, 4 hits E.g. no standoff jamming bonus of -20 PH for the Badgers Just to crosscheck kill of the EW bird, with AIM9 of course, confirms nicely that IR AAM is unaffected by EW and attack again remainder of ZXA, now without EW escort gives same PH 65 101529 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 0 101529 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 35 101529 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 39 101529 combat3.c:1477 - AirToAirResolution Ph: 65, Roll: 20 101529 effect4.c:5176 - CheckAirMissileHits 4 x AIM-120 AMRAAM against RED 4 x Tu-16 Badger G, 4 hits I expected and posts suggest too that ZYA should have also received the PH bonus against AAMs. Issue-019-Standoff-jamming-does-not-modify-missile-Ph.pdf EW.zip

Issue Information ⦁ Issue ID #000030 ⦁ Issue Type Issue ⦁ Severity 0 – None Assigned ⦁ Status 12 – Working as Intended ⦁ Version 2009.083 ⦁ Fixed in Radar LOS calculation errorPosted by Grumble on 21 July 2013 - 01:33 PM Radar LOS is not calculated correctly, radars detect targets over the horizon and LOS. Most recently I observed this in HDS3 9.0, I hoped to be able to "sneak out" my Tel Aviv Hawkeye from under the Damascus SAM umbrella by pairing it with a ground attack a/c. (Otherwise the Hawkeye is spawned at high altitude immediately at take off, which I guess is a compromise for AEW, but a painful one.) The trick works, the Hawkeye-Skyhawk twosome starts at low but Damascus is still detecting them and launches SAMs. The test scenario demonstrates this by launching the pair from Nevatim, load the scenarios as RED, Damascus immediately detects the E-2C at 149nm, well beyond true LOS. The -l radar log confirms the wrong LOS. 100001 search.c:881 - Radar Emitter=Damascus Target=E-2C Hawkeye, TargetRange=149, Radar LOS = (BaseLOS x weather_mod + 128)/256 100001 search.c:882 - Radar LOS of 246nm = (246nm x 256 + 128)/256 --> Radar LOS=60644/256 100001 search.c:888 - A RCS=164 TName=E-2C Hawkeye AName=Damascus Range=149 Die=37 aPD=70 100001 search.c:961 - B RCS=164 ARng=300 Arng=300 SRng=60 Srng=60 100001 search.c:1020 - Detected E-2C Hawkeye with Air Radar of range 300 with PD 70, Roll=37 100001 search.c:1040 - Type and Height of target known Tested with 2009.050,076 and 083, I have not yet installed 086 but I guess the radar model was not changed. Issue-030-Radar-LOS-calculation-error.pdf LOS.zip LOS 1.zip

Issue Information ⦁ Issue ID #000076 ⦁ Issue Type Issue ⦁ Severity 0 – None Assigned ⦁ Status 12 – Working as Intended ⦁ Version 2014.020 ⦁ Fixed in 2014.020 Mk1 Eagle Eye - 50nm visual detection?Posted by Grumble on 13 July 2014 - 05:28 AM Background: Playing EC2003 Bear Baiting user scenario, red AI is consuming my Rafales fast. The F2 and F3 versions have only the 27nm Mica AAM vs. +40nm Alamos and Adders, but theoretically this should be manageable with the help of the Rafale's low RCS, the Su-27S 65nm radar detects it at max 12nm and even the Su-27SM's 135nm radar has max 25nm range on it (don't mess with the Su-35 though ). But in practice the Sukhois either pre-launch me or immediately return fire even if I use IR Mica from the rear, e.g. they have already fix on me when I approach. How? I turncoated my iterated save files to witness the detection event myself and it was that red Fighters on low altitude detect blue, high Rafales as they come closer than 50nm, even if the Rafale approaches outside of the front 60o arc. This is both for military and cruise throttle (I avoided AB). Is this working as intended? 50nm visual detection on a Rafale feels extreme. Attached save file, it is turncoated to Blue AI, Red Human. DQA is attacking ZJA on medium. Set DQA to high and ZJA will visually detect DQA come the next cycle. Issue-076-Mk1-Eagle-Eye-50nm-visual-detection.pdf bda.zip

Issue Information Issue ID #000024 Issue Type Issue Severity 0 – None Assigned Status 91 – Duplicate Version 2009.076 Fixed in Dead fish in the water - Red subs do not navigatePosted by Grumble on 16 June 2013 - 09:33 AM Playing HDS2 3.0, Convoy Ho!, red submarines were painfully hard to detect, yet they were themselves very passive. I checked what are they up to with Show All. Looks like there is a some problem, either with the scenario or with the AI navigation, SE shows red groups would need to do creep speed on their patrol routes, except perhaps ZKU, starting from further North at 25kts, but ZKU would also slow down to 5kts after reaching the expected path of the convoys. Red group routes at the start, Show All, playing Blue. The Red subs stop navigating after just a few miles, they either stop completely or do roundabouts on the spot at 5kts speed. Red group routes at the end of the game, 10 days gametime has passed, showing they did go nowhere. I tripped over ZJU V3023 at the end of the game, taking a closer look, it is laying in place, going nowhere, speed at 5kts, it's course alternates between 77 and 249 degrees and sometime it also does instantaneous depth changes between deep and shallow. It can not move, even after Show All, clearing it's path and plotting a new one, it does not obey move orders. While laying in wait could be a good ASW tactics it's not what the AI was scripted to do here. I only attached an end game save, the issue is very easy to reproduce, restarting the scenario playing blue, red subs behave the same way every time. ++ Just checked HSD2 4.0, same symptoms. ++ HDS2 5.0 too. Issue-024-Dead-fish-in-the-water-Red-subs-do-not-navigate.pdf CrazyIvan.zip HDS2-3.zip hds230stop (1).zip hds230stop.zip hds250stop.zip SUB.zip

Issue Information Issue ID #000058 Issue Type Suggestion Severity 0 – None Assigned Status 30 – Feature Request Version 2009.097 Fixed in GE - Enable player to set initial formation of surface groupsPosted by Grumble on 05 October 2013 - 06:59 AM Allow the player to rearrange formation of surface (&submarine) groups at the start of the scenario, as if in SE. I start most scenarios by rearranging formations of my surface groups. For 2 to 6 hours my ships are just transiting to stations I prefer. During this time my groups are not battle ready as would want them to be. Ships also either transit at flank speed, not good if enemy subs are around, or I have to stop the group completely to make them creep to stations. This is dead time, I could be playing instead. This would be no cheat either. In real life the commander does not pick up command in the middle of Atlantic, his ships are in formation the way he likes them ever since leaving Norfolk. Perhaps there are some scenarios where initial formation is significant for the play, so ideally this would be a feature the scen author can toggle on or off in SE. Issue-058-GE-Enable-player-to-set-initial-formation-of-surface-groups.pdf

Issue Information Issue ID #000074 Issue Type Issue Severity 1 – Low Status 30 – Feature Request Version 2014.010 Fixed in User scenarios loosing orders txt files through save/loadPosted by Grumble on 25 May 2014 - 11:02 PM A cosmetic one, GE looses track of the Red/Blue side orders txt files of User scenarios when the scenario is loaded from a save game. OK: When the User scenario is started anew from the scenario file, the orders are correctly loaded from <scenarioname>.BLx/RDx files ISSUE: When a save game of the User scenario is loaded, GE searches for the orders files under <savegame>.BLx/RDx. Repro: Load mod HDSC10 user scen check Show Orders are ok, from HDSC10.BLH save save.hph then load it Show Orders: No orders found for this User Scenario USER SCENARIO ORDERS Could not find the orders text file: C:\Program Files\Matrix Games\Save\HDSC\10\save.BLh Issue-074-User-scenarios-loosing-orders-txt-files-through-save-load.pdf HDSC10.zip

Issue Information Issue ID #000039 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2009.087 Fixed in 2009.089 TCS half detectionPosted by Grumble on 10 August 2013 - 06:27 AM TCS detection is reported but the detected contact is not displayed, neither as exact fix nor as uncertainty region. In the attached savegame (HDS5 3.0) F-14 BKA detects group ZDA via TCS at 1:22:52:28 (to go, within 2 seconds of the save, PD roll allowing), pressing the Show button on the contact report popup points out the location of the contact (via the flashing radial spikes linking nearby groups to the point) but ZDA is not displayed. It is also not listed in the Attack list of any of the blue groups within AAM range. ZDA is only displayed after it is detected also via other means, visual or radar. Two savefiles attached, one from 2 secs before detections, the other is 30 seconds earlier to allow for sensor change tests. Issue-039-TCS-half-detection.pdf nowyouseeme.zip

Issue Information Issue ID #000035 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2009.087 Fixed in 2009.089 Drop sonubuoy key activates hull sonarsPosted by Grumble on 01 August 2013 - 03:29 AM The drop sonubuoy key activates hull sonars of ships and submarines also. Expected: drop sonubuoy should drop buoys and activate dipping sonars only. Player might accidentally use the key for the wrong group or might want to activate dipping sonars of a/c formation patrols of a mixed group / CVBG. This will erroneously also activate hull sonars of ships and submarines, revealing their locations to enemy sonars. Load savegame passive.hp9, press the key for CVBG AAC, hull sonars of the Tico and Spruances are also activated. See drop.hp9. Note, the Leahy and Belknap stays passive, it seems that only units also with Towed Array sonar are affected. See towed.hp1, the Type 22/2 and 22/3 of AFC have gone active, the Invincible and the Type 42s stayed passive. Issue-035-Drop-sonubuoy-key-activates-hull-sonars.pdf drop.zip

Issue Information Issue ID #000070 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2014.005 Fixed in 2014.006 Phoenix bug rising from the ashesPosted by Grumble on 03 May 2014 - 07:39 AM Fixed issue #33 seems to have returned with versions 2014.00x, Phoenix AAM veers off intercept course in terminal phase. (attached mc1.zip) Phoenixes from ABA score OK on ZYA/ZWA Il-76 AEW with v2009.102 but with 2014.00x they go off course near to the target. Black path: 2009.102, red path: 2014.003 Issue-070-Phoenix-bug-rising-from-the-ashes.pdf mc1.zip

Issue Information Issue ID #000018 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2009.076 Fixed in 2014.006 Phoenix AAM intercept course calculation errorPosted by Grumble on 18 May 2013 - 12:20 PM AIM-54C "overreacts" 180 degree turn of it's target and turns toward extremely distant interception point. This is playing HDS1 5.0. Su-24 Fencers (plane group UFA) are attacking Keflavik, F-14s launched 2 Phoenixes (GBM) on them and F-15s (FHA) also attack with AMRAAMs. After the AMRAAMs shoot down a Fencer the remaining Sukhois turn to attack the F-15s. The Phoenixes are already well underway during this. (savegame: crazyphoenix1) When UFA is in range of FHA's Sidewinders launch two at them. The (stub of the?) evasion routine kicks in (?) and UFA briefly turns to 166 degree then back again to 345 towards FHA. GBM first turns to the correct 84 degree course for a second and then to 177 degree! (savegame: crazyphoenix2) Issue-018-Phoenix-AAM-intercept-course-calculation-error.pdf crazyphoenix.zip

Issue Information Issue ID #000033 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2009.083 Fixed in 2009.094 Long range AA missile intercept geometryPosted by Grumble on 26 July 2013 - 11:59 AM Long range anti air missiles occasionally follow very strange and unrealistic intercept paths. Looks almost as if they were flying to a precalculated intercept point and then turn towards the target, which could be normal for long range AA but this behaviour is not consistent (usually the missiles are tracking their targets all the way, see Gammon example) and the intercept points also seem wrong, like too far away, often beyond the target. The targets are often loitering, the problem could be linked to the loitering-at-cruise-speed issue. I could not yet recreate this with a test scenario (tried but missiles work ok in the small test scenarios) but here are 3 examples with battleset scenarios. Phoenixgeom: Group AIA launches Phonixes at group ZNA, missile group ALM flies strange zig-zag course to ZNA, distinctly changing course two times. Phoneixgeom2: Group AIA launches Phonixes at group ZNA, ZNA loiters on high but with 590kts speed (e.g. it's cruise speed) when AIA launches ZNA changes it's course to 48 degree from 209 degree, missile group ALM flies *over* and passes ZNA, then turns back to it. (The missiles' intercept point looks like it could be the point where ZNA could have been if it had been really cruising.) Gammongeom2: Missile group ZLM is attacking AHA, flies to a point where AHA was a minute earlier, then turns to track AHA. Gammongeom1.hp8 is a savegame from 1 minute earlier, before AHA reached it original patrol destination and started to loiter, however I can not recreate the situation recorded in Gammongeom2.hp8. Still the issue can be consistently observed in Gammongeom2. Issue-033-Long-range-AA-missile-intercept-geometry.pdf AAgeom.zip Phoenixgeom.zip

Issue Information Issue ID #000071 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2014.006 Fixed in 2014.007 Phoenix edge case number 4 (4?)Posted by Grumble on 17 May 2014 - 11:35 AM One more edge case, 2014.006. 02.hph: launch aams at ZYR 03.hph: aams few miles from ZYR 04.hph: aams passed ZYR Here too, 2009.102 is ok, phoenixes hit as expected. Issue-071-Phoenix-edge-case-number-4-(4_).pdf edge4.zip

Issue Information Issue ID #000064 Issue Type Issue Severity 1 – Low Status 23 – Fix Accepted By Reporter Version 2009.102 Fixed in 2014.008 Ferry 0Posted by Grumble on 26 October 2013 - 02:09 PM Ferry mission to carrier groups targets the lowest numbered (00?) surface unit of the group, even what that unit is not a carrier. Aircrafts end up embarked on a destroyer. When aircrafts are ordered manually to land on the same group the carrier is selected correctly. Check: Launch an F18 on ferry from Ras Karma to ACC, Full Report of the Hornet shows home base DDG 75. F6 to Ras Karma, then F6 to ACC (need F6 Ras Karma first, F6 to current home group does not reset home base) and full rep. shows home base Eisenhower. Issue-064-Ferry-0.pdf ferry00.zip

Issue Information Issue ID #000078 Issue Type Issue Severity 0 – None Assigned Status 23 – Fix Accepted By Reporter Version 2014.010 Fixed in 2015.014 Mk3 Eagle Eye - AI intercepts undetected PGMsPosted by Grumble on 15 July 2014 - 02:50 AM After the Mk2 fiasco with the GBUs I tried the Hammer AASM, it has Medium max altitude, so should not be affected by the contrails visual detection, still, the Udaloy and Sovremenny pickets are engaging it with SAM. (057b.hpm, drop PGMs, bearing only, on both ships) I switched to red (058red.hpm) to check how does the detection occur, only it does not, at least SA does not report any detection, but the ships are launching SAMs at unseen, incoming missiles. (I believe the turncoat save file hack does not mess up the SA notifications, but even if it does SAMs are fired without visible targets.) Issue-078-Mk3-Eagle-Eye-AI-intercepts-undetected-PGMs.pdf 057b.zip

Issue Information Issue ID #000038 Issue Type Suggestion Severity 0 – None Assigned Status UNFILED Version 2009.086 Fixed in Group report popup window niceitiesPosted by Grumble on 09 August 2013 - 07:16 AM A light course for connoisseurs, for long, boring winter evenings when there is just nothing to do . The information presented in the Group report popup ('F' key after selecting a group) is somewhat ambiguous and incomplete for multiple carriers. (I know, I know, but look, I did file this as a 'suggestion' ) Only the first carrier's name is displayed on the "Carrier Name:" line Total Aircraft number counts a/c-s both on deck or on formation patrol, includes both fixed wing and helos and counts all carriers and ships (helos). per a/c type-per ready status-table only accounts for the a/c-s on the deck of the first carrier in the group Total A/C info below the table counts only on deck aircraft Suggestion is to present the information consistently and/or use longer, more descriptive text labels: Carrier Name -> Carrier(s) and list all carriers space allowing Total Aircraft, this is ok as is. Perhaps an idea is to present on deck and patrolling a/c-s separately as 174+12. And if formation patrols are included it would be nice to see long range patrols and intercept mission a/c-s too, 174+12+6. Account for all carriers in the table, also say that this is for carriers only (excludes ships with helos). the bottom totals are ok as is, only say somewhere that this is the on-deck count. The example and savegame is from HDS5 2.0, where AAC sails North with two carriers. I wanted to check whether I can afford to send 4 Tomcats for all 3 long range CAPs and at the group info to quickly tell me how many fighters (=Tomcats) are there in AAC. The numbers did not add up so I started digging. Issue-38-Group-report-popup-window-niceities.pdf Current Status Menu HDS9-10.zip fullinfo.zip

Issue Information Issue ID #000041 Issue Type Suggestion Severity 0 – None Assigned Status UNFILED Version 2009.082 Fixed in Suggestion: log SAM firing arc limitationPosted by Grumble on 21 August 2013 - 12:14 PM In short: We have missile (SAM?) arc limitation enforced from 2009.082, but unlike guns this happens silently for missiles. This often left me dumbfounded, why doesn't my Belknap engage that bogey?? And I actually read the release notes and celebrated the new GE arcs with Enrique , so I feel the new feature could turn frustrating for the average player unless it is made more visible. The suggestion is to have the missile arc enforcements logged similarly as it happens for guns: - Chg:0000 GE Message Log window will show when standard gunnery engagements are abandoned due to: target submerging, target going out of range, and target going out of valid arc. (ported from 2010.003) This would enhance the consumer value of this feature with a comparably easy fix, short term. Longer: If I'm allowed to branch off, dig deeper and think in longer terms then the enforcement of valid arcs is one example where the game uses different (and somewhat inconsistent) levels of abstraction for modelling closely related real world phenomenas. The point I'm getting at is that models for closely related physical events should (preferably) use consistent levels of abstraction or the GE need to put other controls in place to keep the simulation balanced (and some of these controls might not be related to real world limitations). Here with the arcs:The firing arcs are now modeled almost true to life, down to the last minute detail.but other heading/course/aspect related models are currently much more abstract Ship turning rates are not enforced, heading changes are instantaneous . RCS does not depend on target aspect ECCM is "assumed", yet this probably also depends on the arcs. Ship AI does not manage arcs, ship units will not maneuver for valid arcs, this only works through player intervention (micro management). missile hit probabilities account for some aspect related effects too (I think) so this is an interference Director arcs are not enforced, once a missile is airborne the ship can turn any direction. etc. All I want to say is that until these other, related events can also be modeled on a similar level of physical accuracy as the firing arcs I would not shy away from using "inventive" game rules for arc limitations to have a balanced arc "effect". For example: VLS mounts do not suffer arc limitation (same as now) mounts with arc limitation can still fire in any direction if the speed of the group containing the unit is creep or less. arc limitation is enforced even at creep speed if the unit is engaged from two or more directions simultaneously Rule 2 is an abstraction saying that if the group is slowing down then the individual captains can maneuver their ships for optimal position, heading or aspect to take on the threat. This rule also helps AI vs. player balance, as it is relatively easy to teach the AI to drop to creep speed in case of an arc limitation while to have the AI actually maneuver individual ships would be quite a challenge (I guess, hope Tony proves me wrong ), though a human player is capable of doing this through micro management. Rather than encouraging micro management the SA would prompt the player too for permission to slow down to creep speed to allow maneuvering for valid arcs. The same time Rule 2 would also present the player an option to slow down enemy surface groups for his submarines to intercept. He just need to engage them with ASMs from the right aspect (assuming there are arc limitations possible to exploit). Rule 3 would keep players on their toes. Encourage them to plan ASuW attacks considering the arcs to reap the benefits. Issue-41-Suggestion_-log-SAM-firing-arc-limitation.pdf

Issue Information Issue ID #000047 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.094 Fixed in Kirov goes for a walk (AI)Posted by Grumble on 15 September 2013 - 02:50 PM (Btw. there is no 2009.095 version yet in the Issue Tracker.) I'm playing HDS7 8.0 Cauldron with "Ignore ships running aground" (accidentally) but I don't think this is a reason for the AI surface groups to take a walk across the Crimean. The Kirov group I'm sure have a scenario plotted course going to Odessa, to my Slava group, yet it has just came ashore near Donuslav Lake and heading East-North-East. Could be trying to intercept my AGS group, which is irrelevant for the scenario. It seems strange that the AI deviates from the plotted course this much and this silly. Perhaps the attached save games can help to find out what is it doing. Issue-47-Kirov-goes-for-a-walk-(AI).pdf ITER_SAVE_GAMETIME.zip

Issue Information Issue ID #000049 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.094 Fixed in Fox ThreePosted by Grumble on 20 September 2013 - 01:41 PM Looks like an other air intercept geometry error, this time it's for planes. It happens when a fighter is depleting it's long range AAM store and the intercept point is recalculated for the remaining short range AAMs. Load fox3.hpc (attached) Attack XFA with CFA's last two AMRAAMs ("Fox Three!") in a few seconds the GE recalculates CFA's course but it actually turns away from XFA, to 109o and 10nm long. See fox2.hpc. Hope this does not just happens for me, screenshot: Issue-49-Fox-Three.pdf fox3.zip

Issue Information Issue ID #000046 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.094 Fixed in Beyond bingo AI interceptsPosted by Grumble on 14 September 2013 - 01:24 PM AI is scrambling (but aggressively , finally we can say this ) a/c-s to targets well over the interceptor's range. Actually I would prefer AI to calculate even with wider than before margin, i.e. to only scramble for targets well within range, the interceptor should have enough combat fuel left when reaching the target (or a handy tanker up his sleeves). Hmm, now that I think about this ... this might be more complex than I thought, preferably AI would need to react differently to loitering and closing contacts, also uncertain contacts are different ball game. Here is HDS7 5.0, AI is scrambling <500nm mission radius Mig23s to 650-700nm targets, unless these Floggers are solar powered they will not make it. And it keeps sending them turn after turn. I checked turncoated bda-red.hpc for red groups target id and contact info. It had exact fix on my planes through the now extinct ZSS and ZRS groups, so it knew their range. It's craving should be curbed. Issue-46-Beyond-bingo-AI-intercepts.pdf bda.zip bingo.zip

Issue Information Issue ID #000051 Issue Type Suggestion Severity 0 – None Assigned Status UNFILED Version 2009.094 Fixed in 8 missiles 9 hitsPosted by Grumble on 21 September 2013 - 08:21 AM This is more of question. Occasionally I've seen that missiles in AA engagement get bonus pK rolls, sometimes. I thought this is a bug. Yesterday I came across a save which produced this consistently. A rule?? It seems like if a missile group is attacking an air group with N units then each missile above 2N gets two pK rolls E.g. load attached save file, if CVA attacks WUA 2 x Mig-23 with 4 missiles > 4 pK rolls 5 missiles > 6 pK rolls 6 missiles > 8 pK rolls etc. This is how you get 9 hits with 8 missiles: 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 81 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 27 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 38 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 57 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 14 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 54 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 80 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 76 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 26 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 37 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 48 107161 combat3.c:1519 - AirToAirResolution Ph: 60, Roll: 58 107161 effect4.c:5226 - CheckAirMissileHits 8 x AIM-9R Sidewinder against RED 2 x MiG-23ML Flogger G, 9 hits Looks like a rule with a history . Care to tell? Is this from the Paper rules? It would be more natural to give a probability bonus than rolls, but it's a safe way to double pK indeed. And why after 2N and not from 2N? Is it saying that pilots have an ok chance to evade 1 or 2 missiles but have trouble evading 3? I hoped that this bonus is triggered for WUA because CVA attacks them from the blind, but no, the bonus is granted for head on attacks too. Are you aware of any other hidden gems of air to air engagements? Issue-51-8-missiles-9-hits.pdf 9of8.zip

Issue Information Issue ID #000052 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2009.094 Fixed in Closing to next AAM rangePosted by Grumble on 21 September 2013 - 01:29 PM Closing to next AAM range would be a wonderful feature, (See how happy I was when I stumbled into it: Tony's revamped Game Engine #25) turns out it's in the GE, but it does not work consistently, could say as illusive as Bigfoot. (But I've seen it I swear! ) It happened just after I saved the attached file: I press [F1] Attack for DRA Target list pops up with TRA preselected and a soon as I accept TRA pressing OK, before or simultaneously to the Weapon Selection popup opening (turns out TRA is within Sparrow range despite it being displayed outside of the range ring, so I get the popup) the message "Closing to next AAM range" is displayed in the log window and a course is plotted for DRA for a Python range intercept the Weapon selection popup is still open at this time So it happened two times for me in quick succession but now I can't reproduce even with this lucky 1 second save file. Pretty please, make this work! Issue-52-Closing-to-next-AAM-range.pdf nextaamrange.zip nextaamrange2.zip

Issue Information Issue ID #000040 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2009.086 Fixed in 2009.090 Tame AIPosted by Grumble on 13 August 2013 - 02:12 AM Tony, I know it is a known issue that the AI becomes less aggressive or less agile towards the end of scenarios, i.e. as time passes by. I think it was Brad confirming it to someone in a post. Is this bug a lost cause? Like it has been IDed but would require complete redesign of the AI to correct it? Please let me know if I'm wasting my time reporting on it! But I hope the fat lady has not sung yet, here are a few observations from my latest run in with the tame AI. This is HDS5 5.0 The Anglo-European War, so a comparatively small scenario. AI is red, playing EU/French side. BTW. it is French CV CDG vs. 2 x UK Invincible At the beginning the AI is alright. It has attacked and sunk several of my ships with standoff weapons, both with ASMs from Rafales and Exocets from Super Etandards. Little later an example for when AI is loosing planes to the RTB mission too easy. The AI would be more potent if it could reassign the RTB planes, ordnance and fuel allowing. (savegame 05.0012.hpa) AI has sent 2 x 2 Rafale, ZNA and ZMA to intercept Tornado F.3s ANA and AVA ZNA shoots down 1 x F.3 of ANA the other flees on full afterburner ZNA then turns home (must be because the Enemy is going too fast) Nastily (bad Grumble!) I turn ANA back and send it chasing ZNA again as it has fuel plenty. (This is when the savegame is from.) Eventually ANA shoots down 1 Rafale and the E-2C of CDG, while ZNA and ZMA are happily RTB with 90% of fuel and almost full load of AAMs. Pity. There are also 8 Standoff Rafale on CDG with 4 AAMs each, AI could scramble those too, though this would be really advanced thinking. Once the AI's AEW patrol has been shoot down it never sends up the other E-2C on board of the CDG. Around this time the AI is still ok, it even sends pair of the remaining air to air Rafales after my E-2C from Benbecula. (savegame 07.hpa) break off: But the Tornado F.3 CAP is able to sneak up on them from behind and splash them with Sidewinders. If the AI is ever going to be revamped, it must be taught the risks of sending solo flights into full enemy radar cover. A player has even described on the forums his 'tactics" of sending up an AEW bait plane and then the AI is sending all his fighters after the AEW one by one which are easy kill. Rather have the AI mission cost/benefit analysis consider radar coverage of the flight path. Decision = + value(target)*success_probabilty - value(self)*fail_probability - enemy_sensorcover(filghtpath) + friendly_sensorcover(flightpath) - enemy_AAthreat(flightpath) + fuelremaining ... After a day of game time though the AI is more of a pacifist. CDG meets with the Ark Royal, (savegame: 12.hpa) the AEW Sea King detects the French CV group, the AI probably only detects the AEW plane (it's a long range patrol, not formation and the Ark Royal group is otherwise passive.) but the AI does not even attempt to intercept the Sea King. Surprisingly, there is now a pair of LR Air to Air Super Etendard (mistyped as Etentard in HDS5) on CDG, so there are actually planes available with air to air loadout. (!!) The AI does show some initiative, there is no AtA Super Etendard scripted in the mission! Still no intercept mission was started. The AI passively suffers my hoarding missiles on it and when Georges Leyuges is sunk the AI group completely stops. I checked it's airwing with Show-All, there are still 9 Rafales there with Standoff loadout and Super Etendards, two of which is LR AtA. To rekindle life into the AI I manually ready 5 Rafales to AtA loadout. (savegame 12.0046.hpa) Nothing. No AI intercept mission against my a/c-s. Then I manually launch two Rafales to attack my Sea Harrier CAP then switch off Show All to see how would it look like. This way I actually manage to coerce the AI to shoot down one of my Harriers. (savegame 12.0054) Surprising development, the Rafales I cheat-launched has the multimode RDX radar (SS too) and they detect my ships while chasing the Harrires (SA prompted me to turn radars on as planes might detect us.) This seems to kick the AI in gear CDG's group starts to move again and the AI readies all it's available helos (Lynxes and Alouettes for Guided loadout and sends them to attack the Ark Royal! (savegame 12.0056) It ignores the remaining 4 x Standoff Rafales on board, ready 5 and the Standoff Etendards, on board, ready 5 and the 3 x Standoff Etendards already loitering above CDG as ASuW formation patrol Looks like that these planes are somehow lost for the AI, perhaps they are not joined properly back to the "available" a/c list of the AI after previous missions? Also, it is interesting that the AI readied an Etendard for AtA instead of the Rafales. Perhaps the Rafales were "lost" from the free list earlier than the Etendards? Let me know if any other other savegame from this scenario or other inestigation of specific situation can help to solve this bug! Issue-40-Tame-AI-Page1.pdf Issue-40-Tame-AI-Page2.pdf 12.0048-airafwork.zip bda.zip re05.zip TameAI.zip TameAI2.zip

Issue Information Issue ID #000060 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2009.097 Fixed in Turf monster eating AI planesPosted by Grumble on 18 October 2013 - 11:16 PM Occasionally there are unsolicited slander messages reporting that an "enemy a/c group have been shot down" when I'm completely innocent. HDS8 9.0 Demise of the 7th fleet seems to be rich in this, To Go 2:21:38:14 4 enemy MiG-29 Fulcrum of group (ZUb), have been shot down. To Go 2:21:08:39 4 enemy Jaguar Intl of group (ZZa), have been shot down. To Go 2:20:26:55 6 enemy Super Etentard of group (ZSR), have been shot down. To Go 2:20:19:02 4 enemy Jaguar Intl of group (ZWb), have been shot down. These are most likely AI planes running out of fuel, usually on formation patrol, ZSR is miffing a bit. Tony, is this a known issue or merits a closer look? Issue-60-Turf-monster-eating-AI-planes.pdf

Issue Information Issue ID #000062 Issue Type Issue Severity 1 - Low Status UNFILED Version 2009.102 Fixed in HDS8 Active Sparrow 7MPosted by Grumble on 26 October 2013 - 09:52 AM AIM-7M Sparrow missiles in HDS8 do not self destruct loosing illumination. The AA-9 Amos destructs as expected. asparrow.save: F-18C fired Sparrows on the Raptor but the AMRAAMs will get the Hornets first, Sparrows fly on. asparrowa.save: example Issue-62-HDS8-Active-Sparrow-7M.pdf asparrow.zip