Aerial Refueling

[wld427 1705]

I would definately add it to all the PRACS planes as well!

[Feint 137]

Thanks for the support and ideas. The way it works now is I have set up a switch like this:

_caller = _this select 1;
switch (typeOf (vehicle _caller)) do
                                   {
                                       case "AV8B": {_vehicleCaller attachTo [_tankerPlane, [-11.25,-61.22,-4.43]]}; // DONE
                                       case "AV8B2": {_vehicleCaller attachTo [_tankerPlane, [-11.25,-61.22,-4.43]]}; // DONE
                                       case "AH64D": {_vehicleCaller attachTo [_tankerPlane, [-13.40,-66.00,-3.60]]}; // DONE
                                       case "AH64D_Sidewinders": {_vehicleCaller attachTo [_tankerPlane, [-13.40,-66.00,-3.60]]}; // DONE
                                       case "AH64D_EP1": {_vehicleCaller attachTo [_tankerPlane, [-13.40,-66.00,-3.60]]}; // DONE
                                       case "AH6J_EP1": {_vehicleCaller attachTo [_tankerPlane, [-12.40,-61.00,-2.60]]};
                                       case "AH6X_EP1": {_vehicleCaller attachTo [_tankerPlane, [-12.40,-61.00,-2.60-12.40,-61.00,-2.60]]};
                                       case "MH6J_EP1": {_vehicleCaller attachTo [_tankerPlane, [-12.40,-61.00,-2.60]]};
                                       case "CH_47F_EP1": {_vehicleCaller attachTo [_tankerPlane, [-11.40,-68.50,-1.70]]};
                                       case "CH_47F_BAF": {_vehicleCaller attachTo [_tankerPlane, [-11.40,-68.50,-1.70]]};
                                       case "MH60S": {_vehicleCaller attachTo [_tankerPlane, [-12,-69,-0.25]]};
                                       case "UH60M_EP1": {_vehicleCaller attachTo [_tankerPlane, [-12,-69,-0.25]]};
                                       case "UH60M_MEV_EP1": {_vehicleCaller attachTo [_tankerPlane, [-13.10,-68.00,-2.00]]};
                                       case "MV22": {_vehicleCaller attachTo [_tankerPlane, [-13.10,-68.00,-2.00]]}; // DONE
                                       case "AH1Z": {_vehicleCaller attachTo [_tankerPlane, [-11,-62,-2.25]]};
                                       case "UH1Y": {_vehicleCaller attachTo [_tankerPlane, [-11,-59,-2.25]]};
                                       case "UH1H_TK_EP1": {_vehicleCaller attachTo [_tankerPlane, [-11,-59,-2.25]]};
                                       case "UH1H_TK_GUE_EP1": {_vehicleCaller attachTo [_tankerPlane, [-11,-59,-2.25]]};
                                       case "USEC_ch53": {_vehicleCaller attachTo [_tankerPlane, [-13.67,-68.30,-3.98]]};
                                       case "14US": {_vehicleCaller attachTo [_tankerPlane, [-13.65,-63.62,-4.43]]}; // DONE


                                       default {_vehicleCaller attachTo [_tankerPlane, [-9.2,-64,-2.25]]};
                                   };

So if your plane's classname isn't in the code, there's a default value that will be applied to that new classname (by default). It might not line up perfectly, but it won't be too far off. And the script can always be updated with new classnames.

I'm planning on switching from typeOf to isKindOf in order to catch more classes without having to define the classes individually. With the Arma2 in-game weapon loadouts being a limitation for addon makers, aircraft addon designers are creating a dozen classnames for a single plane with the only difference being the different loadouts. That's a lot to type out for one plane. So isKindOf would be more appropriate, because then I could just have:

switch ((vehicle _caller) isKindOf) do
                                        {
                                            case "AV8B": {blah blah blah};
                                        };

and that would take care of the AV8B and the AV8B2 as well as any reskins with different classnames. And as long as the new AV8B reskins or slightly different models weren't too far off of the original, the plane would still line up (depending on the changes to the original design).

As for designating a specific memory point, I'm not sure I know how to do that as I don't have any experience with 3d modeling. I could say that the default value would be [0,0,0] attachTo placement for all new aircraft, and then aircraft makers would have to design their planes offset to the side, down and back in order to line up with the refueling module, but wouldn't that make things a lot more difficult for aircraft makers in terms of...everything?

