Joe K

Please allow me to introduce myself ... I've been around for a long, long year Stole many a man's soul and faith ... Pleased to meet you Hope you guess my name (Sympathy for Mr. Grumble) Well, all I can say is if the Grumbles, et al, are actually so numerous and/or so effective in RL as what I see in the game, then I really don't see how the US forces could ever hope to crack that nut. And conversely, if in RL, US anti-missile defenses are as ineffective against incoming Soviet missiles as what I see when I play the game, then they'd better head for the hills! And lest someone say that it's all the fault of my tactics, may I remind that the player has no control over AAW operations, and at best can only try to deploy the screen effectively - which is of little help since the defenders don't shoot (much) at the incoming missiles in any case. Actually, there are things you can do ... Study this ... and I do mean STUDY http://www.matrixgames.com/forums/tm.asp?m=2032492 Always interested in good ideas...

True, this is not a ferry mission... but what of it? You are correct: That should have been stated as the reported mission-required range, not the separation distance. My bad; Sorry for the confusion. What are the numbers for this? I was figuring longer than that... In fact, when I calculated, I was getting a two-and-one-half hour round trip... er, well, up to the point where they ran out of gas; not for the complete round trip. I also assume that the re-fueling would commence before they reached target (although I don't recall any report of that either, but because those reports are relatively subtle, I would not be surprized if I missed that one - considering that I was not particularly looking for it). Believe me, I do understand why the slower tanker could cause the run-out condition, given the report that the game computes fuel consumption based on the throttle setting, not on the actual speed. I am not questioning the out-of-gas situation here; I'm only concerned about the tanker not splitting off. Two things that don't make sense to me in this: 1. Why would it take so long to do the re-fueling? (Are there numbers relating to this somewhere? If so, what are they - for future reference?) 2. Is it true that a tanker should not split off if the group is on a return-to-base leg? If so, it would explain some things about this - but, on the other hand, also would be inconsistent with my observations in other instances of similar situations - where the tankers do split off even on RTB legs. Are there some cases where they are supposed to split-off and others where they are not supposed to split-off? If so, what determines this? Are you sure? Sure of what? As I've mentioned, one reason I did that was simply convenience - as I got tired of having to fuss with so many little groups, when it (apparently) made no difference in the outcome either way. (Ironically, when I did not include the tanker, fuel was not an issue - even for these large groups). Another reason was that I sort of hoped - despite all indications to the contrary - that launching a massive number of missiles all at once might swamp the defenses and allow one or two to get through. (I should have known better... but I'll try "anything" once. )

I am not sure what you mean by the 'clock', but the 'randomizer' is not separate from the GE. Its built into the code, so if there were some problem with it, it should be repeatable in different computers. System clock... or "system time services"... or whatever you prefer to call it. The randomizing functions typically are provided by the programming language's "built-in libraries". Although I cannot speak to how Harpoon is designed, some of Tony's comments imply that it does indeed use the "canned" randomizing functions. That said, it is my understanding that the canned functions usually get incorporated into the executables, so you are correct as far as that portion being "built into" the executable code (although not into the source code). On the other hand, to the best of my knowledge, all such functions eventually make use of the system time services that are part of the host computer. Your "computer experts" may be able to correct this if it is wrong, but this is my understanding of the matter - and what I am basing my beliefs on.

If they don't work for you, but they work for others, what conclusion should be drawn? It seems apparent that the problem is not with the game, but rather, over there where you are. This is not aimed at you personally, so please don't take it that way, because honestly I would like to see your issues resolved in a permanent way, but is there any other way of describing it? I'd hope the conclusions would not be drawn until the facts support them. As far as I know, no conclusion in that matter is warranted at this point since the cause(s) is (are) not known/understood. The 'computer experts' around here tell me that this is highly implausible. I would tend to concur myself - except for the recently-developing evidence that I've been seeing here. Personally, I don't suspect code corruption - and mainly for the reasons you mentioned. Database or in-memory data corruption could be another matter, although the probabilities would favor a more random effect with this as well. A bug or flaw in the code should recur under the proper "environmental" conditions, so the probabilities would favor it showing up in at least a few different installations. I doubt it too, because the 'die rolls' are shown to go both ways, given enough tosses. Assuming there is no problem with the clock or randomizer in a given situation. Me too, because I rather dislike the suggestion that your own experiences are commonly found or are a characteristic of HCE, because they are most certainly are not. Understood. But please keep in mind that in most cases, I was questioning whether the things I noticed were typical or anomalies - rather than asserting that they were. I regret if my frustration over them came through in a way that indicated otherwise.

I really, really wish we could dispense with these misconceptions. As far as I'm concerned, HCE is a "slick" app... and I'm certainly not wanting it to do "everything" for you... and it doesn't require 'external knowledge' to play. That said, nothing there says that there may not be some rough edges that can be smoothed in order to improve it. As with any app that has evolved over the long term, there are inconsistencies that pop up - for various reasons - but with no particular reason why that can't -or shouldn't- be corrected (barring any bizzare situations where it would take an absolutely inordinate amount of effort to fix - and I don't think that is the case in most of these issues, given that other similar aspects work in better ways, leading to the conclusion that it would be fairly easy to bring them all to operate in the same way, using the desired mode as a pattern for the others). Regarding the "do everything" issue, I think that is an exaggeration. Let me put forth my "vision" about that: IMO, each operation that can be commanded should be able to complete pretty much autonomously if left unattended, albeit perhaps not with ideal or optimum outcomes in some cases. (This would simulate the real world where many people are involved and responsible for the proper outcome of the particular operation, and does not require nor necessarily benefit from, meddling by the commander. This would provide the aspect where the commander deals with strategy and can rely on subordinates to make it happen - within reason). The game already does this to a large extent... the only problems I see in this regard are the occasional situations where some gotcha pops up because something wasn't "covered" in the automatic side of things. My response to those who enjoy micro-managing everything, and wearing many hats within the command chain is simply this: What I'm suggesting does not preclude this micro-management mode in any way - nor would I desire it to! All I'm suggesting is that things ought to go fairly well even when no micro-managing is being done. Part of this is to simulate behaviors that a subordinate or pilot, etc. would reasonably be expected to do - rather than having some, well, just plain ridiculous things happen if the commander does not keep his thumbs in everything. I don't see this as being unreasonable nor restrictive in any way. (Please correct me if I'm wrong about this). Regarding external knowledge, I'd say that certainly is useful and helpful, but I don't see it as a requirement to play the game - nor do I think that it should be. I see no reason why the game should not serve double duty as a training environment (in fact, I thought that was what it did in some cases). I think the issue that came up about "external knowledge" had to do with weapons capabilities versus the GE-imposed limitations - or lack thereof - of their suitability and use for particular applications. From my own perspective, all I'd ask for here is what I think would be a valid simulation of real life where if a commander does something apparently wrong, an XO - or whoever - would likely give him a "heads-up" and/or a recommendation about it. In the game, the Staff Assistant sometimes serves this purpose, but other times, the SA just seems to sit back in the corner and snicker while he knows the commander is gonna screw something up. All I'm suggesting about this is to have, via the SA or whatever, the player be advised when he accidentally - or even due to incompetence - attempts to do something obviously wrong. Again the game already does this in many ways and instances, and all I'm suggesting is that it cover comparable situations in comparable ways by advising of potential errors and so forth. Again, I'm seeing this as a slight extension of the existing general mode of operation, not some big re-vamp - nor as harming the playability of the game in any way. Am I wrong? Hopefully, that clears up some of the wierd notions about my suggestions/requests/opinions regarding the game operation.

As am I. Then I'd surely appreciate it if you would not assert that I am also unaware of - and have not tried, or am unskilled in - those tactics. I readily admit the possibility that some such situation may exist, but - as you like to say - I'm not seeing any direct evidence of it, so I can't take it seriously. Yet, if it is true, then I'd certainly want to know about it. I'd say the jury is definitely still out regarding that aspect. At this point, it seems to be the most plausible explanation that I've seen. You mean like viruses, etc.? Or are you talking corrupted code or databases? Given past life experiences with computer-related stuff, I certainly wouldn't discount that possibility! But, I tend to doubt it in this case. The key word here may be "hopelessly". I do keep hoping that the reason(s) for this will be found, so that I can get back to enjoying the game as in years past. And yes, I really have been playing Harpoon for as long as I said... and yes, I do believe that there are some aspects where the AI and the player do not have parity (for reasons perhaps still not entirely known)... and I do occasionally throw up my hands and seriously consider going back to an older version of the game where things behaved more "normally" - but then I'd have to give up all the nice embellishments in the newer versions, too. And like any addict, I've become "hooked" on those. So perhaps the answer to your question is analogous to why an addict keeps on an addiction that in some ways is hurtful.

If things worked more consistently, it would avoid most need to keep both windows exposed concurrently. That is, one could "get away with" having the windows overlaid, with no particular difficulties as a result. In any case, I've yet to find a way to expose both (all) Windows, yet still have the Group Window large enough to cover the involved area while being magnified enough to actually distinguish individual groups when the action gets going. Consequently, I make the Group Window very large and overlay it on parts of the other Windows. That's what I was wondering... I don't know that I'd go that far, but there is some stuff that appears to be inconsitent with other similar operations... and may be relatively easy to make consistent. If so, it would help the situation a lot. I'd volunteer... but I doubt that I have the skills to do it.

Yeah, the difference being, it seems, that I like to play the game rather than have the game play itself for me. I must assume, then, that you deal with only a few engagements and other activities concurrently? No disasters happening around here. (Unless I'm just not paying attention). So inaccurate numbers only count when it's in regards to my examples? Its not a matter of not liking to do the math, but rather that I don't need to. ... I don't like to do the math on the fly, either... which is why I'd like the computer to do the mundane stuff for me. Or, I suppose, one could actually explore, try and develop some skills and tactics rather than repeating the same mistakes ad nauseum for years and years? You seem to keep missing the point that I have tried numerous different tactics - none of which had any greater effectiveness in general. So, perhaps you could share some of your wisdom in the matter?

The GE accounts for differing aircraft speeds by defaulting to the cruise speed of the lowest speed aircraft type in the group. The system is simple and works well. You, as commander, have to do some of the thinking, you know. That sort of thinking is what subordinates - or computers - are for. As I see it, the commander's thinking is in the nature of strategy - and maybe tactics. Number-crunching is for the accountants or the computers to take care of... and provide a summary for the commander to use in his planning. (IMO). Well, my whole point here is simply that if the fuel/range computation is going to be accurate, it should account for all of the affecting factors - otherwise, it's just confusing the issue (and leading to disasters). You say that you like to micro-mange, yet you don't like to do the math? Strange! Anyway, I don't have any problem with micro-managing, if that's your thing... but IME, micro-managing stuff like that has been a lot of trouble for no gain. (Now, if it did some good, then that'd be different...) But, that sort of leads to why I was doing 24-plane strike groups in the first place: Because the only way that I've found to "crack" an AI carrier group is to literally run it out of SAMs, it requires massive and repeated strikes. It's a whole lot easier to simply mount those strikes as a few large packages rather than a bunch of little ones! I think I mentioned that it was necessary to launch attacks by a total of 60 F/A-18s and 68 A-6Es (plus missiles from a SAG and a sub on the first iteration) a total of three different times before the first hit animation appeared for the AI's carrier group. (I ultimately launched these attacks eight times before finally killing the carrier group - of course that was after being down those 24 Navy F/A-18s). Not much micro-managing to be done when banging heads against walls like this! And before you say it, yes, I've tried many other tactics in these cases, most of which involved extensive micro-managing, including multi-axis attacks, use of assorted weapons, yada, yada, yada. The only thing that works is to simply run 'em out of SAMS, so why bother with all that other horsing around??

It is critical to match scenarios with the databases and battlesets that they use. Each scenario uploaded to HarpGamer should have the appropriate database listed on the same page where the scenario is posted for download. The available databases are likewise posted in the Downloads section of this website, appropriately enough called Databases. There are two files, one named the same as a stock file. So I would have to manually rename the original to play this scenario? Then remember to switch it back to play stock scenarios? And do this with tons of different combinations of scenarios and databases? ...I'll just stick with the stock scenarios:-) Harpoon is a great game, I'm not putting it down... But you need to clean that up. It's not that I don't understand what needs to be done, I've used computers since DOS 2.2 on a Franklin 1100... heck, I've even been the lead designer on a computer game for a major publisher. I'm just not willing to do all that for each user scenario I want to play. You REALLY need to clean that up so, at most, the player needs to put files into a single directory. You need to find some way of not having to manually back up and rename a file constantly to keep up with which scenario you are playing. I like Harpoon a lot, I used to be an SFB junkie so I like naval combat and this is one of the best naval combat games I know (Uncommon Valor is the only other naval computer game that compares too it). I still like Harpoon a lot, I'm just not even willing to go through all that at my age:-) You've put my feelings into words quite well. This monkeying with databases and so forth was something that I was never able to get working - granted, the fact that my first experience with it resulted in sort of "blowing up" my installation, and it had so severely scared me off of the whole matter that I did not even try to figure it out again. In any case, from my perspective, the whole mechanism relating to optional databases is a can of worms, and I'm with you: At my age, it just isn't worth the aggravation. Too bad, because I suspect there'd be a lot of enjoyment in using the other stuff - if I could get past that hurdle.

I don't believe tankers don't split after completing normal IFR, I've tested a lot of IFR flights and have not seen it. Ofcourse normal IFR might not complete in particular cases, each case has its own reason. If other occasions occur then get back to us with the specifics, it is useless just talking in generalities when there is no known problem. Don Well, my whole intent when bringing this up was to see whether this "generality" was a known effect/problem - or if it is something that warrants the effort of investigation. Instead of answering that, people have embarked on "analyzing" the generality (or perhaps simply debunking my method used in the problematic example). Bottom line: I will be happy to try to provide "specifics", but only if it is an unknown issue - hence my question of whether there was a known explanation for these non-splits, before putting effort into trying to capture it. Actually, I think this basic misunderstanding of my intent has existed throughout the various issues that I've raised. That is, instead of "reading" my questions as, "What's up with this?", they were read as statements of, "This is really screwed up". I apologize if my frustration has come through such that my presentation has led to these misunderstandings of my intent.

The conditions of the situation were not properly stated. The numbers you gave appear to be internally self-contradictory. That is why you have not been given a clear response. But consider this: If you try to launch an IFR-capable plane beyond its range, you can't. If you include a tanker in the group, you can now launch. It's like removing the safety mechanism from a machine. Safety is now your personal responsibility. BTW, once you include the tanker in the group, you can then remove it, and your first plane will launch to a place it can't actually get to. Also ... see above. OK, seeing everyone wishes to continue beating on that particular example, let me say a couple of things about that - as there seems to be some misunderstanding: First, what numbers are self-contradictory, and how? Second, this specific situation did not involve launching a group beyond its un-refueled range. I thought that I mentioned it, but in case I didn't, the 24-plane primary group was allowed to launch without a tanker (per the dialog), but because it was a large group (with associated potential fuel-consuming delays), I added the only available tanker to the group, as sort of a safety precaution. I was not aware of - and therefore did not consider - that the slower cruise speed of the tanker would actually shorten the range of the other type of planes (Hornets) in the group. As it turns out, that was a mistake. But it was compounded by the tanker not splitting off from the group, and thus forcing the group to continue at slower speed, and thus further shortening its range. As an aside, it would be helpful to understand the factors that are figured into the launch dialog's decision as to whether the group has enough range (fuel?) to reach the requested target. Empirically, it appears that the calculation takes the number of aircraft into account (in other words, any fuel consumption due to form-up of a large group) because I've seen cases where it will not allow the launch of very large groups against targets that are somewhat less distant than the specificed (individual plane's?) range for the assigned loadout, yet decreasing the number of planes assigned will allow it to be launched (and without subsequent fuel problems). Apparently, it does not account for these effects of un-matched speeds of different types of aircraft in the group, though. (?) If so, IMO, this is a bit of a problem. I have also seen cases where adding a single tanker to a group still would not allow it to be launched as a strike mission, yet adding one or two additional tankers would then allow it to be launched. As a result, my assumption was that the launch dialog takes into consideration the amount of re-fuel available - even if it doesn't account for effects of unmatched speeds of group members. While on that subject, I've noticed that weapons range does not seem to be figured into the computation of adequate fuel. What I mean is that if a loadout gives, say, an 1168 nm range, and the weapon has, say, a 70 nm range, then theoretically, at least a single aircraft having this loadout could attack a target that was beyond its 1168 fuel range - due to the added distance of the weapon... but the dialog does not permit this launch. I have actually launched small groups of aircraft under these conditions and had them launch their weapons before they reached BINGO, so it looks like the theory holds true... and also looks like the dialog does not take the weapon range into account. Although not any tremendous problem, it does impose a rather inaccurate and confusing restriction on the launch criteria.

It is critical to match scenarios with the databases and battlesets that they use. Not intending this to be a provocative question, but just wondering: Would it be practical to automate the selection of the database when the scenario is loaded, or whenever - so as to avoid those sorts of confusion, and reduce or eliminate the possibility of error?

Not really a digression, because it was starting off from that foundation that led to your disaster. Heck, it takes about 12.5 minutes for that kind of a group (25x aircraft) to even launch and form up. One item I forgot to mention earlier was your admission that you weren't really paying attention. Well, in HC, as it has been from time immemorial (to borrow a phrase), tanking requires your attention as it is a prime example of where the player is expected to exercise micro management. It has always been that way. Large and unwieldy groups only aggravate the issue. I say it was a digression because the point here was that the usual split-off notification did not occur (and that's what I would normally key off of). I was not aware that it was necessary to pay attention to anything while awaiting the completion of IFR... but, if I do need to, then what do I need to be paying attention to during that time? (I mean, I don't know what information is provided that I could monitor, and I don't know what intervention I could make in any case, so...???) I readily concur that my specific 24-plane example was extreme, and I used it ony because it was the most recent case and so the details were fresh in my memory. It certainly wasn't the only example, and in hind-sight, probably not the best choice because it lead to a critique of my technique rather than discussion of the non-split-off issue. But, despite any issue with the merit of the composition of my group, I'm not following how that led to the non-split. Are you saying that a single KA-6 can not service up to 24 F/A-18s over a distance of about 2100 nm? I can understand the issue of the KA-6 slowing the group down and thus eventually running it out of fuel, but I don't see why it never completed the re-fueling, and split off (and thus would have allowed those Hornets to resume their normal cruise speed - which may or may not have allowed them to reach base, but at least would have gotten further). But I digress yet again... the crux is why the split-off didn't happen. I see this happen every so often where the tanker(s) does not ever split off (and it has happened with small groups, albeit without the loss of a/c as in my example). As I recall, it has usually shown up in connection with a ferrying operation, or with a group that is returning to base after a mission and the tanker was joined to the group sometime after the group had stated its return to base. I had always sort of dismissed this as possibly "normal" behavior, and my question was basically that: Are there circumstances where it is "normal" for (a) tanker(s) to stay with a group after finishing the IFR? If so, what determines that? As an aside, I certainly realize that refueling operations may involve micro-management - at least as far as getting tanking groups together with thirsty groups in a timely manner, and coaxing them to start the IFR - but I didn't realize there was much to be done once they had finally started IFR. But if further micro-management is required, then may I suggest that something ought to be done to reduce that level of involvement, because otherwise, it would effectively mean that one cannot carry on other game operations concurrently with re-fueling activity - which seems to me to be unreasonably restricting of game play.

Partly because of the way I position the various Windows on my display, I have run into some apparently inconsistent behavior relating to the Windows automatically switching focus, or auto-centering, or auto-panning, so I'm curious if there is a way to avoid these undesired aspects. First, regarding auto-focusing: To make my Group and Unit Windows as large as possible, I have overlayed ("tiled") those two Windows. Consequently, I've observed that when I have the Unit Window in front of the Group Window, and certain Staff Assistant dialogs or orders dialogs pop up that have a "Select" button on them, in some cases, clicking on "Select" will automatically bring the Group Window to the front, allowing me to see the "highlighted" (i.e. - selected) group... but on other dialogs, clicking the "Select" button does not bring the Group Window to the front, and since there is no way that I've found to manually swap the Group and Unit Windows while a dialog is up, in these cases, I can't see what group is being highlighted (on the Group Window), and as far as I can tell, it does not hightlight it on the Unit Window anyway. So, I'm wondering if all of these "Select" actions shouldn't bring the Group Window to the front in order to show the highlighted group - to be consistent, if nothing else. Also, is there any good work-around to see the highlighted group in the cases when it doesn't automatically focus the Group Window, in lieu of having all of the Select actions work alike? Second, regarding auto-centering of the view in the Group Window: In some cases at least, when a group gets "highlighted", the Group Window will auto-center on that group. (It's not clear to me whether this happens in all cases, or only if the Group is originally outside of the current viewing area at the time it gets "highlighted"; also, I don't use the Unit Window enough to say how things work in the Unit Window). Similarly, auto-centering of the viewed area occurs when launching an air patrol, and (IIRC) when setting waypoints in a course. Many times, this is desirable, but in a few instances, it would be better if the view on the Group Window would not shift automatically, so, that leads to my third question: Third, regarding keeping the Window view from "panning": I'm curious if there is some way to "lock" the view on the Group window. (I notice a "Lock" button on the Unit Window, although I'm not sure of its function, but the Group Window does not have a "Lock" button). I have a lot of trouble with the Group Window's view "self-panning" when I'd prefer it to stay put. This includes times when I have it magnified and positioned on an area of interest, and I attempt to launch an air patrol (which often causes the view to shift), or when I "highlight" a group in order to find it (which sometimes causes the view to auto-center on that group), or when I try to use the scrolling bars on the Window (and the view goes nuts), or when I move the cursor over the Window (and the view "self-pans"), or some other situations where the view may auto-adjust when I'd prefer it to say put. So, my question is whether there is some practical way to "lock" the view when I want to keep it in place for some reason. Thanks.

A technique I've only recently picked up for the situation when a lot is happening quickly is this: You get an assistants message with various information and execution options, remember while it is showing the game is paused. You make your decision on what to do (and think about what is likely to happen next). If your decision is to give orders to a group that is currently selected, or you can select that group from the message window then press and hold the appropriate keyboard 'F' key (eg F1 attack, F3 course edit) while you mouse click the 'select', 'continue' or '1:1' option in the staff message window. Keep the key board button down until you see that you are in the appropriate box for your desired orders. otherwise press and hold the ctrl alt P key combination (for 0 time compress) while mouse clicking the 'continue' etc. In 0 compression you can select your groups one by one and issue their orders, then go back to normal time (or what ever). Now if in that very second many things are happening you will have to go through all the staff messages before you get to your appropriate box to do what ever, but that is reality, you can't split a second and make time stand still while you issue orders, but this technique does let you split two seconds and issue as many orders as you like, one for the supreme commander and one for the pilot officer in his Hornet etc, or what ever. I'll have to tinker around with that, because I'm not quite sure I understand how that works... but certainly, if I could get it to go to 0 sec time compression while dealing with the Staff Assistant messages, that would help to alleviate the problem. In any case, the main problem with the flurry of Staff Assistant messages (that for some odd reason always seems to come up only when there is something critical needing to be dealt with - must one of Murphy's postulates ) is that it is necessary to gain control of (i.e. - select) the group in question before issuing it any orders - and this is prevented by the recurring SA pop-ups. The other thing that typically complicates things is that other groups often demand attention within the sequence of SA messages, and so focus must be shifted to those... only thing is, there may be no way of knowing which group was originally needing attention - because typically it does not report the group name, and a lot of the dialogs don't allow me to "highlight" the group involved, so by the time all the other fires have been fought, it can be a problem backtracking to the earlier group(s) that needed attention. Anyway, it typically becomes a can of worms. I guess my wish would be for a way to set aside the SA messages that require additional "manipulations", while reviewing and discarding the rest... or perhaps some way to sort or prioritize the advisories so they can be dealt with in an organized manner.

The main problem with that is the flurry of Staff Assistant advisories that typically pop up around that same time, effectively preventing the player from issuing any such "revised" orders... and thus allowing the attacking group(s) to fly merrily into harm's way before the player can get any control of them. Of course, this would not be such a problem if only one attacking group was involved, and nothing else was going on anywhere else in the game. Normally, that's not a luxury that's available, though. I guess, overall, I'd have to say that if the supreme commander is going to have to deal with all the various micro-managing of each group, then there ought to be provision to automatically handle some of these obvious "gotchas" on his behalf - as would be the case in RL, where subordinates would be responsible for keeping their assets out of trouble and carrying out the general orders. Or, alternatively, if the player "should" be wearing all the hats and micro-managing all these details himself, then there ought to be provisions in place that allow him opportunity to deal with all that stuff, rather than effectively denying him control at times. Just my two cents worth...

Well, after you knock off all the surface units, I suppose you could always use the cheat key to locate the remaining subs, and then go back to normal mode to try to hunt and kill them.

I wondered myself whether the relative speed was at issue, although I surmized that F/A-18s flying at 415 knots would consume less fuel than at 490 knots (in RL, anyway). As far as the game situation, I wonder whether it would be possible to avoid this by "micro-managing" the group's speed to 490 knots? (Of course, the whole point would have been moot if the tanker had split off when it was done re-fueling... and it seems unlikely that it would have taken all that time to refuel even 24 Hornets... so that part is a puzzle). I didn't dare split the tanker manually after the attack because I wasn't sure whether it was actually finished with the re-fueling. (Is there some way to tell?)

Two observations: 1. Your aircraft groups are probably too large and unwieldy to be useful. 2. A single KA-6D has very little fuel to offer to a group of 24x recipients. 1. Perhaps. Unfortunately, it's also rather unwieldy to manage "coordinated" attacks by 68 A-6Es, 60 F/A-18s coming from two bases, along with a sub and a SAG, if I use "normal"-sized groups. Also, I was hoping to "swamp" the target carrier group with Harpoons, seeing it would easily dispatch those missiles when launched from smaller groups. As it was, it took three attacks by this entire huge "package" before any Harpoons even reached the hit animation stage. I guess I tire easily of launching and managing them in smaller groups. 2. True. But, as I said, I added the tanker thinking it was "insurance" - in case a lot of the fuel range was used up by launching the large group. Actually, it would have allowed me to launch the group without the tanker, because the target was within range, albeit only minimally. So, it appears that I shot myself in the foot by including the tanker. But, we digress... The real points of the example were the questions of why tankers sometimes don't try to separate on their own after refueling is done, and why including the tanker actually made the fuel situation worse.

Are there cases where a tanker or tankers are not supposed to break off after completing re-fueling? I'm curious because most times, after completion of re-fueling, a dialog will appear asking whether to separate the tankers from the group... but sometimes, this dialog does not occur, and the tanker(s) remain attached to the group. I'm wondering whether this is a normal occurance, due to some special circumstances, or if it may be a bug that I should attempt to capture? I've had this happen every so often, but I don't see any particular difference from the cases where the tanker-separation dialog does appear, so I'm curious what may be the reason for this. (Incidentally, in the cases where the separation dialog hasn't appeared, it has usually resulted in the eventual loss of the re-fueled group, due to running out of fuel - even though there should have been plenty of fuel after the re-fueling. This may imply that the re-fueling actually never took place - even though the report window showed that the tanker no longer had re-fueling stores). For example, yesterday, I lost 24 F/A-18s after launching them, along with a KA-6 tanker, at a carrier group that was nearly at the limit of their un-refueled range (I think the numbers were 1168 nm range, and 1026 sepration between the carrier groups). So, I threw in my only tanker "just to be safe". However, as the group reached its attack point, I noticed that the tanker was still attached, yet the report showed that it had no re-fuel stores. The group completed its attack and turned back but the tanker remained attached. The fuel range circle indicated at that time that there was still enough fuel to reach base. I then became distracted by other engagements, and next thing I knew, there was a report of 24 F/A-18s running out of fuel and crashing - about 150 nm from their carrier. So, apparently, including the tanker didn't ensure there was enough fuel. I wonder whether the re-fueling process was interrupted by the attack itself, although the group report already showed no re-fuel stores awhile before the weapons launch point, so...??? Oddly enough, I had launched my other 24 F/A-18s at the same target shortly after the large group, but in two groups of 12 planes each, with no tankers... and those groups got back with plenty of of fuel to spare, despite not being re-fueled at all. Rather puzzling. Anyway, if this is normal behavior, please explain what's going on (so I can avoid getting myself into trouble in the future)... or let me know if it's not normal, and I'll try to capture an example situation for examination. Thanks.

This probably is two separate questions, but they are sort of opposite sides of the same coin, so: I've noticed from time to time that when I have a strike group attacking a base or surface target that consists of multiple units, if one of the units gets destroyed, the attacking group will "lose" its target and go to loiter - instead of continuing to attack other surface/ground units in the target group. I must then re-initiate the attack. Is this normal? Am I doing something wrong? A recent example of this was that I wanted to pick off the helos in an AI carrier group - to prevent it from detecting and destroying my nearby SAG. So, I launched several separate pairs of F-14s to "plink" the numerous helos in that carrier group. The F-14 groups were spaced apart, and when the first attacked and killed the first helo, it stopped attacking, followed quickly by all the other F-14 groups breaking off the attack and going to loiter. I re-initiated all the F-14 groups to attack, and the sequence repeated each time a helo was killed. I've seen similar behavior in the past when attacking ships in a formation, or attacking a base with attached ground targets, where the attacking group(s) will break off the attack and go to loiter whenever a unit of the target group gets destroyed. This doesn't seem right of its own accord, but is especially puzzling in view of this other converse, and much more undesirable, behavior: When an air group is ordered to attack surface units of an AI group that has both air and surface units, and the attacking air group has both ATA and stand-off ATG weapons, the attacking group will continue moving towards the target (without notification) even after it has launched all of its ATG weapons. I believe the attacking group is continuing in an attempt to engage the air targets in these cases - even though no ATA attack has been ordered or authorized. This usually results in disaster by exposing the attacking group to SAMs. Related to this, I've noticed at times that when an air group that has ATA and stand-off ATG weapons is ordered to launch a surface attack against an AI group that includes both air and surface targets, the dialog asking whether to attack air or surface targets will appear prior to launch... and then appear again after launch. Is this double dialog somehow causing the undesired effect - even though I may choose surface attack on each instance of the dialog? Also, is there some reason for having the dialog repeated? (It seems to be simply redundant - and consequently somewhat annoying - but... ???) So my question is why these attack behaviors occur, because they aren't a desirable behavior in either case (IMO), and they also seem to be inconsistent with each other - that is, in one case, the attack stops after each target unit is destroyed, but in the other case, the attack continues regardless of whether (a) target unit(s) is (are) destroyed. Is this normal behavior? (If so, I have a wish list item or two)... or am I just doing something incorrectly when initiating these attacks? Thanks.

One would typically use the newest. Yeah.. just checking because it sounded like there was something "special" about the 052 iteration as far as the testing effort.

Well, I tried to reply to the several questions asked or implied in response to my submitted info, but after previewing my reply, it would not allow me to post my reply (saying I have no permission to post to this topic) - even though it showed I was still logged in. So, I tried to copy the text of my reply and then logged out and back in and tried to paste it into a new reply - but the text is no longer available to paste... Ugh! Anyway, I don't time now to re-type all of that, so I guess it's lost... and I'm not sure I recalled all of the questions anyway. If there is anything in particular that I need to address, let me know and I'll try again later.

Have you got something else radiating nearby? Might the enemy be investigating that, and just tripping over your Hawkeye? If this is for something other than the Viet Nam Bridge scenario, might the hostile fighters be checking out a sonar detection of your CV, and again just running into the Hawkeye by accident? (And of course, this is probably another one of those cases where you'll be told that a saved game would be useful ... ) Nope, nothing else. Also, apparently not the case anyway, because examination of the targets of those intereceptors showed they were specifically going after the Hawkeyes.