Grumble

hello everyone! I anticipated this question a while ago and logged my answer here:

It took some time but I accepted that I need to tailor my wishes to suite the possibilities. I'm off "structures" these days, happy with just "patches". But...no, no, don't tempt me I quite like the simple idea of a ready5 patch, feels light and fun. So that's just that, no structure. As said, the 5 minutes I have on mind is the time it takes to start launching a group, rest of the group follows in 30 seconds intervals as now. Few more shots of takoff and landing "patches": ready30sec (or ready60sec) for patrol on the ground. This would to model that units "allocated" to active patrols are in state of increased alertness and can be launched sooner, when rested and in ready state. How to rest them?? Well, I'm sure everyone allocates maximum two shifts to a formation air patrol. You want 2 fighters on AAW patrol, you only "allocate" 4 to the patrol, I mean you calculate with 4. But this would "kill" the crews and planes fast, you need at least 3 shifts. This patch would reward allocating properly 3 shifts to an air patrol, 1 in the air, 1 resting, 1 on the ready, by allowing to launch the ready shift in 30secs instead of 5mins. How to do this easy? On launching a plane (or group) manually the GE would check if there are formation patrols setup for the base with the same loadout and if there are at least twice as many planes with the same loadout on the ground as on patrol. and if the launching group is smaller than the number of patrolling planes then it can start launching in 30secs, otherwise it's 5mins. Not perfect but good enough for a patch. Cat-Shots Allow carriers to operate as 1 runway for landing and 1 for each catapult for takeoffs (or 2 if more than 1 catapult). Vertrep Allow shorter launch time for rotary aircraft, like 5mins for fixed and 2mins for rotary. Landing and takeoff queues. If not actual queues then modify land/launch time if there are other groups already landing/launching. Longer land/launch times for damaged bases. Also, +25% damage on a 4 runway base means 3 runways left, +50% 2, ... E.g. at +25% damage 3 planes can take off and it takes 7 minutes to launch. Slight digress: Longer ready times for ground loadouts. like 2-3hours, or more?

Yes, me too. Story: Just last month, playing a NACV scenario a flock of AS-15s were picked up on radar bearing down on one of my dispersement airfields, range 50nm. I leisurely launched a pair of F15s and dispatched them, no sweat. Then started to think that it was too easy, I was completely unprepared, I had no fighters in the air only an AEW, which I expected to detect bombers before launch, except I failed to check the DB that the Kents have an 1000nm range and low RCS+TF. I was unworthy of the 30 seconds launch time. I thought to post this just on it's own as this might only require a change of a constant in the code, yet it could have far fetching consequences, like shaping up old brass getting careless. Simplest option could be just to compile an alternate build, like 2014.018b with 300 in place 30. Or add a command line option for beta testers. Or Staff option, but that is already GUI change which is more effort. Also, I realize I'm assuming here that the 30 seconds "launch time", the time it takes for the first a/c to takeoff, is a different constant from the 30 seconds of the time between consecutive takeoffs and the 30 seconds between landings. If these 30 seconds are all the "same" 30, then it's not that simple. I have a 300,30,30,.. takeoff and 30,30,... landing sequence in mind

I wish there would be an option for actual 5 minutes Ready 5 time. Must have been discussed here somewhere but search comes up empty, so, why is the Ready 5 time 30 seconds actually? I hardly ever use AAW formation air patrols (or ASuW for that matter) these days, it's manual patrols or nothing. (When there is AEW coverage available.) All but the most severe popup threats can be dealt with manual patrols that can get airborne in 30 seconds. I would love the game to be (optionally) realistic in this and "force" me to not ignore formation patrols.

Hi Derek, welcome to the Prodigal club! One of your "might have been unit" is actually available, the Harpoon Designer Series battlesets all have the F-14E as Tomcat 21. I think there is at least one battleset scenario featuring it too. And for the rest, until you wait for a HCDB update, there is the Platform Editor (PE, the unit modifier). What was the problem you faced with that?

Ah, H2, that was the version which made me hung up on Harpoon for like 20 years. Can't exactly recall it was some bug/crash, I remember I did all the tutorials but one of the first scenarios had some deep problem with, I think, SAM engagements. Probably I was running it under some Windows version though, not DOS.

Very much looking forward to this. H3 is a long time waiting for me, stil have all versions on my box, only I got immersed in HCE after instaling HUE . Features / changes comparision between the versions, like Silent Hunter Uk did, would be much appreciated.

