opusfmspol

The waitUntil is doing what one could expect; create a delay until condition is met. But if run constantly it really should use a sleep. It would be better if run only when really needed, i.e. at times when the squad leader is likely to have died/is respawning(reviving). If your custom revive is using a 'HandleDamage' event handler, it might be better to have the (server side) waitUntil spawn inside the event handler whenever the result is such that the unit will lose group leadership. So when the event handler completes, the unit loses group and the waituntil completes almost instantly. If not using 'HandleDamage' perhaps you could similarly use it to minimize the time waitUntil is running.

Not tested, but try this in the editor init field of the playable units in groups synched to the AIS (because one in group synched = whole group gets synched): _respawnHandle = this addEventHandler ["Respawn",{Private "_unit"; _unit = _this select 0; if (Local _unit) then {if (Captive _unit) then {_unit setCaptive false;};};}]; The event handler will be added on each machine joining, but the setCaptive command will only run where the respawned unit is local.

I would think it lags because it's using a suspension without sleep. waitUntil checks condition (about) each frame. How many FPS is running? CPU gets tied up making high volume checks waiting for true. But even when true does occur, it spawns right back into the waitUntil. So CPU is getting kept busy with no rest. Using Sleep 0.1 in the waitUntil could free up some lag. If speed of the join is not critical, maybe use Sleep 0.25, or 0.5. But at about 0.5 (twice per second) I would think players could start observing the join has a very slight delay. If speed is critical then the sleep time becomes a tough balancing act, trying to find CPU friendly versus FPS.

