Search the Community

The attached scenario is run in westpac BS using HCDB 150929 database. GE 2024.006. There is a single sub. THe max speed of this sub on surface is 10 kts. It is currently submerged and traveling at its max speed or 21 kts. Use command F2 to set the speed/depth to surfaced and any speed about 10, say 15. Execute the command and the sub continues on the surface at an illegal speed. If you set the speed again you are now only able to set the legal speeds if it remains surfaced. A similar thing happens with subs that have a higher surface speed than their max submerged speed. I would expect that when changing the speed/alt from submerged to surface you should only be able to set legal surface speeds. SubChngeDepth_Spd.scq.zip

If a target is ordered to be attacked by an aircraft within gun range but outside gun arc (with no other weapons available) then a staff message is received "Sir, should we engage with only cannon fire?" If you answer yes the game will crash. If you answer no then your plane proceeds on its current course with no action. If you determine the bearing of the enemy plane using ctrlF then use course editor F3 to head generally in that direction you can engage the enemy. I'd expect that you should be able to answer yes to the staff message and have your aircraft turn to engage (if it turns fast enough), or at least not crash game. The test uses westpac BS and HCWW-101110 DB. I used GE version 2024.006 (but I've been seeing the issue for quite some time). To reproduce start the saved game, your (sole) aircraft group should be active (selected), the enemy plane group is likely hidden in the GUI but is visible, issue attack F1 command (there should be only one available target) and answer yes to the staff message. There is a brief pause of a a few seconds and the game crashes. The saved game and the original scenario are included. WW_cannon_GunArc.scq.zip

BS=Medc2003, DB=HCDB2-170909 & GE=2024.006 Situation: SG ABS (blue) comprises two units, AB00 I believe is not detected by the red enemy or at least they have no indication of location. AB01 they have exact location. They fire missile at both units. I believe that the missiles are targeting AB00 as if they had an exact location but they do not. Two saved games are zipped, AShM-SL005 is a couple of seconds before SLSSMatNotKnownTarget. Open game AShM-SL005, the red enemy has approx fix on AB01 and no fix on AB00, within a sec (or two) an exact fix is obtained on AB01 and missiles are fired at both units although red enemy still has no location of AB00. SLSSMatNotKnownTarget simply shows this situation at time of firing missiles. SLSSMatNotKnownTarget.zip

Test uses mk13gmls (one armed bandit), 4 harpoon ssm available and three surface target in range. DB indicates only one harpoon can be fired at a time (single rail launcher) but the restriction isn't applied. Also DB indicates only two targets at a time but can target more. attached zip contains txt explanation of test, original scenario (Westpac BS) used in test, two saved game short cuts and screen shot to help explanation text. Procedure: start scenario mk13gmls.scq (use HCDB-140909 DB, Westpac BS), play blue, continue until detect three enemy ships. This point is save game mk13gmls-1 if you want a short cut. Attack (F1) the enemy and see that the computer allocation is correct for single rail GMLS assigning only one missile. (left diag in JPG file) but you can allocate any number up to the total local mag of 4 *. I have allocated three, one to each target and execute. Wait a little for missile flight part way to target, this is game save mk13gmls-2 and you can see right diagin jpg 3 individual misile units of a single group headed for their respective targets. 1/ Only one missile should be able to launch at a time, but can launch more. 2/ Only 2 targets ( I don't know why two on a single arm launcher but db says 2) should be able to be engaged but can engage more. * re the numbers, in a modified DB with 40 available harpoon in the mk13 I could launch all 40 at the one time. Don mk13gmls.zip

Land attack (only) missiles are hitting sea platforms. (another TonyD, Eric70, donaldseadog adventure) zip pack includes saved game LAM1.hpq and the scenario file, LAMissile-hcdb-Westpac,from which it has played, the xml file and the GE from a play of the saved game. In the saved game start a flight of three skipjack bombers have attacked the AD AAm with three vollies of KentC Land Attack missiles, and RTB. This plane /loadout combo can't directly attack sea groups( tested seaprately). The outcome varies with different plays but invariably some Kent over run the AD (or the AD is destroyed) and go on to hit the ship Xiangyanghong 21. The Kent shouldn't attack sea platforms, and maybe shouldn't attack their own side. Played with GE 2023.008, database is hcdb-150929, and battleset westpac. It is believed that this has been occurring in previous game versions. LAM1-hcdb-westpac.zip

