Stalintc

HCE 2008.034 This fix was tested and appeared to work, but after running the scenario for about 10 seconds it then crashed with the following error: Can someone please confim they experience this also.

I have confimed this also happened for me in the following versions of HCE: 2008.24 2008.33 This save should be loaded using the WestPac battlset. Cheers Terry

what's wrong with that picture (think aligning the search). Ok I have now added what I think would be a solution to aligning the search, this is basically a ring of radio buttons around a circular image that depict the general direction of the search pattern. So for example the player wants to do a parallel search pattern in the direction of 270, the player would then click in the radio button next to 270 select the other partticulars including the radio button for parallel and then OK to begin the search. The radio buttons around the circle will basically tell the AI want direction to plot in, but I personally think that insted of exactly 270 etc etc there should be a percentage of variation in the direction that the AI actually uses just so its different everytime, because real life is not always that exact. Here are some examples of different layouts to this affect... The second image is depicting the same window idea but with radio buttons for the ranges. However I personally believe it makes the box more cluttered than it should be. And should the user not be able to designate their own ranges and intervals? How does the AI side decide which methods it should use? If the enemy AI or formation AI were to decide which method to use, it should base its opinions on what it knows from the battle picture. Perhaps this simple set of rules below could be expanded but please do have your say on it: Parallel: - No current unknown or known enemy sub contacts are within 100nm of the formation. - No contacts that have been recently lost were within 100nm of the formation. Creeping: - No current unknown or known enemy sub contacts are within 100nm of the formation - Contacts have been recently sighted with 100nm of the formation and contact has been lost. (since the end of patrol pattern should be where the sub contact was last detected before it was lost. Sqaure: - A known enemy sub contact is within 100nm of the formation but not fully localised. (No fix on unit XXX) Assuming unit is from the opposition and this known to the AI Sector - An unknown sub contact is within 100nm of the formation but not fully localised. (No fix on unti XXX) Assuming unit is difficult to detect because it is not yet classified Now this leads us onto the aspect of how does the AI decide what ranges and intervals to use for its searches to complete the above dialogue box as if it were human. I know not what the limitations of coding the AI are, but in order to keep it simple I believe the AI should be able to pick a random number between X and Y. I dont see the AI gaining much benefit from deciding how the search ranges are to be conducted for the work involved in making it decide. I'm sure others have opinions and ideas on that and I would encourage you to share them, because reasoning this for the AI has me baffled. However when we talk of what direction or *road* the AI selects for its search pattern, I believe the AI should be able to select this based on the current bearing of the ambigous contact. But if no contact is known, this I believe should also be somewhat randomised. How does this influence scenario design, what does the scenario designer have for choices, etc... I have very little experience with scenario design and I only use the editor to knock out small test scenarios, so I dont think I can answer this fully and accuratley, but I will reply on what I understand of the process. If the AI is capable of thinking for itself with regards to ASW it should then reduce by a margin the amount of work the scenario designer needs to do setting up patrols for the AI. But perhaps also the scenario designer should also be allowed to still manually set those patrols up, because he\she may still want to have that higher likelyhood that the players submarine assets will be picked up. Handing off responsibility to the AI while still regaining control is the road to flexibility with scenario design. "You can do it if you need to, but you dont have to" approach to scen design. However I do believe that if the AI was capable of doing this well, we would see a higher trend of random and differing results each time a scenario is played. That in my opinion is the backbone of what makes a scenario great, is that it never plays the same way twice. Making the AI do more of its own chores well increases this effect to a huge degree. Perhaps this could be better answered by our resident scen design veterans <g> Anybody have any further thoughts? speak up!!

