aeroson

Had this issue: init.sqf was trying to execVM missing script if you do this on client, you see error message and must click continue, same probably happens on server, but you can't click continue -> server didn't finish initialization -> players spawn as seagulls Fixed by: Add -noLogs to server params, this will cause the server to not care about errors (and not show them nor log them). Or fix your missing scripts.

Found bug in v.1.4 beta Running on Windows 10 Explorer > Right click XXX.pbo > PBO Manager > Extract to XXX.pbo\ Extracts $PBOPREFIX$ Explorer > Double left click XXX.pbo > In PBO Manager v.1.4 beta window > Right click root node > Extract to XXX.pbo\ Does not extract $PBOPREFIX$ Also any chances of putting the source code onto github.com ?

Here is my story in screenshots: http://imgur.com/a/DYPgF Tried all password I could have used. None worked. Tried chrome and firefox. None worked. Tried deleting cookies. Didn't work. Any ideas ?

There is a working addon on Steam workshop that does something similar: http://steamcommunity.com/sharedfiles/filedetails/?id=289207924&insideModal=0&requirelogin=1 The code that does it:

Thank you for this amazing script, I can see alot of work and testing was put into it. Iam not getting the issue desribed above. However I found and fixed some bugs: Fixed bug where it did not work once you respawned with your old body having backpack in ventral position. Fixed bug? where the addActions on your old body would stay after you respawned. I also put it all into one script that we can use in our missions without the need to update our modpack: https://raw.githubusercontent.com/aeroson/a3-misc/master/FSF_SecVentral.sqf Cheers.

Thank you, this is amazing.

Amazing, easy to use, cleverly designed and made. Easy to customize. Thank you. Recommending change of eos\core\eos_core.sqf in lines 32 to 40. So you can set that if helicopters fly under 100m _heightLimit=100; enemies will spawn, but if over 100m they will not. It also ensures that if players are in building on third floor above 5m from ground the enemies will not despawn. if (_heightLimit!=0) then {_actCond = format["{vehicle _x in thisList && isplayer _x && ((getPosATL _x) select 2) < %1} count playableunits > 0", _heightLimit]; }else {_actCond="{vehicle _x in thisList && isplayer _x} count playableunits > 0"; };}else{ if (_heightLimit!=0) then {_actCond = format["{vehicle _x in thisList && isplayer _x && ((getPosATL _x) select 2) < %1} count allUnits > 0", _heightLimit]; }else {_actCond="{vehicle _x in thisList && isplayer _x} count allUnits > 0";};}; Also patrols (light and armoured) have sometimes one waypoint placed at [0,0] so if you don't kill them, they move there and if it's vehicle it gets stuck in river on the way there.

@fond: There is no such feature in this group manager script. It must be something else.

I'm thankful for this very useful and handy tool. Arma3:_Startup_Parameters allows "<path>\mission.sqm" (Load a mission directly in the editor...) I'm unable to use it since ArmA3Sync thinks every space means next parameter, despite the path being in wrapped in " " both of these Additional Parameters: "C:\Users\ME\Documents\Arma 3 - Other Profiles\NICK\MPMissions\Test%20Mission.Sara" -"C:\Users\ME\Documents\Arma 3 - Other Profiles\NICK\MPMissions\Test%20Mission.Sara" are turned into: -"C:\Users\ME\Documents\Arma -3 -Other -Profiles\NICK\MPMissions\Test%20Mission.Sara"

The most amazing tool for Arma 3. Thank you.

