[Tutorial] Weapon proxy handling on Planes & Choppers

[[frl]myke 14]

Hello everyone.

Recently i realized that even these days there are planes released that uses some fancy object hiding and setObjectTexture methods to have different weapon loadouts. Basically the same methods as Franze has used on his F/A18 back in Armed Assault. While at that time, this was just a work of genius, today it is not necessary anymore as the weapon proxy system has been massively improved in ArmA 2.

The only explanation i have for this is, that people aren't familiar with all possibilities the reworked proxy handling allows today. So i decided to write down what i know about and also how i actually do use it.

Be warned, you shouldn't be absolute beginner although it isn't rocket science either.

Required knowledge:

- basic modelling skills

- basic knowledge of O2

- basic knowledge of config files

- creating ammo in cfgAmmo

- creating magazines in cfgMagazines

- creating weapons in cfgWeapons

So don't expect a modelling tutorial, this topic is already pretty well covered. It really focus on how the proxy system works and what's possible with it.

Hope it is of any use for you out there. And please forgive me, i'm not that good at explaining things and english isn't my native language but i tried my best.

Download:

http://dl.dropbox.com/u/9367994/proxy_tutorial.pdf

[jagheterjan 10]

Thanks Myke, much appreciated

[[aps]gnat 28]

Nice! Thanks Myke.

I had most of this aready figured, but the "invisibleMag" trick was probably a much better way of managing the "flexibility" than what I was trying, which was using the HIDE animation to disappear the whole proxy.

[t_d 47]

Great, always good to see new tutorials. For the problem of weapons that are fired appearing at the model center instead of the proxy position: This is probably because of missing cfgNonAIVehicle class defining it as missile proxy. BIS shapes of course should have these classes and that's why your fix works.

[[frl]myke 14]

@T_D

already tried to solve this problem to no avail. However, it isn't a critical problem as it can be easily solved by using BIS proxies. Although if you have further info about it, feel free to share them here. ;)

[t_d 47]

I have no hard facts about it, but I know that cfgNonAIVehicles class is for proxy definitions and the classes seems to follow some naming conventions(which I dont know) like islands objects need to start with Land_ or CfgModel classes needs to use the p3d name.

[[aps]gnat 28]

Myke,

TD's onto the link I think, I also use cfgNonAIVehicles and have no such issue.

I recently noticed the Missilebox was missing these definitions.

[Gnome_AS 10]

Another great read there Myke, thanks again for sharing and putting this together. Very much appreciated. :)

.

[PuFu 4600]

nice one Myke. Thanks for taking your time to wite it down

[[aps]gnat 28]

Myke

Think I can see now why your CfgNonAIVehicles is not working for you.

If I'm not wrong, the class name must = the word "Proxy" plus the exact name-of-the-p3d file

Hence an example, your missilebox p3ds;

class ProxyGLT_KAB500L_proxy : ProxyWeapon
{
	model = "\glt_missilebox\GLT_KAB500L\GLT_KAB500L_proxy"; 
	simulation ="maverickweapon";
};
class ProxyGLT_KAB250L_proxy : ProxyWeapon
{
	model = "\glt_missilebox\GLT_KAB250L\GLT_KAB250L_proxy"; 
	simulation ="maverickweapon";
};
class ProxyGLT_FAB500 : ProxyWeapon
{
	model = "\glt_missilebox\GLT_FAB500\GLT_FAB500"; 
	simulation ="maverickweapon";
};

[[frl]myke 14]

Thanks Gnat. One question though: am i right that the proxyShape is relevant? As you know, you can have 2 separate models per ammo, one being the model shown attached to the plane, the other inflight. Mostly they are identical but there are a few with different models, mainly unfolding winglets.

Looking at BIS config, it seems that proxyshape is relevant just would like to have this confirmed.

Btw, the test config i sent you already contains those proxy definitions for all weapons of the Missilebox, so if you have a minute to check if it works correct, i would really appreciate it, mate.

[[frl]myke 14]

Ok, something interesting happened. Somewhere in the past, BIS changed the loading and reloading for proxy weapons. Don't know when but with >1.60, a annoying bug is removed and opens up new possibilities.

Old behaviour (bug):