To my knowledge there's no way to stop group leadership from getting passed down when the leader is killed. It occurs instantaneous in the background because a dead unit goes to grpNull, but a delay occurs in it getting called out until someone else in the group realizes the leader has been killed (something with knowsAbout ?). Respawn and MPRespawn event handlers can make a respawned player the group leader again. Your script above does it. Warfare also does it, running the Client_Killed.sqf and then the Client_PlayerRespawn.sqf. But from your next post, I take it the issue is that the respawned unit can no longer issue orders or missions. This is where the scripting maybe should have considered having the orders and missions issued by a player group leader rather than a specific unit. Because the respawned unit will not be the same one that was placed in editor. The variable assigned in editor will identify the dead unit. The respawned unit will have a different identifier without a variable assigned (unless scripted to do so). The editor variable can be reassigned to the respawned unit. Option 1: Reassign the editor variable when the unit respawns. In the commander unit's respawn event handler add: SL_1 = _this select 0; However doing that might cause problems if code or scripts handling the dead unit are still relying on the assigned variable. And there would still remain the problem of no orders or missions being issued while player respawns, if that is an issue. Option 2: Revise the scripts, and in the commander unit init field in editor, place something like: grpCommand = Group this; In the scripts to issue orders and missions, instead of referencing the unit by variable, i.e: if (isPlayer SL_1 && Alive SL_1) then { // SL_1 issues orders and missions. _missionAction = SL_1 addAction ["Issue New Mission", . . .]; _ordersAction = SL_1 addAction ["Issue New Orders", . . .]; }; reference the group leader, like this: if (isPlayer (Leader grpCommand) && Alive (Leader grpCommand)) then { // grpCommand leader is player and can issue orders and missions. _missionAction = (Leader grpCommand) addAction ["Issue New Mission", . . .]; _ordersAction = (Leader grpCommand) addAction ["Issue New Orders", . . .]; }; This would be best for single player, multiplayer and dedicated server.

Are you using the First Aid: Simulation module (AIS) or a setCaptive command? When a unit goes into agony the AIS sets the unit captive. If the unit recovers, captive gets removed. But if the unit dies while in agony, captive does not get removed and the respawned unit is set captive. Captive units are detected as side civilian and AI won't engage them. A respawned captive unit needs "<unitName> setCaptive false;" run on the machine where the unit is local to have AI start engaging them again. Simple fix might be a Respawn Event Handler or MPRespawn Event Handler that includes: _unit = _this select 0; if (Captive _unit) then {_unit setCaptive false}; If not using AIS, maybe test with a respawn event handler or some trigger to detect and message about respawned player side and captive status, to eliminate that as a possibility.

Probably a viewpoint. https://community.bistudio.com/wiki/Location#Location_Types

Not tested, just cleaned and tuned up somewhat. Hope it helps you fine tune into a working state. if_uncon.sqf drag_wounded.sqf

True that. All are local in single player. Other suggestions: If not already doing so, use launch param -showScriptErrors so that errors appear on screen when they occur. If doing so, don't use launch param -noLogs so that detected errors get logged in the .rpt report. Maybe it's a matter of using quotes instead of semiquotes. When data type is a string, any strings within it should be using semiquotes, i.e.: "dragger playMoveNow 'AmovPercMstpSlowWrflDnon' ;" Maybe enableAI "ANIM" needs to be done before playMoveNow "", I.e. move won't play while animation is disabled.

Locality in multiplayer maybe? Waypoints are a group function, but I seem to recall a problem I had to overcome some months ago where waypoint condition was detected on all but waypoint expression ran only on the machine where the leader was local.

@Spudnut The "HandleDamage" event handler would be the best way to go, it should be sufficient. But if not, you could also copy certain of the module scripts and fsm's to your mission folder to modify how they work for your mission. It would rely on a soft path used by the first aid scripts and fsm's. In summary: - When the hard path "\ca" is used, the engine only runs core addon scripts. When you see a soft path "ca" (no beginning backslash) is introduced, the scripts and fsm's using that path can be copied into the mission folder for the mission maker to work with. The engine first searches the path in the mission folder for the script or fsm. When not found it defaults back to the module. So the hard path ensures an addon script or fsm runs without change, the soft path allows mission makers to copy certain ones over into mission folder and change how they work. - Each of the First Aid modules initializes on a hard path. FA (Action), AIS (Simulation) and BC (Battlefield Clearance) each have their own initializing script ("x_serverStartUsingLogic.sqf" where x_ is the module name FA, AIS or BC). Copying those scripts to mission folder won't work since the engine runs them from the hard path. - But each of the initializing scripts defines a path for running the remaining scripts and fsm's. AIS and BC both introduce a soft path for their scripts and fsm's, but the FA module continues to set a hard path. - However, the StartUsingLogic script for AIS does a proxy initializing of FA if not already initialized; and when it does, it introduces a soft path for FA. - So copying FA scripts into the mission folder will work when AIS is used to initialize FA. You basically leave the Action module (FA) off the map and place the Simulation module (AIS). The AIS initializes both FA and AIS, both introducing soft path. Then you can work with both the FA and AIS scripts. BC - soft path, FA - hard path, AIS - soft path + initializes FA with soft path. In your mission folder create a folder "ca", and in ca folder create other folders copying the path of the scripts or fsm's you would work with, i.e. "ca\Modules\AIS\data\....".

'expected nothing' is because the OnAct field of a trigger must return nothing. The command createDiaryRecord returns a string. Try with a defined variable used, something like: record0 = player createDiaryRecord ["Diary", ["Jackal's Location", "The Jackal's farm house is located coordinates 044124."]];

Disregard surrender module, error was mine. Found units set captive get excluded. I hadn't realized that. (DOH! *headslap* --ow) But still having local variables accepted in editor init fields, and don't know if that's an issue or not. _testing = true does not give a 'local variable in global space' error, but: _ok = _this execVM .... does cause the local in global error. It isn't an error on _ok, it's an error on _this. That's where the cursor rests when the error is acknowledged.

I have local variables getting accepted in editor init fields, and surrender module doesn't seem to be functioning at all, but it was two days ago. Is anybody else experiencing this? verifying cache and deleting/redownloading pbo's hasn't helped. My next step is full reinstall. edit:-- Reproduction: [deleted, was bad example] Full reinstall of Steam, A2 and OA done. Same result. But on a plus side, the 'cannot find sound' spams aren't appearing in OA .rpt log, which is a great help with mission debugging.

Now I apparently have to do the same. I noticed A2 made no switch download when I went from beta to stable, but Dwarden had posted earlier "A2 beta branch == A2 stable branch", so I thought nothing of it. Appears something does need changing though.

I just switched from beta (both A2 and OA) to stable, and it's not recreating what you show. I get all five icons lower left, (A2,OA,BAF,PMC,ACR) and the A2 missions content is accessible. Are you launching by using mod params that exclude A2? In library right click Operation Arrowhead, select "properties" and then button "Set launch options" and check param "-mod=" if used; or if launching by .bat file, check its param: -mod=. Edit: Launching with params in Steam, I just encountered the issue. Launching with these params were no problem: -nosplash -showScriptErrors -world=empty But as soon as I included a -mod= line, the problem occurred. I went down the line removing mods; -nosplash -showScriptErrors -world=empty "-mod=C:\Program Files (x86)\Steam\steamapps\common\Arma 2\arma2.exe;Expansion;ca;BAF;PMC;ACR" -nosplash -showScriptErrors -world=empty "-mod=C:\Program Files (x86)\Steam\steamapps\common\Arma 2\arma2.exe;Expansion;BAF;PMC;ACR" -nosplash -showScriptErrors -world=empty -mod=Expansion;ca;BAF;PMC;ACR -nosplash -showScriptErrors -world=empty -mod=Expansion;BAF;PMC;ACR -nosplash -showScriptErrors -world=empty -mod=BAF;PMC;ACR -nosplash -showScriptErrors -world=empty -mod=BAF;PMC -nosplash -showScriptErrors -world=empty -mod=BAF -nosplash -showScriptErrors -world=empty -mod=st_bunnyhop (last test used a community mod only) All of them reproduced krzychuzokecia's issue. Only when the -mod= line was variously restored to "-nosplash -showScriptErrors -world=empty" did Arma 2 content reappear. Using the "Expansion" launcher for mods worked fine though. Seems the issue is perhaps with using the -mod= param?

If you're not running beta, but another version, you would switch to beta version. Beta in Steam is installing the latest candidate from first post (currently v1.64.144373). And if you are already on beta and it's not updating, you might check your update setting in Steam, could be turned off or waiting for your prompt to update. To switch to beta: When you have Combined Ops (CO, which is A2 + OA), it's important that both A2 and OA are set to beta, and that A2 gets loaded and launched first before OA gets loaded and launched. CO needs A2 content to run before OA gets run. Whenever versions are switched, download- verify- launch A2 first, then download- verify- launch OA. A2: 1.) Have Steam launched in administrator mode. 2.) In Steam library right click A2 game and select properties. Select 'betas' tab and choose -beta from the list. An update queues. Wait for the A2 files to complete downloading. 3.) Right click A2 and go to properties again, select 'local files' tab. Choose button: Verify Integrity of Game Files. Wait for verification of the files to complete. 4.) Launch A2. You only need to reach the main selection screen. OA: same process, 1.) Have Steam launched in administrator mode. 2.) In Steam library right click OA game and select properties. Select 'betas' tab and choose -beta from the list. An update queues. Wait for the OA files to complete downloading. 3.) Right click OA and go to properties again, select 'local files' tab. Choose button: Verify Integrity of Game Files. Wait for verification of the files to complete. 4.) Launch OA. You only need to reach the main selection screen.

Regression. It was not doing that before.

Voting came back (1.64.144343). But when player commander deployed the MHQ into an HQ, this error happened: Warning Message: 'iconStaticObject/' is not a class ('' accessed) Occured with a confirmation pop-up, to be acknowledged.

Encountering multiplayer problems with Warfare on LAN play, both editor-made missions, and the BI missions ("When Diplomacy Fails", "Superpowers"). Occurs with DS and non-DS multiplayer. The "clientID" variable doesn't get defined. In the WF scripts, during client initialization a function is used to get clientID. The function uses Find command and should return index +1; i.e., 0 (not found) or the index number of the client's joined group. But .rpt log is reflecting clientID undefined error. (perhaps indicating the function isn't returning anything?) I didn't suffer this as host with a create-and-play editor mission. I encountered it when the mission was exported to .pbo and launched with a DS. Then I deleted the PBO and went back to the editor mission, and had a second client machine join in; the joined client had the problem but the host didn't. The problem indicator occurs at mission start, and is rather obvious; the client can't vote for commander when the clientID is undefined. The action menu doesn't appear. If they open map to vote, only "AI" appears in the vote list. (edit: forgot to mention - running A2 beta and OA beta.)

And that jogs my memory, thx for that: It appears TRANSPORTUNLOAD also has similar issue. https://community.bistudio.com/wiki/Waypoint_types#Transport_Unload It may be that the single waypoint is hardcoded with checks for both groups, causing the fail. Running looped currentCommand checks on leaders and the units could affirm. Whenever a unit reaches unitReady status, the empty string ("") gets returned. But as found, it only gives accurate return to the local instance, and returns true to all others, making the others jump the gun. It seems a unitReady check might be getting made on the truck before a "GET OUT" command is made to the cargo team.

These seem to be working, give them a shot: syntax: x = skill unitName syntax: x = unitName skill skillType

Are you using editor "GET IN" synched with "LOAD" waypoints to have the units board the aircraft and trucks? Rather than mods the culprit could be a known issue that synchronized "GET IN" and "LOAD" waypoints have in multiplayer. Hosted MP and DS need scripting effort to make them work. Instance of Arma: Launch of an arma exe. SP and Hosted MP are one instance of Arma launched, as both server and player/host. DS is a separate instance of Arma. A machine can have two instances running at one time, with DS launched and MP launched to join as a player. Launching DS creates one instance, launching MP to play creates another instance. DS testing gives best results when using two machines with three instances (DS/Player & player), it can give answers to questions raised where locality might be tied to a machine rather than an Arma instance, the DS/Player being JIP on server machine, and the other player being a true remote JIP. Synchronized "GET IN" and "LOAD" waypoints Placed in Editor: - In SP it works because server and player are the same instance of Arma running. - In Hosted MP it works for host, but not for JIP. Server is same instance as the host, but JIP is a separate instance of Arma running. - On DS, it works when AI leaders have both the "GET IN" and "LOAD" waypoints. It fails when either leader is a player. Regarding certain waypoints probably being hard-coded in their function with the 'unitReady' command (which doesn't broadcast), there was discussion already: Since then I've done more testing. And where I had thought that the vehicle with the "LOAD" waypoint must be created by the same instance of Arma as the leader having the "GET IN" waypoint, I'm now questioning if that's really the case or if which instance of Arma reads waypoint conditions is the critical factor. I found that only the instance of Arma for a group leader is checking his group's waypoint condition. No other instance checks the waypoint condition. If the leader is AI, only server instance checks the condition (even when players are subordinate in the group). If the leader is player, only that player's instance of Arma is checking waypoint condition. And in SP and Hosted MP, player/host is the server instance. But all instances will execute the waypoint expression once condition becomes true for the leader doing the check. The 'unitReady' command doesn't broadcast between instances, which is a real problem to overcome where only waypoint group leaders check waypoint condition and synched waypoints may have it hardcoded to their function. The synchronized function of the waypoints would fail where the two leaders are not in the same instance of Arma. (Final note: my platform is A2/OA Combined Ops, but as the linked discussions above showed, not much appears changed with this waypoint behavior in A3. To test waypoints for the instances of Arma, I inserted diag_logs into waypoint conditions and expressions, then checked to see which instances were reporting to the .rpt log. Was surprised to find only the group leader instance reporting the waypoint condition check.)

Video tutorials by apocalypse dan:

Try trigger condition: isNull ammo_1 That should work if the box is getting deleted when loaded.

See if this works: _vehs = []; { if (vehicle _x == _x) then { _x setPos ([_destination,50,50 * 1.3] Call GetRandomPosition); } else { if !(vehicle _x in _vehs) then { vehicle _x setPos ([_destination,50,50 * 1.3] Call GetRandomPosition); _vehs = _vehs + [vehicle _x]; }; }; } forEach units _team;