Joe K

When writing a series of scenarios as a "campaign", it would be helpful if the probability of including various units in a scenario could be made contingent upon the outcome of playing the preceeding scenario in the sequence. Or alternatively, to have a fixed number of units available at the start of the "campaign", with the "pool" being depleted based on the outcome of playing each scenario in the sequence. The purpose of this would be so that each scenario would not "start fresh" but rather would be affected by the attrition of units that occured when playing the preceeding scenario(s). This would allow a continuity from one scenario to the next, where the losses suffered by each side in preceeding scenario(s) would be reflected in the units that would be available when playing the subsequent scenario(s). This would also simplify the configuration of an overall "campaign" (i.e. - series of related scenarios) by allowing it to be simplified into multiple these scenarios, rather than having to create one all-encompassing scenario where the entire campaign would need to be played out in a single scenario/game. It would allow victory conditions for each "battle" (i.e. - scenario) in a campaign, yet have a continuity of losses that would ultimately influence the probability of success in the overall "campaign" (as represented by the subsequent scenarios in the set).

Agreed - wholeheartedly!

One consideraton here: It is entirely possible to need multiple refuelings on a mission - especially with short-legged a/c types (like the F-16 or Harrier), thus the feature would need the ability to "intercept" on the out-going leg, too - if needed. Now, it would be really cool to combine the ability of multiple re-fuelings from tankers capable of such with this intercept feature, to provide for these missions that need multiple re-fuelings, as in the following scenario: A flight of, say, six F-16s goes on a mission that is 2.75x their fuel range, requiring at least two refuels over the entire mission. Now, add a large tanker (KC-10, KC-135, etc.) that's already airborne somewhere near the course of the faster F-16s... the F-16's are launched on their mission; sometime after, the tanker is ordered to rendezvous; eventually it does so, and later does the first refuel (waiting until near the end of the F-16's fuel range, in order to maximize the range). Then the tanked group gets the usual "split tanker from group" query, but with a new option, like: "Shadow supported group". If the player selects this option, (and assuming the tanker has more refuel capacity available), then it will split off from the F-16 group as usual, but then continue to follow them on their course, albeit falling behind; later, when the F-16s need another gulp, the two groups would re-rendezvous automatically (or upon an applicable user query response), and perform a subsequent re-fueling, up to the remaining re-fuel availabiilty. All these operations could recur until the tanker's supply became exhausted, potentially allowing one tanker to repeatedly refuel its supported group - but without having to remain joined to the attack group - so as to avoid slowing the group and to avoid being present during the group's attack... yet at the same time, semi-automatically handling the tanker support operations - so as to avoid all the unnecesary user micro-managment! A second option could be provided in addition to the "Shadow..." and normal "Return to base" options: "Loiter for group"; If the player selected this loiter option, the tanker would split off, but would hold station and then re-join the group upon its return - assuming, of course, that the tanker has remaining re-fuel stores (and enough fuel of its own to remain on station)! Ain't re-fueling fun! ;-}

So, my wish is for one of two possible solutions: A. Have the BINGO warning occur even during the "return to base" mode, or B. Have the group automatically optimize its speed on the "return to base" run - such that it returns as quickly as possible, given its available fuel. Regarding the "B" option above, this would need to be a user-selectable decision in each case - because of the cases where it is preferrable to return to base only at lowest altitude - in order to reduce the possibility of detection. However, it would still be possible to optimize the speed under the altitude constraint - it just would take a bit longer to return in such case.

