mrgwilliam

1st Rapid Response Force Military Simulation at its finest The 1st Rapid Response Force is an International Military Simulation unit dedicated to a high level of tactical simulation. As a Unit we intentionally choose not to base ourselves on a real life unit so that we can use a structure that is based on the real world but merges officers and NCOs to reduce redundancy. We are a newly launched unit that has been in development for eight months so that we could get our systems perfectly established for the type of experience we want to create. Here are just some of the examples of what defines us: Strong Foundations Spending eight months developing a unit comes with some advantages - we have used our over three years of experiencing running MILSIM groups to design a group that will allow us to reach a great level of military simulation without suffering a unit collapse because of boredom and paperwork. We decided to close down our old unit which had more than 140 active players so that we could dedicated ourselves to building a robust MILSIM group that would stand the test of time. The 1st RRF is designed to grow to 160 people, which is in our experience the largest active group that we can maintain at our desired level of quality. Rigourous Training As a unit we have over 30 MOS codes backed up with more than 35 training programs which combined total over 700 A4 pages of written training content. All of our training programs are written by people with real life experience but have been adapted to our specific ARMA environment. This is a step change to the regular “Modified Field Manual†approach of some units as it means we are only training useful and applicable information. The 1st RRF is an environment where anyone can fulfill their ambitions of leadership at any level in confidence that they will receive the highest quality training necessary to perform their function in a correct and standardized way. We don’t believe in making it up as we go along and are religious in our dedication to standards and interoperability. Deployments We don’t believe in the weekly operation concept that many units use. It is brittle and does not work well for international communities. Instead we use a 5 week deployment cycle in our unique deployment battlespace. Elements in the RRF operate on independant deployment cycles with 1 week of training, 3 weeks of operations ( scheduled on a per element basis working around availability ) and 1 week of off time so that members are free to enjoy other games. This system would not work if not for our dedicated team of 57As who manage and run the deployment environment to ensure it is providing a high quality MILSIM experience and our unique Fusion system that provides high performance persistence above and beyond other persistence system. Fusion is fully integrated into ACE and TFR so that all aspects of the player are persisted including medical states and ammunition loads to add a genuine need and challenge to our logistics elements. A Wide Variety of Elements The 1st RRF is home to a wide variety of element types including infantry ( Airborne, Air Assault, Amphibious, Light and Mechanized Infantry ), Aviation ( Fixed and Rotary Wing ), Logistics ( Air Traffic Control and Logistical Supply Teams ), Armoured ( Bradley and Paladin crews ) and Leadership Elements. Each Element has a custom training program and mission set but is equally useful in the battlespace. We do not have any element for the sake of having them and each is essential to our succesful operation in the deployment environment. This is due to our “No Magic†policy meaning that we do not use teleports or arsenal’s in the deployment space. If a member dies or a unit runs low on supplies - a real team will need to make the supply run or reinsert that individual. Friendly and Mature Community We pride ourselves on having an open and welcoming community. We only allow 18+ members to become uniformed members of our group but younger players can still join our public servers in order to learn and experience with us. Unit dramas are a constant threat that can be extremely destabilizing to a unit; To prevent this we operate with a high level of transparency as well as defining our stance on all actions in our Discipline Guidelines. Our command staff do not descriminate and we are publicly commited to equal rules and punishments regardless of rank or position. We release all of our materials and tools publicly so that we are held accountable by our community. We are driven to be the best not because of proprietary tools but because of our community. You can learn more about our group and the roles available by visiting our website at: https://1st-rrf.com or joining us on teamspeak at: ts.1st-rrf.com We require that applicants are: 16 or Over Have access to a Microphone and Teamspeak Maturity and a wish to learn As we are just launching this is a great opportunity to grow with the unit and become part of our founding group!

["RHS_CH_47F_base",[],[[0.5,-7.75,-1], [-0.5,-7.75,-1]]], Is the correct values for the RHS_CH_47F, the one that currently comes with this is broken

The value for the RHS CH47F seems to be off, when I try it, it instantly kills the ATRQ ["RHS_CH_47F_base",[],[[0,-0.4,0]]], Does anyone know the correct value?

