Joe K

FWIW, when I was using the term "near-miss" here, I was trying to describe the situation where the shot(s) came close enough to activate the animation display, yet did not score a hit - as opposed to a shot that didn't even come close enough to activate the animation. Is there a more conventional term or terms to use to describe these "almost hits" versus the "not even close" shots?

Speaking of the animation and hit calculation, there is another thing that I've always wondered about, but never really figured out: After a ship has been hit and damaged enough that it is sinking, or at least on fire and presumably heavily damaged, during an attack, it often happens that many separate subsequent missile animations pop up for that same ship - even when all incoming missiles were fired in the same volley and were targeted at other ships in the group. This seems to have (or produce) the undesirable effect that a bunch of additional missiles (more than originally targeted on that ship) get wasted on a sinking target, instead of going against their other intended targets. So, I'm wondering what is actually going on here, and I suspected a couple of possibilities, and am curious if any are correct: 1. The fire on the ship somehow confuses the targeting of the remaining missiles or torpedos, and "attracts" them to that sinking ship, diverting them from their intended targets... or... 2. The AI is smart enough that it does not intercept incoming missiles that are targeting an already-sinking ship, and thus a whole lot more missiles get through to hit the ship than would normally be the case (although this does not explain having more missile hits being animated than the number of missiles actually targeted on that ship in the first place). Anyway, if a sinking or on-fire ship really does divert missiles and torpedos from other targets in the simulation, then I need to account for that in some way. The Catch-22 is that the obvious ploy of targeting fewer ships in a volley and/or just sending in fewer missiles, means that the volley will be less likely to overwhelm the defenses (read, more likely to get defeated). So, what's a weapons guy to do?

It certainly isn't useless, because I use it regularly with success. But it is (of course) less accurate than having a solid fix on the target. The point you must understand here is that the bearing to the uncertain target (the target that lies in an uncertainty zone) must usually lie between the Shooter and the target, and not necessarily between the friendly Detector and the target. If the shooter and the detector are one and the same, then great, its not usually a problem. If the shooter lies behind the detector, or even in front of it, and you can draw a straight line that connects all three, then you're still ok. But if the shooter and the detector are separate platforms, and have separate, widely spaced bearings to the same target, then it is pointless for the shooter to try and exploit the bearing being picked up by the detector. Let me know if this is becoming clear, otherwise I will try and illustrate with screenshots. Yes, I'm with you on all that. My (unspoken) assumption was that, in the case in question here, the shooter was the detector (because all the uncertainty zones seemed to be pointing at the shooter group - albeit they were small and thus might have been a bit deceptive). In considering the larger picture, there were other groups around the general area that could have been getting some sort of detection on those AD units - including Hawkeyes, TARPS, at least one EA-6B, and a couple groups of A-6Es - although all of those groups were significantly further away, and arrayed at assorted bearings relative to the targets. I did that specifically in attempts to get a fix on the targets, but did I shoot myself in the foot (almost literally) by having them there and trying (out of frustration at not getting a fix) to launch anyway - causing a bearing-only launch? I mean, would these other detectors have somehow influenced the shot in a negative way? If so, it sort of defeats the purpose... BTW/FWIW, I believe I mentioned that I've tried fix-less shots numerous other times, and as far as I can recall, I have never gotten a hit without having a fix, regardless of how small or narrow the uncertainty zone, nor where I set the activation distance. From my perspective, that makes it useless - or futile, or whatever. One thing that I don't know is whether the SLAMs in this case are capable of BOL; another thing I don't know is whether the activation distance dialog is offered for weapons that are not BOL-capable. (I would hope not, but...???)

I thought were were trying to find out whether my game-saves exhibit the same behavior on other platforms... and because apparently they can be run only on the Demo, I figured it would be useful to try those games-saves in the Demo on as many machines as I can get my hands on. (I thought we discussed doing this, previously? )

