IAWS standard definition

[[FRL]Myke]

As now i've released Fotmunchs/edyD's F-16C for ArmA 2 and made it IAWS compatible, it's about time to introduce IAWS to the public and define some standards which should be followed to be IAWS compatible with it.

First of all:
What the heck is IAWS?

IAWS defines a standard which allows swapping weapons (missiles and bombs that are attached via proxies) between planes, no matter in which addon they come.
At long shot, i hope there will be a module which opens a dialogue to the pilot and there he can alter the loadout of his plane. You may look at Franze's F/A18 for ArmA 1 as he has such a weapon loadout dialogue included.

Now in ArmA 2, the proxy p3d applied in O2 no longer limits what weapon finally will be shown. Remember ArmA 1, a plane with 4 weapon proxies will always show 4 weapons of same type, even if you loaded 2 round Sidewinder and 2 round Maverick. You will either see 4 Mavericks or 4 Sidewinders.
There were some workarounds with scripting which worked pretty well, but it was still limited by ArmA 1 as they couldn't be altered easily.


So a IAWS plane will not work as standalone?
It will work as standalone as usual, no limits there. Ingame, you wont see any difference between a IAWS and a non-IAWS plane. So from this point, it has no downsides.


RULES FOR IAWS COMPATIBILTY

I hate to give rules and say "you have to..." but sadly it needs a few. But there are not a lot and all easily done.

Adaptions on MLOD: Plane
There are several rules to be followed in the planes MLOD

Placement of weapon proxies:
Unlike as it was done until now, weapon proxies are no longer placed referring to weapons center but to weapons upper edge.
http://www.armaholic.com/datas/users/372-proxies.jpg

This shows you a 3 point weapon holder. Note the lineup uf the proxies.

This has to be followed for all weapon proxies.

Named selections in memory LOD:
This change is mainly a help for any dialogue scripter as he can use the relative positions of these points to place the dialogue controls accordingly.
Just look from the front to your model and at each weapon holder place a memory point.
For naming you're free, i've used "IAWS_PylonX" where X is a number. So the F-16C has 10 of those memory points.

Offcentering weapons MLOD:
Of course, with such a proxy placement, any normal modelled weapon MLOD would be burried halfway into the pylon, so the weapon MLOD needs to be offcentered downwards so it's upper edge is zeroed and not the model center.
http://www.armaholic.com/datas/users/372-mk82.jpg
As you see, it's upper edge is aligned with the horizontal center line.
And it also needs the named property "autoCenter 0", as Snake Man pointed me to.

Additional rule for Proxy:
While i was working on the F-16 i've encountered the problem that the custom weapons (not BIS weapons) didn't worked properly. They were shown correctly but when firing, they spawned at planes center and the proxy wasn't removed.
So for proxy definitions in the MLOD, use standard BIS missiles or bombs unless you find out what changes need to be made that custom weapon MLODs and cfgAmmo work as intended.
Just use AIM9xSidewinder as proxy, i've used them on the F-16 and it works.
You may start with your own weapons for visual control and/or WIP screenshots, just redefine them to BIS weapons p3d later.

Proxy numbering:
Even with different proxy types, make sure the numbering is continuing through all proxyweapons. No double numbers allowed. You'll get double numbers if you apply different proxy shapes. First Sidewinder has .001 and also does the first Maverick you apply. Change them so its a continuing list.
Also keep a order for applying the proxies, goin from wingtips to center.
And alter always between left and right, so wingtips will be .001 and .002, upfollowing pylons .003 and .004 and so on until you reach the center.

Info about ArmA 2 addMagazine handling:
ArmA 2 fills the proxies in the order the magazines are added, be it in the config or via scripting. So if you add a 2 round sidewinder magazine and proxies .001 and .002 are placed on wingtips, Sidewinders will be applied there. Firing weapons follows reversed order so the Sidewinder on proxy .002 is fired first.

Well, thats all MLOD related, now to the config.

Planes config.cpp

There is one additional config entry in the plane's config:


iaws_pylons[] = {
{1,"iaws_pylon1"},
{2,"iaws_pylon2"},
{4,"iaws_pylon3"},
{4,"iaws_pylon4"},
{4,"iaws_pylon5"},
{4,"iaws_pylon6"},
{4,"iaws_pylon7"},
{4,"iaws_pylon8"},
{2,"iaws_pylon9"},
{1,"iaws_pylon10"}
};

