Joe K

Not much "new" and interesting to report today. Ran the game-saves on a second test machine, with pretty much similar results as on the first one (that is, no solid manifestation of the problems so far). I tried running a large scenario (specifically, The Backyard) on the first test machine (without closing the app entirely) to see if I could "prime the pump" as far as coaxing out some of the stuff, but subsequent runs of the game-saves still behaved the same there. I'm letting both test machines "simmer" for a couple of days with the app left open, although I don't hold much hope that doing so is going to change things there because not much else is really going on on those machines - they aren't even connected to the Internet, so there's not a lot going on to induce any virtual memory-shuffling, etc. But, we'll see... Also tried to create a couple scenarios on the HUE version, but everything looks cool with all the platforms that we tried there. I'm really not sure what I'm going to need to do to induce a problem there, since I have no good idea what circumstances may lead to the behaviors. I mean, I tried all the same platforms as the ones that exhibited in my Middleweights game-saves, but no joy there. And running the native scenarios don't seem to have any hint of the problem, either. So, this may be a bit of a project...

Didn't forget. Just still trying to compare apples to apples as much as possible - that is, the game-saves on the same version of the demo, but on different machines. BTW, I'm a bit confused about which version is the proper one to use now for your purposes (once I get to that point), that is, 052, 053, or 054?

Side question: What is your opinion of the Atari 800XL emulator?

I'm sorry but I can't find the thread where this stuff was taking place, so I'm starting a dedicated thread for discussing/reporting this special testing I'm tasked with. All runs here were using the 050 Demo. Initial test-runs on one new(er) computer, of my earlier games-saves that demonstated the issue of inability of player's AA missiles to acheive hits in some scenarios, has been a complete bust so far. If anything, the player's AAMs have seemed to be almost too effective, achieving infallible 100% hits. This is adding more confusion to the situation then it is resolving. Last night, I also tried running the THB scenario on that machine, because of the situation where the Sparrow missiles were showing a similar inability to achieve hits like the AIM-120s were failing in the Middleweights scenario that I had the game-saves for. That run also gave dramatically opposite effects, as the Sparrows were absolutely lethal against the MiGs in this run. On the other hand, some of the other issues (poor detections by Blue, and long-range detections/intercepts by Red, and sneak attacks by undetectable Red planes) did show up there in a similar manner as on my primary machine. So, now I have to try to sort all that out. As an aside, I played around with different patrol altitudes for the Hawkeyes in that run of THB, and found them to be quite a bit more effective at low altitude, as far as preventing the MiGs from sneaking into the area undetected, at least. I ended up putting one Hawkeye just East of the carrier, and flanked that with two other Hawkeyes at low altitude, north and southwest of the carrier by about 100 nm each, and closer to the Red bases. This kept them out of the range of the Red bases' radars, but seemed to make a whale of a difference as far as detecting the MiGs in the covered areas - which usually cruised in at Medium or Low altitude. The MiGs were still fairly close when they got detected, but far enough out that it was easy to intercept them (with those now-lethal Phantom II/Sparrow combos), or to get my other planes out of their way in time. Anyway, at this point, it's just another set of data points in the puzzle, awaiting untimate analysis. I'll try it on the other two machines when I can get up there, for additional comparative info; meanwhile, I'm going to run this installation awhile longer, to see what changes over time, if anything.

Well, I'll see what I can do... but I think I may look up a helmet before I stop by his place on that errand. And perhaps a face shield would be advisable, too.

..and I thought my first 286, with one whole meg of RAM (and whopping 20 meg HD) was hot stuff. That's what using old XTs to do remote database searching does to you I guess. Don Thomas 286? Whazzat? I got my preps for playing Harpoon by playing sub games on my Atari 800... and I thought that was cutting edge with a 5-1/4" floppy disk drive (instead of the cassette drive), and 64K of RAM. Well, at least I didn't have to program for an 8086 or Z80...

