TonyE

Hmm, not here, more details like does right-click and save as work for you? It is a PDF created in Acrobat 7 Pro, displays fine in version 8 here. What Browser?

See the attached PDF for the heart of the exploration. First I had an idea, then I got a big piece of graph paper (roughly 36" x 24") and sketched out my ideas. For some reason a big piece of paper sometimes works for me when a letter sized piece won't, who knows why... From there came the digitalization, otherwise known as convincing Visio to show me something like what I so easily drew with pen and ruler. Then the longer document of explanation. And that's where the PDF comes from. As many of you know I'm part of the Stratsims gang http://www.stratsims.com and get the novel title of Lead Programmer. As well I have been and will soon again officially be an HC programmer. The two endeavours are mutually exclusive in terms of code, never has code for Stratsims gone into HC and never has code for HC gone into Stratsims works. Ideas and experience are another matter and they cannot help but cross polinate. Where is this going, well to credit... Modularizing a program isn't something I can really credit anybody with, it is a pretty natural progression in programming thought. I think Brains of HC and IRC fame has championed generic everything as much as possible so he deserves a lot of credit. The hours pondering Stratsims and CIC and all of the people that contribute to that also impacted and bore this document. But what made it spill out onto paper and electrons is HC and my understanding of the Harpooon system and how it is divided into pieces for paper and computer games alike. Oh, a good dose of prolonged sickness didn't hurt the creative juices either! With all of that out of the way, enjoy, provide feedback if you so desire. My intent was to map out something possible, not as generic as Brain's ideal, not fully compartmentalized to allow swapping out any one piece without affecting others, but something I view as attainable at my skill level given amounts of time I do not have (so it's realistically an exercise, not a template for something to actually be done but who knows ). HC_Restructure_Idea_Set_1___20071027.pdf

Is that what you do with your free time, swim around poking a 20' metal rod into the bottom of rivers/bays/oceans? Ah, for the luxury

Hi Gary, Here's the grand strategy for you, the details will come in the next couple of days. 1. We'll get you updated to 2003.15. We can't give you 2003.16b3 since it is a beta and AGSI/Matrix don't look kindly upon people distributing old betas. 2. I'll see if I can coax a recent HCDB into 2003.15 format. At that point things will probably run pretty well and we'll help you get it working. So look for a couple more posts this weekend.

Thanks for the heads up.

One submarine test scenario, for play as Blue side. What I found playing as Blue... Red and Green behaved, UNTIL I detected the submarines, then the Neutral let loose and sank the Red sub. So I think it's not right yet but would like more input, a test scen with a Red player would be good. Anyone else? NeutSub1.zip

Today in IRC the topic came up. I would like to see a minimum of two orbital altitude bands, one for low and mid earth orbit, and one far out band for SBIRS and such.

I'm in pretty much the same boat as Brad but I'm even more extreme in the casual player aspect. When I pick up Harpoon for a game, it is HC 75% of the time or so. Case in point on the casual thing, the most fun I've had with Harpoon in close to a year was playing one of Ralf's scenarios from the wrong side two weeks ago. I enjoyed the crap out of smashing a two carrier battlegroup with an abundance of Russian bombers. Here's what I would suggest, if HCCE is available for sale before ANW 3.9, grab HCCE, if ANW 3.9 is released first, grab ANW. With the return of Darren Buckley to the H3 scene and other ANW participants finding a firmer footing, ANW progress should be more consistent and focused than it has been the last few years (3.9 is bearing the first real fruits of that). ANW in the longer term is the game with the future, we're going to do what we can with HC, and for the next couple of years that may seemingly outpace the development of ANW, but ANW should by all rights grow into the choice of most computer Harpoon players as it transitions to TNH (The Next Harpoon). I suppose based on that, another way to look at it is now is a good time to take your foray into HC, ANW is a stepping stone to something greater while HC isn't a stepping stone to anything so the focus is on the here and now with HC, it is on the future with ANW.

Again I'm speaking outside the rules (what a pest I am!). You cannot assume the contact is in a CZ, you may just have a maneuvering contact that defies an easy TMA. The best way to know your contact is in a CZ is when it disappears and reappears much later, much stronger (goes away while transiting from CZ to direct path detection).

Speaking not from the rules I would say you could have a house rule of sorts that makes high probability of classification in that situation possible. What I'm thinking of is scenario background or other intelligence combined with your unclassified contact to give a high probability of accurate classification. Thought: * Scenario outline suggests two submarines operating in the operational area, a DE and a Nuke boat. * You've had passive sonar contact fairly consistently over a period of twelve days (okay, so I'm reaching) but no radar returns from a snorkel Therefore there is a high probability you detected the nuke boat, not the diesel electric boat since there wasn't snorkeling going on. You aren't sure but the odds are that you are correct. So the passive classification wasn't possible, but by fusing (had to use the buzzword) your pieces of data, you came up with a probable classification anyway.

Rabbit, Don (Gilman) would like your input and real life experience to weigh in on the SAR topic. In your experience, how does the whole process work out in the real world I suppose starting at the unfortunate moment you realize your steed is not going to make it back to base?

I think Ralf wants to keep the scenario a bit private until the game is released, I don't know if we need a whole section for them at this point. I'd say just post it up to a new thread here in the General forum with the scenario name.

Well, I'll be! It isn't even April 1st. Thanks Jan

I forgot this in the first post, I'm concerned that Neutral subs will still fire on AI subs so make sure to test that. Hopefully they won't but it is a situation I didn't test.

HCE - 2007.024 ============== - Chg:0000 GE Stop showing SAM and Gun counts at enemy installations and land units on the mini report window. - Chg:0000 BSB Hide the running of end_edit.bat but capture its output to the log file. - Chg:0000 GE Improve DLLExport interface to improve speed when no DLLs are loaded. - Chg:0000 GE Hopefully prevent Neutrals from attacking AI, prevent AI from giving player detects of Neutrals. To Test: GE Set up test scenarios with Neutrals. Make sure that... 1. Neutrals do not report AI positions to player 2. AI does not report Neutral positions to player 3. Neutrals do not attack AI 4. Do these with player as Blue, then with Player as Red. BSB - make sure end_edit runs (you'll know it runs if you end up with a battleset.res with a current date/time, you will also see its output in BSBuilder.log.

Next question to ponder, do we want to do this or should we just keep tweaking the existing refueling? The new refueling won't work for pre-ec2003 battlesets and so the old method still needs to be maintained in some form.

Brad, Rene, and myself went thru a chat about refueling. When tweaking code in 2007.023 it was pretty apparent that refueling can be expanded from its current behavior without breaking the scenario or save game format. Goals: 1. Allow a tanker to offload fuel multiple times, until it has no more fuel to offload. 2. Separate the amount of offloadable fuel from the tanker's loadout range, instead characterize it in 'drop tanks'. Mechanism: 1. Tanker loadouts will use a special case drop-tank with a non-zero range. A scaling factor of 100 will be applied. a. example: drop tank with range 3.0 means it can offload 300nm of fuel (cruise speed). b. Maximum value for the field is 3276.8, meaning a tanker could offload 327,680nm of fuel. 2. Assume for now only the first drop-tank in the tanker loadout will be used, but there is no impediment besides some code to allowing multiple refuel stores (drop tanks) on a tanker loadout. 3. Drop tanks with zero range remain as symbolic drop tanks. 4. Retain refuel hotkey for forced immediate refueling. Challenges: 1. Figuring out when a group needs to be auto-refueled. a. My first guess says the auto-refuel begins when the last refuelee would reach 10% fuel. That may mean refueling starts when some planes in the group are well above 10% fuel. Note, this may be way past bingo fuel of some of the individual planes (think transiting the Atlantic with F-16s). 2. Figuring out which planes get refueled, in theory the shortest legged planes would get fuel to even out the ranges of the planes in the group. Left Undone: 1. Planes will not automatically find and join with a tanker group, it will still be the same player controls, just more ability once the refuel commences. The auto-find-a-tanker cannot be implemented without breaking save or scenario formats. Please comment, this is the first draft and I haven't started any coding.

Yes, we're talking a large rework of much of the game to make the gator navy operate. The database structure isn't broken per se, but it is certainly expanded greatly. What does break are scenarios, saves, and tens of thousands of lines of code. It is by no means a small or incremental change, it is a core structural change to the game and many of my evening hours are now spent figuring out how to make such fundamental and far reaching changes without making the existing game and materials useless. Don't get me wrong, I know it is possible, but as it seems Akula just recognized, this is huge. When we go down the path of breaking the scenario format some time after the first patch you'll be testing builds of the game that aren't even playable, probably for weeks and months at a time.

I don't think anything happened, just not much action there at present, I'm sure HCE release will perk it up a bit. I'm a little surprised the Israeli airstrike didn't come up in conversation though.

Yes, that is one piece towards layable mines.

Brad got me thinking about satellites this weekend and that got me to wondering how you, as scenario designers, like to define the path (altitude, direction, etc.) of a satellite. A satellite orbit can be fairly well described with 6 items of data as defined and explained at http://www2.jpl.nasa.gov/basics/bsf5-1.html . I look at that and say, that's great but as a scenario designer is doesn't help me, in most cases I just want to plot a certain number of points and speeds over the map area I'm concerned about. That leaves some unknowns to be taken care of (like when it should appear next at the start of the path). Anyway, we're looking for ideas and I think the scenario designer's wishes may play a large role on this one.

Just a code tidbit for the curious folk out there, and something that is related to the discussion. Structure of an HC Unit (in code terms) A unit has certain characteristics... The Unit itself can be a ship/land unit, sub, or installation. So you say, what about planes, missiles, torpedoes, etc.? Well, they fit into slots in the Unit structure. A group of 12 A-6 Intruders all with ASuW loadout is composed of: 1 shell unit with a name 'plane' 1 plane record within the Unit, that says qty 12 A-6 with ASuW loadout Same deal with a group of 4 TLAM launched against one target: 1 shell unit with a name 'missile' 1 missile record within the Unit, that says qty 4 TLAM This structure saves memory, what would have been 12 plane units or 4 TLAM units is expressed as a single unit. The structure also complicates matters since planes and weapons are now special cases that don't work like other units. If you hadn't guessed by now, I think that structure has to change to make any decent amphibious warfare model work. I think 1 missile eventually needs to be one unit, 1 plane needs to be one unit. I think that to eliminate complexity but even more to: Increase the level of fidelity of the fight, presenting a more realistic view for air defenses. If you've taken to firing missiles in pairs instead of a large group, you'll see there is a difference in enemy effectiveness shooting them down. Ease the implementation of Units carrying Units, carrying Units, etc. I don't think the child unit model can reasonably be grafted on to the existing structure. Allow easier implementation of the formation editor for aircraft groups

Once again Akula takes a complicated topic (logistics, even if it is hidden as At Sea Replenishment) and breaks it down into a manageable system (why can't I do that?! ). The pool of logistics points in a certain number of areas on a platform gives a workable logistics model without the minutia of tracking each individual weapon type, filling magazines each time a weapon changes, etc. (yes H3, I'm looking at you!). Where I first felt the flow and ease of the pool of points is in TacOps. It was so easy and natural that I got exactly what I needed as a commander, the knowledge my guys were low on ammo, an abstract way to get them resupplied, and the worry about running out of supplies before the scenario finished. Looking at Akula's model I would take it another step farther and allow each weapon to have a certain cost defined at the DB level (tempting to make it at the scenario level but at the DB level the implementation is much easier). So rather than a Mk82 and a TLAM each costing one point, a Mk82 might cost 2 Ammo points where a TLAM costs 400 Ammo points. That change fulfills one of the keys of a logistics system, making the fancy weapons much more limited than the cheaper and usually less capable weapons. Now you start considering LGBs against small ships instead of Harpoons because each Harpoon costs 40 Ammo points while a LGB costs 8 Ammo points. The Good: 1. No need to manage magazines with the exact make and model of each weapon. 2. Adds the strategic element of maximizing damage while minimizing losses. You, the commander may decide that the air defense network must be destroyed with TLAM to keep aircraft losses minimal, and to later allow JDAM carriers to come into a lightened air defense environment. 3. Operates at a level (individual ship/base) to make a CSG (Carrier Strike Group) limited in supply, as compared to a single global points pool that could still give a carrier group way too much power and on-station time. 4. Easy for the player, and the scenario designer! The only one having a really bad day in this model is the DB editor who will be universally hated for making a TLAM 400 Ammo points instead of 401 The Bad: 1. Tony will still be able to artificially inflate the number of AIM-54C available since he can make all of the A-6s carry dumb bombs to make up for the costly AAMs. 2. Even the points model is a huge step for HC, requiring some big idea changes, many of which Akula lays out. What this model makes me think of (for future discussion): In concert with taking over bases and occupying area, the idea of factories that change raw resources into the 4-6 resources Akula lays out. Many of you already know my dream of controlled areas providing money with which I can wage war on the longer terms, building cities and such to increase raw resources. Not only that but logistics points give some direction and hint at costing the scenario, if one person can win a scenario spending only 10,000 points, he can really laugh at a person who took 75,000 points to reach victory. This also raises the old economic questions of do I build factories, develop my cities, or do I buy smart weapons to fight the battle... Anyway, looking forward to everyone's input, please consider this topic a general commentary on logistics as a whole. I don't know that my future discussion item is appropriate to the topic but may be something to keep in mind as you develop comments about Akula's model and my suggested additions/changes.

No takers on this yet so I'll throw in my thoughts as they relate to HC... The most basic solution is to modify hit chance up or down depending upon the capabilities of the missile. I think that is too restrictive and is the procedure in use already. Next comes the generational idea. A generation 1 missile against generation 3 defenses doesn't have nearly the chance as a generation 3 missile against generation 1 defenses. As part of the abstract generation number would be an allowance for terminal maneuvers. I tend to like generational approach to attack vs defense. Increasing the level of complexity we get to lists of terminal maneuvers a weapon can perform (each weapon could have multiple maneuvers highlighted) and a list of maneuvers a defensive mount or weapon can counter. It is tempting then to let the player choose which terminal maneuver to use (to keep it manageable, limit each group of weapons to only using one terminal maneuver type). I would say, don't let the player decide, if the player has an exact fix on the target, then have the game choose the 'best' terminal maneuver against the known defenses, otherwise use a default or randomly chosen terminal maneuver). Complexity past that in a model probably means scripting of some sort with the PE for the offensive terminal maneuvers and a few flags for defensive weapons capability (ex. fast bearing change capable, fast altitude change capable, sea skimmer capable, etc). I don't see this as adding much of anything beyond the lesser complexity models except for the more detailed information that would then be part of the database as a reference work. Thoughts? Different approaches?

Light Complexity Approach Key details: 1. Does not break scenario file format 2. Breaks save file format (I don't think we can do SAR without breaking save files but this approach comes painfully close) 3. Works as much as possible with code we already have Description: Units to be rescued are placed in the SE, no new downed crews or stranded VIPs are created in the course of play. This simplifies the changes to Victory Conditions as a more dynamic number of rescuees breaks the current VC model. 'Recovery' mechanism. The simplest approach is what Akula mentioned, fire a weapon at the rescuee to recover them. The cool side benefit is that very little change is needed in Victory Conditions as units are still being killed and we make VCs for things killed in HC. Add a flag in the DB for weapons that can rescue, only those weapons can rescue a rescuee. How to craft a rescuee? Akula suggested they be neutral units. That is a novel and obvious thought that hadn't crossed my mind. Still I think my preferred approach is to have a flag applicable to ships and mobile land units that denotes them as rescuees (meaning they are not automatically in the players communications network, and that they can be fired on by friendly forces). How to detect a rescuee? Whenever another friendly group (unit?) comes within 10nm of the rescuee, the rescuee becomes localized for the friendly side. For the opposing side to detect the rescuee, they must be within 7nm (ranges subject to discussion). This eliminates the need for a new sensor and ESM type. To aid in initial detection, suggest placing suspected coordinates of rescuee(s) in the orders file. Obvious Challenges in this Approach: 1. Arming platforms with SAR weaponry would be quite a process. Easy enough to add it to many helicopters, but what about the inherent capability of just about every sub/ship/land unit to grab a rescuee? Please comment, keeping in mind the goal here is to keep the model as simplistic as possible. Also feel free to craft and post a more complex model.