Now, building on [FRL] Myke and RKSL-Rock's idea, if the plane itself had a part named "refuel_probe", and my script could just be something along the lines of:

_fuelProbe attachTo [_newAirPlane, [0,0,0], refuel_probe];

or something, then yes that would make things much much easier. Unfortunately, in the above example, the fuel probe would be controlled by the plane being refueled which is the reverse of what I am currently doing. Ideally, the plane that needs to be refueled is controlled by the refueling plane or the refueling drogue or whatever the case may be. So I'd have to figure some reverse of that, but...well, there you have it. I'm open to ideas.

I'll add something to the readMe file when I release encouraging addon makers to designate a refueling portion of their planes with "refuel_probe" and "refuel_socket". Beyond that, I'm not sure what else I'd need. Then if addon makers start doing that, I can update the script and work with you guys ahead of time to get it to work universally.

Edited February 3, 2012 by Feint

[raptor 6 actual 13]

I'm not trying to beat a dead horse here, pardon the expression, but by following the suggestions of naming the probe as a memory point, you also allow mission makers the ability to script sound files relative to the proximity of the drogue. For example, if the approaching aircraft is level in flight with the drogue, but 30 feet away, a sound file would trigger saying "30 Feet!" Or if he's too high, too low, etc.,etc.,etc,. I think you get the point.

I think you've opened a whole new can of worms here and though I know what I just mentioned is step 1000 when you're basically at 200 and maybe beyond your scope of focus right now, you've still given people a lot to think about. Following eagerly!

[Feint 137]

Well, there is a "distance from probe" or "distance from drogue" that tells you how far away you are. You have to get within 2 meters of the red sphere to actually hook up, and you have to stay within that distance for around 1 second. So it will take some practice to get good. I know what you're saying though.

Thanks for the suggestions from everyone. I'll be finishing up some testing and more classname stuff. Then I want to reposition the red spheres to be more accurate and I want them to disappear when you hook up to the drogue or boom, not after tanking is complete. So hopefully I'll be able to release something very soon that you can all play with.

[[frl]myke 14]

First of all, don't think we're trying to tell you how you have to make your addon, just throwing ideas and see what comes out.

Picking up the idea with the memory point, the command selectionPosition could pick a specific memory point which has the function of determing the exact refuel position. It returns a positional value based on modelspace from which you could calculate a offset value for the attachTo.

You don't even have to insist of a specific name, just say it needs a additional config entry (which is perfectly possible to insert in any config) which holds the name of the memory point as a string.

FEINT_probePosition = "name_of_memorypoint";

So in your code you could check if this config entry of the actual plane exists, if yes, gather the name of the selection with getText and then do the required calculations.

:EDITH:

As for designating a specific memory point, I'm not sure I know how to do that as I don't have any experience with 3d modeling.

You don't have to have any experience in modelling, it is sufficient to know that modelmakers will include such a memory point and the respective config entry. ;)

If the config entry doesn't exist you still can use your predefined code or the default values as you already do now.

[rksl-rock 1300]

I'll add something to the readMe file when I release encouraging addon makers to designate a refueling portion of their planes with "refuel_probe" and "refuel_socket". Beyond that, I'm not sure what else I'd need. Then if addon makers start doing that, I can update the script and work with you guys ahead of time to get it to work universally.

Ok I've added the named points to :

• Typhoon V2.0
  
• Tornado V1.0B
  
• Harrier V0.9B
  
• F-16C V0.8B
  
• F-35C
  
• JAS39 Gripen
  
• J20
  

and all the IAP and WIP stuff with the appropriate equipment.

[Feint 137]

Great! Thanks you guys. I think this will make things a lot easier.

RKSL-Rock, are you releasing the updated versions of your aircraft any time soon? I'd like to play around and see if I can make this new idea work.

Myke, I might be coming to you for some more advice on how to do this. :)

Edited February 3, 2012 by Feint

[rksl-rock 1300]

The typhoon is nearly ready. Its got some 1.6 blues atm but i can sort a pre release version to help you test. I'll PM you tomorrow with a link.

[wld427 1705]

You now have me looking for a PRACS tanker aircraft :)

Are we using the memory point "refuel_probe" for the drouge and "refuel_socket" for the recepticle like on the F-16?

Edited February 3, 2012 by wld427
question

[Feint 137]

@Rock, Thanks!

@wld427, yes. That's the plane plan. :)

[raptor 6 actual 13]