This occurred in GE 2022.016 but repeated (different scenario) GE 2022.20 Error isn't reproduced in saved game from 1 and 4 seconds prior. GE.LOG file attached in zip, line 689,553 (game time 109392) shows: 109392 Combat5.c:1580 - G AMA:AirAttacker: ZZr.. AirTargetType = (a symbol not copied) 109392 Combat5.c:1602 - G ZZr:target_type = 1, range=4, bearing=88 109392 Combat5.c:1704 - after case, gflag=0, wrange=143, WR.weapon_range=143, attack type (type_aa)=0 Note the attacker is an F16 loaded with pavewave bomb 4 m range. (maybe a help, maybe a herring?) Scenario and two saved games from -1 and -4 seconds included. played in custom battle set with in built database included. 109392 Combat5.c:1791 - wrange Was TRUE, which means WR.weapon_range was TRUE 109392 Combat5.c:1803 - Having Staff ask Sir, the effective attack range for these aircraft is 143 NM. Target range is 4 NM. Should we close and attack? excepFltType_aa.zip

playing the Heart 3 scenario (2022 attack on Taiwan) at some 4 hours of gameplay this adjunted error (See files): taiwna 222222.hpq

using database hccw 140314 battleset westpac seen in GE 2022.027 scenario SlowTurn_CW_WestPac.scq starts with blue single ship group headed near north and detects a single ship red group just out of gun range approx due west. save game SlowTurn.hpq Blue group has been ordered to attack red group, it has calculated course to close and attack, out of range reported as 3 mile. Group continues on original course for 30 mins but during this time it continues to recalculate the course to close. save game SlowTurn+28.hpq is about 28 min after attack order, in about 2 mins the group will come around on heading for the latest course to close. Research tells me a destroyer should turn on about a 1/4 mile radius (~450 yds), at 30 knots it should do a half mile per min so turn about 90 deg in 45 sec. ? SlowTurn_CW_WestPac.zip

If you wish to start a new Battleset inbuilt scenario and go to the appropriate menu then the description of the scenario should include only the scenario background but it also includes the Blue Orders. The screen shots are from BS giuk 2003, but it seems other BS are the same. Not a critical error effecting play so low priority.

use GE 2022.014, database HCDB2-170909, westpac BS In the zip is the scenario used to produce the saved game, (Important) start the scenario with auto formation patrols enabled, this produced the first MCM Sea Dragon patrol unit AA-001 which is patrolling correctly at low alt to the north east. At game start a second Sea Dragon is set via formation editor F3 to patrol to the south west and is unit AA-002, it is patrolling at medium alt and not dropping any markers. (alts can be seen in the toolbox window) In the formation editor box 001 unit is shown as an ASW Patrol, 002 unit as an AEW Patrol. I would expect both instances to patrol at low altitude and in the formation editor to be listed as ASW patrols. Game play suggests that the helos patrolling at medium alt are not detecting mines. Not shown to maintain simplicity, if an MCM helo is sent out as a Group to patrol it will fly and then hover at low alt, as expected. screenshot: MCMHelo.zip

Issue Information Issue ID #000022 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.080 Fixed in Memory Allocation Fault in Westpac Edited ScenarioPosted by eeustice on 07 June 2013 - 08:50 PM CV TG AMC disappeared from view in the game window around game time 7:10:41:20, however I still could see it in the unit window. I brought it back into the gam window by selecting it in the Oder of Battle drop down menu and splitting the TG. This is a similar problem to what I had on 5-6-13 with my Debug Assertion Failed Wespac Scenario Crash. This time when I brought the TG back into the screen as soon as the whole TG was beamed back into the Game window I got a Memory Allocation Fault. I don't know if this is related. There is a F-21 Super Tomcat that has a Refuel load on it that has been trying to land on CV TG ANS for some time. I don't know what happened to the other 9 F-21's that were in the group. At the point where this crash occurred all Land Bases an TG's for the Red side have been destroyed. There are still quite a few Red sub groups left. I am not sure it Memory Allocation Fault is being created by the Beaming in of TG AMC back into the game window, or by the F-21 trying to land. I have included in my zip file a copy of the current db I am using for the game, 2 saved games. The first saved game is just before CV TG disappears from then the game window and the second save file is where I got the Memory Allocation Fault when I tried to reload my last game saved. I was able to repeat the Memory Allocation Fault a second time. I was able to repeat the disappearing CV TG several additional times so I could come up with the approximate game time the CV TG disappeared. I am not sure if the issue from 5-6-13 and this one are related. If you guys need any additional info please let me know. Issue-22-Memory-Allocation-Fault-in-Westpac-Edited-Scenario.pdf commondb 6-7-13.zip