When loading 2 magazines of the same type, like 2 magazines with 2 GBU12 to sum up to 4 rounds totally, the weapons showed 2 "bullets" and 1 magazine remaining (like you're used to it with rifles, as example).

So the selected weapon showed:

GBU-12
2|1 

So far nothing dramatic. Problem was, when the first 2 rounds were dropped (magazine emptied), the weapon reloaded and the 2 bombs from the second magazine switched pylons to where the first 2 rounds were, looking rather odd.

This led to the following "problems":

- you couldn't have more than one magazine of one weapontype without this ugly "pylonswitching" midflight.

- you couldn't have, for the same reason, intermitting loads like aim9/gbu12/agm65/gbu12/agm65/aim9 or variations of this without making different plane models with different proxy numbering.

Now, this has been fixed. Multiple magazines are not longer shown as bullets|magazines but as a total of "bullets". So adding 5 magazines with one round each doesn't look like this anymore:

GBU-12
1|5

but like this:

GBU-12
5

The weapon doesn't reload magazines anymore like a rifle but it counts all available magazines for the respective weapon type. You can also have intermitting load. The following example is a valid loadout and works without any bugs:

       magazines[] = {
           "1350Rnd_30mmAP_A10",
           "FRL_1Rnd_DUALRAIL",
           "FRL_1Rnd_ANAAQ28",
           "FRL_1Rnd_GBU12",
           "FRL_1Rnd_GBU12",
           "FRL_1Rnd_GBU24",
           "FRL_1Rnd_GBU24",
           "FRL_1Rnd_GBU12",
           "FRL_1Rnd_GBU12",
           "FRL_1Rnd_GBU12",
           "FRL_1Rnd_AIM9M",
           "FRL_1Rnd_AIM9M",
           "FRL_empty_1",
           "FRL_empty_1",
           "120Rnd_CMFlare_Chaff_Magazine"
       };
       weapons[] = {
           "GAU8",
           "FRL_AIM9M_Launcher",
           "FRL_GBU12_Launcher",
           "FRL_GBU24_Launcher",
           "CMFlareLauncher"
       };

The proxy numbering remains important like before. The example was made for the BIS A-10 from the A1 sample models (remember, this one didn't had the dualrail for the AIM-9, this was introduced with A2).

So on the left outermost pylon it loads a dualrail, on the right outermost a AN/AAQ28 targeting pod. Then the following pylons (one left, one right) will hold a GBU-12 each. The next pair (one left and one right again) a GBU-24. The remaining 3 pylons (one centerline and one left/right each) hold GBU-12 again.

And this works. No matter in what order you fire the weapons, never any bomb/missile swapped the pylon midflight.

There is one remaining bug. If there are unused proxies at the end, the game restart filling on them until all proxies are filled.

The A-10 had the outermost pylons on each side prepared for a Dualrail and therefor 4 additional proxies. The first pair was filled with AIM-9M as you see in the config above. On the first try, the proxies on the other side (where the AN/AAQ28 was and therefor no proxy wepons should be), the game attached a Dualrail and a AN/AAQ28 to the proxies which were meant to hold AIM's in case of a second Dualrail instead of the targeting pod.

Simple fix: adding empty p3d magazines like described in the PDF in the first post.

[[aps]gnat 28]

Very interesting thanks Myke.

I will have to re-read and absorb/experiment the "new" way this works ........

[[frl]myke 14]

Basically it's pretty easy. You have your numbered proxies:

001|002|003|004|005|006

Now working with single round magazines, each magazine/weapon will fill up the respective proxy:

AIM-9M|AGM-65|GBU-12|AGM-65|AGM-65|AIM-9M

Only bug so far, if you have more proxies which should stay empty, even if they are at the end, you have to fill them with empty mags like provided in the Missilebox. You know, GLT_Empty_X.

[[aps]gnat 28]

Myke,

When you add an actual proxy model to an aircraft p3d file, are you still using 1 single standardised p3d model for EVERY proxy location?

From memory you were using an aim9 p3d.

(Exception might be FFAR pods?)

And this works with the above desribed method?

I've always modeled the p3d proxy that was actually intended for that location, then obvious loaded magazines that get the same visible.

[[frl]myke 14]

At first i used the BIS AIM9x model as proxy, as at the beginning i had problems with missiles not spawning at the correct place but in the center of the plane. But you've pointed me towards the CfgNonAIVehicles and now i use mixed proxies, as long as they have a proper CfgNonAIVehicles definition.

Most important thing that matters: numbering. No (weapon) proxy number should be given twice. This usually happens when creating a proxy AB first and a proxy XY afterwards. As soon the used model changes, O2 restarts numbering. But you can fix that manually afterwards by right-click the proxy in the selections window and select "rename". There you can change the number manually.

FFAR pods, if not "hardmodelled" to the plane, can also applied as cfgMagazines/cfgAmmo combo. Define those as you would any other missile/bomb. What you see on the plane are cfgMagazines. If there is no weapon defined/loaded, you just can't fire them.

Speaking of FFAR pods, you load a magazine for the pod and of course a regular FFAR rocket magazine and weapon for firing.

[[aps]gnat 28]

Thanks Myke.

Yeh, I was thinking that you might be renumbering them.

I'm beginning to see that if you use just 1 proxy type and make the 90deg corner your center reference point for any "hanging" on an airplane model, then things become much easier.

If you then adjust the actual missile or bomb so that it's "hang" point is 0-0-0 in O2, then it all works out.

Just like using your MissileBox weapons .....

BTW, if found that too many properties in a P3D model will cause the weapon model to be off-center despite careful alignment of the proxy (in plane) and weapon to 0-0-0 within O2.

Several models I've had to cut the properties back/delete to bare minimum (usually LODNoShadow=1 and autocenter=0) ...... but oddly I've had to re-start O2 and Buldozer to get the changes to take effect.

Thanks! ..... back to work.

[teacup 2]

Has anyone figured out how things work in A3, regarding weapons/magazines/proxies on aircraft? 4 days into it, and i can't make sense of anything, it's such a royal, unpredictable, unintuitive mess.

I hoped making the correct proxies (referencing the correct weapons/mags), properly indexed, and then adding the magazines in config, would result in a simple, working loadout. I had no ambitions of dynamic or flexible loadouts, just basic stuff. Was i in for a lot of headscratching..

First oddity is that missiles "travel" down the hardpoints: remove all mags from the Wipeout, then add "2Rnd_Missile_AA_04_F", and fire them. Repeat. Even though all hardpoints are empty, the newly added missiles are not placed on the base hardpoints numbered 1 and 2, but 3-4, 5-6, and so on, untill all hardpoints are used up and missiles start coming from the center of the aircraft. Can these planes be properly rearmed via scripts, even with their original loadout?

The other weird thing is ammo multiplication: you add a 2 round mag, it shows 4 bits of ammunition, you add a 4 round mag and it shows 10 bits of ammo, provided you have enough proxies they can populate. Is this a bug or a feature? What's the logic?

Then come the odd combinations: 2 round mag AA + 2 round mag AGM = asymmetric loadout (showing 3 x AGM + 1 x AA), even though proxies are ordered correctly, even numbers on one side, odds on the other. After all ammo is fired one AGM still hanging onto a pylon (?).

To make matters more complicated, A3 comes with some new stuff to pile onto the old: model.cfg has some stuff for hiding/showing different loadouts, Buzzard has some mistery MemoryLOD points called "missile_1", "missile_2", "missile_3" and "missile_4", and there's also this:

memoryPointLRocket = "Rocket_1"; /// use this for simulating different rocked pods in case you don't want to mess with "maverick weapon" simulation

memoryPointRRocket = "Rocket_2"; /// it is used to alternate two points/pods of fire the missiles

If anyone could shed some light on any of the above, i would be grateful. Otherwise i have to get back to testing, isolating, trying to make sense of things, and i'd rather spend time more productively.

[FobiaBG 1]

On 1/11/2011 at 7:50 AM, [frl]myke said:

Hello everyone.

Recently i realized that even these days there are planes released that uses some fancy object hiding and setObjectTexture methods to have different weapon loadouts. Basically the same methods as Franze has used on his F/A18 back in Armed Assault. While at that time, this was just a work of genius, today it is not necessary anymore as the weapon proxy system has been massively improved in ArmA 2.

The only explanation i have for this is, that people aren't familiar with all possibilities the reworked proxy handling allows today. So i decided to write down what i know about and also how i actually do use it.

Be warned, you shouldn't be absolute beginner although it isn't rocket science either.

Required knowledge:

- basic modelling skills

- basic knowledge of O2

- basic knowledge of config files

- creating ammo in cfgAmmo

- creating magazines in cfgMagazines

- creating weapons in cfgWeapons

So don't expect a modelling tutorial, this topic is already pretty well covered. It really focus on how the proxy system works and what's possible with it.

Hope it is of any use for you out there. And please forgive me, i'm not that good at explaining things and english isn't my native language but i tried my best.

Download:

http://dl.dropbox.com/u/9367994/proxy_tutorial.pdf

Hello! Can you reupload please? I'm having a hard time with proxies and cfg :(((((