TonyE

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.

Thanks Brad and Rene, bonus points for the concise test scen Brad!

Buddha, I think everyone forgot to elaborate on what to do for now about the 2048 limit, sorry about that. The mantra "always add, never delete" has the important connotation that you can modify existing entries. In making your own database if you don't need to guarantee compatibility with existing scenarios, you can modify installations you don't ever plan to use into ones you do plan to use. A Bejing airfield for instance may have no use in a Caribbean battleset so you could rename your Bejing installation and change any characteristics about it for use as say, Hugo Chavez Military Field #1. Does that help explain?

As Rene and I discussed on IRC, I don't get crashes adding bases to custom battlesets (or the standard battlesets) but look forward to hearing or discovering why Rene is having trouble with this. Thanks guys

The AGSI wiki gives a partial list: http://www.advancedgaming.biz/wiki/main/in...manders_Edition In addition to that list: New Radar jamming model Improvements to sonar Ship to Ship torpedo attacks Western Pacific battleset (many played it as a beta, HCE will have the first release version) Many more changes and improvements to come after release.

I think Brad is trying to pick a fight, Craig, where are you? Oh, did I mention with the short legged tankers of the F/A-18 and strikes will neccessarily be of few numbers if long range can be maintained Full squadron attacks from A-6, but half squadron attacks of Hornets if you are lucky once support aircraft are considered

Now if that doesn't help DD(X) and CG(X), I don't know what will. Take the previously spotless Burkes and throw in some doubt...

My two cents contain a couple of assumptions: 1. The F/A-18s have early model AMRAAM, not these 75 and 90nm nice toys. 2. The 1980's airwing only requires 1980s style upkeep, not trying to keep ancient birds going today. Given those two assumptions, I would put my money on the 1980's airwing. Some basic reasoning of how I get there, pretty much in order of importance... 1. In the 1980s the planes were for the most part single tasked. An F-14 driver spent all of his time being a fighter pilot, not dropping bombs every 3rd mission. The level of training in each specialization (F-14 for AAW, A-6 for ASuW/Bombing) could be more completely accomplished than with mixed use F/A-18s. 2. With the A-6 superior range to most F/A-18 configurations, not to mention F-14 vs F/A-18, the 1980's battlegroup commander could use separation to his advantage, sucking the poor F/A-18s low on gas and limiting them to strikes that require tanking, as compared to untanked A-6 strikes. This offsets the potentially slower turn-around of the 1980's airwing vs the 2000 airwing. In sum, the 1980s airwing might be able to generate more attacks on target if range is well managed. 3. I still hold a personal opinion that AIM-54Cs can sneak up on a target much better than we usually expect. It is a big missile with pretty large kill area, even close counts on many AAM shots. Secondly the sucker likes to fly high, and the target's radar may well not be able to look high enough to track the Phoenix inbound, depending then upon RWR to warn of needed evasive action. 4. If range gets closer than Phoenix shots (not to mention after the Phoenix run out), the F/A-18 is going to do a number on the 80s airwing with AMRAAM, I cannot discount that. The short range shots I again favor the F-14 with a fighter pilot, not the attack pilot of the F/A-18. 5. Numbered towards the bottom of my list since I know so little about the morale and and such of the two airwing's operational philosphy, I'm thinking the 1980's airwing is much more ready and accepting that risks must be taken. The 2000 airwing is, I assume, taught caution and conservation. That difference in approach will give the 1980's airwing the room to adapt to the situation more quickly. Cold War was about long range shots, current approach is don't shoot until you know the opposition is hostile by visual ID! Can a Harpoon game simulate this encounter? I think it fits most easily into H4, range, logistics, morale are easily accommodated. Next in my list is H3/ANW with logistics part of the game. Low man on the totem pole for this one in my opinion is HC. In HC the player may use his own logistics tracking but you can't enforce that on the AI and that's a deal breaker for this scenario. Phoenix, AMRAAM, and Harpoons are limited and both sides sorely need them in this matchup.

Brad and I flew a couple of missions today (and a couple Saturday). I tried out the B-1 against a number of artillery emplacements with excellent results. It must be a fairly stealthy bird in FA as I didn't even get painted or shot at by the plethora of air defense. Let me just add that the 7 packs of 1000lb bombs did a nice job despite my early fears of missing every target. After that mission we did what turned out to be a tough one, taking out the air defenses of a convoy. I died multiple times trying to kill the airplanes at an airfield, oops... Gotta go.

