Wolfenswan

Ugly but the best I can think of. snipers = [iD,ID,ID]; restrictedWeapons = ["Wep1","Wep2"]; Put this into a script that's fired every time some approaches a weapons crate. _unit = _this select 0; _weapon = primaryWeapon _x; _i = 0; while {_weapon == primaryWeapon _x && _i < 100} do { _weapon = primaryWeapon _x; _i = _i + 1; sleep 0.5; }; _weapon = primaryWeapon _x; if (_weapon in restrictedWeapons && !(_x in snipers)) then {removeWeapon _x}; //and fire a hint/textmessage, readd the weapon to the crate etc

try this addEventHandler [ "HandleDamage", { _box = _this select 0; _ammoName = _this select 4; if (_ammoName in ["DemoCharge_Remote_Ammo"]) then { _box = _this select 0; _box setDamage 1; //deleteVehicle _box ; //use this if you want the container to disappear }; }]; In this case only a democharge would do the trick. Add more classes to the array for more options.

Hey everyone, the script errors for the JIP system and fn_setWeather will be fixed in the upcoming 3-0-8 release. If you want to hotfix it yourself: In f_JIP_reinforcementOptions.sqf in line 47 replace nul = [_loadout,player] execVM "f\common\folk_assignGear.sqf"; with nul = [_loadout,player] execVM "f\common\fn_folk_assignGear.sqf"; In fn_setWeather remove both lines refering to simulSetHumidity. Regarding scopes: For now all units are using RCO/Red-Dot by default as it was in F2. Once we're finished with the gear script (which atm. mostly requires reducing and redistributing the load and weight which is still based on A3 Alpha values) we have some plans on introducing more options via parameters. For now if you want to replace the RCOs on rifles you can change the first class in the _attach string for each weapon in the assignGear files. (so for example in _rifle_attach = ["acc_pointer_IR","optic_Aco"]; replace "acc_pointer_IR" with whatever scope you want to give all units that get a regular non-eglm rifle that scope).

This script of mine allows you to designate civilians to be "sleeper agents", that'll engage a specified target or side on approach. It automatically selects the correct opposing side etc. It's fairly customizable, check the code itself for a proper documentation. The script is set to work with A2 but only two very minor changes are needed to get it work with A3, they are explained in the code. It should also work with the site moduls though for now you'd have to execute the "affect all" version of the script after a short time into your mission as I don't know yet how I can write into the init space of the civs spawned by the site module. ws_assassins.sqf on github

I'm travelling atm. and I'd wait for the release of 2-7-0, so there's no rush. I have a few ideas for the German factions (especially the SS and Paratroopers). Mind if we take it to the Folk Forum?There's already a thread in the dedicated F2 development subforum. No need to blow up the F2 thread here.

Hey Savage, I've got the some issue and was about to PM you here. An option would be to have A1 and A3 with 3 each, as I don't know how much sense a 2-man fireteam makes gameplay-wise. A1 could be all SMGs while A2 sports the rifles and A3 is the fire support. The naming suggestion sounds good. As long as they are coherent through the platoons it shouldn't be a problem. I think the same layout should work for the British and Germans. Alternatively their MGs (BAR/MG42 or 34) could be removed from the squads themselves and the number of organic MG attachments increased by default. Btw. I've uploaded a new version of F2-i44 to github, implementing some of the changes made in the regular F2 and further tweaking the loadouts (all backpacks and inventories should be full by default now).

Pro-Tip: Don't use the same nick everywhere, especially if it's unique. That "norsk2277" asking for advice on how to bypass Battleeye and misc. DayZ Hacks wouldn't be you would it?

You can subtract from an array. Check here. Example: _units = [s1,s2,s3,s4]; _traitor = _units select floor (count _units); hint format ["Traitor: %1", name _traitor]; _units = _units - [_traitor]; If S1 was selected _units is now [s2,s3,s4];

This works for helis but even a hold waypoint won't prevent an AI plane from taking off. I usually set the plane's fuel to 0 and allowCrewInImmobile true and have a trigger set the fuel back to 1 when I want the plane to take off. Alternatively you could try disableAI/enableAI "move"

To my knowledge a Trigger checks it's condition every frame (x frames). So, in theory, a loop that only checks the same condition every x seconds due to an included sleep should provide better performance. Am I correct in this or is for some reason a trigger still the more economical solution? To illustrate my question a bit better: 1. A script creates a set of units, randomly. 2. Each of these units should perform a certain action once a unit of type X gets lose. 2a. Have the script create a trigger and attach it to the Unit with the correct condition. 2b. Have the script start a while {alive _unit} loop with sleep 1 that repeatedly checks if the condition is fulfilled. Thanks.

I'd suggest a more distinct foldername like z_garrison as your script includes quite a few files. As expected it works like a charm with murk_spawn. Some observations/suggestions: - I noticed it just gives a script error when it doesn't find a house in the given radius. A globalchat debug would help (or increasing the radius till the group finds one). - Debug markers indicating which group went where would be helpful as well - destroyed buildings apparently are considered "valid" - i don't know if ruins have their own buildingpos values, none at all or keep the buildingpos values of their undestroyed version? - the script works fine in the bigger cities of Chernarus as long as you place the group next to a enterable building and keep the radius low. Otherwise they'll also try and "enter" buildings with no buildingpos. Could a simple buildingpos < 0 check prevent that?

Great script, works like a charm and will probably replace UPSMON as "the" garrison script in my missions. I'll try it in conjunction with murk_spawn later today and will report back but I'm expecting no issues. One request though and it's a bit of a general request to all scripters: Could you put your entire script in a custom folder by default? I know it's not much work to do on my side but it would make your script even more convenient out of the box ;) Or maybe I'm just too much of a sucker for neatness in my mission folder and other people don't mind cluttering it up. If so, ignore me.

Here's what I'd try (bit of Pseudocode, sorry). It's ugly and def. not the best solution but it should work. init.sqf { _x addAction [defusescript.sqf]; } forEach [iED1,IED2]; defusescript: _iedpos = getPos _this select 0; _id = _this select 2; IED_var = [_iedPos,_id, round random 100]; publicvar "IED_Var"; PVeventhandler for IED_Var doesn't do anything but passes the values to yet another var that's server-exclusive and again PVed, this time by the server to *all* clients. Another PVeventhandler either removes the action or causes a boom, depending on the round random 100. The double PVeventhandlers are necessary to affect the client that called the action initially. Alternatively, you could write some redundant code in the action script and remove the PVeventhandler.

My knowledge regarding respawn missions is very limited but afaik you'd be better off looking for documentation on adapting kegety's spectator script to a respawn mission or the more complex scripts like norrin's. @Clydefrog has to be if (_faction == "[b]usmc[/b]") then { #include "folk_assignGear_usmc.sqf" }; has to be case "[b]USMC[/b]": Regarding Group IDs: The USMC units all have GrpUS_CO = group this;, GrpUS_DC = group this; etc in their inits? Also make sure the function module and the two "don't delete me" units are placed in your mission and loaded BEFORE anything else.

I forgot: are class strings case-sensitive? You've got MK_48 and it's Mk_48.

That's the same mistake as in the beginning, distance only works with single objects not groups or arrays. You need to use a loop with forEach

_vcl = _this; should be _vcl = _this select 0; You could also use this script: http://www.armaholic.com/page.php?id=6080

1. {_POWgrp = _grp - _x;}; should be {_POWgrp = _POWgrp - _x;}; 2. I think I've been a bit unclear: _grp has to be an array, it's not going to work when it's referencing a group object If you put a _grp = [] at the beginning of the script and a _grp = _grp + _POW inside the for loop my code should work. 3. It helps a lot to use stuff like this for debugging: player sidechat format ["%1,%2",_POWgrp,_grp];

Something like this should work _obj = POWSafe; _grp = [POW1,POW2,POW3]; _safe = 0; _safedistance = 20; while {true} do { sleep 1; { if ((_x distance _obj) < _safeDistance) then {_safe = (_safe + 1)}; if (!alive _x) then {_grp = _grp - _x;}; } forEach units _grp; if (count _grp == 0) exitWith (hint "Too many POWs died!"); if (_safe >= count _grp) exitWith (hint "all living POWs made it!"); };

Try a loop that waits for a global var to flip. Here's what I use. //Wait for clients to synch sleep 0.1; waitUntil {!(isNull player)}; waitUntil {(player == player)}; waitUntil { time > 0 }; player allowDamage false; player enableSimulation false; while {!(ws_initdone)} do { _dots = ""; for "_i" from 0 to 3 do { titleText [format["Preparing mission%1",_dots], "BLACK FADED", 0]; _dots = _dots + "."; sleep 0.3;};}; player allowDamage true; player enableSimulation true; titleFadeout 1; ws_initdone is flipped by a different script that's run serverside and started before the loop Also I'd suggest externalizing code in different scripts and use more loops and forEach to make it easier to read. My guess would that somewhere in there you have a check for a variable that doesn't actually exist on the client or something annoying like that.

Bumping this thread because I'm interested in an answer RE: locality and how the commanded AI is affected by AI mods run either on client or server.

yes latest built. happened only one time so far, otherwise it has worked like a charm (the extraction likes to stop miles away from the actual designated location though). A problem I had with enableSimulation is that players were able to fire exactly one shot, even when it was set to true. But that might have been a problem with the way I implemented it.

Had a problem with the teleport not happening (BTR-70) on the CH version but apart from that the new version is running great. Maybe you could include a player action that allows to force the teleport? It might have been caused by the btr-70's way being blocked by a civilian car and it had been doing circles for minutes until one of us decided to get out and drive the civ car away, then get back in. any specific reason you're not using http://community.bistudio.com/wiki/enableSimulation ?

I'm having a very strange and frustrating issue in a dynamic mission of mine: In theory an object (Wreck) is placed randomly in Chernarus and after that is done a action is added to it, allowing to start a data transfer. The problem is that apparently with a certain number of players (20+) this doesn't work reliably: the action isn't added and can't be called. However, it does work as intended when testing locally, alone on a dedi or with 3+ players on a dedi. The relevant bit of code, executed on all clients: waituntil {(ws_initdone)}; if (isNil "ws_uploadaction") then { ws_uploadaction = Wreck addAction ["<t color='#dddd00'>"+"Begin transfer"+"</t>","ws_scripts\ws_uploadaction.sqf",nil,1,false,true,"","((_target distance _this) < 9) && (group _this != grpRU_Grnd)"]; }; ws_initdone is flipped to true once a good location for the Wreck has been found and it has been placed. Things I've tried without success: - Adding the action to the Wreck, then moving it - adding the action to the Wreck via the unit init field in the editor I'm at the end of my wits now, any ideas?

Oh derp, Obviously. Cheers. As said I've now added: sleep 0.1; waitUntil {!(isNull player)}; waitUntil {(player == player)}; waitUntil { time > 0 };