Pretty much the same here, alpha tester->beta tester->minor programmer->agh-everyone else bailed now I'm the programmer. I have written some good and elegant code for the game and much in my professional life but at heart I'm a hardware guy (as in resistors, capacitors, and transistors). But alas the need for hardware in small business was much less than software and integration so I adapted. I can relate to that!

Ah, good. Since radar range due to LoS (Earth's curvature effect) from high to ground is about 250 nm, we can now say that ESM could pick up the plane at about 275 nm. Add 25 nm for the attached ground units. Therefore, if the radiating Hawkeye at high altitude is within 300 nm of either Vietnamese base proper, then it will be detected by ESM. Further away, it is below the horizon. So, what's the deal when I park the Hawkeyes out there 300 nm or more, with their radars left OFF? I dunno, it seems a bit much to me, but I guess I wouldn't feel so bad if my side could also use blind ESM to do similarly effective intercepts at similar distances.

Geez... I wish I'd seen that before I did the test; it might've helped, in a few spots at least.

Unortunately, in my case your conclusion would be flawed - because I don't own a cell phone. Seriously. So I simply couldn't comply. Well, I hope it's useful, because I just spent six hours re-running THB, taking strategic screenshots - hopefully at the points that you needed - and noting the info that seemed to be relevent, and even a game-save... so, I sure hope it was worthwhile. Unfortunately, from my standpoint, it wasn't - because the blasted run refused to do the main thing that I was trying to capture - that is, that "early intercept" that I'd seen in the two previous test runs of THB. Anyway, what I had hoped to capture were these issues: 1. The early intercept of a Hawkeye, before it had even reached its fairly distant patrol position and turned on its radars. (This failed, as the MiG did not turn up this time; really not sure what I did differently, but...). 2. The apparent incredulous speed involved in that intercept in #1. (Also failed due to lack of MiG, but I did track other trips and found them to be generally right on, but a couple were somewhat off, albeit not extremely). 3. Ability of MiGs to sneak up on RA-5C, Phantom IIs, ships, etc. without being detected. (This was pretty successfully captured). 4. Inability of Phantoms to find the MiGs (without the MiGs using radar). (This was successful). 5. Inability of Sparrows to kill MiGs in that scenario. (This was sort of successful, although the Sparrows did manage to kill one MiG-17F). There were also some other assorted things that seemed odd to me, and I noted them in the text. In particular, Although the MiGs initially tried to intercept both of the Hawkeyes that I put up, later in the game, they ignored the one that was actually closer to both of the Red bases, and only kept at the more distant one. Seemed strange, but didn't really affect the demo. So, with that intro, I'm attaching a Zip that has 10 screenshots, one game-save, and a set of notes that I took, that also describe the screenshots. Enjoy! THB_Demo.zip

No, you cannot impact the AI's ESM capability and it cannot impact yours, ESM is there regardless. You should have experienced by now that radar on/off does not affect the same side's ESM. Just wanted to be sure. That means that the AI can still detect just about everything, even without its radars - as seemed to be the case that I was seeing.

Does anyone recall whether any of the "OEM" databases, going back at least to HC Gold, ever have had Phantom IIs with a loadout that had only the four Sparrows and no Sidewinders, as in the case of some of the early F-4 marks)? Thanks.

Just curious whether I can disable or degrade an AI group's ESM capability if I destroy its radar? Or does it have ESM regardless? Also, does the active/inactive state of the AI's radar affect its ESM capabilities? I'm speaking in terms of game action here, not RL. Thanks.

Well, the reason I mentioned that is because my "imaginary friend" seems to be kind of "getting into" this whole investigation thing. He is an app developer by trade, although I think he does it for firmware, mainly. Despite remaining rather p'ed-off over being outed, I'm sort of getting the feeling that he might be enticed to contribute - if things could be smoothed out somehow. I mean, he's played the game pretty much continuously since DOS days, as far as I know, and was sort of - well, a lot - excited back when he thought he might get in on the re-development - back before the, um, stuff hit the fan. So, I suspect there's still some repressed spirit lurking there. Only thing is, he's really time-challenged these days, so I don't know how much he could get into it. Anyway, just an idea, FWIW...