Tony hinted I could a write How To on Issue reporting as "Would you write one?" so I took the hint. I don't think there is much technical novelty to add to the topic (but I will try), Tony said my issue reports were good but all I did is based on the beta guide and the forums here. Perhaps there is one thing, I want to write good issue reports and this is because I did my share of debugging in the past. To understand why do you want to write a good issue report you only need to understand (a little) how issue fixing works. From the software engineer point of view there are 4 steps in fixing an issue, these are Reproducing the symptoms, Identifying the bug, Analyzing it and then Coding the fix, "RIAC". However in the case of a released commercial software running in various uncontrolled environments by uncontrolled users it is rather: "RRRRRRRRRRRRRRRRRRRRIIIIIIIIIIIIIAAC". It can easily take 10-20 times as much time to reproduce the bug as coding the fix. The Reporter (beta tester) can have a big contribution here, making sure the issue is reproducible, providing clear instructions how to arrive to the error, providing log files and/or test saves, that is making sure that the usually expensive (or scarce or voluntary) software engineer resource spends his time on what only he can do, analyze and fix the code. So you want to file a good issue report to cut out as many "R" and "I" as possible, ideally you want Tony just do a facepalm & "AC" and have the bug fixed by return post. Ok, now that you are converted, take a look at technicalities: Read the the Beta Testers Read me First from Tony. http://harpgamer.com/harpforum/index.php?/topic/3574-beta-testers-read-me-first/ Reproducing the error. Iterative save. Iterative saving is your best friend here (for GE issues). Regardless of testing actually. But if you want to reproduce a perceived error you need a recent save. My quick launch toolbar h.bat is: call c:"\matrix games\cd2huce" winharp32 -S001800200 -S001800200 creates saves every 00180 gametime seconds and rotates max 0200 pieces of numbered auto save file. The iterative save files are placed into the ITER_SAVE_GAMETIME subfolder under your save file folder. The iterative files are named as <your last manual save file name>.NNNN.hpX. Reproduce. Ok, you have a recent save file. Can you reproduce the error again? No? then don't bother, Tony would just go G"RRRRRRRRRRRR...." too, if you can't reproduce others won't either. Yes? Great! You have cut out a bunch of "R"-s, go ahead. Try it on a Stable version Especially if you are using the latest beta it is a good to test the issue with an earlier stable version. It might turn out that the issue was added with the recent beta codes. Let Tony know if earlier stable version does not throw the problem. (You are cutting "I"-s now.) Record So you can reproduce the error, make sure others can too, record step by step what to do from loading the last save file to reproduce the error. ("R"-s again). Prepare the issue dump. Collect to include in your issue report: description of the problem and how to reproduce it, version of GE/SE, custom DB if used, save files, possibly before and also after the problem occurs (for you). IMPORTANT: Include the scenario file too (assuming a user scenario here). The format of the save file changes more frequently than the scenario format (at least in the past they did). Including the scenario file adds cross-version testability Advanced dumping: create a test scenario (industrially cutting "I"-s ) Every unit in a scenario adds (say) 10000 more lines of code to scan when trying to identify an issue. And that is per game second. You want to provide the smallest possible scenario which is able to reproduce the issue, with the bare minimum of units and with a save as close to the occurrence of the error as can be (without loosing the context). If you can fire up the SE and create scenario just with the offending units and can reproduce the error ... you can hear the buzzsaw going through the "I"-s! few more One issue per report. Don't report multiple issues on the same record even if these are linked. It's just a way of loosing track of them. Keep 'em separate or copy&paste one per instance. Remember show all - Ctrl-Alt-S Loads of debug logging options are available, see the Beta Tester Manual (attached in the Read Me first). Once there is a fix out, check back to the Issue Tracker and update the status of your report "Fix accepted by reporter" or extend if there is still an issue. Remember, facepalm&AC! /Grumble

Updated my last post.

Apparently I jumped the gun, it was not ok to upload Brad's HCDB with the RCS modification and the file has been removed from the downloads section. Apologies. Please find attached the suggested RCS changes in excel instead. Grumble Have posted modified HCDB-130924 commondb.res under the downloads section. Generally recalibrated ship RCS values based on the Skolnik function designed as posted earlier in this thread. Small size ships got a general increase of RCS. Few modern ships got significant reduction, e.g.: Overview RCS - ship length graph, original vs. modified "Stealth levels" are guess work based DB text description, Wikipedia and other web information on ship designs. And that is only for a small portion of them I had time to read after, any suggestions are welcome! Changes are listed in the attached excel. HCDBshipRCSMOD.zip