bis_fnc_MP does not have the ability to issue a BattlEye Ban, this ban was most likely caused by the following code in your cfg onHackedData = "ban (_this select 0)"; // tampering of the signature detected I have had this happen to me on multiple occasions, its an odd occurrence but once I modified this value to kick, it only kicks instead of issuing a server side BattlEye ban. So TLDR; No one hacked into your server, BattlEye most flagged your game client as using hacked data (odd but does happen) issuing a BattlEye Ban.

Typically the hexagons representing friendly units are added via mission difficulty, you can try to modify your Difficulty settings however the server may override them.

@R3vo, that would be a solution however the manner these functions will need to be implemented requires the function to return with the array as it will be pushed to off server storage for persistence needs. I will try messing around with that and see if it makes any difference. edit: Alrighty I did some debugging and found the following. Once the first _weapons = weapons _player; is called inside the getLoadoutPlayer.sqf / function call, the error pops up.. "Error Generic Error in Expression". I am guessing this might be a locality issue or maybe an issue with how I am passing the player variable into the function, however I added a debug hint hint format["%1 %2",_playerName,_playerUUID]; and this reports out my information without issue. I am still stumped as to how to get this working

Ok, tried that and it works to a certain extent (spawn function does execute the function), however it forces me to store the return array globally in variable playerLoadout to access it. My goal is that the getPlayerLoadout function return the array of information, spawn does not appear to accomplish as it runs the procedure outside of the calling code.