Issue Information Issue ID #000026 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 0000.000 Fixed in Chaotic SAM rate of firePosted by broncepulido on 30 June 2013 - 09:04 AM I think a long time ago we wrote something about it, but I don't remember it very well. I was messing with the Cold War DB, thinking in the relation of posible SAM fired from a Beam Rider system (hypothesis, 1xilluminating fire control radar and telecommand system), a SARH system (hypothesis, 2xFCR), a NTU system (hypothesis, 3xFCR) and some AEGIS/PAAMS systems (perhaps 4xFCR, but PAAMS doubles as FCR with less performances). How I've not clear what was the relation SAM rate of fire/bursts per turn, I did a little test, and I get only almost chaotic results !!! Employed as test platform the 2223 entry and her simply 59422 SM-1MR single-arm mount, as in the attached scenario. I don't write the preliminary tests, but these are the main outcomes: First outcome: the number of missiles fired it's not number of rail dependant (I tested the modified launcher with 1, 2 and 4 rails). Second outcome: the number of missiles fired it's not number of possible targets dependant (I tested the modified launcher with 1, 2, 3, 4 or 8 possible targets, perhaps late it can affect the number of planes shoot-down when the missile group reaches the plane group, but I've not tested it). Third outcome: mount type, rail or cell, is indifferent to the number of missiles fired. Fourth outcome: only the modification of ROF number in the mount affects the number of missiles fired, OK, that do the issue simpler. Fifth outcome: apparently the game engine solution is to fire a SAM burst each 30 seconds, and the number of missile fired ROF number dependant only (but sometimes launches one only SAM 10 seconds after the main burst). For me is a good and simple solution, but actually his behaviour is very chaotic .... Issue-26-Chaotic-SAM-rate-of-fire.pdf MSLROFTS.zip

Issue Information Issue ID #000028 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.082 Fixed in Platform Editor magazine limit=50 , also nowPosted by broncepulido on 07 July 2013 - 10:30 AM After an essay to fill more than 50 magazines on a ship (Iowa) with the new Platforme Editor theorically corrected as in the quoted text down, I see the limit is the old 50 (with 51 magazines exporting the platforms I get a 3163 message error):Quote With this content: If I select "ArraySize" in the seventh line I get this text: I attach the pfBuild2005 file I get in HC2009.82 wich I'm using now. Issue-28-Platform-Editor-magazine-limit=50-,-also-now.pdf pfBuild2005.zip

Issue Information Issue ID #000014 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.083 Fixed in AP gun ammo expended, but remaining ammo it's not "0", is "65473" shots!!!Posted by broncepulido on 13 April 2013 - 09:40 AM Testing the old River Plate 1939 scenario with a modified DB I see after the 280 mm AP ammo in the Graf Spee forward turret should be theorically expended, the remaining ammo it's not "0" AP shots, it's "65473" AP shots, and the turret is keeping fire!!! In the adjunt Word file I've captured some screenshots detailing best the comportment. Also, I included the modified DB I was using (for sake of simplicity, because I think is simply another overflow issue) and a saved game. Issue-14-AP-gun-ammo-expended,-but-remaining-ammo-it's-not _0_,-is-_65473_ shots!!!.pdf Gun Ammo size Error.zip Gun Ammo Amount error 2.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 #000042 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.089 Fixed in Air Groups Landing on CV'sPosted by eeustice on 22 August 2013 - 03:09 PM When launching 1 plane each from 2 CV's as an air group if both planes land as a group both planes land on the same CV. When launching 1 plane each from 2 CV's as an air group if the air group is split up to 2 groups with just a single plane in each one. 1 aircraft lands on each CV. The scenario I created is in the HDS 9 Battle Set. I did not use a specific scenario. I placed 2 CV's in a TG and have saved games from both versions. There is a screen shot of the Readied Aircraft on the CV's after landing. I have seen this in my West Pac Edited Scenario. If there are any questions please let me know. Eric Issue-42-Air-Groups-Landing-on-CV's.pdf CV Aircraft Landing.zip