Ok, thanks Brad, that clears the doubt. And PGMs work both ways of course. There is one PGM that does not get this treatment, the AGM-62 Walleye II checks in at RCS 115. Is this because of older technology / larger size or only happenstance, like it was added to the DB in the old times, when RCS received less attention?

I was squarely smoked in the Labyrinth, WPAC 8.0, by the Neuron UCAV and the Hammer AASM GBU, I only know it was Neuron as it turned on radar for a look just before launching (could be an AI improvement, go all the way passive for stationary targets, ouch!). I still wonder how to defend this threat but can't find the chink in their armor, other then planting a CAP on the direct route between the enemy AB and my HVU, which is just gaming the game. One option could be to rather have the CAP try to intercept the weapons they deploy, the Hammer AASM, only those are even harder to detect than the platform. Looking in the DB the GBUs (JDAMs, EGBU, Hammer AASM and the LS-6) register at the extremely low 66 RCS, practically undetectable (1nm detection range vs. 55nm short range air search radar of the FARP, but even a 250 long range AS has only 5nm range on it, which is what the GBUs cover under the 30sec detection cycle.) - Is this the intended effect? GBUs are not dectable / defendable? - Otherwise, would it be (is it) a viable option to defend long range GBUs with SAMs or AAMs? Anything else? thanks.

Here are my observations for the RCS of destroyer subtype ships, as an AAR of my walkthrough of the HCDB DD RCS values, hope this can be put to some use. 1. The ex Sumner destroyers have a mix of 190 and 213 RCS I assume these have the same RCS, bet on 213. No apparent reason for them to have very low 190 or is there perhaps? ID Name Country Length Disp. RCS 2289 Miaoulis (FRAM II/86) Greece 115 2200 213 2348 Zafer (Sumner) Turkey 115 2200 213 2393 Babr (Sumner/80) Iran 115 2200 190 3244 Wu Chin I mod 2 Taiwan 115 2350 190 3245 Wu Chin I mod 3 Taiwan 115 2200 190 3246 Tien Shi (Sumner) Taiwan 115 2000 190 3813 Miaoulis (FRAM II/80) Greece 115 2200 213 3947 Babr (Sumner/87) Iran 115 2200 190 3998 Dae Gu (Sumner/1) South Korea 115 2200 213 3999 Dae Gu (Sumner/2) South Korea 115 2200 213 2. Similar with the ex Gearing FRAMs (28 total), mix of 213 and 223, 4 examples below 213? ID Name Country Length Disp. RCS 2288 Themistoklis (FRAM II/87)Greece 119 2425 223 2344 Alcitepe (87) Turkey 119 2450 213 3243 Wu Chin I mod 1 Taiwan 119 2425 223 3549 Alcitepe (82) Turkey 119 2450 213 3. The Luhai Type 051B mentioned in the DB text to have reduced RCS design so probably it can have similar or better RCS than same size ships. 217? ID Name Country Length Disp. RCS 2067 Tourville (1990) France 153 4650 216 2483 Luhai Type 051B China 153 6600 224 2612 Haruna (1997) Japan 153 4950 217 4. Kolkata Type 15A. described as stealthy design but has same RCS as older, heavier Russian classes, 207? ID Name Country Length Disp. RCS 2264 Udaloy PT (1155) Russia 163 6700 215 3279 Kolkata Type 15A India 163 5500 214 2150 Udaloy II (1155.1) Russia 164 7700 213 5. The <110m group ships have sharply lower RCS than few meters longer DDs. These appear to be older classes, no indication of stealth. 212? ID Name Country Length Disp. RCS SkolRCS 3791 Tariq (Black Swan mod) Egypt 91 1475 186 212 3887 Indakh (Savage) Tunisia 93 1590 208 212 3518 Vampire Australia 95 2800 188 213 2498 Jianghu V Type 053 China 103 1425 200 212 3313 Murasame (DD107/80) Japan 108 1800 192 213 3314 Harusame (DD109/80) Japan 108 1800 192 213 3790 El Fateh (Z/89) Egypt 111 1730 190 213 3756 Ostergotland Sweden 112 2150 188 213