I voted yes. However, I would like to say that rather than just having a damage limit before the sub surfaces, perhaps also a percentage chance of the sub surfacing gets calculated with each hit after a certain damage level, which increases with each hit... simple example below: 35% damage - 30% chance of surfacing on next hit (if not destroyed) 60% damage - 70% chance of surfacing when next hit (if not destroyed) (The above figures are rough and not calculated in any way, they are just ideas) Just an idea, this would prevent guaranteed surfacing, which I dont think should be the case, since im sure there are other factors involved. But overall I love the idea, I think its great.

Would love to play gents, however I wont be around Sat, hope you have fun

Comrade, I am afraid it is not, you can only see the currently loaded ammunition available for immediate firing, you cannot see what the ship has below decks to reload into that position. I was informed by CV32 that I needed to enter the PE to view that info, and boy was I surprised to see how many shells and torpedos some of my ships had below decks waiting to reload. I see what you mean though

Tony, Thank you very much for reading through that! all input will go very far to making this document worth making and reading! The sprint drift thing is something I need to cover yes, I am somewhat shakey at the moment about describing it and I may need to ask for some help with that. But im sure you eggheads will be more than willing to answer any q's <g> With regards to the contents and glossary, that will be put into works later in the development, I am still currently in the process of fleshing out the meaty stuff, its far to early to do a contents I feel because I may still chop and change the order yet. Cheers

Further to the above statements, I wanted to add something with regards to the user end of the operation, what control I feel the user may need to have over the process. Workings 1) User decides where they would like to setup an ASW patrol 2) User selects the group containing the aircraft they would like to launch on that patrol. 3) User clicks *Launch* as normal and then is prompted for a patrol type. 4) User then puts radio button in what would be a fourth one, for ASW Patrol. 5) User is then prompted for the location of the search and would click on the map as if they were selecting a patrol destination, at the epicentre of the ASW search. 6) User is then prompted with a dialogue box similar to what is attached to this post asking them for the details of what search they would like. 7) After clicking *OK* the user is now prompted for what aircraft like they would like to assing as normal. (preferrably with only ASW capable aircraft in the list <g> ) Intergration into other parts of the interface The above will work fine, until the player attempts to change the unit course to something else... of course the player should be entitled to do so. And perhaps there should be a button on the top bar which can re-initiate the above process. It is also inevitable on that note that the player may wish to change the location of the search, which would heighten the need for a button re-initiate the process even more. There would be no point having the feature if it could not be accessed at any time like *Attack* for example. New Menu Explained Here is a brief explanation of what the items in the menu in the attached image should do. > Four radio buttons on right - Pass the argument to the AI as to what search pattern to use and plots a course according to this. This will affect the main part of how the AI behaves on the course too. > Boundary - Define to the AI in nm how far the boundary of the search is to stretch. > Sonobuoy Interval - Define to the AI how often to drop sonobuoys > Repeat? - Checkbox to make the AI perform the search course, but then replot and do it again in a loop until other orders are issued. > Use dipping sonar - Checkbox to make the AI stop at intervals to use its dipping sonar (providing it has one)