First of all, the presence of this config entry already makes the plane identifable for scripts. If it's there, it is IAWS compatible.
The entry defines an array which defines all weapon holders available on the plane, starting from the left and goin to right.
The numbers defines which type of holder it is:
- Wingtip = 1
- Single = 2
- Multi = 4
- Body = 8
We need this later in the cfgWeapons where a missile/bomb can be attached. As example, it would look weird to have a Mk82 on the wingtips.

Weapons config:
In the weapons config, we need also just one additional line only:


iaws_type = 1 + 2 + 4;

Also this line already identifies the weapon (and its related magazines and ammo) as IAWS compatible for scripters.
This entry says where this particulary weapon can be mounted:
Wingtip + Single + Body
It can't be (or shouldn't be, for whatever reasons) mounted on Multiholders. Multiholders are those mechanisms which allow more than one missile on one pylon, check the F-16C, it has 2 Multiholders right next to the main body.

I don't know how this mathemathic definition scheme is called but i know it is also used by some other config entries.
It allows 2 different ways of defining:


iaws_type = 1 + 2 + 4;
iaws_type = 7;

The more experienced programmers will know this style, i'm definately not a pro. But i know this works and is easy enough to use, although the afterwards scripting may not be understood by everyone. :D

Not necesserly needed but surely welcome: please create magazines for 2, 4, 6 and 8 rounds, even if they're not needed for your actual project.

Wow, this has become a damn long text. I hope you understand the meaning of all, else just ask and i will try to get more precise.


:ADDITION:
The definition needs an small extension. Right now it isn't defined to which (manufacturer) side weapons and/or plane belongs to. So there is no possible mechanism to avoud loading AIM-9X on a SU-34, as example. So i extend the definition with an additional rule:

Weapon and/or plane manufacturer side has to be defined with the following line:


iaws_side = "WEST";

Possible values are "WEST" or "EAST".
Be aware that this isn't related to which side a plane belongs to but which side produced the plane and/or weapon. So a F-35 could be set to EAST but neverttheless it is a WEST side manufactured plane so it probably shouldn't use weaponry made by EAST.
Depending on any upcoming (hopefully) weapon loadout system, Missionmaker may decide to allow crossloading weapons or deny it.

[Commando84]

man this seems hightech! :) you haven't thought about making a tutorial for making a addon aircraft from start to end? :)

[[FRL]Myke]

In fact, all this is pretty simple, else i wouldn't understand it myself. :p

Honestly, i just realised that the new proxy weapon handling of ArmA 2 offers this opportunity. There are only a few things that must be done in another way as it was usual back in ArmA 1.

So weapons MLOD was always centered as they had to be adjusted on the plane to fit. No need to take other weapon sizes into account while placing since for each wepon loadout a own MLOD had to be created.

Take the F-16C i've ported into ArmA 2. It offers 5 different weapon loadouts in the editor but it is only a single p3d file. In ArmA 1 you would have 5 different p3d just to fit the weapons desired.

It is a simple idea which offers a lot of possibilities. I hope addonmakers will step in and make theyr work IAWS compatible, even more as it is easy to make and has no downsides.

[[FRL]Myke]

I'm sorry for bumping this up but i was hoping for some more feedback, especially from the ones who mostly do planes. Namely Eble, Gnat (who is more into naval but still) Snake Man and some others.

[Eble]

I have my eye on this and I'm very interested in using it in Arma2, I 've got all the aircraft from arma working in arma2 with the 'traditional' scripting fix so far.

But this seems a more simple method, take for example the Eurofighter has from memory 10 P3d's so cutting those down to 1 would make a huge difference.

If you remember right I actaully made the F35 originally IAWS way back when you first came up with this idea, it was something I played with but never released.

The plan I have is to port forward all the jets I converted for Arma, at best these can be place holders until better models are created etc.

I'm very interested in using IAWS so I will explore this more in the next few days, I'm just at the start with these conversions as I know when I begin it will be a massive time sink until I get them all done.

Southy

[[FRL]Myke]

@<hidden>,

this IAWS guideline could be also interesting in another way for you. As you are well known for releasing quite a lot of planes, for you it opens the option to desplace weapons completely into a separate addon, all together in one package. Then on the plane, just make use of the IAWS standards and every missile/bomb will fit on any plane you make.