I just wanted to pop in and again say thanks to Feint and everyone else that's given suggestions. By no means did I mean to convey any disrespect by "forcing" a request on you, and I'm not saying any body is throwing that charge around. This is a great development for those of us that have actually been on board the KC-135 and seen the day to day operations of what goes on thousands of feet above the ground.

Again, Great work and hope to play it soon.

[Feint 137]

No need to apologize at all. I think it is great that we have an active community that throws around ideas. I never feel forced to accommodate any requests of any projects I'm working on. On the contrary. I always love hearing about new ways to do things smarter and more realistically. And if there are other mod makers out there who think, "Hey, let's do this and then it will cut your work in half once the coding is done" then I'm all for that. Definitely!

UPDATE:

Holy crap, I think I figured this out. Thanks to RKSL-Rock lending me a preproduction plane with the memory point, I was able to write something that worked really well. :) I'm pretty stoked, to use a California term. Hehehe. :)

I made a short script that places a red sphere inside the basket of a refueling drogue. Then it finds the refueling_probe relative position, converts that position using modelToWorld, measures the distance between the refueling probe and the red sphere, and when the distance collapses to 2 meters or less, the plane attaches to the red sphere using the opposite of the offset of the refueling_probe memory point. Works perfectly on the ground. Now I just have to try it in the air. I could even collapse the minimum distance value to 1 or less so that I'd have to get the probe directly inside the basket before refueling would begin, but that might be torturous trying to fly that accurately.

QUESTION:

I have an x, y, z offset. I want to find the opposite of that offset. This is how I'm doing it now (see below). I'm not sure it would work in all cases of positive and negative offsets but it is working so far.

_caller = _this select 1;
_vehicleCaller = vehicle _caller;


_x = _vehicleCaller selectionposition "refuel_probe" select 0;
_y = _vehicleCaller selectionposition "refuel_probe" select 1;
_z = _vehicleCaller selectionposition "refuel_probe" select 2;

switch (true) do
   {
       case (_x > 0): {_x = 0 -_x};
       case (_x < 0): {_x = abs _x};
       case (_x == 0): {_x = 0};
   };
switch (true) do
   {
       case (_y > 0): {_y = 0 -_y};
       case (_y < 0): {_y = abs _y};
       case (_y == 0): {_y = 0};
   };
switch (true) do
   {
       case (_z > 0): {_z = 0 -_z};
       case (_z < 0): {_z = abs _z};
       case (_z == 0): {_z = 0};
   };

_vehicleCaller attachTo [attachedLeftSphere, [_x,_y,_z]]

Do you guys have a better solution to find the opposite of an offset value?

Also, my mind is zapped at the moment. I need to figure out if a vehicle has this memory point. If the memory point name isn't in the config, is there a way I can just check the model directly? Myke, you mentioned getText, but can you give me an example? The wiki and comref don't have very much to go on. Maybe you can save me some trial and error.

I could do something like this:

if (_vehicleCaller selectionposition "refuel_probe" = (0,0,0)) then {hint "refuel_probe is not present"};

but that seems inelegant. Suggestions?

Edited February 5, 2012 by Feint

[[frl]myke 14]

Myke, you mentioned getText, but can you give me an example? The wiki and comref don't have very much to go on. Maybe you can save me some trial and error.

Sure, i'll try, although i suck at explaining things but i'll do my very best.

As you may know or not, a config.cpp can also contain self-defined configvalues. I need this (as an example) in my Missilebox to define if a weapon is GPS/INS guided or not. By default there is no such config parameter so i introduced it myself:

class cfgWeapons {
class GLT_BombLauncherBase;
class FRL_GBU31_Launcher: GLT_BombLauncherBase {
	scope = public;
	displayName = weaponName;
	magazines[] = {
		"FRL_2Rnd_GBU31",
		"FRL_4Rnd_GBU31",
		"FRL_6Rnd_GBU31",
		"FRL_8Rnd_GBU31",
		"FRL_16Rnd_GBU31",
		"FRL_24Rnd_GBU31"
	};
	GLT_isGPSguided = 1;
};
};

Take note of the config entry "GLT_isGPSguided". Now in a script i can get this value by using getNumber command:

_value = getNumber (configFile >> "cfgWeapons" >> "FRL_GBU31_Launcher" >> "GLT_isGPSguided");
if (_value == 1) then{
  ....do some fancy stuff here;
};

So what you could do, first i think you should set default values to class "Air" like this:

class cfgVehicles {
class AllVehicles;
class Air: AllVehicles {
	memoryPointRefuelProbe = "";
	memoryPointRefuelSocket = "";
};
};

This defaults both values for probe and socket to a empty string. Addon makers would now just insert the selection name into the respective config entry. By using getText on the actual plane, you either get a empty string on both config entries, which means the addon isn't prepared for your refueling system and you can switch to some default procedure. Or it will give you a string for a selection name (memory point) which you now can use to line up the plane with the correct refueling system.

Also addonmakers are free in naming the memory point as you could read it out from the config.

I hope i wasn't too complicated in explaining. If you have questions, feel free to visit my profile and get my ICQ or MSN contact data. ;)

Edited February 5, 2012 by [FRL]Myke
Typos fixed

[Feint 137]

So when I'm writing my script, I should write something like,

_probeName = 
[left][color=#333333]getText (configFile >> "cfgVehicles" >> "[/color][color=#333333]memoryPointRefuelProbe[/color][color=#333333]");[/color][color=#333333]_socketName = getText (configFile >> "cfgVehicles" >> "memoryPointRefuelSocket");
[/color][/left]

But how do I write it so the script runs getText on the aircraft in question? I would think it would be something like getText (vehicle _caller) (configFile... etc. Or is it (vehicle _caller) getText (configFile... etc.?

[[frl]myke 14]

Well, at the beginning of the script you probably have something to catch the plane object, maybe like this:

_plane = _this select 0;

In this case, the variable _plane is holding the plane object which needs refueling (not the tanker, to avoid confusions).

The Synthax for getText is:

getText (configFile >> "cfgVehicles" >> "PLANES_CLASSNAME" >> "DESIRED_CONFIGVALUE")

Used on your example and the above _plane variable, this would look like this:

_probeName = getText (configFile >> "cfgVehicles" >> (typeOf _plane) >> "memoryPointRefuelProbe");
_socketName = getText (configFile >> "cfgVehicles" >> (typeOf _plane) >> "memoryPointRefuelSocket");

Now if you defaulted both configentries in a baseclass to a empty string "" , you just have to compare if one of both actually has a string inside. If both are just "", you know that there isn't any memory point defined and you can switch to some generic routine or, if you have predefined routines for the actual plane, switch to those.

[.kju 3244]

A few config and scripting design thoughts:

1) To have a default for a new custom config value only makes sense, if you can define an useful default.

newValue = ""; is as good as not having such default.

So this is mainly an artistic choice.

b) A good design would be for a script only version:

1) Look for config value

2) If found for given class, use it

3) Otherwise look in script for definitions for the given class

4) If no luck either, use a default or skip completely.

c) If you do an addon only version anyway, you can just define all defaults for BI planes/choppers in your custom config part of the addon.

d) Little SQF design advice - this is much nicer:

_caller = _this select 1;
_vehicle = vehicle _caller;

_position = switch (true) do
{
case (_vehicle isKindOf "AV8B"):		{[-11.25,	-61.22,		-4.43]};// DONE
case (_vehicle isKindOf "AV8B2"):		{[-11.25,	-61.22,		-4.43]};// DONE
case (_vehicle isKindOf "AH64D"):		{[-13.40,	-66.00,		-3.60]};// DONE
case (_vehicle isKindOf "AH64D_Sidewinders"):	{[-13.40,	-66.00,		-3.60]};// DONE
case (_vehicle isKindOf "AH64D_EP1"):		{[-13.40,	-66.00,		-3.60]};// DONE
case (_vehicle isKindOf "AH6J_EP1"):		{[-12.40,	-61.00,		-2.60]};
case (_vehicle isKindOf "AH6X_EP1"):		{[-12.40,	-61.00,		-2.60]};
case (_vehicle isKindOf "MH6J_EP1"):		{[-12.40,	-61.00,		-2.60]};
case (_vehicle isKindOf "CH_47F_EP1"):		{[-11.40,	-68.50,		-1.70]};
case (_vehicle isKindOf "CH_47F_BAF"):		{[-11.40,	-68.50		-1.70]};
case (_vehicle isKindOf "MH60S"):		{[-12,		-69,		-0.25]};
case (_vehicle isKindOf "UH60M_EP1"):		{[-12,		-69,		-0.25]};
case (_vehicle isKindOf "UH60M_MEV_EP1"):	{[-13.10,	-68.00,		-2.00]};
case (_vehicle isKindOf "MV22"):		{[-13.10,	-68.00,		-2.00]};// DONE
case (_vehicle isKindOf "AH1Z"):		{[-11,		-62,		-2.25]};
case (_vehicle isKindOf "UH1Y"):		{[-11,		-59,		-2.25]};
case (_vehicle isKindOf "UH1H_TK_EP1"):		{[-11,		-59,		-2.25]};
case (_vehicle isKindOf "UH1H_TK_GUE_EP1"):	{[-11,		-59,		-2.25]};
case (_vehicle isKindOf "USEC_ch53"):		{[-13.67,	-68.30,		-3.98]};
case (_vehicle isKindOf "14US"):		{[-13.65,	-63.62,		-4.43]};// DONE

default						{[-9.2,		-64,		-2.25]};
};