Guess I was asking for this when I posted just a shape of an idea but I was eager to share and had no more time on my hand. Anyway the objectives are: My immediate objective is to ask in a grounded way whether the Dergach RCS is too low. It seems too stealthy at 170 (38.6nm detection range vs APS-145 in HC) when compared to either the Coast Guard study (gives 20-36nm for the much lower performance APS-134 vs 1m2) or the H4.1 data (63nm SS range for APS-145 vs very small targets). I could not find any hint pointing at stealthy design, however I have practically no source on this. Next is to build grounded case (to discuss) that the smaller ships are too stealthy (too low RCS on average) in HCDB. E.g. many have Dergach-ish performance. Last I wanted to share the spreadsheet formula for RCS value calculation, I was pleasantly surprised how well the Skolnik function can be made to match the HCDB RCS values with light parametering. I see potential that the formula can be used to improve HCDB, either just to find the odd entries which need checking, or, possibly to regenerate RCS values for certain types of ships, for example if there is merit in 1. or 2. I do not see this last as a major overhaul of the RCS values, the function matches the current values pretty good (see the below graph how good), it would only add consistency across ship sizes where no other data presents itself for a specific class to have out-of-ordinary RCS value. Well, yes indeed, I found that there is almost no RCS data published outside of wargames. But then there is the Coast Guard study, which anchors the case for the APS-134 for 1m2 and 100m2 RCS real world ship targets. The Coast Guard study is just one reference, but the good match of HCDB with Skolnik generated values tells that these are generally good RCS functions, there is no need to change the shape of them, only we need to anchor this curve to the Coast Guard reference points. This is where the spreadsheet formula can come handy, it can be made to reasonably match the HCDB curve and then it can be easily shifted up/down to the Coast Guard anchor point(s) by just changing a constant one place in the spreadsheet. As example below is the DD and DDG subtypes curve, HCDB-130924 and Skolnik, all I did for the blue curve was that I checked the larger deviations and set appropriate "Stealth levels" where the HCDB description or Wikipedia info confirmed a RCS conscious design, this is why even most "spikes" are matching. There are few deviations left, these would be interesting to discuss and these would be the first candidates to get corrected/adjusted. Additionally, it is interesting that the HCDB curve suffers a steep drop in general for DD ships below 110m, this adds to point 2 I'm making above. I would now continue with specific examples for the correction candidates, only out of time for today.