@<hidden>
There is one thing which causes me headache, FFAR pods.
I would like to have them IAWS compatible too so you could be able to load a FFAR pod instead of a missile/bomb. Don't have any ideas yet how this could be solved in a user/scriptfirendly way. I'm open for any ideas about this.

[Sakura_Chan]

Is there any standard for empty pylons? Like if I wanted sidewinders on the wings and just one bomb on the belly pylon, is there some invisible weapon placeholder that would let you space out the loadout?

[quiet_man]

@<hidden>
There is one thing which causes me headache, FFAR pods.
I would like to have them IAWS compatible too so you could be able to load a FFAR pod instead of a missile/bomb. Don't have any ideas yet how this could be solved in a user/scriptfirendly way. I'm open for any ideas about this.

I have to admid, I have no clue on Arma engine, so I'm wild gussing:

At Arma 1 you could "overload" a weapon point by "addmagazine" and it would show only one rocket (or many merged?), the weapon point would apear empty only after the last rocket was fired. So just make "pods with one rocket" and load many pods?
Not good of course if the games would draw XX pods for every rocket and might not work with the new engine distributing magazines?

Is it possible to add "bundles" to a wepon point? Make the last rocket view as FFAR pod? So the pod would stay until the last rocket is fired?

As I warned you, wild gussing :rolleyes:

QuietMan

[[FRL]Myke]

@<hidden> man

just go ahead, every wild guess might bring up ideas and some (me) starts thinking in other directions too.

Sadly, overloading doesn't work. Tried it with assigning 2 magazines of sidewinder which were drawed correctly, say i had 4 Sidewinders loaded. But as i emptied the first magazines, the remaining 2 missiles switched place to where the previous 2 was loaded.


@<hidden> Chan

I'm indeed thinking about fake magazines to fill up gaps. Have to test it if and how it works though. Maybe this could even lead to a solution for FFAR pods.....a Pod as magazine with no related weapon.....hmm....time for a test and research session. :D

[NeoArmageddon]

@<hidden> Chan

I'm indeed thinking about fake magazines to fill up gaps. Have to test it if and how it works though. Maybe this could even lead to a solution for FFAR pods.....a Pod as magazine with no related weapon.....hmm....time for a test and research session. :D

As i said to you in ICQ: i need empty mags for the refill/loadout module... but i think i can make them on my own.

BTW: I just started working on the loadout system for IAWS

[[FRL]Myke]

As i said to you in ICQ: i need empty mags for the refill/loadout module... but i think i can make them on my own.

BTW: I just started working on the loadout system for IAWS

Excellent. I guess as soon there is something more practical around than just some clumsy theories, people will start to adapt it on theyr own work.
I'm also glad that Eble is watching this as he is one of the most productive plane addons maker around.

Also as this loadout system is meant to come as module, including empty mags in there is best solution so addonmakers don't have to worry about.

Still thinking about those FFAR launchers. Maybe an additional parameter in the cfgWeapon like this:


iaws_fake_launcher = "<name_of_mag_with_launcher_p3d_as_model>";

And in the plane addon creating ammo and mag defining the launcher model as magazine but without related weapon.
Remains the problem that missile launcher memory point can't be switched afaik. But at least one step further.

[Defunkt]

I don't know much about ArmA aircraft (or vehicles in general) but I would encourage those of you who clearly do (Myke, Eble et al) to expand on this standard. It always bothers me that there may be little consistency between mods in terms of performance (speed, durability, firepower, fire-control) and it would be great to have a few nominated experts specific to different vehicle groups (particularly aircraft and armour), that might recommend appropriate values to addon makers, an informal certification if you like.

[[FRL]Myke]

Finally i wrote all down ot a IAWS Whitepaper so everything should be covered there.

Let me point once again that making a plane and/or weapons IAWS compatible, they'll still work as intended standalone. If IAWS is not used, there aren't any restrictions.