_vehicleCaller attachTo [_tankerPlane,_position];

[max power 21]

And here is an interesting visual bug. Here I'm refueling and clearly attached accurately to the drogue, but in the cockpit view, the edge of the drogue doesn't overlap the nozzle. It seems to be a visual bug with the Arma2 engine because even if I move the drogue closer to the cockpit, the drogue never overlaps the nozzle.

I think this bug is a result of the viewPilotLOD always being rendered last. This is so your cockpit never shows anything like leaves interpenetrating the structure of the vehicle when you're driving under a tree, for example, or grass never comes through the floor. Also, it hides the occasion that an infantryman's rifle goes through a wall or something.

There is an interesting counter-bug to your bug. I've troubleshot a bug where if an extremely long weapon proxy (such as a machinegun) used a long muzzle flash model instead of a proxy, increasing its length even longer, would always be drawn before the soldier's hands. It looked like the hands were always closer to the camera than the weapon. I think this has something to do with the center of the bounding box of the proxy being farther away than the extents of the character. Maybe you can use this to your advantage somehow. Perhaps you can make a probe model proxy with some long trangles on the end of LOD 0 with an alpha transparent texture on them. If you make them long enough, you might be able to fake your way out of this viewpilotLOD artifact.

Edited February 8, 2012 by Max Power

[CyclonicTuna 87]

Wow! This pretty cool! I saw the sceenshots, but one question. When the module is released will it come with the KC-130? I'd really like to see this implemented in Rough Knight's Carrier operations Duala campaign

[Feint 137]

Wow! This pretty cool! I saw the sceenshots, but one question. When the module is released will it come with the KC-130? I'd really like to see this implemented in Rough Knight's Carrier operations Duala campaign

Negative. The KC-135 is part of the JSDF Mod and is currently not available as a standalone addon. You could contact them though and ask them to just release their KC-135 plane as a separate download. :)

QUICK UPDATE:

FYI, this module is not dead. It's simply on hold as I am making more time for some of my other mods. As soon as I can finalize a few details on other mods I'm currently coding, I'll return to this and finish it up.

[Diener 1]

Hey Feint we fellow arma2 fans over at SIG Clan http://www.sigclan.com are very interested with the Aerial Refueling i still need to get in contact with Myke from FRL he can verify that i emailed him a few weeks back needing an account and a legit person with the ArmA2 community, if you could give me a pm on here or Armaholic or at my website which i submitted above it would be appreciated. Go Illinois Lol im about 3 hours to the south of you m8.

[Warsaw 1]

Looks great.

[Feint 137]

I had some computer issues for the past 8 months which I never had time to fix. I've started working on this project again. Hopefully I can make some headway on it in the next few weeks.

Shot an update video tonight:

[[frl]myke 14]

Looks extremely nice.

One question though: the hint, does it show the tankers radar altitude or barometric altitude?

[raptor 6 actual 13]

Great video Feint....and welcome back mate....I was getting worried you had drown in your own projects, lol.

[Feint 137]

@Myke, I used "getPos (name of tanker plane) select 2" as the indicator for the altitude of the tanker. So whatever that is. It should correspond to the altitude indicator in most stock aircraft cockpits. And it also corresponds to the flyInHeight that you can set for AI. It's not getPosATL nor getPosASL. I am now realizing that some of the maps have that "fake altitude" thing, right? I'll have to do some testing on other maps to see if there's a problem. So far I'm mostly just testing on Chernarus and Utes because the AI needs a lot of room to fly straight.

Thanks Raptor. It's good to be back. That's funny about drowning. That joke took me a second. :)