1 - Better and more automated AI routines for plotting ASW searches and sonobouy drops, types of attack on surface targets. Basically outlining to the AI what you want it to do and it then makes its own courses and decisions on how to carry out that order. For example expand the attack order so that there a few types of attack that the AI can plot *pop up* *pincer* *offset* etc etc. Also with regards to ASW you can tell it to do MAD runs and it will plot them or sonobouy drops and it plots them it a pattern you can specify, or of your own choice from a list. 2 - Time delays for ships changing course. (I still think it is weird how ships change direction instantly.) 3 - The ability to view the contents of a ships magazine without having to open the PE. Simply because I see no reason why a player should even need to jump to the PE to view anything when this can be displayed in the GE itself, it is a drag to keeping looking up each vessel in the DB to see what it has and then double check after you forget. 4 - Proper countermeasure modelling for ALL unit types which can carry them. 5 - Land elevation data and its effect on radars and return signatures. (So aircraft can fly low and actually use terrain elevation as an advantage when their weapons dont permit stand off) This I feel would make a HUGE difference to the way the air war is currently played out it would allow a player or the AI to tactically use the terrain to its advantage and would be greatly helpful to a side which is outnumbered and outclassed, allowing tactics to prevail as much technology - Ever been in the situation where you are prevented from waging a good SEAD strike because you cant get close enough to the target without being shot at? or you want to increase the PK of your missiles by reducing the distance they have to travel and vulnerable to AA fire. With good terrain modelling you can use it to hide aircraft from radars at low level and get inside the weapon engagement zone of SAMs and attack them more effectivley with pop up attacks. - Currently it is not very workable to attempt to attack aircraft very well with their radars on and longer range missiles than yourself, while this sounds correct which it is for the most part, these battles can also be won with superior tactics if the land was able to help sheild CAP patrols from radar signals which is refferred to as AMBUSH CAP and it also allows fighters to sneak around an incoming attack and take them from behind their radar cone. - Didnt see that coming did you? one of your bases\ships just got struck by AI that was using the terrain to stay out of your radars, a hole you failed to plug. Imagine being able to do that yourself and defeat the odds stacked against your attacking aircraft?! cool huh.. - Hide your ships\patrol craft from radars using a peninsula and ambush them when they come into range of your own weapons, use other units to pin down their location and fire BOL only to slip away before they realise. - We have land units now dont we? of course we do and would it be fantastic if those were also difficult to find because a radar cant sweep over them or other ground units dont have LOS. 6 - Ability to aquire water depth data from a single mouse click (display by the range and grid coords..) GRANTED! 7 - Scale colouring for water based on depth. 8 - Torpedo search patterns on reaching activation point. 9 - AI aircraft that understand missiles are dangerous and attempt to run and outmanuver incomings, insted of charging fiercly into the fray. 10 - Enemy AI that does not send planes charging through SAM sites to get to your shipping and other assets and understands to try to avoid contact. 11 - Enemy AI that understands a basic concept of recon and attempts to find enemys without using preplotted routes by a scen designer. 12 - Mines that are actually mines not submarine objects as placeholders. 13 - Game launcher that allows hot swapping of DB's 14 - Larger formation rings for those long range BARCAPs 15 - Simple set of drawing tools, to place lines\circles\sqaures\text onto the map to aid in planning, marking CAP zones, marking up contacts about to be lost etc etc etc 16 - Animations for hitting land targets. 17 - Animations for torpedos hitting ships. 18 - Animations for point defence and gun fighting. 19 - Unit window that zooms out further. GRANTED! 20 - Tactical pause at the BEGINNING of each scenario when it is loaded for the first time. NOT after a save or DURING the scenario. GRANTED! This would allow a player upon loading a scenario to survey the land\sea, what assets are where, plot CAP,AEW,ASW and plot initial formation orders etc etc, insted of being thrown right in and scrabbling to get a physical picture of WHAT is WHERE, while the OOB is very helpful it does not give a physical picture in terms of the map of where assets are located without letting the clock tick. I personally believe this would be a very important feature when loading a large scenario where you are tasked with co-ordinating alot of platforms from the very start. At least then it would be possible to "get the ball rolling" in terms of launching rotational duties like CAP,ASW,AEW etc etc routing and so on. While I do agree with the point "Well the AI does not have this luxury" in retrospect it does have the luxury since it can think much faster than the human player regardless of how many units it has. I am not suggesting that this be added for returning to a SAVE game or DURING the scenario, simply at the very start before any clocks start ticking, once the clock starts thats it time up, because I do very much agree with the point that in war there is no such thing as a pause, but we must also consider, what was happening before the scenario got loaded? did redfor and bluefor just wake up one day at the same time not knowing what the hell was going on and just decide to launch some random crap? 21 - Force Reload Key combo For those situations where reload just doesnt happen, much like with air to air refuelling. Also would come in very handy if you wanted to ensure the mounts were full ready for the next engagement if you knew you had time 22 - SM2 and alike air and sea capable weapons to be able to engage both target types, not just air A severe limitation in weapons deployment in some scenarios, while I agree AAW is its most useful aspect, it does have its uses in surface combat, which I have come across and been a little annoyed at not being able to use