You don't need to use the PE at all in most cases, just make sure you have the appropriate commondb.res and commmondb.rsr files in place. For most people the PE just means more things to go wrong. Feel free to put it in the wiki but it isn't the final form so you'll be doing a lot of changing if you start now (in other words I'd say a lot of things are more deserving of wiki entries than an early beta battleset creator that will not work this way upon release). Otherwise it appears you have the procedure correct.

We still need pre-EC2003 AAA checked, it should fire to any altitude.

HCE - 2007.023 ============== - Chg:0000 GE Prevent potential crash when launching weapon with long name - Chg:0000 GE Allow battlesets with zero scenarios, no more crashing - Chg:0000 GE Upon scenario load, suppress the orders window if no orders are available, go straight into the game. - Chg:0000 GE Refueling manually will now replace any existing refueling events that haven't started to transfer fuel. The aim is to prevent an inability to manually refuel (i.e. the command is given but no refuel occurs until much later). - Chg:0000 GE Let BOL weapons hit anybody, including player ships. - Chg:0000 BSB Fix controls alignment on scenarios tab so they behave when the form is resized. - Chg:0000 BSB Re-ordered the controls in the program so the tab key usage makes a little more sense. - Chg:0000 BSB Expanded logging to cover entire program. - Chg:0000 BSB Added a most simple facility for saving and loading battleset settings. - Chg:0000 BSB Prevent error about invalid float when manually entering a Lat or Lon value. - Nfo:0000 BSB Determined that the map creation utilities do not know how to make a map from Iceland as a Western boundary to the USA as an Eastern boundary. This needs to be remedied. So, test your BOL stuff, in my test case, a Harpoon happily impacted a neutral ship. The battleset builder does quite a bit more logging into BSBuilder.log. I tried non-square maps without success at this time. Wrapping around the world the long way also does not work when crossing the international date line. We may have to beg Bret for a fix to that last one.

Yup, that's why I wanted to handle it separately since BOL weapons should hit anything in the path after activation. Tony

Hi All, I think this is as good a point as any to make a few comments about what Rene has done here, and help guide such efforts as we move forward. I really like what Rene has done and do hope to make use of some of his ideas, and directly his work, as it can be worked into the game. For one, I don't like making reports and Rene has made some very nice ones. We (HC3, or whatever Brad, Akula, and I are called) want to encourage these ideas and contributions. That Rene kept his modifications inside of the beta group was key. Public release of such modifications is not allowed since the PE is AGSI's. To that end, if there is demand, we'll make a shell Access database available against which people can write reports and redistribute said creations without AGSI approval (this is approximately the model I use with dbComp on the H3 side but that situation is more complicated and required AGSI's approval and agreement). Now the disappointing part but also some common sense... We need most of your testing time spent on the real PE, not any user offshoots. We're here to beat on the game components as well as expand and that means mainly beating on the pieces that are official. Yes, use Rene's modifications as you see fit and make modifications of your own, but please spend the majority of your available time on the official programs. Rene's efforts are going to save me hours and hours of work, so be like Rene, but also keep the ultimate goal in mind

I won't tell you how to craft your scenario, but... Why don't you just make that opening move part of the scenario intro text, not an event that actually happens in the game? i.e. "Yesterday Red pirates attacked a Neutral merchant at coordinates ..." That said, there are two directions from which you will eventually be able to do something closer to what you are attempting here. First is probably longer termed but it is a more complete implementation of the Neutral side as a real side (the Green side) rather than a fixed Neutral side. With that come stances towards each of the other sides and an ability to get the green side mad enough to turn hostile if provoked. Second is an offshoot of a Search And Rescue implementation. That is the idea of a friendly unit that is out of the comms net and must be detected. I imagine that capability could be generalized to situations beyond SAR as needed.

Buddha, Can you explain the attack going Ok part a little more. When the AI is blue, the attack against green proceeds? When the AI is red, the attack against green proceeds? The correct behavior is for the AI not to launch at neutral units. Players should be able to launch at neutrals. We'll deal with BOL after this one is clarified.