IAWS Whitepaper (http://www.armaholic.com/datas/users/372-iaws%20whitepaper.pdf)

[Seil]

Just a quick question, is there at this time or planned method to limiting what ordnance can be loaded onto each pylon? Meaning, there are 2 pylons on the tip of the wing of the A10 specifically for sidewinders, is there a way to keep those from being loaded with Mk82s and other payloads that will not fit nor are supported in real life by those positions?

-Seil

[[FRL]Myke]

Yes, such a restriction system is defined through the IAWS guidelines. However, it depends on the addonmaker defining both plane and weapons properly.

There are 4 different types of pylons defined: Wingtips, Single holder, Multi holder (3 rails on 1 pylon) and Main body (for the really big ones). But you better think of it as size limits, not as position limit. So there are planes that are designed to carry small missiles (AIM-9 Series and AIM-120 series) at the main body but these pylons can't take larger weapons like Mk-82. Eurofighter is such a candidate. There it would be necessary to define those pylons also as "Wingtip" type pylon.

[Seil]

Very cool, I guess I'd like to play with it now :D I'm a programmer not modeler or artist, so I can't offer much help or test with the creation of aircraft side of things.

Are the stock aircraft in ArmA2 going to be modified to support this as well then?

-Seil

Edit - I suppose we're waiting on BIS releasing the models for that.

[[FRL]Myke]

Are the stock aircraft in ArmA2 going to be modified to support this as well then?

Yes, this is the plan. But for this i have to wait until BIS releases (hopefully) unbinarized versions of it since i have to adapt the models to make it work properly.

[Seil]

Roger that, don't know what's going on with an interface for selecting loadouts right now, haven't seen anyone mention anything, I started work on one that should be pretty slick, should have something to preview tomorrow after another hour or two of work ;)

-Seil

[[FRL]Myke]

Sounds good. A friend said he would do something, preferably it would be a module so it would be easy to implement to missions. However, he has actually some hardware problems with his PC and i'm moving my house this month, so there is not much progress these days.

Anyway, i would be very interested with what you're doin. Please contact me via messenger (check my profile and pick one ;) ).

[Seil]

Alright, well, please take note this is in severe pre-alpha status, so the background graphic and everything is yet to be finished.

This is a teaser more or less, I've been designing an interface to be similar to the stock ArmA2 gear menu for IAWS. The following screen shots demonstrate what you would see with various aircraft for loadout control.

Also note, if the pylon count for any given aircraft is incorrect in these shots, it's ok, the system isn't hardcoded with number of pylons per plane type, instead reads what the given plane has and then creates the correct number of slots to match the plane. These are just teaser shots to show what you might expect to see.

http://seil.simcup.net/arma2/iaws_shots/a10.jpg
http://seil.simcup.net/arma2/iaws_shots/av8b.jpg
http://seil.simcup.net/arma2/iaws_shots/f15.jpg
http://seil.simcup.net/arma2/iaws_shots/f16.jpg
http://seil.simcup.net/arma2/iaws_shots/f18.jpg
http://seil.simcup.net/arma2/iaws_shots/f22.jpg
http://seil.simcup.net/arma2/iaws_shots/f35.jpg
http://seil.simcup.net/arma2/iaws_shots/ef_typh.jpg

At any given point the layout of the slots may be subject to change as the interface matures, just thought I'd tease everyone while more work is done.

-Seil

[Kremator]

LOVING it Seil! Take your time and get it right...... looks great so far !

[Seil]

Got most of the main scripting done. Next up is connecting the visual elements and building it into a module :D

-Seil

[[APS]Gnat]

Sorry Myke .... I only just saw this thread ;)

Great idea, I'll try to implement for the Su33 for a start.

Only thing I didnt see in your text, I'm pretty sure proxies "sequence of arming" and "sequence of firing" is NOT directly related to what you number the Proxy, its related to the sequence in which you create them in O2.
Sure, that should mean nothing beacuse the first created is 001, 2nd is 002 ..... BUT if you directly edit the proxy name-number or copy-paste proxys, the numbers now mean shyt.
Hence if things get confused in O2, easiest solution is to delete all proxies and start creating them in sequence again.

....... unless they fixed that in ArmA2 ... ?

[Sparky]

good job.
I have a question though, regardless of the missiles as proxies, there are cases that the pylons are different. Like in the Ah64, there is different pylon for hellfires and different pylon for the hydra pods. In situations like this does the new ArmA2 proxy handling permits change on the pylons? an example could be a version of an ah64a with 4 hydra-70 pylons and an other with 4 hellfire pods.
Currently in ArmA1 we have srcipted our ah64a in order to work from a single p3d, but with an extensive use of animations and scripting which proven to be not a very good idea as from performance perspective since all the possible pylon combinations have to be modelled on the p3d.

[[FRL]Myke]

@<hidden>[APS]Gnat