Defect Name: Helicopters on land order at final waypoint land instantly. Build: HCE 2008.033 Repeatable: Yes Operating System: Windows Vista Ultimate x64 DB used: HCDB-080406 Scenario used: TESTINS (Purpose built for this test) Battleset: EC2003 IOPG Long Description: When a helicopter is assigned the *land air* order at the final waypoint of its course, it will instantly land at the target airbase when it reaches that final waypoint. It will negate the entire distance to its home base and the operation will be performed in the space of a second. Process: - Open GE - Open the attached save for EC2003 IOPG named InstaLand1. - Ensure helicopter group ABH has a speed order then let the game run. - Note the behaviour exhibited when the helicopter reaches that final waypoint. Expected Behaviour: Helicopter reaches final waypoint and then replots its course to land at the designated airbase. Exhibited Behaviour: Helicopter reaches final waypoint and then is instantly moved to a landed status at the designated airbase. Workaround: Do not issue *land air* orders at the end of a waypoint course... Issue the land air manually to the unit when you wish it to do so, it will then replot and land fine. InstaLand1.zip

Tested in 2008.032 and 2008.033 and error no longer occurs. Also confirmed database version is now displayed for EC2003 scenarios after loading from a save.

Defect Name: C++ error recieved on resolve torpedo attack vs sub Build: HCE 2008.24 Repeatable: Yes Operating System: Windows Vista Ultimate x64 DB used: Stock DB Scenario used: Kodak Moment Battleset: EC2003 IOPG Long Description: An air launched torpedo in the save attached to this report is causing a C++ error during the resolution of its attack on a Kilo class submarine. The displayed error message will allow continuation of the game by clicking *ignore* Process: - Open GE - Open the attached save for EC2003 IOPG Kodak Moment - Watch the torpedo attempt to resolve its attack on the Kilo class submarine - After a few moments the game will stop and the error message will be displayed. - Note that clicking any other option than *ignore* will cause the game to CTD Expected Behaviour: Torpedo resolves its attack against the submarine and either misses or hits with interuption to the game client. Exhibited Behaviour: Torpedo resolves its attack against the submarine and gets interupted by an error before completion. Workaround: When this error is displayed during the resolution of the attack, be sure to click *ignore* or the game will crash. Notes: I am yet to test this in the current Beta, but will be doing so in the next day or two. I can see no evidence of this error being looked at or repaired in the change logs and I can find no evidence of past reports on this matter, so I expect the results to be the same. Kodak_Moment1error.zip

I vote no for refuelling, while it is better, there is still very much room for further improvement and perhaps a little early to pose the question if you dont mind me saying. However progress is good and it will be excellent to see it continue in that direction! I vote yes for the patch release, there is alot of stuff in there which will make the community very happy, it is also a stable build which I would be proud to release to the public if it were my work, job well done and 5 stars!