Ok, so this is it. I start with expectation setting (I’m preparing for storm ) So, keep in mind, this thread started when a Dergach FFL seemed to be too stealthy, it turned out that as per HCDB she has RCS 170, an E-2C grp2 Hawkeye, would detect it only inside 38nm. This does not “feel” right, but can we verify it. Well, no, not surprisingly there is not much factual data on the net about naval ship RCS, all I got is the HCDB. As second best I settle to check HCDB consistency across ship sizes and compare it with the few available data from outside. References,what can I work with: (1) An 1984 Coast Guard study testing the APS-134 FLAR against 1m2 to 100m2 RCS surface targets, also referencing these to 1m to 30-90m length. (2) The Harpoon 4.1 Smarter Radar document listing expected radar detection ranges of most DB sensors against Large 3,000,000 m2 Medium 300,000 m2 Small 30,000 m2 Very Small 3,000 m2 Stealthy 300 m2 Note: H4.1 seems to use ship m2 RCS values on a different scale from the Coast Guard study and also from Skolnik. (And both are on the m2 scale, so the difference is not due to dbsqm representation.) Will need to convert. (3) An empirical formula from M. Skolnik that references radar frequency & displacement to naval ship RCS m2: rcs = 52f1/2D3/2 where f is radar frequency in MHz and D is ship displacement in kilotons. (4) Tony’s RCS worksheet (RCSW now on) which is practically the GE routines to calculate between RCS m2 <> RCS dbm (as in the HCDB) <> detection range (radar). (5) HCDB-130924 Data scoop, the factual (like) data from the references: (5) HCDB: APS-134 is 150nm SS radar (5) HCDB: APS-145 is 360nm AS/SS radar (1) APS-134 vs 1m2 target: 20.0 to 35.9 nm in sea states 1 through 3. (1) APS-134 vs 100m2 target: initial target detection 74.0 to 80.5 nm in sea states I through 3. (1) 1m2 RCS :: ships < non metallic 8m (25 feet) long (Targets 16 to 25 feet long were considered to be representative search objects. Targets of this type equate to an approximate radar cross section of 1m2) (1) 100m2 RCS :: Ships 60 to 300 feet long. (To represent these targets, an intermediate value for radar cross section of 100 m2 was selected.) (2) APS-134 performance vs Lrg/Med/Small/Vsmall/Stealthy 150/150/96/54/30 (2) APS-145 SS performance vs Lrg/Med/Small/Vsmall/Stealthy 250/195/111/63/35 (3) I'm going to use S band, 3000 MHz freq. for the Skolnik formula. Note: HCDB stores RCS values of dbm2 like logarithmic scale (dubbed “HCRCS” in the RCSW), ranges between 160-250, for our “feels like” assessment I convert these to square meter RCS values, comparing ship length to m2 gives at least some “feeling” unlike comparing it to a logarithmic value. I use the RCSW formulas for this. 0) Initial checks, correlating (1) the Coast Guard study to HCDB and HC GE, per the RCSW: for an APS-134 (150nm SS radar) to detect a ship target at 20nm the target has to have >500m2 RCS or >177 HCRCS. for an APS-134 (150nm SS radar) to detect a ship target at 80nm the target has to have >100000m2 RCS or >219 HCRCS. Now I create a function that calculates RCS for the ships based on other data available from the DB, I’m going to use displacement and length as input here. My hope is that it will be possible to match this function to the DB values on average, discrepancies are either purpose made (like stealthy ships) or values that need to be corrected (my goal to find). Excel number crunching: Export HCDB ship annex into a excel Convert HCRCS values to m2 values (HCRCSm2 values) for human comparison. Then combine ship length and displacement values into a single normalized-displacement value (longer ships get “bonus” to displacement and vice versa). Calculate an RCSm2 with the Skolnik formula based on the adjusted displacement. My expectation is that the Skolnik function will have similar shape to the DB values on average. Then adjust the Skolnik function values (add a constant to it) to match the real life experiments, i.e. (1). By now we should have an RCS like curve that matches the few examples we have. This can then be used to pinpoint out-of-ordinary values in HCDB (candidates for further investigation) and also to generate baseline values for new ships when no other source is available. Of course most of the outstanding values will be intentional deviation, due to differences in ship design, like advancement in ship stealth technology. For this most common case I added a Stealth column to the table, where a “stealth level” can be entered, each level diminishes the Skolnik value with power of two (or increases it for negative values.) Finally there is also an override column. Sometimes you just don’t want to argue with a function. Ok, enough talk, do it. I’m splitting the ship annex into smaller groups (like carriers, cruisers, destroyers, etc.), there is less scatter and exception in smaller groups, easier to follow a trend. I demo with destroyers: steps 1) and 2), HCRCSm2 of destroyers presented on the length scale: Steps 3) 4) 5) HCRCSm2 and Skolnik curve: Now the shape looks ok (if there is any trend in the red curve, the blue could well be one ) but the low point is way too low (for the HC way of radar model) The leftmost, smallest destroyer is Egypt’s Tariq, 91m, 1475t, HCRCS=186 == 1685m2, this would give a mere 27.19nm detection range for the APS-134 (per HCSW), which it can even achieve (according to (1)) against 1m2 liferaft. So I will boldly shift the Skolnik curve up with (say) 80000, Step 6): This yields a 74.81nm detection range for the APS-134 against the Tariq, still modest but in line with (1) measurements against 60 to 300 feet long targets. Also according to (2) the APS-134 achieves 96/54nm against small/vsmall targets, no problem here either. Lets also check the other end of the DD line how does the +80k impact that, ignore the Zumwalt and Kongo classes just for now, the Improved Spruance had 78nm APS-134 range according with the original DB value, the adjusted Skolnik gives 85nm, within bounds I say. Ok, so I convinced myself that Skolnik with the +80k shift gives a reasonable approximation. Now comes the more tedious task of checking ships with larger deviation vs Skolnik Starting from the largest Zumwalt, obviously intentionally small RCS, I set it lvl 10 stealth (Skolnik RCS decreased to it’s 1/1024 part) Kongo, ok again, set lvl 5 stealth Several Spruance classes, ok no change needed Atago classes, give it lvl 5 stealth KDX-3, lvl 2 Then Kolkata Type 15A, Udaloys, Delhi Type 15, Shirane, nothing special, keep as is … Step 8) Skolnik and DB curve after few of the largest destroyers were adjusted for stealth: Ok, definitely some more work in here but on track, to be continued. I leave it for now with the shifted Patrol Boat curve, without the manual adjustment yet, better match than with DDs.