I wouldn't swear on it right now but while i was testing some stuff for the F-16C, i guess to remember that the numbering in fact influences the loading sequence. Although you can have mixed weapon proxies, for better overview edit the numbers according to the scheme i said. In ArmA 2 the weapon proxies in O2 are of less importance than they were back in ArmA 1 since in the config you can have different loadouts without having different models with according proxies (which you already know).

To lazy to check but i think the F-16C has only Sidewinders proxies in O2.


@<hidden>
Missile Launchers are in fact something that gives me headache since i didn't found a solution to create a generic way for those launcher pods. It is still a matter of research but at this actual point, IAWS does not support pods of any sort, only proxy based weapons. Hopefully, when Seil get his Module ready or NeoArmageddon, this system will get raised interest and hopefully someone has the ultimate solution for this. Then there will surely be an update. For now i have to be sorry.

[wld427]

just a lil spoiler....the forthcoming move of our PRACS aircraft to arma2 will support this system.

thanks for the heads up and the hard work on the research myke.:bounce3:

[Defunkt]

Pleased to hear it. But wasn't somebody working on a script and U.I. so pilots could re-arm on the runway?

[Mandoble]

Not sure why, but action "useWeapon" in IAWS configured planes has a curious effect when a weapon type runs out of ammo. The remaining bombs or missiles are automatically re-distributed using the empty pilons. Is there any explanation or fix for that?

EDIT:
Found out this effect has no relation with IAWS, it is directly an ArmA2 bug.

[hardrock]

Just by the way: The ACES (http://ofp.gamepark.cz/_hosted/hardrock/en/proj/?aces) project for OFP tried to achieve pretty much the same. You can find it for OFP bundled together with the Eurofigher Addon (http://ofp.gamepark.cz/index.php?showthis=10038). I think it also has been ported to ArmA.

Maybe you can find some script code in there that's of any use to you. Especially all the proxy handling system has been worked out pretty well, I guess.

[[GCA] Salah ad Din]

Hi,

nice to see some standards created for Arma2 addons.

Question1: will this work for choppers, too?
Question2: how compatible is that with Mandomissiles (I saw that Mandoble posted here, so I guess compatibility should not be a problem)
Question3: when is it ready :D

[PhilippRauch]

looks sweetsome, just when do you beta it ? So i as dev, can takealook and then build my models accordingly .. you know, many devs wont like to make stuff for an addon thats never going to be released. Also for testing that my ordnance works on my plane it would be nice to get alook ..
But that being said, its a very good idea and i really see forward to it, being used to great extend. (Im quite confident that i will ;) )

[Slatts]

think i might use this for the irish mod once we make our pc-9 :D
working on some gun pods by FN
http://www.fnherstal.com/index.php?id=498

will be a while on this though with other stuff to do :P
more of a heli weapons,but planescan take it too

[allewille]

So... How do you use IAWS?? Is it like a separate addon or what?

[[FRL]Myke]

@<hidden>

First of all it is a procedure definition on how to build up addons. Hopefully there will be an addon (Module most likely) that will allow pilots to change theyr weapon loadout midgame without the need to change the plane.

@<hidden>
:ADDITION:
The definition needs an small extension. Right now it isn't defined to which (manufacturer) side weapons and/or plane belongs to. So there is no possible mechanism to avoud loading AIM-9X on a SU-34, as example. So i extend the definition with an additional rule:

Weapon and/or plane manufacturer side has to be defined with the following line:


iaws_side = "WEST";

Possible values are "WEST" or "EAST".
Be aware that this isn't related to which side a plane belongs to but which side produced the plane and/or weapon. So a F-35 could be set to EAST but neverttheless it is a WEST side manufactured plane so it probably shouldn't use weaponry made by EAST.
Depending on any upcoming (hopefully) weapon loadout system, Missionmaker may decide to allow crossloading weapons or deny it.

[st3rv]

Want me to model some missiles as a part of this? Im bored of my project for now so i need something to keep me occupied...

[[FRL]Myke]

Mate, you're here at the right time. :D

Actually i try to gather as much different missiles and bombs MLODs as possible to unite them in one weaponpack for planes (choppers might use some of them aswell maybe).

That said, i take whatever you can/will give me. Preferably MLOD and texture, normal map and specular map i can do myself but if you want...up to you.

