Everything posted by IssueMigrator1
-
Formation Air Patrols deficient behaviour
Issue Information Issue ID #000178 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.002 Fixed in Formation Air Patrols deficient behaviourPosted by broncepulido on 16 February 2017 - 10:52 AM This is a behaviour present from some itinerations ago, but not sure how to reproduce it, as sometimes is present, and others not. Playing the Reagan against China scenario I did observe it clearly at last. Playing Red/China, in the first minutes I shoot down the 3xF-15C3 Formation Patrols of Okinawa, 1xE-3G, and a few 3?xASW aircraft. The spected behaviour should be the Blue/US AI-controlled side to form new patrols, but as in the attached file saved game, using the cheat mode, no patrols are in the air, and a lot of fighters and ASW aircrafts in Okinawa (of course not 36xF-16C3 fighters, as some were previously shoot-down), and clearly the 2xE-3G remaining. But I think not ever that's is the outcome, sometimes the IA forms the patrols or the patrols only at the game start and a short while after, many times the second series of patrols and sucessive are not formed. Someone has detected similar behaviour? Issue-178-Formation-Air-Patrols-deficient-behaviour.pdf REAGAN AGAINST CHINA FORMATION PATROLS TEST.zip
-
From 61% to 0% Bingo Fuel in 1 Second
Issue Information Issue ID #000180 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 0000.000 Fixed in From 61% to 0% Bingo Fuel in 1 SecondPosted by eeustice on 25 February 2017 - 08:57 PM Launched tanker group with 30 KC-46A tankers and merged with air group FMA. At the start of refueling there us 61 % furl with air group FMA. As soon as time starter air group went to 0% fuel. Attached are a couple of screen shots, the GE game log., 2 saved games. One game second after Alt+R has been pressed. As soon as game starts Air group goes to 0% Bingo fuel. Second saved game is after FMA goes to 0% to Bingo. Also included is a copy of my Fictional db. I am going to try and recreate this in a much smaller scenario and post the files if I can get it to happen. Please let me know if you have any questions. Thanks, Eric Issue-180-From-61%-to-0%-Bingo-Fuel-in-1-Second.pdf From 61% to 0% Bingo Fuel in 1 second.zip
-
Impossible sonobuoy use tracking in Platform Editor
Issue Information Issue ID #000189 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 0000.000 Fixes in Impossible sonobuoy use tracking in Platform EditorPosted by broncepulido on 26 August 2017 - 12:43 AM A long time bug in Platform Editor (It's also possible I don't know clearly as use it). Is very difficult to track in what loadouts is carried a concrete type of sonobuoy, as the Platform Editor pops-up a blank subwindow without any results when interrogued about any sonobuoy type use. You only can track sonobuoy types use by loadout by memory or making a paper list or similar. Issue-189-Impossible-sonobuoy-use-tracking-in-Platform-Editor.pdf
-
Impossible sonobuoy use tracking in Platform Editor
Issue Information Issue ID #000190 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 0000.000 Fixed in Impossible sonobuoy use tracking in Platform EditorPosted by broncepulido on 26 August 2017 - 12:43 AM A long time bug in Platform Editor (It's also possible I don't know clearly as use it). Is very difficult to track in what loadouts is carried a concrete type of sonobuoy, as the Platform Editor pops-up a blank subwindow without any results when interrogued about any sonobuoy type use. You only can track sonobuoy types use by loadout by memory or making a paper list or similar. Issue-190-Impossible-sonobuoy-use-tracking-in-Platform-Editor.pdf
-
P-3B Orion at 3010 knots speed!
Issue Information Issue ID #000195 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.011 Fixed in P-3B Orion at 3010 knots speed!!!Posted by broncepulido on 08 October 2017 - 01:14 PM Playing with 2017.012 from a few days ago. Employing the GIUK 1991 WWIII scenario, because it's plenty of different platforms and situations (also, it's very amuse). Almost everything Ok, (only losing a few no NOE capable fighters when they're pulled to VLow in automatic interceptions, but I'm incapable to build a scenario capable to isolate this issue). Also, I fear in the previous scenario play, after restoring save game, I started to lose naval groups helicopters because low in fuel! But this is a new and stranger thing. Norwegian P-3B Orion of GKA group was ordered to intercept Submarine Group OOU (In the middle, near the North limit of the board almost in the Polar Circle). When the submarine was detected, GKA was almost over she. Later I saw it going North, and North, and North, and dissapear... Now, suddenly, group GKA is near Oslo, some 60 nm East of Oslo, near a Su-27P, and flying at 3010 knots!!!!! See attached file. Issue-195-P-3B-Orion-at-3010-knots-speed!!!.pdf P-3B GKA at 3010 knots.zip
-
Very Low Interception Problem
Issue Information Issue ID #000197 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in Very Low Interception ProblemPosted by broncepulido on 14 October 2017 - 06:14 PM After many, many attempts, at last I was capable to design a scenario were are generated (but only in one third of the played scenarios!) situations what force the interceptor fighters to go to Very Low after requested to increase speed to reach the enemy aircrafts. Are employed Mediterranean Battleset and HCDB2 170909. This phenomen is produced at least from Build 2017.007, I think. Play Blue/Ucrainian side with "Auto Patrols" on. Accelerating the time to 5 minutes compression, after a while the E-2C will detect a Su-24M2, and the Su-27 in flight West of Odessa will be requested to intercept. In many cases it will be requered to increase speed, click on "yes", and the Su-27 will go to high speed BUT very low altitude, producing crashes against the ground (at least on a third of the played scenarios). Load scenario in attached file. Issue-197-Very-Low-Interception-Problem.pdf VERY LOW INTERCEPT TEST.zip
-
Aircraft drifting out of Base Air Patrol Zones "cheese"
Issue Information Issue ID #000196 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.011 Fixed in Aircraft drifting out of Base Air Patrol Zones "cheese"Posted by broncepulido on 12 October 2017 - 11:11 AM Build 2017.011. Aircrafts in patrol in designated Base Air Patrol zones drifted greatly to another counterclockwise adjacent zone (in the Odessa concrete case, drifted above Sevastopol and are shoot-down by SA-10 SAM!). Apparently not observed in Air Patrol Zones in ship groups, only in bases. Found when building a scenario in the Black Sea. Attached file is a unrelated Test Scenario, but with identical results. It's 14xP-8A Poseidon in each Blue base to illustrate the problem. In the two Sicilian bases the problems are less observable, but clearly in the Odessa-based P-8, overflying Sevastopol, and coming shooted-down. Issue-196-Aircraft-drifting-out-of-Base-Air-Patrol-Zones _cheese_.pdf TEST AIR PATROL ZONES CHEESE 2017 OCT 12.zip
-
Main Body Convergence Problem
Issue Information Issue ID #000198 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 0000.000 Fixed in Main Body Convergence ProblemPosted by Nightshade111 on 18 October 2017 - 09:26 AM I'm having a problem with moving ships within the main body ring. If my ships are sailing on a course and I try to move 1 or more ships within the main body then those particular ships whose position I'm shifting (within the main body) all converge together at one point within the main body ring. The only solution I've found to make adjustments within that ring is to cancel the formation's course until the particular ships I'm moving take up their new positions, the obvious drawback being that afterwards I have to set my course all over again which as you can imagine is annoying. I'm using the latest updates, HC2017.011GESEDBDUBSBB and HC2017.013GESE on top of the fully updated Matrix version which is 2015.027. Issue-198-Main-Body-Convergence-Problem.pdf
-
New ship-based air patrols issue
Issue Information Issue ID #000199 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in New ship-based air patrols issuePosted by broncepulido on 25 October 2017 - 06:44 AM After observed some irregularities in ASW air patrols in the last iterations, I decided to built a test scenario. Randomly added 10xSH-60B and 10xSH-2F in USS Wasp, simple because I want to no think about how much helicopters to add (If casually fitted Wasp with less choppers probably I did not see this outcome). And surprise: - The first and last ASW patrols, 360º cover each, one with SH-60B and another with SH-2F, are the programmed by me. - Also are present another TEN no programmed air patrols between the first and last ASW patrols (See "Formation Editor"), with apparently no concrete pattern of pattern patrols!!!!! (i.e. each "phantom" patrol have a very peculiar shape whitout apparently relation with the other "phantom" patrols formed, a pattern of patrols could be "first patrol: first sector. second patrol: opposite sector", but I don't observe none pattern)(Also I suspect the apparently no concrete pattern of pattern patrols is ever the same in sucessive plays of the scenario, but too complex to affirm that now). See attached file: - Latest HCDB2, WestPac Battleset and 2017.13 SE and GE. Issue-199-New-ship-based-air-patrols-issue.pdf
-
AI controlled sub exceeding max depth
Issue Information Issue ID #000167 Issue Type Issue Severity 4 - High Status UNFILED Version 2017.013 Fixed in AI controlled sub exceeding max depthPosted by CV32 on 12 November 2016 - 12:39 PM Noticed AI controlled submarines exceeding their max depth, especially while evading attack. In attached savegame, observe Echo II SSGN going to Vdeep when max depth is Deep. Savegame is from Backyard I, Westpac. Issue-167-AI-controlled-sub-exceeding-max-depth.pdf redcrash.zip
-
Sub Group not Changing Depth Correctly
Issue Information Issue ID #000200 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in Sub Group not Changing Depth CorrectlyPosted by eeustice on 13 November 2017 - 07:57 PM Sub group AAU has 4 subs in group. Sub AAU001 ran aground. Set depth to a shallower depth. Only AAU000 changed depth. AAU001, 2 & 3 stayed at deep depth. Included in the Zip file is a test scenario, saved game file, latest commandb, screen shot of the sup group, GE and Msg logs. If you have any questions or need any additional info please let me know. Eric Issue-200-Sub-Group-not-Changing-Depth-Correctly.pdf Sub Group AAU Depth.zip
-
SE 2017.013 Crash
Issue Information Issue ID #000201 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in SE 2017.013 CrashPosted by eeustice on 18 November 2017 - 04:33 PM When trying to repeat an existing patrol the SE crashed. The steps that I use to create the crash are included in the zip file. The SE file, commandb, SE log and a word doc with the instructions are included in the zip file If you have any questions please let me know. Thanks Eric Issue-201-SE-2017.013-Crash.pdf SE Crash.zip
-
Red ship no course change after detecting enemy verified
Issue Information Issue ID #000203 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in Red ship no course change after detecting enemy verifiedPosted by broncepulido on 20 November 2017 - 03:07 PM I did observe many irregularities in the Syrian PTG boats in the A Passage to Lebanon scenario, apparently Syrian boats don't abandon their original courses even after detected enemy ships, but they increase speed to maximum, keeping their original courses, don't approaching enemy ships. At last in this second scenario I did get the pretended effect (And of course is no checked the "no change course" for red ships in the Miscelaneous AI Settings). After some 3-4 hours of gameplay, Blue ship is detected, and Red ship accelerates to 28 knots as in pursuit of Blue ship, but without course change! And now, Red ship is going south at 28 knots, just to running aground in the Egyptian coast! The game is of very difficult play now, in consequence. See new attached file. Late Standard HCDB2 and Middle East Battleset. Issue-203-Red-ship-no-course-change-after-detecting-enemy-verified.pdf TEST RED SHIP NO CHANGE COURSE 2011-11-21 SECOND ATTEMPT.zip
-
Red ship loses course
Issue Information Issue ID #000202 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.013 Fixed in Red ship loses coursePosted by broncepulido on 20 November 2017 - 02:48 PM I did observe many irregularities in the Syrian PTG boats in the A Passage to Lebanon scenario, apparently Syrian boats don't abandon their original courses even after detected enemy ships, but they increase speed to maximum, keeping their original courses, don't approaching enemy ships. Trying to isolate and reproduce the effect, and before the "experiment" is a success (In the current scenario Blue ship is not yet detected by Red ship, for verify if course is changed), I did observe another problem: As after 16 hours gameplay, Red Ships abandon her planned path and go right north to running aground in the south coast of Turkey! See attached file. Late Standard HCDB2 and Middle East Battleset. Issue-202-Red-ship-loses-course.pdf TEST RED SHIP NO CHANGE COURSE 2011-11-21.zip
-
AC Loitering Altitude
Issue Information Issue ID #000207 Issue Type Issue Severity 0 - None Assigned Status UNFILED Version 2017.016 Fixed in AC Loitering AltitudePosted by eeustice on 11 January 2018 - 05:32 PM When editing an Air Groups course AC would not loiter at end of course when AC stay at same altitude even though Loiter button was selected. To get the AC to loiter you need to go back into the Edit Order screen and select Set Altitude and Speed and then select Loiter. The AC will then loiter at the end of the new course. If you change altitude at the end of your course the AC will loiter at the new altitude without having to go bac and select loiter a 2nd time. Attached is a test scenario set to loiter at the end of a new course. Notice that loiter is not highlighted. I have also included the saved game and a copy of my db. If you have any questions please let me know. Eric Issue-207-AC-Loitering-Altitude.pdf AC Loitering Altitude.zip
-
Error downloading scenarios?
Issue Information Issue ID #000003 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 0000.000 Fixed in Error downloading scenarios?Posted by broncepulido on 06 December 2012 - 03:44 PM Trying to downloading some old scenarios, as the Battle of El Arish, I see it's not feasible, or I'm very dumb today: http://harpgamer.com...le-of-el-arish/ Issue-3-Error-downloading-scenarios_.pdf
-
Stopping Submarines problem
Issue Information Issue ID #000008 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.072 Fixed in Stopping Submarines problemPosted by broncepulido on 29 January 2013 - 04:22 PM I was thinking was bad scenario planification in "The Halibut scenario" and playing red the blue submarines are undetected but never find the "cable", but not, now also the blue submarines stopped after 20 minutes game time Issue-8-Stopping-Submarines-problem.pdf
-
GE allows launching AAMs on target without exact fix
Issue Information Issue ID #000017 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.076 Fixed in GE allows launching AAMs on target without exact fixPosted by Grumble on 09 May 2013 - 11:00 AM When a target is in range of an AAM the GE allows launch on target without exact fix. This is regardless of guidance type, so IR, SARH and Active Homing, etc., all affected. The attacking a/c (well, the attacking side) should have exact fix before allowed to launch, currently the "Should we attempt to locate ..." SA message is only triggered if the target is out of range of the AAM. Expected behavior: GE should always prompt attacker first to locate target if there is no exact fix on it. [ Hopefully the "Should we attempt to locate" case is coded for the AI side otherwise fixing this issue would make the AI less potent in defending itself. However currently the AI probably enjoys unfair advantage too, it was reported on the forum that Mig31s are launching long range AAMs on F-22s when those are too far away to have exact fix on the stealth a/c (unconfirmed). ] Sequence to reproduce: Load original GIUK user scenario nofix.sc1 Turn off Kinloss base radar and launch Tornado F3 patrol to Cape Wrath. (savegame nofixF3.hp1) Turn on Tornado radar when onsta to locate Tu-95 loitering North of Cape Wrath. The Tornado will loose fix on the Bear as it turns South while loitering (savegame nofixF3nofix.hp1) Order the Tornado to attack the Bear, GE allows launch of Skyflash and Sidewinders without exact fix. Restart or order the Tornado home and launch F-14s to patrol over the Norwegian sea, halfway to Faroe Islands. There is an uncertain Recon Bear contact over the Islands. (savegame nofixF14.hp1) Order the Tomcat to attack the Recon Bear when still more than 110nm away from the Islands. GE correctly prompts player to "Locate..." Send the Tomcat further North (savegame nofixF14inrange.hp1) Attack the Bear again, GE allows launch without exact fix if the Bear is in range of the Phoenixes. Attached the scenario and the savegames. Issue-17-GE-allows-launching-AAMs-on-target-without-exact-fix.pdf nofix.zip
-
Debug Assertion Failed Wespac Scenario Crash
Issue Information Issue ID #000016 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.076 Fixed in Debug Assertion Failed Wespac Scenario CrashPosted by eeustice on 06 May 2013 - 07:21 PM Edited Westpac scenario The Backyard crashed with a Debug Assertion Failed message just as a group of F-14 ran out of gas and crashed into the sea just before getting to their carrier. I have included in the zipped files the last 2 saved games the launcher saved. I also had a CV group AEC just vanish from the screen a while before that. If you wanted to land planes on the carrier you could see it in the Select Group for landing window however it NM went up to 5518 but the remaining fuel on the plane groups did not change and groups could still land on the CV's. However you could see the ships in the group if you placed the unit window over it location. I don't know if the 2 are related. I also included the saved game before and after AEC disappeared. It is the same db as in yesterdays issue but I have included it into the zip file too as well as a screen shot of the fault. If you need any additional info please let me know. Issue-16-Debug-Assertion-Failed-Wespac-Scenario-Crash.pdf wp4-2.0029.zip
-
HDS3 range circles off by 10%
Issue Information Issue ID #000029 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.084 Fixed in HDS3 range circles off by 10%Posted by Grumble on 16 July 2013 - 12:53 AM Range circles in HDS3 are displayed 10% shorter than the nominal value. This does not seem to effect the game mechanics, for example AAM attacks are made from the true possible distance, but the display shows that AAMs are fired when the target is still outside of the AAM range circle. First I spotted only the AAM discrepancy but click-measuring easily shows that all circles are off. E.g. clicking the opposite edges of Phoenix AAM range circle: 199-200nm (expected 2x110nm) F-14D AS radar: 326-330nm (expected 2x180nm) Kirov's SA-N-6: 89-90nm (expected 2x50nm) This can be tested in any HDS3 scenario but attached a simple user scen. and savefile with loitering F-14 and F-15. Should not forget, crosschecked with HDS1, there range circles are displayed true to size. Issue-29-HDS3-range-circles-off-by-10%.pdf HDS3circ.zip
-
SE Crashes if incorrect aircraft type is selected
Issue Information Issue ID #000034 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.085 Fixed in SE Crashes if incorrect aircraft type is selectedPosted by eeustice on 27 July 2013 - 05:58 PM SE crashed while trying to add helo's on TF ships in Battle Set HDS9. Problem occurred when an SH-60 Seahawk was attempted to be added to the USS Yorktown which is not on the list of Helo's that can be used on that type of ship. Suggest that when an incorrect aircraft type is accidently selected that the Add button is disabled. Same should happen if a Ship has no air craft capability. Several ship classes have a 0 aircraft capacity, but a list of aircraft appear. Example's: US AO Cimarron Class US LSD Whidbey Island Class US LSD Class Anchorage Class US LPD Raleigh Class US DDG Arleigh Burke Class US CG Leahy Class US LCC Blue Ridge Class US CGN Long Beach Class If you have any questions please let me know. Eric 34-SE-Crashes-if-incorrect-aircraft-type-is-selected.pdf HDS91039.zip
-
Loiter at cruise speed
Issue Information Issue ID #000032 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.083 Fixed in Loiter at cruise speedPosted by Grumble on 26 July 2013 - 10:41 AM Aircrafts loitering at med or high altitude change indicated speed to cruise speed after saving then loading the game or cancelling an attack order. E.g. when the a/c prompts to launch weapons but the player cancels it. (there are probably other situations when this happens, these two are the most apparent) The a/c holds position and Throttle remains at "Loiter" but the Kts number changes to the a/c's med altitude cruise speed. Test scenario, load savegame 1 Group ACA loiters high, speed 405kts, order it to loiter at med (or high), ACA indicated speed changes to 300kts, save and then load the game, ACA speed is 405kts again order it to loiter at low, save and then load the game, ACA speed stays at 300kts load savegame 2 ACA is intercepting ZYA on high altitude and will prompt to launch AAMs in a few seconds, cancel the launch, cancel the "Return home" prompt, ACA starts to loiter but speed is 405kts Change ACA altitude to low before launch, after cancelling ACA loiters at 300kts speed Issue-32-Loiter-at-cruise-speed.pdf LOITER.zip
-
GE - Fix formation station-keeping
Issue Information Issue ID #000057 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2009.097 Fixed in GE - Fix formation station-keepingPosted by TonyE on 02 October 2013 - 11:13 AM The inability of group members to properly keep their stations in formation is a long-standing and well-known issue. Time to take another look at it and see what can be done. To investigate: * Station keeping in groups that have paths defined in the SE and remain untouched in the GE. * Station keeping in groups with no path and speed set. * Station keeping in groups that are moving at Flank speed. * Station keeping in groups at 5kts/creep. * Station keeping in groups that are composed of units split from other groups. * Station keeping in groups that are the result of joining multiple groups together. Issue-57-GE-Fix-formation-station-keeping.pdf
-
Window Detail
Issue Information Issue ID #000082 Issue Type Issue Severity 0 - None Asssigned Status 10 - Confirmed Version 2014.013 Fixed in Window DetailPosted by eeustice on 20 August 2014 - 08:09 PM Window Detail box not aligned with data in the new SE, Attached is a screen shot of the box. If you have any questions please let me know. Thanks, E Issue-82-Window-Detail.pdf Window Detail.zip
-
Mk2 Eagle Eye - 40nm visual detection of GBU/SDB/PGM
Issue Information Issue ID #000077 Issue Type Issue Severity 0 - None Assigned Status 10 - Confirmed Version 2014.010 Fixed in Mk2 Eagle Eye - 40nm visual detection of GBU/SDB/PGMPosted by Grumble on 15 July 2014 - 01:43 AM Linked to the Mk1 there is one other complication PGMs as Brad pointed out are supposed to be immune to AAM/SAM, they got very low RCS like the 6 for GBU-53 SDB II, to ensure this, but they are still being intercepted by AAM and SAM. Most GBUs have "High" max altitude and so these fly to target on High, I guess they are detected visually, as per 5.4.2. Radar log shows that radar detection is indeed impossible, in the first detection cycle missile is "not detected", but in the second cycle they are already "not detected" by radar, but also "Target was previously tracked". In the attached save game, 2x2 F-35B is ready to drop GBUs on SAM sites, but all 32 of them is going to be shot down. Switching to red side (044 red.hpm), Staff Assistant reports the visual detection indeed. Probably gliders should be exempted from under 5.4.2, or a workaround could be to update GBUs max altitude to medium in the DB. Issue-Mk2-Eagle-Eye-40nm-visual-detection-of-GBU_SDB_PGM.pdf 044 bombsaway.zip