Currently, if an air group is already "returning to base" (and apparently even if there is a return-to-base "leg" in its course), an air group will not get notification when reaching BINGO fuel. This causes some problems when trying to get a group back to base ASAP: For many aircraft types, setting the speed to Military or Afterburner after initiating the "return to base" order can cause the group to run out of fuel before reaching base. Obviously, if the group is already BINGO when the "return to base" order gets initiated, then it's plain foolish to set the group to a higher consumption rate... but it's often desirable to hurry a group back to base before it has reached BINGO - like when it has exhausted its weapons, or it is needed to be re-armed in order to fight a "different type of fire", etc. Currently, there are only three options for accomplishing this "rapid return to base": 1. Order the "return to base", then set a higher speed/altitude than the default; This often leads to running out of fuel - unless the group's speed can be micro-managed. 2. Set a course that does not include any "return to base" leg, and set a higher-than-normal speed; This may produce the BINGO warning - usually far enough ahead to prevent running out of fuel (unless it happens fairly close to the base) and the usual "return to base" option can be invoked at that point; However, this tactic has a second potential problem because if the BINGO point has not been reached by the end of the prescribed course, then the group may "over-fly" the base before the "no course" warning occurs, thus wasting time by having to turn around and go back to the base... pretty much defeating the original purpose. 3. Set a two-segment course that includes a high-speed run to a certain point, followed by a normal "return to base" leg; This can work, if a good guesstimate of the proper change-over point can be made, but if the quesstimate is wrong, then either the group will run out of fuel and crash, or else it will not return to base as quickly as possible. (As far as I know, there is no way to calculate this change-over point accurately by the user, thus forcing only a "best guess"). So, my wish is for one of two possible solutions: A. Have the BINGO warning occur even during the "return to base" mode, or B. Have the group automatically optimize its speed on the "return to base" run - such that it returns as quickly as possible, given its available fuel.

I'm not aware of any way to set the altitude (or depth) of formation members independently. (If such capability does exist, then the following is irrelevent). It would be helpful in formations if the altitude of air units and the depth of sub units could be set independently - or at least could be set to some default that is somehow optimal for each type of unit - like ASW units at Low or VLow, as optimum, AEWs at their specific optimum altitude, CAP at Low or Medium, etc. The disadvantage of automatically-set default altitudes/depths is that sometimes the current purpose of the unit in the formation is not what might be implied by its type and/or loadout - for example, when needing to use an ASW helo as a surrogate for a missing AEW asset, while retaining its ASW capability (due to limited ASW resources, etc.), or when a CAP is being used for anti-missile defense as opposed to anti-aircraft defense, or when some CAP units are being set as "lurkers" for ambush, etc. In cases like these, it would be helpful to be able to set the altitude/depth of the unit "manually", as needed.

Another way that air group "formations" would be useful is when escorting a high-value asset - such as an AWACS, or even a tanker. Especially with an AWACS, which may have a patrol course set, it is currently quite challenging to provide reliable fighter escorts for the AWACS. This is because there are only two ways to do this, neither of which is really practical: 1. Just include the escorts in the "formation-less" group: The main problem with this is that the escorts can't be positioned away from the AWACS, so typically AI interceptors will get shots on the AWACS before they're ever detected, giving no time for the escorts to engage them. This is compounded by the fact that often the interceptors have longer-range missiles than the escorts. 2. Put one or more escort groups on a parallel course to the AWACS patrol course, but far enough away along the axis of expected attack to be able to "picket" for the AWACS. There are several "management" difficulties with this approach: * It is difficult to accurately match the escorts' course(s) to the AWACS's course - because the AWACS's course is not visible when setting the course(s) for other groups, and * It is almost impossible to match the speed of the escort group(s) to that of the AWACS group, because a group's speed cannot be "fine tuned" to match a specific speed, and * It is impossible to provide a refueling tanker to cover both the AWACS and the escort group(s). By having an air group formation, most of the difficulties could be resolved: * The escorts could be positioned in the formation at a relatively fixed range from the AWACS, and such range could be adjusted according to the missile range of the escorts and/or of the expected AI interceptors, and/or based on the range at which the AI interceptors can be detected, in order to provide adequate engagement time for the escorts, and * The relative positions of the escorts around the AWACS could be managed as needed, and * The escorts' speeds and courses would automatically match the AWACS's course and speed, and * One (large) tanker could be included in the formation - to refuel the AWACS and the escorts (although it would be even better if the tankers were capable of dispensing multiple refuels - at the times needed by the various aircraft types in the group) All of this would make it much easier to manage the AWACS/escort/tanker group in a practical way. There are still a few disadvantages, though: 1. It is currently not possible to set the altitude of formation members independently - so all elements would have to be at the same altitude - as opposed to putting the AWACS at high altitude, with the tanker and escorts at low altitude (to reduce detectability) - which can be accomplished with separate groups, and 2. Current methodology for refueling would not be ideal (as mentioned above), and probably would lead to the old bug-a-boo where the "short-legged" members of an air group run out of fuel before the overall group deos, and so they crash - essentially unannounced. Overall, though, there would be certain advantages in having air group formations.