Defect Name: Refuel not spread to whole group Build: GE 2007.000 Repeatable: Yes Operating System: Vista Ultimate 64bit DB used: HCDB release Scenario used: HDSK 1.0 Wrath Battleset: EC2003 IOPG Long Description: - When a tanker has been added to a group of aircraft containing one or more different types of LOADOUT and refuelling takes place, the tanking process will only address and refuel one group of those aircraft LOADOUT types and the others will not be refuelled. - When a tanker has been added to a group of aircraft containing one or more different types of AIRCRAFT and refuelling takes place, the tanking process will only address and refuel one of those AIRCRAFT types and the others will not be refuelled. - When a tanker has been added to a group of aircraft which has been previously split and rejoined together again with the SAME LOADOUT and SAME AIRCRAFT type, the tanking process will only address and refuel one of the groups of aircraft that were part of the split groups before they were rejoined into one group. (You can see clearly that once you rejoin the group together again and just open the split or join dialogue they are now in two seperate parts despite being essentially the same loadout and type etc and to which only of these sections gets refuelled) - When a tanker has been added to a group of aircraft which has previously been collated into a slightly larger group with aircraft from another group, which may or may not contain differing loadouts and types, only one section of those aircraft in the whole new group will be refuelled. Process: - Join tanker to a group that follows any one of the above scenarios. - Press Alt-R to force refuel. - Split the tanker from the group. - Observe the bingo state and total aircraft range for the whole group, (note the percentage shown is taken from the aircraft with the lowest fuel reserves in the group) - Split the group into its seperate sections. - Observe the bingo state and total aircraft range for each of the new groups and compare. Expected Behaviour: Tanker joins the group and refuels all aircraft within that group Exhibited Behaviour: Tanker joins the group and refuels only one section of the group TESTER NOTE: I am currently unable to provide a test scenario as I am currently in need of creating a VM session of WindowsXP as my installation of Vista Ultimate 64bit does NOT support 16bit subsystems and applications. However I will create the VM session and provide files when I am next capable of doing so... apologies for the inconvenience caused.

BUMP - updated 07/01/2008

Works great with the DGVOODOO v1.50 beta glide wrapper! One of the keepers I should have gotten hold of a long time ago, to go with my never dying copy of Falcon 4.0\Falcon 4.0 Allied Force, good campaign and a solid simulation.

-The ability to switch between installed licenses of HCE (beta testing - differing DB installs etc etc) I do this currently by exporting a copy of each license reg entry to my desktop as I install the HCE clients to my computer, and then import the respective reg entry to the registry for each install, for example if I wanted to load my Beta install insted of my personal copy. Which currently throws up an error not allowing you open the exe if you dont have the correct license code for the exe in the registry entry. Cheers

Hi Akula, Yes that will fix it, but there is nothing stopping it happening on the new course you have set and will very likely happen again if you have course changes that are close to right angles. Yeah I first noticed this problem midway through a MAD sweep to which I had a *ladder* style course set with 90 degree course changes, which was well into a sortie with several courses used already well out of the original patrol point. So you are perfectly right about the loiter thing, but im very sure this doesnt relate to this one in any way. If you load up the save that I posted with the message, you can see just how bizzare this is, you can watch the plane flick back and forth for quite a while on some occasions before it continues. I even had one, at one point where it was still doing it after 5 minutes and then deleted the waypoint before it would continue on course. Thanks for the your thoughts Akula on this truely bizzare little bug! Cheers

I have found a simple workaround to *unstick* the aircraft. Process: - Select unit in group window - Click *Course* - Select *Waypoint One* - Click *Delete* and confirm the deletion Result: Unit now continues on the rest of the ordered course.

Thanks for that Tony, It appears I mis-understood the fact that metres are not displayed Does seem very much like it when you click at that high mag though, it almost makes sense. But thanks for the clearup on that, it will save some confusion Cheers

Defect Name: Incorrect range metric being displayed for ranges under 1 Nautical Mile Build: HCE 2007.031 GE Repeatable: Yes Operating System: Win XP SP2 DB used: Scenario used: GIUK 5.0 Gatekeeper Battleset: GIUK Orignally reported: http://www.matrixgames.com/forums/tm.asp?m=1641789 Long Description: When examining small distances in the unit window, ranges under 1 Nautical Mile which should be measured in metres? get displayed as Nautical Miles. Process: - Open any scenario - Set unit window to 128x magnification - Click once in the unit window - Click again a very short distance away from the first click - Note behaviour at bottom left where range is displayed Expected Behaviour: Checking distances under 1 nautical mile is shown in metres? Exhibited Behaviour: Checking distances under 1 nautical mile gets shown in nautical miles (e.g 1000 metres shown as 1000 nautical miles)

