Wolfenswan

Sorry I meant the way you expected it to work is how SWS is supposed to work, i.e. getting someone up with a FAK. If the bug can be reproduced reliably, could you do a test without any AGM modules running? There might still be some interference. Very weird. Can you do a test with the open HEMTT trucks? And if possible also without AGM, though I can't imagine how it would be the culprit here. I'll do a test with the boats when I find some time.

Hm. No, that's how it's supposed to work and how it's working fine for us. Are you running any mods or scripts which might be interfering? Odd. We tested it with the new FFV vehicles and it worked fine, but the new "cargo-turrets" will only be slotted if the "crew"-flag is set to true. However, if it works locally but not on dedicated then the issue might be something else, are you moving player units or AI into the boat?

You need the f/spect folder and the relevant sections from the description.ext (cfgFunctions and spawn-templates). It's probably easier if you describe what you did and how you set it up so I can point out the mistake. You can also take a look at this mission, the creator is using an extracted version from F3 as well.

It's pretty straightforward to extract the spectator script from the framework and use alone (no inner dependencies) and for us it's better to focus on developing the framework as a whole rather than having to maintain several sub-releases besides F3 itself.

I wrote a few functions to get AI into buildings for our sessions, they are part of my library (under /AI/). I wrote those with perfomance in mind, so the AI won't necessarily face out of windows or react dynamically (ASR_AI3 does usually take care of that well enough). If you need something like that have a look at Zorilya's script.

Can people please post their server.cfg values for comparison? In our smaller session (<20 players) I didn't notice a massive perfomance loss; 50 SFPS with a bit more than one hundred AI present. Will have a closer look during our main session with about 40 players.

A tracker-ticket exists. And I can confirm that it has nothing to do with ASR_AI3 or any script-set skillsets. The return values for skill are always identical and what you'd expect them to be. For the time being I've set this in our server.cfg: skillAI=1; precisionAI=0.3; which produces results at least similar to what one would expect. But ofc. it doesn't help with the issue if AI is local to a client and the client has set up some sort of über-AI.

Why did you put everything into the call compile, and why do you assign _grpName a variable to then overwrite it with a newly created group? Does the created group keep the designation as _grpName? _grpName = call compile format [%1,_compStr]; _grpName = createGroup (side player); [player] joinSilent _grpName; _grpName setGroupID [_compStr]; [[[_grpName,_compStr],{(_this select 0) setGroupID (_this select 1) }],'BIS_fnc_spawn',true] call BIS_fnc_mp; Though your BIS_fnc_MP parameter should work as well if it is able to distinguish between multiple parameters when a script command instead of function was passed (would be good to know, honestly).

If the player P1 (for example) dies and is revived, does the variable P1 still point to the corpse or the born-again player? As said, using the playableUnits array is probably a better solution.

How does BTC revive work? Does it create new units for the dead ones? I don't see a reason why you wouldn't count the playableUnits array? Also, instead of the two waitUntils you should use a trigger or at least add some sleeps into the waitUntil checks. Otherwise it's wasteful and waitUntils have the nasty habit of carrying over. You could also consolidate those checks into a single one: If either the players win the mission or all die a global variable (let's call it missionOver) flips to true, a trigger registers this change and then shows the correct ending screen, depending on whether > 0 players are still alive.

Can you do a quick check which faction a empty RHS vehicle returns? In any case the next version of F3 will allow forcing a faction via assignGear.

Turns out a delayed showGPS false; showMap false; works well enough for my purpose.

I've written this civilian-assassins/ambush script ages ago. Has been a while that I used it, but I assume it should still work.

Are the values identical for the server and for the clients? What are the values of AI local to a client?