Well... I'm really not sure about the colors in the various situations. I did, however, notice a couple things: * The AA units had no trouble downing my planes - whatever color the AA units were ;-} * In the re-plays of the scenarios, I tried "parking" planes having SS radar (F-16s or Su-24s) near the target bases, and turned their radars on. They survived long enough in some cases to "guide" other attack groups to the target bases, yet didn't affect the "no-re-attack" behavior. In a somewhat related question, does setting a group's radar(s) to intermittant make them as detectable as setting their radar(s) to On? Observation seems to indicate that groups are very easily detected when using intermittant settings - even with long cycle periods.

I really dunno what's up; after running it by Tony, it seems possible that something is mucked up locally on my system - although it's unclear why/how it would cause the behavior seen (i.e. - virtually no detection of AI groups, but 100% detection of my groups by the AI... plus extremely low effectiveness of my weapons (of all types) versus seeming invincibility of the AI's weapons. All I can say is that it's darned peculiar, and doesn't seem sensible. it's like something is really goofed up somehow; hmmm... is there a setting that adjusts the AI's relative effectiveness (like setting the "difficulty level") that I've missed, and might've gotten set to "max difficulty" somehow? I'm assuming they do, but I'm not sure how to confirm it. We're speaking of the types (red & blue) in the USNI, Scenario 1. Haven't read that (wasn't even aware of it). I've had pretty much the same aircraft available each time I've tried the Scenarios (red/blue), and the F/A-18's (curiously lacking AMRAAM) are present, as are the Sea Harriers, the Gr.s, and a bunch of -totally useless- F-16's for the blue side. The red side came up with a few MiG-29s, about eight MiG-27s, and six Su-24's each time. (FWIW, the red side was equally ineffectual at "seeing" the blue AI's groups). Actually, the Sea Harriers/AMRAAMs were much more effective than the Hornets: IIRC, the only kills I could get with the Hornet groups were against the MiG-27s (but the MiG-27's usually returned the favor by wiping out the Hornet pairs with return fire... again, not making much sense. I gotta think that something is bogus with this; I'd have to go back and confirm it, but I don't recall any comparable problems when playing the USNI stuff in HCG; have those scenarios been altered substantially betwen versions?

Thanks! (My guess had been that it was indicating detection by enemy radar, or some such...) True! (In this instance, I'm dealing with air units primarily). The puzzing thing is that I have the same issue if I leave my radars off, fly at Low or VLow, etc. Also, I cannot detect the AI groups (or their missiles) by ESM, active radar, IR, or even visual means - even when they're shooting at my air groups! Theoretically, I should "see" their missile guidance radars at least in some cases (e.g.- Sparrows, etc.) in order for them to be able to kill my groups, right? (Doesn't happen! I rarely ever get even a contact on an AI group - let alone a fix! It's really weird!) I should be able to detect AI groups doing this to my groups, right? (Not applicable in this situation). Yup... but apparently the player's groups have inferior eyeballs - 'cause my groups are getting visuals only very rarely - yet the AI groups are forever "sneaking up" on my groups, totally undetected. (Now, my eyesight isn't that great... but the GE isn't picking up on that, I hope! ;-} ) Understood. In my case, I've been playing computer Harpoon since the Three-Sixty DOS version... most recently, HCG/WestPac... and the detection behaviors I see in this HCE demo are totally different than the earlier versions . Well, I was playing the USNI Scenario 1, from one side, then the other - same results. Throughout the USNI, Scenario 1, regardless of which side I was playing, the AI missiles were nearly invincible, yet my groups' missiles were totally spoofed in maybe 75%-80% of the cases. I replayed the Scenario several times, with similar results. Right... but not the case in this instance: The attacking groups would "stumble over" the AA units while approaching the target base, and indeed, the AA units would appear in the initial weapons allocation dialog, but the attacking group would get into that abortive mode after the initial attack, and would not continue to attack either the AA units nor the base itself (as described in the bug report). And the really annoying aspect was that AI groups would attack my bases/AA units with total impunity. As far as I could tell, no missiles/guns were ever fired against the AI's attacking air groups - totally the opposite of the case when my groups attacked the AI bases/AA units. Frustrating! I don't mind a challenge, but what I'm seeing isn't making any sense - not to mention being totally lop-sided in favor of the AI!

Coming from HCG/WesPac directly to the HCE Demo, a few things jumped right out at me in short order: 1. What exactly does the "lightning bolt" indicate? Seems to appear when the group turns its radar on - but since that is already indicated by the radar range circles, is the bolt actually indicating that the group has been "painted" by enemy sensors? Or...? 2. No matter which side I play and however I deploy my groups, the AI finds them in short order, and blasts them via unseen weapons and platforms; meanwhile my units can even blaze away with radar, but never detect anything until visually - when it's waaay too late. In other words, the AI can find and "see" my groups - and kill them with unseen missiles - without using any radar whatsoever... yet I can't detect enemy groups without literally tripping over them - even if I use my radars... What am I doing wrong? Why the great discrepancy between the AI and the player in terms of detection capability? 3. Adding to my frustration, on the few times that I do detect a target and get to fire at it, the AI almost always evades my missiles - yet meanwhile they plaster my groups with un-evadable missiles; what's up with that?? It doesn't appear to be due to platform/missile characteristics, 'cause it does the same thing when I switch sides - and get to use those other platforms... 4. I can't figure out how to attack a base that has associated AA sites: My air groups will attack only one element of the base group - then stubbornly refuse to attack the other elements - or even to repeat an attack on the first element... What do I need to do to deal with these multi-element bases? I am able to do pretty well in HCG, but in HCE, I can barely get my groups into action before they get roasted! What am I doing wrong? Thanks!

28. Add a 'bypass" method to the Set Sensors dialog sequence When reviewing or adjusting sensors settings where some or all have been set to "mixed", it is necessary to either cancel or cycle through the "mixed" settings dialog sequence for each type of sensor; when no changes are to be applied, this is unnecessary extra time and effort, so it would help if there was a way to bypass the dialogs where no changes are to be applied. A possible way to do this would be to have a "No Change" button on each root dialog in the sensors group. so that sensors that are not to be changed can simply be skipped over - rather than having to cancel the entire operation, or else having to cycle through each sensor set - even when no changes are needed. An additional (or alternative) display method would be a popup that shows the entire sensors configuration - including the cycling times for intermittant sensors - on a single display and/or data entry page, rather than the sequential pop-up dialogs. This would allow a quick overview/review of current settings, and also would allow only specific adjustments to be made at will - with no need to cycle through everything.

27. Add Return to Base and Set Course option buttons to "Awaiting Orders" dialogs When a group loses its contact, destroys its target, or otherwise completes its mission, a dialog box appears and reports the situation and that the group is now loitering while awaitng new orders. It would be helpful if those dialogs offered additional options allowing "Return to Base" (which would be equivalent to the automatic default action that a group would take in this situation in earlier versions of Harpoon), and "Set New Course" directly from the dialog. This is mainly to avoid the "interruptions" that occur otherwise, due to other events being "queued in" before new orders can be issued to the group. A logical implementation might be to put these options on the notification dialogs as additional "buttons".

26. Detection of aircraft, sonobouys by subs - to help with evasion measures Although I'm not familiar with the actual capabilities of various sub systems, my assumption is that at least some of the acoustic detection systems can detect and locate nearby sonobouys, and perhaps even nearby aircraft. If this could be modeled and displayed in the game, it would enhance the ability of the player (and of the AI) to take realistic measures to avoid - or to escape from - detection by these entities.

25. Log where ships, subs are sunk - for "after action reviews" A graphic (iconic), or at least a text log, of the positions where ships and subs were sunk - and maybe even where aircraft were downed - would be helpful for "after-action" analysis, and if available during game play, might be useful info for tactical purposes. Probably it would be wise to have an "on/off switch" for sunken ship icons - so they could be turned on and off at will - to avoid clutter and confusion when not needed. In fact, it would be great if the entire log of events during the game was written out to a text file for post-review. And, for that matter, it would be really cool if the entire game could be "played back" graphically - probably at fast speed - for analysis and review!

24. Visual cues for water depth Visual cues - such as color-coded "topology" - of water depth would be a nice enhancement, making it easier to lay out sub courses, etc.

23. Some means of more easily determining visibility conditions (daylight, weather, etc.) Because there are times when ambient visibility affects detection and/or targeting (such as night attack weapons, F-117 night-stealth a/c, etc.), it would be helpful to easily determine the current conditions of daylight, weather visibility, etc. at a given group's or target's location... so, my wish is for this capability to be implemented.

22. Outlines on base, group and unit icons - for better visibility on topo image maps The backgrounds on the satellite image maps often "camoflage" the game icons, due to contrast problems or other issues. To help alleviate this problem, it might help if the icons had narrow white or yellow outlines - or even an outline made of the "light" shade of the same color - so that contrast will be enhanced between the icons and any background color (because either the dark base color of the icons or the light outline color would contrast with whatever color the current background happens to be).

21. Better fuel info/management for air groups consisting of a/c having different fuel status When a group consists of aircraft "sub-types" that have differing fuel endurances, or when groups are joined and one sub-group has less fuel remaining than the other(s), it becomes essentially impossible to tell when the sub-group with the least fuel will run out - usually resulting in the loss of the a/c in that sub-group. Perhaps a solution would be to have some way to find out the individual fuel statuses of each sub-group. Relating to this is the matter of re-fueling such a combined group (which is frought with problems in general), but especially there is no control over which sub-group gets refueled first - which sometimes can affect whether a starved sub-group crashes or not - even though re-fueling has started. It would help to either have the ability to specifiy which sub-groups get re-fueled first - or at all (if there isn't enough re-fuel capacity to cover all of them). Perhaps the re-fueling algorithm accounts for some of this automatically, but my observations indicate that such situations are still problematic - and so perhaps there is a better way to mange these operations.

20. Better switching between Group and Unit windows In addition to the issues mentioned earlier about re-locating the view window when switching between the magnified ("unit" view) and the "normal" ("group" view) modes of the Group Map, I find the transition to be rather cumbersome in general... so my wish is for a smoother transition between the modes - perhaps using just one map window with a group/unit "viewing mode switch"... or at least a way to suppress the switch between Map Windows when changing magnification. There are also times when it would be helpful to maintain "group view" even at the higher magnifications - this is mainly when attempting to select groups which are in such close proximity that the mouse cannot distinquish between them in order to make the selection at the lower magnifications; perhaps a "Group/Unit mode switch" would help this situation as well.

19. More control over gunfire (start/stop/number of rounds to use, etc.) Although not often used, I find gunfire difficult to manage - particularly to cease it once started. It would be helpful to be able to stop it, and it also might be useful to be able to specify the number of rounds to fire in total - so as to limit the "waste" of ammo when total destruction of the target is not the desired effect.

18. A way for player's ships, subs, or planes to "auto-evade" torpedoes, missiles, enemy groups, etc. One of the big frustations for me when playing the game is that if one of my subs, ships, or even planes gets fired upon, there is little to do other than just "riding it out". I don't know whether "counter-measures" are simulated automatically for the player's side or not, but there is no indication that they occur - and there is no way that I know of to "manually" deploy them. About the only thing it seems that I can do to evade fire is to change the unit's group and speed. This "sort of" works for a/c groups who can go to afterburner - so I can use the "turn and burn" tactic with some success (assuming the a/c are far enough from the launch source when they do it). However, similar tactics are generally ineffective for ships and subs - due to their relative slowness, and due to my inability to "micro-manage" evasion maneuvers effectively via manual control. So, my wish would be for the ability to invoke computer or "Staff Assistant"-controlled "auto evasion" tactics - which would include simulated evasion maneuvers and deployment of counter-measures, etc. at reasonable times - along with a realistic simulation of their effectiveness - or not. At least this would be better than the current options of just taking the licks or else frantically trying to control the evasion process via manual control - often at the expense of taking attention away from concurrent events elsewhere. If nothing else, it would reduce the frustrating "deer-in-the-headlights" feeling of being unable to do anything.

17. Easier way to re-position map windows; also to "hold" window scroll position One issue that has been a frequent annoyance for me is the goofy way that the map windows behave when I try to scroll them: * The scroll bars don't seem to work properly at all times - specifically, dragging a scroll bar often will not move the window to the extremes of the map, and also often "jumps back" to some position other than where I dragged it to. * After I have painstakingly sized and positioned the map "window" for optimum viewing of an operation, it will spontaneously re-center itself when I do certain operations - like launching aircraft, setting a group's course, etc. This re-centering fouls up my view of the "theatre", so I need to "fix" the view each time; also, it's often the case that the original viewing position is what is really needed in order to set a full course, anyway. * Since I "overlay" my Group and Unit maps, when I change the zoom from anything greater than 8x back to anything less than 16x, it re-focuses on the Group Map (which is OK), but also positions the "viewing window" at some nonsense location, making it difficult to "find my way back" to what I was lookng at previously. Anyway, a fix for these undesirable behaviors is my wish, for example, possible improvements would be: * Make the map scoll bars work properly - so they permit scrolling the window to the extremes of the map - and so the viewing window stays put once positioned with the scroll bars; or * Make a facility to "grab and drag" the map in order to position the viewing window on the map. * Make a means to click a spot on the map and have the viewing window center on that spot. * Have a way to quickly zoom the view - like maybe a Shift-click, or a Tab-left/Tab-right for zoom-in/-out - while remaining centered on the current spot. * Have a way to "tack" the view - so that it doesn't auto-re-center when course commands (and others) are issued. * Fix the transition from magnified view (i.e. - "unit view" - greater than 8x) back to normal view (i.e. - "Group View" - less than 16x) on the Group Display so that if remains focused on the same spot on the map.

16. "Mouse-hover" pop-up information displays, and context menus - for various informational puposes This wish may involve rather broad changes - but also would offer quite broad benefits. It would be nice to have two "informational" facilities that are accessible via specific unit/group/base icons on the maps: 1. A "mouse-hover" info display that appears when the mouse is "hovered" over any icon on any map, and 2. A right-click context menu accessible by right-clicking on any icon on any map The "mouse-hover" display would open an info display, probably showing what is typically displayed for the particular group/unit/base in the information window, but would be quicker/easier to use this way. Also, the info could be expanded a bit, for example, an aircraft group's "hover display" might include its speed, altitude, beginning and remaining number of a/c of each specific type/loadout in the group, weapons and fuel remaining, sensors state, whether detected or not, and by what, the group's target, time-to-target, whether it is currently targeted by missiles, etc. and might include additional info such as the Weather Report. Other icons would produce similar displays, but of the information that is relevent to the entity represented by the icon. (Note: It might be useful to have the Weather Report pop up when the mouse is hovered over any spot on the map (icon or not) - although the implementation and use of this feature might be problematic). The right-click context menu would have options to open any of several logically-grouped info/status displays relevent to the group, that might be more specific and more concise than the general "mouse-hover display" - such as weapons status, fuel info, weather report, etc. - as well as relevent command/orders dialogs - such as course/speed setting, attack orders, join/split group, etc. etc. Although the "mouse-hover display" and "right-click context menu" would essentially duplicate info and command options that are accessible by other means, they would be more readily accessible and more easily used this way - and could even be organized to contain more of the status details in a "one-stop shopping" display.

15. Easier way to specify number of weapons to fire, number of aircraft to launch, etc. Occasionally, the default number of weapons to allocate, aircraft to launch, etc. that is offered in the respective dialog boxes differs quite a bit from the desired number - for example, a flight of six B-52s with CALCMs may default to 120 weapons to fire at a target, while only 20 are desired... or if there are 20 F/A-18Cs ready and you want to ferry 4 of them to another base, the dialog will default to all 20... In these situations, it is difficult to "de-select" the unwanted number of weapons, planes, etc. since it is necessary to manually "click down" each unwanted item, making it tedious and time-consuming to change these numbers - especially when large changes are needed. Instead, it would be helpful if there was an easier way to change the quantities - like perhaps editing the number in place, or having a "run-up/-down" operation by holding down the up/down arrows on the quantiy fields, etc.