Many authors will try and build in some degree of randomness (did I really just use that word?) into their scenario so that the playability and potential enjoyment of the scenario can be stretched out over multiple tries. So that, in some way, the scenario is never exactly the same each time it is played. Back in the days of HC Gold, and before (when I had a Scenario Editor), I made a few scenarios for myself, and I used the variable starting points, alternative courses, conditionally-included units, and so forth quite extensively - to the point that I think I managed to crash the game a couple of times... at least a couple of the scenarios could not run beyond a certain point - which was rather distressing, considering all the work I'd put into them. Anyway, the point is, I was using the variable features extensively (perhaps too extensively) in order to provide some uncertainty when I played the scenarios myself. Otherwise, they were just too boring to play because I'd pretty much know everything that was going to happen. (Even worse than using the "cheat key"! )

Well, based on the rather unsuccessful attempts I've made in trying to be helpful, I'm not sure whether my skill set is going to be particularly useful. I'm not particularly knowledgeable about the RL aspects of the subject matter here... and apparently my written communication skills aren't so good... and I'm pretty burned-out as far as doing user support... and I'm not much of a programmer... so that doesn't leave much. On the other hand, I am (or was, when I was employed) recognized as having some "special" ability to induce prototypes to malfunction in ways that nobody else was able to do... consequently, I was often bridled with the job of beating the things up, to get them to cough up their latent bugs. But my "secret" there was that I simply used things in ways that nobody anticipated - and consequently hadn't been accounted for. As you may recall, I was involved at one point with some Beta testing of HCE. Not really sure how much good I did there because of limited time back then (when I was employed). Anyway, I take it that app development or maintenance isn't an area of particular need - as you didn't mention that here (despite all that earlier talk about being overworked)?

Well, I guess it's known that my ability to express myself is, um, lacking... What I had hoped to convey there was that my impression of what happened, plus my look at the estimated number of units on the red bases afterwards, lead me to the conclusion that my first run must have experienced the maximum possible numbers of bombers that were built into the scenario... and thus it was likely a worst-case situation, which itself might be a bit of an anomaly - well, unless the probabilities were such that they were likely include many units for most runs. Put another way, it was my impression that my first run involved having every probability-of-inclusion satisfied, and so I got swamped. Of course, it would also have to imply that the scenario launched all of those bombers at once - and I'm not sure if the Scenario Editor would allow that in regards to conditionally-included units. But anyway, they were like locusts that first time... The second run was no picnic either, yet there were noticably fewer missiles involved in that run. Anyway, the only real point of the anecdote was that my reaction to getting wiped out by swarms of missiles in the first five minutes or so of play was, "How in the heck did that happen??", and then, "How could you possibly survive - let alone win - this scenario?" Subsequent replay revealed a more managable set of circumstances... but right after that first run, I really did think that the game must've gone berserk somehow.

Hey... at least you have hair to hurt!

Perhaps the question here then becomes, what constitutes "competent" and "capable"... as well as what amount of time and effort would actually be demanded of such a "volunteer"? I mean, I am a volunteer firefighter, and it's getting to the point that government regulations and community demands for "completely professional capabilities" would almost literally consume all non-working, non-sleeping hours in the day, leaving no time at all for "discretionary" activities - you know, things like eating, commuting, taking care of family finances, interacting with the personal family, household chores, yada, yada, yada... In other words, pretty much like the way you guys describe the HCE efforts... In any case, that might be a bit much to expect... but the whole idea of having more hands is to lighten the workload, so if it really would involve (somewhat) less time commitment, then maybe some people will turn up.

We must have a very different definition of randomness, as I see the earlier offered example as being very well defined. Apparently... What I seem unable to convey is that there is a finite total number of units that could show up in any given run of the scenario, BUT for each particular run, the actual number available may differ, at random, based on which set of probabilities happen to be met in that instance. Depending on how the probabilities are calculated (that is, either one random percentage number tested against each of the probabilities, or a new random pecentage number tested for each individual probability), there may be different sets of possible overall outcomes, but the point is, in the example here, any particular run would always have at least 50 units and no more than 125, and the actual number would be determined by somehow applying a random value to the probability calculations in each run. Conversely, if there was indeed no random factor in the calculations, then all runs of the scenario would always have the same number of units included. But, then, perhaps my statistics are as corroded as my algebra...