One thing, during this whole gathering process i might end up with several versions of the same missile. In this case i will choose the best model. So at this point i will not give guarantee that your work will be in the pack for sure.

If you still interested, i guess goin for less popular missiles and bombs would be a good idea. Maybe stuff that isn't widely used by US or former USSR. I guess with Sidewinders and Mavericks we're already well equipped. You get the point.

[[FRL]Myke]

Sadly, ACE2 has rejected to make use of IAWS in theyr EASA Module although it would solve some actual problems EASA suffers. Personally i can't understand it. I have my thoughts abt the "why" but these i'll keep for myself wisely. For those who want to know more:
http://dev-heaven.net/issues/7196

[TRexian]

Voted + on the ticket.

(Recovering flightsim addict.)

[Darkhorse 1-6]

Voted + on the ticket.

(Recovering flightsim addict.)

Same here. Minus the flightsim part. I'm just a MilSim Enthusiast who wants to milk every little drop of realism I can get. :D

[[APS]Gnat]

Myke, question on the memory lod points.
Are you aware of a method that allows these points to be "queried" via scripts etc?
ie, "search" for a certain point on a model, them position something near that actual point in 3d game space, or even as you intend, can we do a script query to confirm if an object or whatever is "near" a memory point?

[wld427]

i have been thinking alot about this.

I am wondering if we can assign values to specific hardpoint memory points.

Then restrict what can be loaded to that specific hardpoint via the scripting.


PS myke dont worry about not being accepted by ace. We all should just start our own non-ace club:p

[[APS]Gnat]

Yeh, every hardpoint could have a range of acceptable values (ie weapon types)

[[FRL]Myke]

In fact this is already defined by IAWS since the beginning.


iaws_pylons[] = {
{1,"iaws_pylon1"},
{2,"iaws_pylon2"},
{4,"iaws_pylon3"},
{4,"iaws_pylon4"},
{4,"iaws_pylon5"},
{4,"iaws_pylon6"},
{4,"iaws_pylon7"},
{4,"iaws_pylon8"},
{2,"iaws_pylon9"},
{1,"iaws_pylon10"}
};

The number defines the type (might read it as "accepted size", sort of). This in the planes config, the weapon has this:


iaws_type = 1 + 2 + 4;


The types (size) are categorized like this:
- size 1: small diameter, rather light (AIM-9X, AIM-120)
- size 2: medium/big (AGM-84, AGM-88)
- size 4: small/medium (AGM-65, GBU12, AGM-114), typically multiholders.
- size 8: Big (Cruise Missile, usually only one missile is carried per plane)

[[APS]Gnat]

Arh, sorry, yes it does.

[[FRL]Myke]

As i received the UK weapons from RKSL-Rock, i saw he has some sort of placeholder weapon which allows to blank out certain hardpoints.
I don't know what Rock already did/scripted with it so i've started a few tests and the results were quite interesting.

Most important, if a magazine is added without the corresponding weapon, the weapons still show up on the plane. For this purpose i guess, Rock designed those invisible weapon models to blank out certain hardpoints as it is needed.

Based on that, i guess it is possible to expand the flexibility to almost everything we could ever need.


Let me share my thoughts and ideas with you and let's see how this turns out.

FFAR Pods:
As said, a empty p3d proxy weapon will fill a hardpoint and so it appears empty. So i guess it's safe to state, a cfgAmmo and cfgMagazine with a FFAR Pod as proxy shape but without related cfgWeapon will also show up.
As we know, FFAR missiles aren't taken into consideration when filling up proxies.
Let us look at a single Wing which has (assumed) a Wingtip hardpoint, a single hardpoint and a multirail hardpoint (as seen on the F-16 next to the fuselage). Obviously on the Wingtip and on the Multirail, the FFAR pod wont fit.
Let us assume we want to have a Sidewinder on the wingtip, a FFAR on the single hardpoint and 3 Mavericks on the multirail. For this example we completely ignore the other wing but you can think of yourself as this would be a symetrical loadout anyway.

So we add magazines in this order:
- Sidewinder
- FFAR Pod
- FFAR Missiles
- 3 round Maverick

So on the plane we would see the Sidewinder, the FFAR Pod and the Mavericks.
As weapons, we add the following:
- Sidewinder Launcher
- FFAR Launcher (which has the FFAR Missiles as related magazine)
- Maverick launcher