Gee, I thought that had become a foregone conclusion... that goes without saying. Seriously, I don't want to add fuel to the notion that it only happens on my machine.

It's been quite some time since I touched the Scenario Editor, and a question came up but I can't recall the answer: Is it possible to have an air strike in-progress or at least imminent at the start of a scenario... or do all air attacks have to be launched from a base? In other words, is it possible to set it up so that the player will be under attack as soon as he starts playing the scenario, or will there always be the time required for the AI to launch a strike from a base and travel to the attack position?

You should try playing that scenario on my machine... the blasted things are darned near impervious here. Can't kill 'em... half the time, can't even see 'em! Interestingly enough, the other types of AI a/c (F-15K, Rafale, Golden Dragon?) in that scenario aren't nearly as tough to shoot here. But the F-16s? I might as well knock ping-pong balls at them... at least I can out-run 'em (well, most of the time)!

In trying to get a handle on this relative detectability issue, I have a few hypothetical cases, and since I can't create test scenarios for them (yet), I'm hoping someone can shed light on what should happen in these situations: Case 1: A player's base and an AI base exist, say, 400 nm apart - or whatever distance places them beyond each other's air radar range. A MiG-21 is loitering directly above one base and an E-2C is loitering directly above the other base. Both planes are at high altitude, and neither have any radar active. Both bases have active radar. There are no other groups "in play". The questions are, who sees what? 1. Is the E-2C detected by the other base? Why? 2. Is the MiG-21 detected by the other base? Why? 3. Is either plane detected by the other plane? Why? 4. Is either base detected by the other plane? Why? 5. Is either base detected by the other base? Why? 6. Do any of these detections differ depending on which base/plane is on the AI's side and which is on the player's side? Why? Case 2a: Two plane groups of opposing sides are within engagement range. One group is a pair of MiG-21s. The other group is a pair of F-4's. Neither group has (or had) its radar active. Both are at cruise speed, Low altitude, and generally facing each other. There is only one base for each side, and the engagement area is beyond the range of either side's ground radar, and there are no AEW, EW, or other airborne assets on either side. The detectability questions in this case are: 1. Is either group detected by the other? How, why, and who first? 2. If one or both groups were loitering, would that change the detectabilities? How and why? 3. If the groups were not at the same altitude, would that alter the detectabilities? How and why? 4. If one or both groups changed direction, would that alter the detectabilities? How and why? 5. Would a different speed of either group affect its detectability? How and why? 6. Would a different altitude of either group affect its detectabilty? How and why? 7. Do any of these detections differ depending on which plane group is on the AI's side and which is on the player's side? Why? Case 2b: Same as Case 2a, except the two plane groups are pairs of F-15Cs. Same questions. Case 2c: Same as Cases 2a&b, except the four planes are all MiG-17s. Same questions. I have my own assumptions about each case, but my assumptions regarding detectability have been seriously brought into question of late, so I'd like to know what is supposed to happen in these situations, and why. (Note: I'm not seeking a detailed numerical analysis here, but rather just wanting to know what is the normally expected detectability in each situation, along with brief explanations, where applicable). I'll compare these to my actual observations, in various similar situations. Thanks.

I'm curious whether having multiple torpedoes in the water concurrently has any effect on the probability of any of them getting a hit. The reason I ask is that I've noticed that if I have multiple ASW assets attacking an AI sub and they launch torpedos before previous torpedos have hit or expired - or even just one platform, if it fires multiple times before its first shot hits or expires - then none of the torpedos will ever hit, and rarely even achieve near-misses. In comparison, if I deny further shots until the current shot is "done", then I see a noticably higher rate of hits and near-misses. So, I'm wondering if having excess torpedos running around somehow decreases all of their probabilities of hit - or if there is some other reason involved. It also raises the question of whether counter-firing torpedoes would be a defensive strategy, by virtue of reducing the PH of incoming torpedos - at least in the context of the game, where there are -to my knowledge- no other counter-measures available to the player. By the way, a couple of semi-related questions about terminology: 1. What is the display called that comes up in place of the Report Window and provides an animation of missiles or torpedos reaching a target ship or sub, and either hitting or destructing in the vicinity. A further aside: Does that display indicate in any way whether misses are due to being shot down by point defenses or due to being spoofed or simply missing? I've read discussions where people seemed to be distinguishing between those cases, and so I'm curious how they can tell the difference. 2. What is the conventional meaning of the term "near-miss"? I've seen it used in contexts where it seemed to mean, "a hit that almost missed" (i.e. - "nearly a miss"), and alternatively, "a miss that was near enough that it caused some damage" (i.e. - a miss that was very close to being a hit). My own understanding was the latter meaning, but... ?