Not meaning to step on anyone's toes here, and I hope I don't get it wrong, and anyway Tony has already answered this, but the point is that any money that comes in from game sales goes to the company that owns the game, and it's not going to the folks who are posting here. The hardcore posters are the ones who are actually developing this version of the game (for free). That's what I was attempting to speak to... to be explicit, I have to wonder why the company that makes the money from this is not poviding more resources to help with its development/maintenance. (I'm not seeking infomation about the actual relationships and financial agreements that may or may not exist; instead I'm simply stating that it is a puzzling situation). Beyond that, though, given the situation is as it is (that is, development by volunteer efforts), then considering there is more work than volunteers to do it, then the obvious question comes to mind of why are more volunteers not accepted into the project?

That's a good question, Victor. I don't recall offhand if there is a set maximum or a set formula, and as you know, the actual detection range varies according to the altitude and strength of the radar. Perhaps Tony can dig up that little tidbit for us. I was wondering if there was any maximum range of the ESM, too - because there might be situations where I sought to avoid ESM detections. If you're referring to bases, then I was actually assuming that the bases were the platfomrs that were utilizing ESM to detect my assets when I didn't expect it... and also caused me to wonder why my own side couldn't seem to manage that. Regarding detection in general, one thing that I didn't take into account were the effects of weather and daylight on visual detections... yet it still goes back to howcum they can see us when we can't see them (under the same ambient conditions, whatever those may be at the time). Seems to me it should be at least roughly comparable.

There is such a thing. It's called a screenshot. I have provided 2 in the "scenario creation" thread from exactly the relevant instant. Now you claim, Joe, that your AEW planes are constantly being jumped by stealthy enemy fighters. Fine. Next time it happens, lean back, stretch, press "print screen", dump it into Paint, save as a JPEG, and upload it here. Then do it again. This will not help for formally debugging the problem, but it will certainly help to convince everyone here that you are actually seeing this effect. Of course, after I have made this plain statement, if you do NOT provide such screenshots, then everyone here, realizing how easy it is to provide them, will be certain that you do not actually see such effects. No, a screenshot - or even a series of screenshots does not provide the play-back that I was thinking of. As far as screenshots providing any "evidence" necessary to convince anyone for or against this, I would debate the "weight" of that sort of "evidence" as being far less compelling than the game-saves I've already provided - albeit not for the sneak attacks situation. Since those were not believed, then I can't see this being believed, either. And lastly, how can it be logically contrued that if I fail to provide convincing screenshot(s), then that "proves" anything, one way or the other? At best (worst?), it might lead people to assume that I don't see the effects... but that has been the case since the outset, so nothing new there. Be that as it may, I'd ask what sort of screenshot is going to demonstrate what you seek here - that is to "convince" anyone that the situation happens even once, let alone regularly. I mean, seriously, what would it have to show in order to be "convincing" of this situation? Is it even possible to demonstrate that way? (I surely don't see how).

Just a quick status update for Tony: As I hear it, the entire HUE is now installed on his secondary machine. (Not sure why he did the whole thing, as I thought he was only going to put in the HCE parts, but...) He put the 2009.050 Demo on it first, so both are in place. When I can get up there again, I will try my game-saves on both the Demo and the HUE version, and report those results, and discuss any appropriate next steps based on those results. Meanwhile, I have the Demo 050 up on one of my other computers now and have been running the game-saves there. So far, these runs have not demonstrated the behaviors at all. That's not making me feel all warm and fuzzy, because even though they are known to take a bit of time on my primary machine before things start manifesting regularly, they've always demonstrated at least a hint of the problem early on... but in this case, they aren't acting up at all so far. I will try to replicate the conditions of the "delayed onset", to see if that produces anything. If not, then my only other test would be to try and replicate the system environment. Unfortunately, I won't be able to run all of the same apps on the second machine as are active on my primary machine because several of those are not installable on the second machine due to licensing or compatability issues... sooo... instead, I'll have to try taking my primary system down to running only the HCE Demo app, and see if that makes the behaviors disappear on my primary machine, too. Unfortunately, I don't have any way to provide a really equal system environment on these two machines - shoot, they're not even the same version of the OS. So, I'm not really sure how conclusive the results are going to be, anyway. I will report all relevent results as they become available.