Issue Information Issue ID #000044 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.086 Fixed in SE MenusPosted by eeustice on 22 August 2013 - 04:01 PM SE menus shift to the right in the Ready Aircraft and Analyze Scenario windows when more than 100 aircraft are in a group. Attached is a screen shot of both windows If you have any questions please let me know. Thanks, Eric Issue-44-SE-Menus.pdf SE Menus.zip

Issue Information Issue ID #000043 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.082 Fixed in PE Text ID'sPosted by eeustice on 22 August 2013 - 03:41 PM Any aircraft above 1000 in the aircraft annex the Text ID reverts to an exponent number. Text ID 1038 looks like 1.038E+03. Attached is a copy of the screen shots of both the last aircraft below 1000 (951) and first aircraft above 1000 (1038). If you have any questions please let me know. Thanks, Eric Issue-43-PE-Text-ID's.pdf Platform Editor Aircraft Annex.zip

Issue Information Issue ID #000037 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.086 Fixed in Aircraft Launch form AirbasesPosted by eeustice on 05 August 2013 - 07:04 PM HDS9-10 Edited scenario when starting the game with 0 sec time interval Air groups from Airfield AFA launches some aircraft groups with all planes in the group after a game time of 35 seconds. Air groups DXA, EAA, EBA, ECA, EDA, EFA and EGA have all 10 of their aircraft launched after 35 sec. Air groups EHA and EIA only have 1 or 2 aircraft in their group after 35 seconds which is correct. The air base has 2 runways. When restarting the scenario at a 1 sec interval game time all aircraft launce per the # of runways that each airfield has. This occurred on all airfields of the scenario. I have also seen this in my West Pac scenarios too when starting a new one. Attached is a saved game from the 0 sec start and the 1 sec start. Test 1 is the 0 time save and Test 2 is the normal 1 sec time interval of game time. If you have any questions please let me know. Thanks, Eric Issue-37-Aircraft-Launch-form-Airbases.pdf HC Launcher Setup.doc.zip HDS9-10.zip HDS91048.zip lau0.zip

Issue Information Issue ID #000045 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.092 Fixed in Unable to fire SSM'sPosted by eeustice on 05 September 2013 - 03:44 PM Unable to launch SSN's from TG AEC at ZQC. When selecting Attack in the GE the missile option is available however when I select Missiles nothing happens, My Harpoon's may be out of range nut my 1000 mile range, TG is only 165 miles away. My 16 inch guns are in range, In game save UntameAI1.003 I am unable to select missiles. In game save UntameAI3 I am able to select missiles and TASM is selected. Included in the Zip file is the latest version of my db,, the original scenario and 2 save games. If you guys need any additional info please let me know. PS: I was looking at the msg log and noticed some interesting info on the gun hits. I hit the ship 65535 times for 55 DP. Thanks for your time, Eric Issue-45-Unable-to-fire-SSM's.pdf No SSM Launch.zip

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 #000050 Issue Type Issue Severity 0 – None Assigned Status UNFILED Version 2009.094 Fixed in Radar gremlinPosted by Grumble on 20 September 2013 - 02:28 PM This is an old one, sometimes fighter air radars are losing exact fix on targets they were already tracking and for all I see they should still be able to do so. I've seen this happen for an F-14 tracking a Mirage F1 at some 50nm and now I got a save file for an F-15 on Su-17 at 12nm. load nofix.hpc group WLA (3xSu-17) is in front of CJA (2xF-15) at 13nm even for a blind to see run the game for 4 seconds for the next radar update ... nope, still uncertain contact only Why?? Debug just confirms the fact: 106541 search.c:884 - Radar Emitter=F-15 Eagle (Is) Target=Su-17 Fitter D, TargetRange=12, Radar LOS = (BaseLOS x weather_mod + 128)/256 106541 search.c:885 - Radar LOS of 135nm = (135nm x 256 + 128)/256 --> Radar LOS=18353/256 106541 search.c:891 - A RCS=152 TName=Su-17 Fitter D AName=F-15 Eagle (Is) Range=12 Die=44 aPD=70 106541 search.c:964 - B RCS=152 ARng=73 Arng=110 SRng=0 Srng=0 106541 search.c:968 - Target was previously tracked. 106541 search.c:1041 - Not Detected Su-17 Fitter D Issue-50-Radar-gremlin.pdf nofix.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