Then obviously you did not fully grasp what was being said, because the issue is exactly the same. Not only should the uncertainty polygon or 'window' be narrow, but you must also shoot down its length. In other words, down the line of bearing. Then you must be saying that it is not possible to "shoot down its length" using the abbreviated bearing-only launch dialog? If so, then it goes back to my original premise that using that dialog is worthless... making me wonder why it is even provided. It was "goofy" because you weren't shooting down the line of bearing. In other words, if your shooter doesn't have matched bearings, your missile will be launched (and will seek) in the completely wrong direction, as you witnessed. I really don't want to have to produce screenshots of this, but if you really aren't getting it, I suppose I will have to. Screenshots aren't necessary... but perhaps an explanation of how to "shoot down the line of bearing" or how to obtain "matched bearings" when using the abbreviated bearing-only dialog would be of help. Keep in mind that I'm not referring to the full B-key BOL procedure here, but rather to the dialog(s) that appear(s) right after the weapons allocation dialog in the cases where a target(s) is (are) not fixed.

Thanks for the info. I had no idea that it was even possible to launch a "package" that could accomplish multiple re-fuelings! (I always had to pre-deploy the tankers separately, and remember to join them up at the appropriate times - often with unhappy results. ) I'll have to try that sometime when I have some "free time" to play around... That's why I lobby for some more "automatic" features for re-fueling - such as automatic vectoring of tankers to groups, a la fighter intercepts. I often suffer more losses from re-fueling SNAFUs than from enemy action - simply due to all the micro-managing that it demands at times when my attention is diverted to other pressing matters, such as air engagements and/or other battles.

While testing my game-saves for Middleweights, I encountered a group of Rafales, so I played along - even though they were not part of the test in question. Anyway, it made me recall a tactic that I had used successfully against them before: I'd bring two or more pairs of F-15s w/AIM-120s to engage the Rafales. The first group in would run in at Low altitude with ABs on, launch a volley ASAP (to draw return fire), turn away, and go to max AB to escape the Rafales' missiles, and maybe even fire a second volley in order to draw more return fire. If this didn't exhaust the Rafales' long-range missiles, I'd either bring in another pair of F-15s for a similar maneuver, or if I didn't have a third pair of F-15s around, then I'd "buzz" the Rafales with the first group, and burn out, in hopes of getting them to use more of their long-range missiles. Once they'd burned thier long-range stingers, I could bring in the other (still armed) pair of F-15s and nail the Rafales, because the AIM-120s slightly out-range the Rafale's secondary missiles... and the Rafales did not seem to have much in the way of counter-measures against the AIM-120s (unlike the impervious F-16s seemed to).

This was explained earlier in the thread. See posts #32 and #33. Unless you're shooting down the line of bearing, your efforts are wasted. Not with you here. #32 and #33 dealt with the question of the "narrowness" of the uncertainty window along the bearing line. In this case, I believe those criteria were well met, because the uncertainty diamonds were tiny - barely larger than the icons themselves - so not only was the bearing well-constrained, the distance to target was as well. Despite that, a good share of the missiles flew more or less perpendicular to the bearing line (in other words, not even close to the uncertainty areas), and some even flew in the opposite direction, roughly along the bearing line, but away from the target (i.e. - behind the launch group). It was all rather goofy. Note: Probably most of the missiles did fly along the bearing lines towards the targets, but invariably overflew the targets and died. This is "normal" behavior (for the game); the missiles that flew off in grossly different directions were not "normal".

