Wolfenswan
-
Content Count
212 -
Joined
-
Last visited
-
Medals
Posts posted by Wolfenswan
-
-
Wait, you're saying that not everybody on the server are running the same mods and you are surprised things aren't working?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.
2) Another way to make an action happen is to use a trigger. For the trigger, you can set it as "once" or "repeated" (you want it at once obviously). You can also set the condition: _unit in thislist; . You replace the "_unit" for the name of the only unit the trigger will activate for (rather than setting it as any BLUEFOR, OPFOR, INDI, etc.)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 ;)
-
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]
-
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.
-
AFAIK Owner returns an number (scalar), while local return a boolean. So they can't be used in the way you write it.Right, owner gives machine id (number) while local someunit can be true or false.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?
-
- skills assigned automatically on AI owner machines onlyJust for clarification: (owner SomeUnit) && (local SomeUnit) is always either both true or both false, r?
-
I'm testing it by just placing me and an opfor soldier, and one opfor squad a bit from us.The opfor soldier does not take of his NVGs (despite it beeing noon) and when I kill him the opfor squad does not react. When I fire on them they get down, shoot back and then get up and act as vanilla. This means it's not working as intended, yes?
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 expect their skills to be preserved. If not, I'd class it as bug.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!
- shot detection adapted to work with DragonFyre sound modCan 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?
- skills assigned automatically on AI owner machines onlyWere 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?
- userconfig changed to sqf and used on servers only (single player too)- all user configurable settings loaded from server now, without exceptions
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.
-
Could it be that this also affects drones just like it affects helicopters?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.
-
Fixed: Medics lost the ability to heal when target was teleported
That's great news
Improved: Road binarization
What exactly does this mean?
-
I don't fully understand lazy evaluations, which is why I did the staggered if then statements.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.
-
Averaging 40 players now every night, we allow JSRS3 and I know many are using it. Server FPS have not decreased from the average FPS I'm used to seeing.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?
-
I'm constantly impressed by the level of skills members present here.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
-
Splendid work! I've always been yearning to do sth. like this but the velocity calculations were too annoying :D
Looking at the script, you seem to create a number of dummy objects. Any performance issues on a dedicated environment? You might want to disable Simulation on the dummy objects as there doesn't seem to be a need to broadcast them over the network.
Also:
[_objectsHouseArray] spawn { _objectsHouseArray = _this select 0; sleep 15; { deleteVehicle _x; } foreach _objectsHouseArray; };
seems wasteful (selecting array inside array). Why not just
_objectsHouseArray spawn { sleep 15; { deleteVehicle _x; } foreach _this; };
?
Furthermore, you could replace the staggered if clauses such as
if (!(_x isKindOf "Man")) then { if (!(_x isKindOf "Helper_Base_F")) then { if (!(_x isKindOf "Logic")) then {
with
if (!(_x isKindOf "Man") && {!(_x isKindOf "Helper_Base_F") && !(_x isKindOf "Logic")}) then {
That way you only have one if check with a lazy eval.
JSRS3: DragonFyre
in ARMA 3 - ADDONS & MODS: COMPLETE
Posted
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.