Defect Name: Aircraft stuck at waypoints Build: HCE 2007.031 GE Repeatable: Yes (can be provoked but is occasional) Operating System: Win XP SP2 DB used: Scenario used: Purpose Built - Air_Test.sc1 (savegame and .sc1 attached to post) Battleset: GIUK Long Description: When aircraft is moving along a plotted course, on occasion it will get stuck on waypoints that require a roughly 90 degree turn, the aircraft will change course back and forth for several game minutes until it eventually rights itself and continues on course. Process: - Open GE - Load save *Air_testsave1.hp1* from GIUK battleset - Observe pre-plotted course - Run game time at 30sec slow to 10sec near waypoints to observe affects - At waypoint note behaviour (The most consistant waypoint is waypoint 3, if it does not happen first time round load the save again and run the above process) Expected Behaviour: Aircraft reaches waypoint and immediatley turns towards the next waypoint in the course. Exhibited Behaviour: Aircraft reaches some waypoints and becomes stuck for several minutes switching direction before continuing course. Workaround: Delete the waypoint the aircraft is currently stuck on and it continues its course to the next waypoint. Previous Versions?: Behaviour was first noticed and is true of the release build of HCE AIR_TEST.zip Air_testsave1.zip

Defect Name: Assertion Failed Build: HCE 2007.029 SE Repeatable: Yes Operating System: Win XP SP2 DB used: Scenario used: - Purpose built - Air_Test.sce (attached here) Battleset: GIUK Long Description: When attempting to add a USSR Fleet Oiler an Assertion Failed error occurs as shown in the below pictures Process: - Open SE - Open *Air_Test.sce* in the GIUK Battleset - Click *create new group* - Choose side *USSR* - Pick location and click *ok* - Highlight *Ships* and highlight *USSR Fleet Oiler* - Click *Add Unit* Expected behaviour: USSR Fleet Oiler gets added as the first unit in the group Exhibited Behaviour: Assertion Failed error occurs and SE closes to desktop Error Process: 1st message 2nd message SE closes to desktop AIR_TEST.zip

Hi all, I notice a few newer players have some difficulty grasping naval tactics, and it can sometimes be long winded to explain some things in a forum post especially if you end up doing it for several of the forum users. I have begun work on an ASW guide, which I will be posting up in this thread everytime I have updated it to keep things current. I have laid out some groundwork for the first section of the guide, not very much, but enough for some of you to see whether it is worth me carrying on writing it in this manner and plus whether the content in there is any good. I would appreciate your input as I am a firm believer that no one person can be the font of all knowledge (which I am most certainly not even close to being) and by opening this up to criticism and suggestions by you all I can produce a quality document for new users of HCE. I dont intend on updating any further for the moment till I have had some input from you guys on whether its a good idea, as it is going to be alot of work This is NOT fully formatted yet.... I WILL be adding some screenshot examples and introducing a contents page.. comments please? Progress: 08\12\2007 - 02:00 - Completed draft text population for section DETECT>FORMATION - uploaded file 11\12\2007 - 12:05 - Begun population of text for section DESTROY - uploaded file 11\12\2007 - 20:35 - Begun Population of text for section DETECT>PATROLS - uploaded file 071\2008 - 15:35 - Continued Population of text for section DETECT> PATROLS - Begun Population of text for section INTERROGATE - uploaded file HCE_Guide_to_ASW.doc

Priority: MEDIUM The ability to add an order in the course editor which will drop a string of sonobuoys close together until the next waypoint is reached. I think this is currently one of the things that would be greatly appreciated by the community (and myself) since good ASW sonobuoy drops outside of formation currently needs first hand attention through the entire drop. The ability to drop long range barrier and interogation nets for contacts without having to hand manage each individual aircraft would be a godsend. Cheers