TonyE

FuelToOffload field added to THCAirRec in uHCTypeDefs and checked in to SVN. The catch is that the field is only available in game version 2015.008 and newer so you may want to delay grabbing this change until I get 2015.008 out. FuelToOffload: LongInt; // ALE 20150611 HC2015.008+ fuel left in tanker in nm

Sounds great Don! I made very good progress on game changes yesterday and introduced a new field on the unit's AirRec called FuelToOffload. I aim to work it into the shared pascal code tonight and get a GE and SE build outby the end of the weekend.

Periodic for sure, refueling being a risky operation it isn't done just to keep everyone topped up. Different altitudes is above my pay grade though my gut says tankers are only going to stay with groups of planes for any length of time when doing a long transit so they may as well stay in the same altitude band.

This is the initial reason I got involved other than to help (the ability to keep track of fuel remaining in the tanker). The fixing of unit names whole ball of wax is going to dictate a change to the scenario file format (first one on my watch). I'm intending to add a refuel data field so that the amount of fuel left follows the tanker. I can't commit to when I'll have that in place though.

I don't recall if the AI tanks but if you are playing Red and things aren't working that should be reported.

Hmm, didn't read you Hmm, didn't read your post well enough, 10 tankers if all in the same aircraft unit should have done the refuel of the first 10 plane clump of bombers in 3 minutes. If you are able, run it without the refuel ExportDLL and turn on the refuel logging so we can look at the details. Zip and attach the log file.

I think you'll find the notes that came with the refueling DLL (refuelDemo.txt) indicate the DLL will pause the game when a refuel event is being processed. That allows you to modify the parameters of the refuel operation. Each plane requires 3 minutes to refuel so the second 10-plane unit of B-1B's wouldn't start refueling until 30 minutes after the first clump finished.

Any help in working up and executing test refuelings would be appreciated. Donaldseadog and I have thoroughly tested the following cases: 1. Long range tanker auto refueling multiple short ranged recipient air units. 2. Multiple long range tanker auto refueling multiple short ranged recipient air units. Ideas for tests: 1. Short range tanker refueling long range recipients 2. Long range tanker manually refueling short ranged recipients. 3. Lots of recipients (i.e. spread the tanker thin). ... I would love to see scenarios, saved games, and ge.log files (with refueling logging turned on) zipped and uploaded to the thread

First post updated with general process.