@Wiggum: No, once this script is executed, it runs forever, unless terminated with terminate or it errors out. @Quorum: Yes you may do something like this: (beware it is untested) if(player in allCurators) then { 0 = ["players","allsides"] execVM 'player_markers.sqf'; // player is zeus } else { 0 = ["players"] execVM 'player_markers.sqf'; // player is not zezs }; @DuM3D0: setUnconscious players are switched to different side i believe. Or if you have BTC revive enabled: BTC revive shows its own marker, that is why dynamic player markers hide its player marker in such case.

@Beerkan: That is true, if you want to add face saving/loading functionality you may encapsulate set/get loadout functions like this. Beware it is untested. setLoadoutAndFace = { _target = _this select 0; _data = _this select 1; _flags = _this select 2; _face = _data select 0; _loadout = _data select 1; _target setFace _face; [_target, _loadout, _flags] call setLoadout; }; getLoadoutAndFace = { _target = _this select 0; _flags = _this select 1; [ face _target, [_target, _flags] call getLoadout ]; }; @Baddazs: That is what the "repetitive" flag is for. "repetitive" intended for repetitive use, will not use selectWeapon, means no visible effect on solder, but will not save magazines of assigned items such as laser designator batteries loadout = [player,["ammo","repetitive"]] call getLoadout;

My apologies folks, it has been a while. I will happily accept any pull requests on git. Expect this to be quite a long post (ordered chronologically). @ Janez: Sorry Janez at the moment iam not willing to spend days debuging, testing and inventing workarounds. @ IndeedPete: Yup i think there is no way (i didn't try any) to get separate attachments and/or loaded magazines in weapons inside backpack/vest/uniform. The only way to save attachements is if the weapon comes with preconfigured classnames. @ PtPau, LKincheloe, Mariodu62, Larrow, 1PARA{God-Father}: You are all very clever guys. The issue is the getLoadout makes unit switch thru all weapons really fast. Yup one solution is to check if you are holding launcher, but that only aplies to launchers. That is why i introducted the "repetitve" option flag. If the flag is used, getLoadout won't cycle thru all weapons, but it also won't be able to save each weapon's loaded magazine + ammo count. // Save loadout (including magazine + ammo count) every 2 seconds [] spawn { while{true} do { if(alive player) then { loadout = [player,["ammo"]] call getLoadout; //<-- THIS LINE }; sleep 2; }; }; So the the line marked //<-- THIS LINE should be changed to: loadout = [player,["ammo","repetitive"]] call getLoadout; //<-- THIS LINE @ DroopyPiles: None uses old VAS nowadays. It has been hereby remove from the loadout manager. You can redownload it now. @ MisterGoodson: You are very right. I didn't use the event handler either because revive scripts replaced / removed them. Or because they were not reliable, e.g. if you get killed in one hit, the hit event handler might not fire. Also in Arma 2 the best way to do this was to use the Killed event handler, but in Arma 3 when unit is killed it drops it's weapon. If you are willing to put your life on the line PM me the (revive script's compatible) changes i should made in the first post D: @ Braae: This sounds like the ideal task for Arma Arsenal by Bohemia, but if you wish to use the set/get loadout functions read on: Run your mission in singleplayer, select your loadout, then in console, save it into variable and then look at the variable and copy it's contents. You can then easily use these loadout contents to load loadout for any unit. select loadout in game execute in console: loadout = [player] call getLoadout watch variable in console: loadout copy contents of loadout into CLIPBOARD paste this into your mission file: unit1 addEventHandle["Respawn", { _loadout = paste loadout from CLIPBOARD [_this select 0, _loadout ] call setLoadout; }]; repeat for all units you want @ Kilo1: First of all the takeovers are not maintained, specifically BTC takeover is for BTC version 0.92 and lastest BTC version is 0.98. The takovers also only replace the loadout handling functions. From the scripts you posted iam unsure of how you are executing the init_player.sqf

Updated / Fixed set_loadout.sqf v4.3 - Added: now using addItemTo commands - Fixed: assigned binocular/laser designator is now properly added @goldenfiver: Thank you, fixed. @Pergor: These functions accept unit as target parameter, not a group. If you want to do something with each unit (memeber) of player's group you can do it like this: (not tested and most likely not working, but you get the idea) // Save loadout of all units in player's group units_reference=[]; units_loadout=[]; { units_reference set [_forEachIndex, _x]; units_loadout set [_forEachIndex, [_x] call getLoadout]; } forEach units group player // Load previously saved loadout of all units in player's group private["_i"]; { _i = units_reference find _x; [units_reference select _i, units_loadout select _i] spawn setLoadout; } forEach units group player

Updated / Fixed get_loadout.sqf v3.4 - Added: "repetitve" option flag, will not use selectWeapon, means no visible effect on solder, but will not save magazines of assigned items such as laser designator batteries - Added: weapons magazines are now saved using the new magazinesAmmoFull command set_loadout.sqf v4.2 - Fixed: Goggles and headgear are now removed before adding assigned items @Phoenix_ZA: Thank you, goggles and headgear are now removed when setting loadout. Though i found no problems involving NV goggles. @TinyPirate, @goldenfiver, @PenguinInATuxedo: All this flickering/ir laser turning off was caused by quick selectWeapon in order to get current magazine and ammo count of weapons and assigned items. The script is now using magazinesAmmoFull, unfortunately magazinesAmmoFull does not return magazines from laser designator, so we still have to use selectWeapon for assigned items. That's why i've added the "repetitive" options flag, use it and you wont't notice any kind of flickering/animation interrupting, though the drawback is magazines of assigned items won't be saved. @TinyPirate: I believe VAS has a Load on respawn feature. But you are right, VAS might reload the loadout and Xmed might be replacing it with it's own loadout right after it. Anyway, you should be able to delay the VAS loadout loading or mine setLoadout a bit. // Load saved loadout on respawn player addEventHandler ["Respawn", { sleep 2; // All other scripts might set loadout in this time, thus making the following setLoadout final [player,loadout] spawn setLoadout; } ];