OK, so there should be no conflicts to worry about goofing up results. (I'm hoping to get one system that is as close as possible to my own configuration, in order to -hopefully- get comparable results). A couple other questions that I didn't ask before: First, my friend mentioned that he got some sort of message while installing HUE on his primary machine about the system not having enough resources to support HUE, but it went ahead and installed the stuff, and he apparently isn't having any issues with HCE on there. He guessed that the message may have applied to some other game in the UE, but it raises some concerns - especially considering that the older test machine we will use is a "lesser" machine than his primary one. Second, he has under his auspices, but not under his ownership, a Windows 7 sub-notebook system. So, I'm wondering if it is "legal" to install a copy of his HUE's HCE component on that system. I'm also wondering whether it's even worth bothering with trying to test the demo on that one, seeing it's a different OS than my own installation. What do you think?

Getting back to the BOL stuff, I was playing The Backyard and trying to neutralize the attached AD sites on the AI base out on the Peninsula, and they were apparently turning their radars off because even though the base showed radar range circles (which I assume means that some radar is active for the base or its attachments), I could not get release for any HARMs against any of the elements of that base, and all the attached units showed only as small areas of uncertainty, with no fixes. So, I was trying to deal with them using SLAMs, but of course could not get any fixes to shoot at. I finally tried some shots using the "automatic" bearing-only dialog, and got some really weird results (although I beleive I have seen similar things occasionally in the past). Anyway, none of the SLAMs would ever get any hits, but the wierd part is some of the missiles went off on perpendicular paths leading nowhere, and some even went in the opposite direction from where their targets were! Not much use in trying that mode of BOL, I guess!! I mean, the missiles were quite literally flying all over the place - except where their targets were.

Correct ... Good questions OK, we had a bit of "fun" resurrecting an old XP computer for testing use, but after some rather extensive horsing around, it appears to be alive and well now, and we're about ready to try installing Harpoon on it. Before proceeding, I just wanted to check a few things - to avoid any potential SNAFUs in regards to getting accurate behavior: 1. I think this old machine had some verison of Harpoon on it previously, although it's not showing in the Add/Remove programs list. Is there any "clean-up" that we'd be wise to do before installing HUE and HCE Demo - to be sure there are no problems with "residuals", conflicts, or whatever? Or any general clean-up or "preventive maintenance" that may be wise to do first? If so, what? 2. Are there any minimum system requirements that may be an issue for HUE's HCE or the HCE demos? 3. Does it make any difference whether we install the HCE part of HUE, or the Demo, first? If so, then which should be put in first? 4. If I recall correctly, when I first started using the Demo version, it had a sequence of installers early on, where updates built upon pre-existing installations of earlier versions. I went through that process, and that raises a couple of questions: First, is any part of that sequence of installers still required? If so, what? Second, if the sequence is no longer required, is there any reason to believe that I might not get an apples-to-apples comparison between the new "single" installation, and my other installation that involved a progression of earlier versions? (If so, do you have any advice as far as how to get it set up properly for valid comparisons between machines?) 5. Are there any special considerations to avoid conflicts between working directories and files for HCE and HCE Demo - or will the default installation locations handle all that without overlap or conflict? 6. Is there anything else that I'll need to be careful of? Just wanting to plan ahead to minimize problems and maximize usefulness/validity... My plan is to install HCE Demo 2009.050, in order to compare directly against my primary Demo installation. then after seeing how that compares, I'll update to 052.

Hmmm... Well, is there any reasonable way to accomplish the command of re-fueling a group before it would happen automatically (by virtue of fuel remaining, I guess)? I have situations where I wish to re-fuel a group before their tanks are dry - for any of several reasons. I've been using ALT-R to do this... so perhaps I have been wasting fuel or otherwise fouling things up without realizing it. Apparently not... yet, anyway. Not sure how to access those, so maybe it's lurking somewhere waiting for me to find it?

Maybe that file isn't useful anyway. I was looking at mine and I see that it is dated way back the first of March (as opposed to the ge.log, which is current-dated), so I'm not so sure when info is stored to that MessageLog file.

Sub is stationary, so that's not it. Message Log is gone, but it doesn't give that information anyway. MessageLog file gone, too? I'm not real familar with the message logging in regards to torpedo hits, but it reports a lot of stuff about missile hits and such, so I just assumed it would do the same for other hits.

Perhaps I misunderstood the purpose of ALT-R, then; I thought it was to order refueling to occur earlier than it would occur "automatically" (based on fuel remaining); I didn't realize that it would disrupt the actual refueling procedure... that's a real bummer! Good point... and actually I've attempted to use that occasionally, but it seemed like it wasn't always giving correct info. (I didn't do any testing of that, I just recall a few instances where the messages didn't seem just right, but I had other things to worry about at the time and so I didn't analyze it). In any case, it wouldn't have helped in my recent pickle - because the plane in question was already in flight and there were no others of that type at base to use for the work-around. Oh well, the whole situation arose from the fact that a tanker somehow got sent back to an out-of-range base after completing its refueling, and I didn't notice the error until the tanker had gone well beyond the point of no return. It so happened that there was another unused tanker in that area, so in desperation, I attempted to save the first one via re-fueling it from the other. But, all that accomplished was to waste the second tanker.

Only thing that I can speculate is that torps from the sub got it... and the sub and OHP had moved apart after the torps were launched, thus explaining the final "out of range" indication. It may be of use to open the MessageLog file (if you haven't over-written it already). It might tell what hit the OHP.

Well, I think that there are at the minimum miscommunications here. So I am trying to get to the bottom of it. But as long as we talk about generalities, then you and I can talk at each other forever, and there can never be any resolution. So we need to talk about very narrow issues, and then we should be able to figure out what is the basis of the miscommunication. The reason I keep talking about the Thanh Hoa Bridge scenario is because I have analyzed that scenario in detail. Not played, not played many times. Analyzed in detail. Take advantage of it. A specific example of what is at least a miscommunication is your statement that your airborne assets were outside the range of the Vietnamese radar. I can tell you definitely that they were not. So you and I are making incompatible statements. We could simply keep shouting these statements at each other. I will not. There is a clear and specific process for resolving this. If you wish to participate, then we will resolve it (and move on, and maybe you will stop losing planes to invisible enemies). If you refuse to participate, then it becomes clear that we do not have a simple miscommunication, but rather that you are deliberately miscommunicating. Harsh words, perhaps, but I never claimed to be a nice guy. Joe, I asked you 2 specific questions in my post 86, this thread (in bold). Please answer these questions. Unfortunately, the situations I'm trying to deal with appear to be general situations, not specific to the Bridge scenario... and in fact, not particularly well-demonstrated in that scenario - so it just seemed to me that trying to discuss them in that context was a bit futile. I would be happy to discuss issues specific to that Bridge scenario, but wouldn't it be better done in a thread that's dedicated to those particular issues, rather than muddying the other issues? For reference, it may be worth reiterating that my personal objective in re-playing that Bridge scenario recently were not to achieve its stated objectives, per se, without sustaining any losses, but rather to develop techniques for successfully destroying the ground AD units. I admit that I was rather miffed that the MiGs could waltz into my own front and side yards, and track down and kill my AEW and EW assets - and even some Phantoms - there, without ever being detected themselves until the last minute... and that the Phantoms were basically useless except for a limited amount of intimidation effect, forcing me to use A-7s as self-escorts for my attack groups (which actually worked relatively well, except that they could not detect the MiGs in a particularly timely manner, and thus were always in "reactive" or "counter-fire" mode). But all that was sort of off-topic in regards to the main issue of destroying the AD units. In any case, I cannot answer your two questions in any more detail than I already provided - because I'm relating that via memory of my past plays of that scenario (The last time I played it was perhaps a month or more ago). So, I can't give specific answers, but only general answers from my recollection... which, as I said before, is that the AI (Viet Namese) base radars showed a range of substantially less than 1/2 the distance between them and my Hawkeyes (which themselves were closer to the bases than was the carrier group. (This observation is based on the radar range circles, not any actual distance numbers, as I don't know how to determine those distances anyway, other than by referencing the radar range circles)). Because the range circles of the AI bases and my Hawkeyes did not even touch, and their respective range circles were roughly comparable, I saw that as indicating the distances between the AI bases and my aircraft as being a bit more than 2x the range of the AI bases' radars. Unfortunately, I'm unable to offer any more specific distances... because I simply don't know that detail. And, I'm not even sure what relevence the exact numbers may have. However, I can say that my aircraft were definitely at least 2x the distance indicated by the bases' radar range circles at the time in question, which to me, indicates they are well beyond the bases' radar range (or else the range circles are extremely misleading).

A Romulan warbird. Sounds a bit like the spontaneously self-destucting air groups that I encounter from time to time.

Two or three questions about refueling: 1. How is fuel allocated among differing a/c types in a common group during refueling? For example, if I have groups consisting of an EF-111 (Patrol) and some F-111s (GP), or an EA-6B (Patrol) and some A-6Es (Precis-2), or some other similar combinations where there is a member type that has a much shorter range than other type(s) in the group and the tanker that is re-fueling the group does not have enough fuel to top off all the members, then how is the fuel allocated among those group members? Do the shorter-ranged members get topped off, and the remaining fuel distributed among the others, or (preferrably) does the fuel get allocated so that all members of the group will have equal remaining range, or is there some other method of allocation? (I tend to have trouble using EW members with attack groups which require re-fueling because the shorter-ranged EW members tend to crash even though the group reports fuel remaining, and I'm not seeing any way to keep accurate tabs on the fuel status of all members of the group, so as to provide adequate re-fueling for all of the members). 2. Even though the situation is due to "operator error", why is it that if re-fueling is attempted on a non-refuelable type, the re-fueling appears to occur properly, and after separating the tanker, the tanker shows no refuel stores remaining, yet the allegedly-refueled unit(s) have not taken on any fuel? Seems a bit bogus... I'd think that when re-fueling was attempted, it would reject the attempt, and leave the fuel status quo - instead of depleting the tanker while not delivering any fuel to the target. (Apparently, the tanker simply dumps its fuel load in this case?) Anyway, it doesn't make much sense to me, so I'm wondering what's up with that. In a related matter, it would be helpful if there was somewhere during runtime that would tell whether an a/c type was capable of being re-fueled or not (short of making wasted trial attempts as described above). If that info is available during play, please let me know where to find it because I'm not seeing it. For instance, I was unpleasantly surprised to find out (too late) that KA-6s aren't refuelable; I just assumed they were since their other family members are. Dittos for some other types that I thought were refuelable in real life, but must be a different version in the game - or something. Anyway, is that info available anywhere during runtime? Thanks.

Now, this is going to sound wierd in light of all the problems that I've had with other a/c types in Middleweights (and considering that was one scenario where I found a lot of anomalies, this might just be another one), but: I had no particular problem with the Rafales as compared to the other types. The longer-ranged missiles were the biggest issue, but I regularly got ample detection of them via AEW, so I was able to avoid them... at least, none ever "snuck up" on me, so I assume that my side detected them all. I usually just avoided them when possible, or snuck up on them enough to lob some missiles at them and get them to back off, while bugging out right after missile launch. However, I was worried enough about those long-range missiles that I mounted attacks on their base, in an attempt to shut them down a bit... and with some success, although the trade-off in losses of attack planes might not have been much more than a wash.