This is essentially my position as well. Without tangible evidence - saved games, etc, whatever Tony (as the code guy) needs to look "under the hood" - continuing to flounder about in perceptions, observations, assumptions, and sometimes, I suspect, rather severe exaggerations or distortions of the facts (whether intentional or not), is just an exercise in wasting time and frustration. To the point that we probably annoy and aggravate one another when that is not at all intended. First off, I'm not stating that there is a "cheat" involved. BUT, there are certainly several situations where behavior seems to be unbalanced for some reason, and I'm frustrated that no explanation has been forthcoming that actually fits the situation and explains all the observations - the most maddening example may be the one I mentioned here about AI groups being regularly able to detect, track, target, and kill my air groups without ever using their radar, yet my air groups can't even find the AI air groups under the same conditions via radar, ESM, visual, or anything - unless those AI groups activate their radars. In and of itself, the reasons why the AI is able to do this still generally baffle me... but even if there really is a good explantion that I'm not grasping, it still perturbs the heck out of me that my own groups don't have somewhat comparable abilities. THAT is that aspect that is most annoying. In some scenarios, such as the Bridge, I quite literally feel like I'm sending blind men into battle with spitballs as weapons, against an enemy that possesses 22nd century capabilities... and that just makes no sense to me at all, given my understanding of the capabilities of the platforms involved. Please believe me when I say that I sorely wish that I could. But also please remember that I have submitted several game-saves which demonstrated various behaviors, and logs which I'm not really sure of the value of/need for, yet to my knowledge, nobody else saw the same behaviors using those game-saves, and the log info was summarily dismissed as not showing any anomalies (which I can't speak to because I don't fully understand the info that those are showing). Given that utter failure of my best efforts to provide satisfactory and reproducible "technical" evidence, I seem to be left with the only alternative of exploring stuff that might explain "operational" reasons for the apparently-inconsistent/incorrect behaviors that I frequently experience during play. I don't know what else to try. And I do very well understand the difficulty of trying to diagnose and repair problems via "telecommuting", without having detailed info nor being able to actually see and touch the problem (been there, done that... and pretty well tired of it, too. Now, I'm getting to see the "other side" of the coin, I suppose...) In fact, I'd love to be able to see what's going on when you run those game-saves - sort of the same problem from the opposite direction, I guess... The only "technical" options still possible -AFAIK- are to see if we can create something that will produce similar behaviors using the HUE installation, so that it will provide something easier to work with on your end. But before we even get out of the gate on that, I have two huge concerns about it: Since I don't have any good idea what may cause these behaviors, I'm shooting in the dark as far as trying to come up with something from scratch that will demonstate them... so it seems highly unlikely that we can induce those behaviors in HUE... and even if we can, then isn't it just as likely as the earlier games-saves were, to fail to reproduce on your end? (I mean, how will it be any different?) My best hope is that the previous game-saves will demonstrate the behaviors on HUE, right off... but then what? The only other thing that I can think of to try is to see whether I can make those games-saves demonstrate the same behavior on other machines in the Demo version, but I guess the concensus has already condemned that plan to failure. So, I'm left to wonder just what I can do that will provide any "useful", "adequate", and "satisfactory" "evidence" to prove the behaviors? But, we've covered all that ground before... It sort of makes me wish there was a practical way to "record" game play, such that it would play-back the game as actually played, for review. Maybe something would turn up from that. Anyone have a spare DVR???