To clarify: Would units created by a ZEUS player use the client's sysdanger values but the server's sysaiskill values? In any case I'd like to suggest a new variable to enable the server overriding all client values at mission start as a feature. It's pretty easy to test locally, just garrison a town and place a few hostile AI with allowDamage false and FSM disabled in the center. This is enough to trigger the scripted attack response which seems to cause them to leave position. You can also try making everyone invulnerable and engage each other to see the same happening with the scripted defense response. A straightforward workaround my group is employing curently is to have the host set asr_ai3_sysaiskill_reactions to [0,0,0] in missions reliant on garrisons using the debug console. If you don't notice your garrison leaving despite reactions enabled I wouldn't mind if I could have a look at your code to see if I can implement it on my end.

If you are testing it locally then the script will exit because isServer is true and you do have an interface. Try commenting the very first line for testing purposes. Beekan's code looks solid otherwise but if you're completely out of luck try mine. However, it's more general, as it affects all units in the mission minus player units. { private ["_unit"]; _unit = _x; // Only run where the unit is local, it isn't a player and doesn't have a flashlight if (local _unit && !isplayer _unit && !("acc_flashlight" in primaryWeaponItems _unit)) then { // Remove laser if equipped if ("acc_pointer_IR" in primaryWeaponItems _unit) then {_x removePrimaryWeaponItem "acc_pointer_IR"}; _unit addPrimaryWeaponItem "acc_flashlight"; // Add flashlight // Removes NVGs from unit { if (_x in assigneditems _unit) exitWith {_unit unlinkItem _x}; } forEach ["NVGoggles_OPFOR","NVGoggles_INDEP","NVGoggles"]; }; // Forces flashlights on // _unit enablegunlights "forceOn"; } forEach allUnits;

I assume stopped would apply to doStop as well, but might also fire when stop/doStop commands are used from the FSM? Personally I'd be happy enough if I could set a variable on individual units or their group to exclude them from being affected by specific ASR_AI3 components. Unrelated to the issue at hand: Is there a good way to override a client's ASR_AI3 settings with those the dedicated server is using? This is mostly relevant for missions using ZEUS where the curator is (hopefully) using ASR_AI3 but might have different settings in place. Would collecting the ASR_AI-generated global variables on the server and making them public do the trick? Edit: I did some limited local tests and it seems that reactions[] is indeed the culprit. A setting of {0,0,0} does not cause the AI to leave their positions but enabling any single value does.

We're not running any other AI Mods. My script creates the units directly on the position and doStops them. Does group-size have any influence on when AI considers to charge? For perfomance reasons my script places them all in one big group, using enableAttack false to allow them to engage individually. So depending on how our mission-makers set it up the groups might be very big. I will try what you suggested and see if it helps. Thanks.

I noticed that with the recent update AI likes to attack players very aggressively and leave their position if it seems advantageous. Which nice and awesome to watch. But unfortunately it also plays havoc with my function to garrison towns, which puts AI into building positions and keeps them in place with doStop (which used to work fine). As of recently I've watched whole towns be "evacuated" and the AI swarming out to overwhelm the players. Is there a way to disable this behavior on specific units, say by setting a variable?

The Site Modules only work with Military buildings. They are pretty insane, as in they don't calculate the building positions on the fly but rather contain long stacked arrays for each possible mil-building class, containing the relative position and direction for a unit to be placed. Last time I tried them in Multiplayer they didn't really work, but that was a few patches ago. Here's my function to collect all positions of a building, in case it helps.

Try adding [] execVM "f\radios\radio_init.sqf"; after line 57 in JIP/f_JIP_playerRespawn.sqf and after line 34 in JIP/f_JIP_reinforcementOptions.sqf.

ARMA 3: workplace simulator. It's so realistic, it's like actually working minus the pay.

Is there any event handler that fires only when a player dies the "final death"? In that case you could call the spectator-init function from that event handler. 3-1-2 was only a small hotfix for the mission conditions selector. Fer probably forgot to update the OP. Not yet but the upcoming 3-2-0 release will be fully compatible with ACRE2. Take a look at our dev branch on github if you're curious.

If it's a SP mission you can try recording the movement. For MP you might want to experiment with disabling various AI modes and using commands such as doMove.

That sounds great!