Example refueling logging in 2015.007. One long range tanker refueling two air units... 104941 staff.c:215 - creating refueling event Group=0x873fb8 (ABAS Endurance = 573781 num_tanker=1, platstart=1 platnow=1 104971 combat5.c:1220 - Processing Refuel Event for Group=ABA 104971 combat5.c:1231 - tanker unit=AB002, numtankers=1 104971 combat5.c:1239 - Tanker fuel=4500nm 104971 combat5.c:1363 - in the not refueling path 104971 combat5.c:1418 - Will try to give each plane in unit=AB000 503nm of fuel when event is processed planestofuel_ids[0] 104971 combat5.c:1418 - Will try to give each plane in unit=AB001 503nm of fuel when event is processed planestofuel_ids[1] 104971 combat5.c:1506 - returning to wait 30 seconds for refueling to complete 105001 combat5.c:1220 - Processing Refuel Event for Group=ABA 105001 combat5.c:1231 - tanker unit=AB002, numtankers=1 105001 combat5.c:1239 - Tanker fuel=4500nm 105001 combat5.c:1243 - in the now refueling path 105001 combat5.c:1279 - about to start refueling unit_id=AB000 105001 combat5.c:1302 - first calculation fuel to add=15294s of Cruise fuel, plane has 12768s, loadout originally had 27653s 105001 combat5.c:1303 - first calculation fuel to add=520nm of Cruise fuel, plane has 434nm, loadout originally had 941nm 105001 combat5.c:1314 - 2765 seconds (94 nm) of Cruise fuel added to DropTanks 105001 combat5.c:1358 - returning to wait 180s for refuel completion 105181 combat5.c:1220 - Processing Refuel Event for Group=ABA 105181 combat5.c:1231 - tanker unit=AB002, numtankers=1 105181 combat5.c:1239 - Tanker fuel=4500nm 105181 combat5.c:1243 - in the now refueling path 105181 combat5.c:1279 - about to start refueling unit_id=AB001 105181 combat5.c:1302 - first calculation fuel to add=15294s of Cruise fuel, plane has 12048s, loadout originally had 27653s 105181 combat5.c:1303 - first calculation fuel to add=520nm of Cruise fuel, plane has 409nm, loadout originally had 941nm 105181 combat5.c:1314 - 2765 seconds (94 nm) of Cruise fuel added to DropTanks 105181 combat5.c:1358 - returning to wait 360s for refuel completion 105541 combat5.c:1220 - Processing Refuel Event for Group=ABA 105541 combat5.c:1231 - tanker unit=AB002, numtankers=1 105541 combat5.c:1239 - Tanker fuel=4500nm 105541 combat5.c:1243 - in the now refueling path 105541 combat5.c:1248 - No units left to refuel 105541 combat5.c:1267 - tanker is returning to base Yes, there are still fudge factors that let the tanker give too much fuel.

HCE - 2015.007 - 2015-06-05 ========================== - Chg:0000 GE Removed the strange 128 offset from air refueling events. - Chg:0000 GE Revamped aerial refueling logging to be more useful. - Chg:0000 GE Fixed logic that would have resulted in groups with more than 15 air units to be refueled being fed random information leading to crashes. - Chg:0000 GE Got rid of the aerial refueling code that would pump twice as much fuel into a plane as it can carry... - Chg:0000 GE Disabled some iterative save logging. - Chg:0000 GE Disabled HandleSavedGameScroll logging.

I imagine part of the decision had to do with concern that refueling a tanker takes away valuable fuel from non-tanker AC.

Thanks Enrique! Any time your benefactors want to fly me over to give a technical brief just let me know .

Why shouldn't tankers refuel other tankers? I have a feeling it isn't allowed in the code to reduce complexity but since we're in there digging around, is there a better reason?

The below is as of GE version 2015.006 We have the refueling event structure: typedef struct AirRefuelEvent { - char targetGroup[4]; /* group being refueled */ + uchar fuelingUnit; /* unit with the gas */ + uchar now_refueling; /* have we started refueling? */ + long fuel_range; /* how much fuel */ - ushort which_plane_type; /* what kind of plane is tanker*/ - uchar planestofuel_ids[16]; /* how many left to do? */ - ushort fuel_per_plane[16]; /* how much fuel */ + uchar side; /* which side */ + uchar num_tankers; /* how many tankers in unit */ } AirRefuelEvent, * AirRefuelEventPtr; The elements starting with a + are set by the requestor of a refuel event. The elements starting with a - are interestingly enough not set by the requestor. Some of them are set when the initial refuel event is processed. Set during processing of original refuel event: a. planestofuel_ids[16]; b. fuel_per_plane[16]; (may be calculated wrong in 2015.006 and older, testing fix) Never used: c. which_plane_type; d. targetGroup[4]; Obvious questions: e. Oh why can only 16 of a possible 255 plane clumps be part of a refueling operation

HCE - 2015.006 - 2015-05-28 ========================== - Chg:I111 SE Implemented, "1. EC2003 Built-in scenarios will use the names from the database." (thanks CV32 and gang) http://harpgamer.com/harpforum/index.php?/tracker/issue-111-installations-annex-mismatch/ HCE - 2015.005 - 2015-05-28 ========================== - Chg:I108 GE Picking away at memory leaks and standardizing on NewPtr/DisposPtr for memory management. Might fix the listed issue. http://harpgamer.com/harpforum/index.php?/tracker/issue-108-heap-corruption-detected/ - Chg:I109 GE Possible fix for too many "Got em all" point defense messages. http://harpgamer.com/harpforum/index.php?/tracker/issue-109-point-defence-debug/ - Chg:I111 GE Implemented, "1. EC2003 Built-in scenarios will use the names from the database." (thanks CV32 and gang) http://harpgamer.com/harpforum/index.php?/tracker/issue-111-installations-annex-mismatch/ - Chg:0000 GE Fueling operations have been moved into their own HCEffect, HCEffect21 using the new function CheckGroupFuel. This effect can be overridden via HCEffect21 in ExportDLL interface >= 9. This includes a new saved game file format. Any saves made with this version will not open in prior versions of the GE. Existing saves from the last few years will be automatically converted to the new format when loading. - Chg:0000 GE Moved decrementing of aircraft fuel from Display.c MoveUnits to Staff.c CheckGroupFuel so that it can be replaced in ExportDLLs via HCEffect21.

This new HC Effect now also includes decrementing the amount of fuel on planes so if the ExportDLL writer wants to adjust fuel burn rates for Red vs. Blue or Burner vs. Military, it will be possible. Or in my case I turned off AvGas usage entirely for my test.

Fueling operations have been moved into new HCEffect21 aka CheckGroupFuel for 2015.005. More later this week with a hope to make 2015.005 available before the weekend is through.

By chance are you using a non-US English language in Windows? In that case there is a small possibility the program is trying to use a comma as the decimal separator instead of a period. Just a random thought from bitter experience.

I like the implicit simplification you are suggesting but not detailing here. With the CIC Warfare Plotter I was headed towards uncertainty zones for "unknown" units but that becomes a real logistical nightmare for the ref maintaining the parameters of the uncertainty zone. Certainly it would be fun to add at some point but no need to get hung up on it at this stage.

Thanks guys and especially Brad for throwing together the Issue Report, please comment there on options for dealing with the problem. http://harpgamer.com/harpforum/index.php?/tracker/issue-111-installations-annex-mismatch/

I like them, even if they are not working as intended, the grid still helps imho.

Of course not . Effect20 does a number of other things but I didn't have time to document them last night. My gut reaction is to move the refueling check into its own HCEffect. We have around 20 available slots. In any event I'll document everything that Effect20 does then we can discuss the optimal approach.

Notes for investigating air to air refueling. Automatic refueling is instigated from CheckStaff. CheckStaff is called in a few places, the key one being CheckGroupStaff. CheckGroupStaff is Harpoon Effect #20, in ExportDLL parlance, HCEffect20. In other words, if one wants to replace the built-in auto-refueling behavior, HCEffect20 must be handled in an ExportDLL instead of in the stock GE. General Process: 1. Effect21/HCEffect21/CheckGroupFuel decides a refuel is merited and creates a AirRefuelEvent that will be processed in 30 seconds. 2. AirRefuelEvent is processed after those 30 seconds, game decides how much fuel to give to each recipient plane. Each refuel event can only involve a single tanker unit even if there are more in the group. Here it is decided how much fuel to give to each recipient. Remember that there can be multiple aircraft of the same loadout with the same type in an air unit (so a single air unit may have up to 255 aircraft). If the group is travelling at Cruise the actual refuel of the first recipient will start in 30 seconds, otherwise queue up a speed change. 3. Fuel is given to the first recipient. Delay until next recipient is 180 seconds * number of planes in the air unit. 4. Fuel is given to next recipient. Delay until next recipient is 180 seconds * number of planes in the air unit. 5. Repeat until no more recipients. 6. Tanker may RTB or stay with group More to come...

You should be able to attach your zip file to a message in this forum. I would suggest starting a new thread with a topic like "SimPlot by kmart494 download" and attach it to that. If there is a lot of action and/or frequent updates, we can add a download section.