Wolfenswan

A free-for-all approach is certainly going to cause issues but it is not going to have an effect on what the other players are experiencing. E.g. JSRS 3.0 is not going to have an effect on what other players can or can not hear, unless it would be not entirely client-side.

It might be ARMA but stuff like CBA and JSRS does not need to be run by all clients, unless the specific mission requires it (e.g. by calling CBA only functions or refering to JSRS classes in some way). A consistent modset is a good idea but if the mods are purely client-side there's no need to enforce them for all players.

It's a purely client-side mod in theory so there should be no MP conflicts.

No need for the trigger if it would work how it should. Anyway, I found the cause for my problem: Setting the new current WP for the group using setCurrentWaypoint from the onAct field causes things to break. E.g. this will prompt the "activated" message several times: wp = (group this) addWaypoint [(position this),10]; (group this) setCurrentWaypoint wp;systemchat "activated"; Setting a new waypoint from a scheduled environment does not cause any issues, it's only calls or putt the code into the onAct field directly. I can just group a unit to a trigger and set the on-activation to whole group/any group member. What I wanted to know though is why my waypoints stopped working as they used to ;)

As I remember it, a waypoint's "on act" field would execute once for the group completing the waypoint. As it is currently it is executed once per group member. Am I mis-remembering or is this a bug? My issue is, I can't figure out a straightforward way to restrict this execution to only happen once, as the only dynamic arguments are this for the group leader and thislist for the units of the group, but no reference to the specific unit in the group which the "on act" is executed for.

I have not tested it on a dedicated yet but it's easy enough to test on local. A systemchat in the on activation field will appear times the number of units in the group. Edit: It seems it's caused by calling a function from the on activation field. If I put only a systemchat in the onAct it fires once, but with a function-call beforehand the systemchat shows times group members. Spawning a function does not cause this behavior.