Hey guys, I have been trying to solve this issue for the past couple of hours but have hit a brick wall. I keep getting the following error "Error Generic Error in Expression" when trying to call my functions: My functions are the following: My compile.sqf file which runs in the initialization file. via a call compile preprocessFile "framework\fnc\compile.sqf"; player_getPlayerLoadout = compile preprocessFile 'player\getPlayerLoadout.sqf'; player_restorePlayerLoadout = compile preprocessFile 'player\restorePlayerLoadout.sqf'; getPlayerLoadout.sqf - player_getPlayerLoadout /* File: getPlayerLoadout.sqf Description: Used to obtain all current weapons, items, and magazines and return them to an array Parameter(s): _this: OBJECT - Player Object that needs to be examined Returns: _this: Array - 0 - Player Information [0 - Name, 1 - UUID] 1 - Primary weapon 2 - Secondary weapon 3 - Handgun weapon 4 - Primary Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 5 - Secondary Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 6 - Handgun Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 7 - Headgear 8 - Goggles 9 - Uniform 10 - Vest 11 - Backpack 12 - Magazines [[0 - classname, 1 - ammo count], ... ] 13 - Items 14 - Assigned Items 15 - Misc 16 - Primary Weapon Current Magazines [0 - magazine type, 1 - ammo count] 17 - Secondary Weapon Current Magazine [0 - magazine type, 1 - ammo count] 18 - Handgun Weapon Current Magzine [0 - magazine type, 1 - ammo count] */ // Establish Player Information _player = _this select 0; _playerName = name _player; _playerUUID = getPlayerUID _player; // Call all relevant information functions for loadout //Weapons _weapons = weapons _player; _primaryWeapon = primaryWeapon _player; _primaryAttachments = primaryWeaponItems _player; _handgunWeapon = handgunWeapon _player; _handgunAttachments = handgunItems _player; _secondaryWeapon = secondaryWeapon _player; _secondaryAttachments = secondaryWeaponItems _player; // Uniform _headgear = headgear _player; _goggles = goggles _player; _uniform = uniform _player; _vest = vest _player; _backpack = backpack _player; //Held Magazine _magazines = magazinesAmmo _player; _primaryMagazineType = primaryWeaponMagazine _player; _primaryMagazineAmmo = _player ammo _primaryWeapon; _secondaryMagazineType = secondaryWeaponMagazine _player; _secondaryMagazineAmmo = _player ammo _secondaryWeapon; _handgunMagazineType = handgunMagazine _player; _handgunMagazineAmmo = _player ammo _handgunWeapon; //Items _assignedItems = assignedItems _player; _items = items _player; //House Keeping _misc = _weapons - [_primaryWeapon,_secondaryWeapon,_handgunWeapon]; _primaryMag = _primaryMagazineType+[_primaryMagazineAmmo]; _secondaryMag = _secondaryMagazineType+[_secondaryMagazineAmmo]; _handgunMag = _handgunMagazineType+[_handgunMagazineAmmo]; // Return Loadout _playerLoadout = [[_playerName,_playerUUID], _primaryWeapon, _secondaryWeapon, _handgunWeapon, _primaryAttachments, _secondaryAttachments, _handgunAttachments, _headgear, _goggles, _uniform, _vest, _backpack, _magazines, _items, _assignedItems, _misc, _primaryMag, _secondaryMag, _handgunMag ]; and the last one the restorePlayerLoadout.sqf - player_restorePlayerLoadout /* File: restorePlayerLoadout.sqf Description: Used to restore players Loadout based on input array Parameter(s): _this: 0 - Player 1 - Array - 0 - Player Information [0 - Name, 1 - UUID] 1 - Primary weapon 2 - Secondary weapon 3 - Handgun weapon 4 - Primary Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 5 - Secondary Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 6 - Handgun Attachments [0 - silencer, 1 - laser, 2 - optics, 3 - bipod] 7 - Headgear 8 - Goggles 9 - Uniform 10 - Vest 11 - Backpack 12 - Magazines [[0 - classname, 1 - ammo count], ... ] 13 - Items 14 - Assigned Items 15 - Misc 16 - Primary Weapon Current Magazines [0 - magazine type, 1 - ammo count] 17 - Secondary Weapon Current Magazine [0 - magazine type, 1 - ammo count] 18 - Handgun Weapon Current Magzine [0 - magazine type, 1 - ammo count] Returns: Nothing */ _player = _this select 0; _playerLoadout = _this select 1; // Remove everything from Player removeAllWeapons _player; removeAllItems _player; removeAllContainers _player; removeAllAssignedItems _player; removeHeadgear _player; // Based on Array -> rearm the player // Uniform _player addHeadgear (_playerLoadout select 7); _player addGoggles (_playerLoadout select 8); _player forceAddUniform (_playerLoadout select 9); _player addVest (_playerLoadout select 10); _player addBackpack (_playerLoadout select 11); // Primary Weapon if ((_playerLoadout select 16 select 1) != 0) then { _player addMagazine [_playerLoadout select 16 select 0,_playerLoadout select 16 select 1]; _player addWeapon (_playerLoadout select 1); {_player addPrimaryWeaponItem (_x);} forEach (_playerLoadout select 4); }; // Secondary if ((_playerLoadout select 17 select 1) != 0) then { _player addMagazine [_playerLoadout select 17 select 0,_playerLoadout select 17 select 1]; _player addWeapon (_playerLoadout select 2); {_player addSecondaryWeaponItem _x;} forEach (_playerLoadout select 5); }; // Handgun if ((_playerLoadout select 18 select 1) != 0) then { _player addMagazine [_playerLoadout select 18 select 0,_playerLoadout select 18 select 1]; _player addWeapon (_playerLoadout select 3); {_player addHandgunItem _x;} forEach (_playerLoadout select 6); }; //Add Magazines {_player addMagazine [(_x select 0), (_x select 1)];} forEach (_playerLoadout select 12); //Add Items {_player addItem _x;} forEach (_playerLoadout select 13); {_player addItem _x;} forEach (_playerLoadout select 14); {_player assignItem _x;} forEach (_playerLoadout select 14); {_player addWeapon _x;} forEach (_playerLoadout select 15); I am trying to verify that I can call these functions but have been very unsuccessful. The files work as intended if I call them via execVM from my debug console however, to successfully test it I make the return variable a global variable and use that as the input to the restorePlayerLoadout file. What I want to be able to do is use the call function in code to run these functions however whenever I try to use it I get the error "Error Generic Error in Expression". I have tried combinations of spawn and execVM, but the error remains. Is there anything I am missing or not doing right?

roy86, how exactly does Patrol Operations auto detection work with Bohemia implementation of the headless client? Do we need to customize anything or does it handle that for us?

zorrobyte, how will this script react to the presence of headless clients? Will it need to be modified or should it not be used with them?

Zenophon will you be working to make your framework headless client compatible with the latest update? https://community.bistudio.com/wiki/Arma_3_Headless_Client

It just seems ridiculous the amount of weapon's sway after running 20m has made vanilla ARMA way to difficult.