onkeldismaster

Unfortunately we don´t use ACRE2, but ACRE1 had something similar. I actually don´t know too much about ACRE2 ;)

It would kinda... But imagine a lot of people using VA with your fixes and TFAR or ACRE2 in addition, they would have to do this either. I think a solution "out of the box" would be much better. (correct me if im wrong, but this should be a check for each mod, thats independent from the mod itself; with a solution like this if (getText (configFile >> "CfgWeapons" >> _item >> "simulation") == "ItemRadio") then { if (isClass(configFile >> "CfgPatches" >> "task_force_radio_items")) then { _radio = getText (configFile >> "CfgWeapons" >> _item >> "tf_parent"); if (typeName _radio == "STRING" && _radio != "") then {_item = _radio}; }; }; this is taken directly from the fn_handleItem.sqf from VAS and it reverts the indexed radio the parent. _item is the item that is handled. If TFAR is not installed, the check is false and obsolete)

Yes that would be sufficient ;), an "override to items" option would be nice, where you can set an array of items, which are added to the items section. I think i stumbled upon another issue over here: If you save a radio (i´m using TFAR) it saves the indexed radio (indexed for the ability to program these - for example tf_anprc152_5 where 5 is the index). If you now load your equip from VA, you always get the index you have saved. This can cause issues, if two players have the same index. If so, the two radios are identical so all the settings are copied.(This leads to one player setting for example his stereo settings to right, and the one with the same index is wondering about the lack of the left speaker.) I have ran in a similar situation with VAS, and Robalo or Tonic fixed it with this bit of code if (getText (configFile >> "CfgWeapons" >> _item >> "simulation") == "ItemRadio") then { if (isClass(configFile >> "CfgPatches" >> "task_force_radio_items")) then { _radio = getText (configFile >> "CfgWeapons" >> _item >> "tf_parent"); if (typeName _radio == "STRING" && _radio != "") then {_item = _radio}; }; };

Would it be possible to get spare optics or attachments off the VA? In BWA3 there are some optics attachments, which are attached via an action, and they aren´t compatible with any slot by themselves. (if you have them in your inventory, and the actual scope in on the rifle, on the action the rifle scope turns into the combined one) These attachments can´t be equipped straight out of VA, but you have to get the pre-attached ones and de-attach these. Anyways great job on 2.0.2 ;)

Thanks for the patch! I might get something wrong here, but on the example mission, every type of VA semms to be empty... R-o-x´s is working fine ;)

Nice, I´ve already tried to define the RH Attachments in CfgPatches and i have set scopeArsenal

Thanks for this R-o-x! I think the issue is with RH Pistols, because arsenal shows the handgun attachments in case of the 4-five (the MRD scope and the suppressor). Maybe its related to the fact, that the attachments of RH Pistols lack of "scopeArsenal = 2;", which would make them usable via Virtual Arsenal. I´ll try messing around a bit with this ;)

Alright I found it. I didn´t use the given Game Logic, but a simple Animal. Nevermind, Thread can be closed.

Recently i bought a second copy of ArmA 3, to set up a headless client for better performance on my dedicated machine. But now a strange problem occurs: The HC is connecting properly, but it is only visible if logged in as an admin. In addition it can´t be assigned at all, so if i try to put it in the designated slot, nothing happens. I´ve searched for this issue a long time, but i had no success. For setup i followed the wiki https://community.bistudio.com/wiki/Arma_3_Headless_Client This is defined in the server.cfg: //HEADLESS CLIENTS headlessClients[]={"127.0.0.1"}; localClient[]={127.0.0.1}; The mission is Patrol Operations 3.1, with an integrated slot for a HC. Where did i go wrong? Did this problem already occur? I hope for some good answers and i would appreciate your help. Greetings OnkelDisMaster

Awesome mod you did there Raven! But theres a small issue, since a while for me. It only seems to appear on dedicated servers. The containers are oriented wrong. I tried it in the local editor and in the local mp-editor, everything works fine. On dedicated servers the container turn a few times when lifting, then they stay in a 90° angle to the chopper. http://i.imgur.com/ZomtJXD.jpg (303 kB) I´m using the latest version (1.07). Tried it with vanilla vehicles and with addon vehicles, both didn´t work. I hope theres a fix for this. Greetings ODM

Ok i got a quick workaround for the TFAR issue....its not well tested yet. - Find fn_loadGear.sqf in the VAS/functions directory of your mission - at the very bottom of the file add [] spawn TFAR_fnc_requestRadios; //calls the radio distribution if you have a radio in your Inventroy Now every time you load a saved gear with a radio, the line calls the radio distribution function, thats called on mission init too. So you get a new prototyped radio on every load.

So lets take an example. Maybe i didn´t understant your system well enough. The fn_handleItem.sqf is used at loading a saved loadout. So if a player has a saved prototyped radio in his inventory for example tf_anprc152_19. This item should inherit from itemRadio, because tf_anprc152 inherits from it, shouldnt it? That means if a unit has an entry, which says tf_anprc152_19 your script should turn it back into the tf_anprc152 class without a prototype. TFAR then changes the radio to a new ID to prevent duplicates. This solution is not working at least for me, because i always load prototyped radios from the ammobox. So if I have saved the tf_anprc152_23, I load it too. I dont think thats the point of the fix, or is it? Greets ODM

Alright thanks a lot

Good Tutorial, Iceman77 but i have an issue with the defines in ArmA 3. I use the IGUIBack and the RscCombo parts. Where can i get the defines for these, because they´re not included in your defines.hpp. So everytime i try to load the mission it says that the base classes are missing.