Looks good but if you want to do that for more classes this seems better: switch (typeOf _x) do { case ("B_G_Soldier_AR_F"): { _x addMagazines ["30Rnd_556x45_Stanag", 3]; _x addMagazine "HandGrenade"; _X addWeapon "Arifle_MK20_F"; }; case ("B_G_Soldier_F"): { // whatever else }; default { systemchat format ["%1 was not processed, class is %2",_x,typeOf_x]}; }; The default bit at the end fires whenever the type does not correspond to any case and puts out a short error message.

1. You probably want to check for typeOf not isKindOf here, as you're checking for a specific type of unit. 2. The if needs to go inside the forEach scope, as you're testing the _x which only exists within it. { if (typeOf _x == "BLU_G_F") then removeHeadgear _x; removeAllPrimaryWeaponItems _x; _x addHeadgear "H_Shemag_olive_hs"; }; } forEach (units _grp);

The difference between _grp and contact1 is only that the latter is global while the other is only a local variable. But both reference a group within their given scope. What you can do is: private ["_pos"]; _pos = _this select 0; private ["_grp", "_pos"]; _pos = markerPos "enemy_spawn_mrk_obj1"; _grp = [_pos, EAST, (configfile >> "CfgGroups" >> "West" >> "Guerilla" >> "Infantry" >> "IRG_InfTeam")] call BIS_fnc_spawnGroup; [_grp, _pos, 50] call BIS_fnc_taskPatrol; [color="#0000CD"]{ // Do stuff here } forEach (units _grp);[/color] private ["_grp", "_pos"]; _pos = markerPos "enemy_spawn_mrk_obj2"; _grp = [_pos, EAST, (configfile >> "CfgGroups" >> "West" >> "Guerilla" >> "Infantry" >> "IRG_InfTeam")] call BIS_fnc_spawnGroup; [_grp, _pos, 50] call BIS_fnc_taskPatrol; [color="#0000CD"]{ // Do stuff here } forEach (units _grp);[/color]

Amusingly, it dawned on me what nonsense I had written when I was already in bet. What I meant to ask is: is a unit always local to it's owner?

Just for clarification: (owner SomeUnit) && (local SomeUnit) is always either both true or both false, r?

Check your RPT, it should say that ASR_AI3 is loaded and being activated. You can also enable ASR's debug mode in the userconfig.

I'm not sure because if AI skill is set only where the AI is local and then the skill checked where it isn't, they do not correspond. If a locality-change of an AI updates this value as well then everything should be fine. I'll run some tests and let you know if you don't get around to it before me ;)

Thanks for the update! Can you expand on this? How's this going to work if a number of clients are running DragonFyre but the machine where the AI is local to are not? Were you noticing perfomance drops with the "global" syncing of skills? I had a hunch that some sFPS issues we were experiencing was related to sending the stuff related to the skills of newly (zeus) created units over the network and was somehow eh "clogging up the pipes" so to speak. How does this work for units which change their locality, e.g. are put under control of a zeus or into a player's group but were local to the server before? Or a Zeus player/player with AI in their group disconnects and units are put under the server's control? Ah, so a userconfig on the dedi will dictacte the behavior of units in a player's group or under zeus control? That's great! I just noticed that the name of the global variables have changed. Is there backwards compatibility to older missions where ASR features were set with a global variable?

_task is local so it won't be known outside the current scope. You need to wrap that into a single call of BIS_fnc_MP: [color="#FF8040"][color="#1874CD"]_descArray[/color] [color="#8B3E2F"][b]=[/b][/color] [color="#8B3E2F"][b][[/b][/color][color="#7A7A7A"]"Find and investigate the crash site. If possible, retrieve any goods the helicopter carried. Bring them to the marked position on the map."[/color][color="#8B3E2F"][b],[/b][/color][color="#7A7A7A"]"Secure"[/color][color="#8B3E2F"][b],[/b][/color][color="#7A7A7A"]"Search the Area"[/color][color="#8B3E2F"][b]][/b][/color][color="#8B3E2F"][b];[/b][/color] [color="#8B3E2F"][b][[/b][/color][color="#8B3E2F"][b][[/b][/color][color="#1874CD"]_descArray[/color][color="#8B3E2F"][b]][/b][/color][color="#8B3E2F"][b],[/b][/color][color="#8B3E2F"][b]{[/b][/color] [color="#1874CD"]_task[/color] [color="#8B3E2F"][b]=[/b][/color] [color="#000000"]player[/color] [color="#191970"][b]createSimpleTask[/b][/color] [color="#8B3E2F"][b][[/b][/color][color="#7A7A7A"]"Crash site"[/color][color="#8B3E2F"][b]][/b][/color][color="#8B3E2F"][b];[/b][/color] [color="#1874CD"]_task[/color] [color="#191970"][b]setSimpleTaskDescription[/b][/color] [color="#8B3E2F"][b]([/b][/color][color="#000000"]_this[/color] [color="#191970"][b]select[/b][/color] [color="#FF0000"]0[/color][color="#8B3E2F"][b])[/b][/color][color="#8B3E2F"][b];[/b][/color] [color="#1874CD"]_task[/color] [color="#191970"][b]setTaskState[/b][/color] [color="#7A7A7A"]"Assigned"[/color][color="#8B3E2F"][b];[/b][/color] [color="#8B3E2F"][b]}[/b][/color][color="#8B3E2F"][b]][/b][/color][color="#8B3E2F"][b],[/b][/color][color="#7A7A7A"]"BIS_fnc_spawn"[/color][color="#8B3E2F"][b],[/b][/color][color="#000000"]true[/color][color="#8B3E2F"][b]][/b][/color] [color="#191970"][b]spawn[/b][/color] BIS_fnc_MP[color="#8B3E2F"][b];[/b][/color][/color] Made with KK's SQF to BBCode Converter That said, why don't you use the in-game modules for that? They work fine and you can use triggers to activate tasks during the mission.

BIS_fnc_MP is your savior. Learn to love it for we do not want to go back to the dark days of ARMA2. Anyway, while not elegant it would be sufficient to wrap all the lines you need to be executed for all clients into BIS_fnc_MP which spawns BIS_fnc_spawn. Example: _hq sideChat "To all units! We lost contact to one of our Chinook transport helicopters. We have to presume that they got shot down. Find and investigate the crash site ASAP!"; to [[[_hq],{(_this select 0) sideChat "To all units! We lost contact to one of our Chinook transport helicopters. We have to presume that they got shot down. Find and investigate the crash site ASAP!";}],"BIS_fnc_spawn",true] spawn BIS_fnc_MP;

Hey everyone, it seems that somehow an issue with the caching component slipped through and as only now been noticed. In short, the caching component does not properly disable the simulation for infantry on aggressiveness 1-2. We will include the fix in our upcoming release but for now we suggest fixing it yourself: 1. Open the file f\cache\fn_gCache.sqf 2. Replace line 12 which reads if ((count (assignedVehicleRole _x) == 0 || {"Driver" != (assignedVehicleRole _x) select 0}) && (_x != leader _this)) then { with if ((count (assignedVehicleRole _x) == 0 || {"Driver" != (assignedVehicleRole _x) select 0}) && (_x != leader _this)) then { 3. Replace line 17 which reads if ((count (assignedVehicleRole _x) == 0 || {"Driver" != (assignedVehicleRole _x) select 0}) && (_x != leader _this)) then { with if ((count (assignedVehicleRole _x) == 0 || {"Driver" != (assignedVehicleRole _x) select 0}) && (_x != leader _this)) then { For comparison, you can see the file with fixes included here. We're sorry for any issues this might have caused and rather puzzled how the issue slipped through, as we tested the component thoroughly and are using it for our own missions. Be assured that the responsible parties will be receive the appropriate amount of flogging.

If there's no check to exclude specific (non-ground-bound) vehicles, then yes. Because in ARMA-verse even the tiniest drones have "human" pilots :D

if (isServer) then { { this addCuratorEditableObjects [curatorEditableObjects _x,true]; _x addEventHandler ['CuratorObjectPlaced',{this addCuratorEditableObjects [(_this select 1),true];}]; } forEach allCurators - [this]; }; If put in the init of the module (not the controlling unit) of a curator this should add all units of the other curators to the module's list and add an eventhandler to all other curators to automatically add all created units in the future. Note: Wrote from memory, so might have a typo or two but you should get the idea.

That's great news What exactly does this mean?

Functionally it's the same to your if statement: If the code outside the braces is wrong (!kindOf Man) it ignores the inner scope. Only if it is true it evaluates the code inside the braces and if that code is true as well, it proceeds to the inner scope. Perfomance-wise it might negligible but as you're dealing with AI every bit might count? I haven't run the perfomance function on it, might be interesting.

Thanks, that's good hear esp. as your numbers are similar to ours. Have any of the JSRS3 users noticed oddities with explosions related to the bug/ticket mentioned above?

Any server admins can comment on whether there's any performance impact/RPT spam from dragonfyre running client-side with 30+ players around?

The knowledge of SQF is less that of a scripting language and more like the shared oral history of a tribe. If it doesn't doesn't get passed on from member to member it will die ;)

Edit: That should be "towards mission ending" not "at". ASM output from two missions we played the last session. I'd consider the perfomance up until the end fine but am stumped at what might have caused the massive drop. We aren't running any extensive server-side mods (only ASM & ASR_AI3). There's nothing out of the ordinary in the .rpt, only the usual "Object not found" and some jsrs related things. Mission 1: Mission 2: To get the larger version of the image: Right click > copy image url > paste in address bar and remove the "l" before the .png