What do we get with this? Well, the FFAR Pod magazine doesn't have a Weapon so it can't be fired and will therefor stay where it is while we can fire the FFAR's with the related weapon.
And as the FFAR Pod occupies the single hardpoint, the Mavericks will show up correctly on the Multirail.


Extend this principle with other things.
I think it should be possible to use the same technique to make it work with other stuff.

Multirails on single hardpoints:
Right now, the multirail is "hardcoded" into the model of the F-16 which limits the flexibility. What if i/we take it out there and create also a separate magazine for the multirail?
Well, this would need some other changes in the model aswell, mainly the proxies. Let us focus on one hardpoint and one Mulitrail which has capacity to hold 3 weapons.
So we create a magazine (surely with related ammo first) for this multirail object. At the Hardpoint we add an additional proxy (assuming we already have those from the previous "hardmounted" multirail) which takes place at the hardpoint, like on any other single hardpoint. So if we add a single weapon to this hardpoint, the remaining 3 proxies which would take weapons if there would be the multirail has to be filled with placeholder ammo (empty p3d). But if the multirail magazine is loded (which already fills up this proxy), the remaining 3 proxies will hold whatever weapon would fit there, Mavericks as example.

So, either a weapon is applied to the "new" proxy and the remaining 3 are blanked out, or a multirail magazine is applied and the remaining 3 proxies can take up weapons as usual.


No doubt, all this would require heavy scripting but this could be done within a IAWS module (i'm working with a squadmate to solve this part) so end user wouldn't have to mess with all this said above.

And also this isn't limited to weapons. Also external fuel tanks could be managed like this. Or other equipement that is meant to be placed on hardpoints.


Downsides:
Sure there are but i guess people could live with it.
As FFAR's are spawned at 2 placed and named memory points, they will spawn there regardless on which hardpoint the FFAR is really mounted. This is a visual downside but considering the flexibility this system would allow, i think it is only a minor, since "only" visual, downside.


Let me know your thoughts and ideas. Also already gathered knowledge is always helpful.


Myke out

[[APS]Gnat]

No doubt, all this would require heavy scripting but this could be done within a IAWS module
Ouch. I was affaid of that (the heavy scripting bit).

About 50% of your discussion here is over my head, but it did trigger a thought I'm going to check out.
Animating the FFAR memory points to see if the game engine will allow them to be moved. From experience some memory points flat out ignore animation.

[[FRL]Myke]

Don't be scared, my friend. I'm working on a "proof of concept" addon to test if it is possible to swap multirails to hardpoints as i guess it. If this works as i hope it does, the Missilebox will include a Module and scripts that will make the work easier for player, missionmaker but also for addonmaker aswell.

If all goes well, the changes that would affect you (and any other plane maker) would be to place several proxies, add a few lines in the config and thats it.

I will write a detailed "how to" if this concept works which makes it easy to include the functionality.
By now i guess for you it would take maybe 30 minutes or less to adapt an existing plane to the new concept.

About being over your head, it is based on the simple fact that magazines are applied to a plane regardless if a corresponding weapon is loaded or not. Already tried that with a single script and you might also check this with the F-16.



_plane = _this;
_plane setVehicleAmmo 0;
{_plane removeWeapon _x} foreach (weapons _plane);
{_plane removeMagazine _x} foreach (magazines _plane);

waituntil {(count (magazines _plane) == 0) && (count (weapons _plane) == 0)};

_weapons = [
"GLT_M61A1",
"GLT_SidewinderLauncher",
"GLT_AIM120Launcher",
"GLT_BombLauncher_Mk82"
];
_magazines = [
"500Rnd_20mm_M61A1_GLT",
"2Rnd_Sidewinder_GLT",
"2Rnd_Maverick_GLT",
"4Rnd_AIM120_GLT",
"2Rnd_Mk82_GLT"
];

hintsilent "Adding weapons";
{_plane addMagazine _x} foreach _magazines;
{_plane addWeapon _x} foreach _weapons;

Place the CAP variant, run this script on it and you will end up with a plane which has visually the Mavericks but when getin in, you can't select them, obviously. This is the base for my actual research and development.

What i'm actually trying to do, is dynamically add/remove multirails and equip those with weapons that might fit. If this proof of concept works, i'll share it with the community.

So, don't be affraid, everything you might have to do (if you want) is adding a few more proxies to the model and several lines to the config for which i will give detailed explanations.