samatra

I'm not an AI guy but I can suggest a hacky approach, when unit is close to a chair, manually rotate him towards chair with setDir or setVectorDir and then keep setting walk forward action until he reaches the chair with _unit playActionNow "WalkF"

Maybe you have a problem with respawn? Maybe respawn makes your unit captive, changes side to side that is friendly to attacking units?

Change if (["task1"] call FHQ_TT_isTaskCompleted) then ["BlueWin",true,7] call BIS_fnc_endMission; to if (["task1"] call FHQ_TT_isTaskCompleted) then {["BlueWin",true,7] call BIS_fnc_endMission;}; Same with second condition

As far as I heard publicVariableClient actually sends packets to all clients just applies them on one due to improper implementation - http://feedback.arma3.com/view.php?id=22695 Might not be actual in A3 and just in A2 but according to comments might have been addressed in 1.63. I'd use publicVariable if FFA_HOUSES is static and not going to change. If it is changing dynamically and array increases or decreases in size I'd go with pvc and when array updates instead of sending entire array again I'd just send what changed in it to all clients and when JIP joined, send them full final array with pvc once.

fn_isUnitCopilot = { if(vehicle _this == _this) exitWith {false}; private ["_veh", "_cfg", "_trts", "_return", "_trt"]; _veh = (vehicle _this); _cfg = configFile >> "CfgVehicles" >> typeOf(_veh); _trts = _cfg >> "turrets"; _return = false; for "_i" from 0 to (count _trts - 1) do { _trt = _trts select _i; if(getNumber(_trt >> "iscopilot") == 1) exitWith { _return = (_veh turretUnit [_i] == _this); }; }; _return }; use as player call fn_isUnitCopilot you can check any units too Script is bit simplified and doesn't check for secondary turrets (turret on top of a turret) but since there is no such vehicles that have copilots on such turrets you should be fine with stock Arma 3 content and pretty much any addon.

Yes as I said my code example is no suitable for multiplayer, only for singleplayer. Here is MP-compatible version. It has small possibility of having issues when two clients call it at once, withing same frame but it is very rare and unlikely. Server: uniqueIdCounter = 0; publicVariable "uniqueIdCounter"; Client: fn_getUniqueId = { private "_id"; _id = _this getVariable ["unique_id", -1]; if(_id < 0) then { _id = uniqueIdCounter; uniqueIdCounter = uniqueIdCounter + 1; publicVariable "uniqueIdCounter"; _this setVariable ["unique_id", _id, true]; }; _id };

Try scripting approach then: uniqueIdCounter = 0; fn_getUniqueId = { private "_id"; _id = _this getVariable ["unique_id", -1]; if(_id < 0) then { _id = uniqueIdCounter; uniqueIdCounter = uniqueIdCounter + 1; _this setVariable ["unique_id", _id]; }; _id }; Call fn_getUniqueNumber on any object and it will assign it said unique id if it still didn't and return it. This code is no MP compatible but can be easily changed to be.

This "id" is memory address of the entity, it will be different each time you say load the game and as you noticed it is not returned for all entities when converting object to string. Do you need some textual presentation of said id to display in the mission? Because otherwise object itself is already unique and not equal to any other object scripting-wise.

diag_screenshot command is not available in public game versions, you can't use it. One of the solutions would be to write an extension that makes a screenshot but I can't help you with that.

1. Have RscStructuredText inside RscControlsGroup 2. Save RscStructuredText height with ctrlPosition command (old text height) 3. Set text to RscStructuredText 4. Get text height with https://community.bistudio.com/wiki/ctrlTextHeight command (new text height) 5. Increase RscControlsGroup size according to new height (new text height - old text height) with ctrlSetPosition command.

tl;dr; Not possible to heli disable explosion on collision, it is hardcoded and not controllable with HandleDamage. From my experience its not possible to stop helicopters from exploding from impact without disabling damage completely with allowDamage false (which also disables event handlers like HandleDamage leaving you blind about incoming damage). Basically HandleDamage event handler IS NOT fired when helicopter receives heavy collision damage as well as some other damages (like when main rotor touches solid surfaces, it breaks rotor and instantly turns off the engine making helicopter fall like a rock), this is indeed a problem and a bug and I was too lazy to report it on feedback tracker (unless reported already). To understand my point, place a helicopter in editor and add to init line: eh = this addEventHandler ["HandleDamage", {0}]; In theory this should disable ANY damage in ALL cases. Try it with helicopter and test two unhandled damage cases that I described above: heavy collision and touching buildings\trees\ground with main rotor, you will still explode\get damage even though HandleDamage supposed to handle it. Adding same code to say plane will make it invincible even if you hit ground nose down at 500 kmh.

HQ versions already support passenger seats in the models, you just need to change config values (transportsoldiers I think). Unfortunately there are issues like improper animations for some passenger seats or gunner and passenger seat being on same place for BRDM-2 HQ but I'd still add alternative versions of these vehicles with full set of passenger seats.

An idea for commanding vehicle versions: BTR-90 HQ, LAV-25 HQ, BMP-2 HQ and BRDM-2 HQ with full set of passenger slots, could be really useful in missions where you need transport armor but no heavy firepower. I know that some passenger proxies are mispositioned on HQ models but I'd go even with these visual issues, unless of course fixing models is in scope of CorePatch since all A2 models are now released by BI which would be even better.

Yes, the less script threads you have, the better. Of course it also matters how your threads work and what they do. Sure, feel free to use cleanup script as you like. Using call instead of switch really gives very small performance increase but I just prefer switch for better readability.

I don't think you can set high\low stances with setUnitPos

For transition into animation: player playMove "aadjppnemstpsraswrfldup" For sudden animation change: player switchMove "aadjppnemstpsraswrfldup"

I'm afraid its impossible to define something with scripting variable or command (worldName) in it. Having world name as default preprocessor marco would be a useful feature for preprocessor though. Your best bet would be some kind of script (external application) that would automate this for you before say you upload your missions.

I'd say that having one constantly working thread is better than spawning many threads just to close most of them right away. So I'd go with second approach. On the other hand you can call instead of spawn in "Killed" event handler, it will do the check right away within current frame, looking at code it shouldn't cause any performance issues.

Not THAT much of a difference performance-wise honestly since all your code is run in threads (scheduled environment) in the end, even when Killed event handler is executed, you spawn another thread which does sleep and waitUntils. For this kind of task (body cleanup) it all comes down and depends on how it would be better for you as mission designer to manage dead units cleanup, add event handler onto each unit manually, add each unit to "watch list", or simply cycle through allDead command returned array as I suggested. If go nitpicking about performance differences, first approach is worse because it creates many smaller scripting threads, second is worse because it regularly runs "array - array" command (FFA_OBJECTSTOCLEAR=FFA_OBJECTSTOCLEAR-[objNull]) which is fairly expensive if you have very long array. By the way since I had this piece of code for cleanup at hand, going to post it anyway: while {true} do { { // If no cleanup timer set, set it if(_x getVariable ["cleanup_at", 0] == 0) then { _x setVariable ["cleanup_at", diag_tickTime + (switch(true) do { case (_x isKindOf "CAManBase"): {120}; // Dead units - 2 minutes default {300}; // Vehicle wrecks - 5 minutes })]; }; // Check if timer ran out if(diag_tickTime > _x getVariable ["cleanup_at", 0]) then { _dead = _x; if(switch(true) do { // Example of additional condition, delete body anyway if it is right at base so they wouldn't stockpile there as players can die and respawn there, fnc_isOnBase is not provided in this example code case (_dead call fnc_isOnBase): {true}; // Check for players nearby, if there is > 0 players nearby, have switch return false case ({ // If player is within 20 meters, exit "count" loop with result of 1 if(_dead distance _x < 20) exitWith {1}; } count (playableUnits) > 0): {false}; // Default is true => delete the body\wreck default {true}; }) then { deleteVehicle _dead; } else { // Switch condition returned false, means we should not delete body yet and timer has to start again. _dead setVariable ["cleanup_at", 0]; }; }; } forEach (allDead); // Next cycle through dead units in 10 seconds. sleep 10; }; Code supposed to be run once in scheduled environment (execVM, spawn) Pastebin for better readability: http://pastie.org/private/lyjhmlor0h7krjxc0ey4uw

Main difference of event handlers is that they execute scripts in non-scheduled environment while your regular script threads (execVM, spawn, addAction, etc.) run in virtual machine or scheduled environment. Having lots of threads doing heavy calculations will seriously postpone execution of other scripting threads, causing so called script lag. Having heavy calculations in event handler called code will not create any script lag but instead will freeze entire game until execution is complete, you need to be very careful with that especially on server machine as server-side freeze will end up with server-wide lag ruining experience for players. SQS and FSMs are bit different but that's another topic. Again, it all depends on what you want to achieve and how much priority it has to have. If you want to avoid data race conditions or have precise on each frame code then non-scheduled execution is a must. I guess body clean up is not that important precision-wise and executing it in ScriptVM threads should be fine, personally I prefer to have single thread iterating through list of something instead of attaching new thread to each item in the list.

I assume you're trying to do cleanup of dead units? This is definitely not a best approach this as more units will be created through the game calling this code block will assign "Killed" event handler (first method) or another thread (third method) onto same unit multiple times. I'd suggest using https://community.bistudio.com/wiki/allDead instead. Speaking of performance, engine event handlers are always "better" than regular scripted checked, but it all depends on what you're trying to achieve, simply deleting units as soon as they die is definitely not a player-friendly experience as players might want to loot dead units first. Spawning a thread with sleep after unit was Killed might be a solution but personally I prefer to have as less threads as possible. If you're interested in my approach to this task I can share the code.

That error means that you're providing invalid number in position for createVehicle command. When in doubt, log everything that you provide as argument to see what goes wrong and when. diag_log format ["_rndPos = %1", _rndPos]; _chute = createVehicle ["NonSteerable_Parachute_F",[(_rndPos select 0), (_rndPos select 1), ((_rndPos select 2) + 150)],[], 0, "CAN_COLLIDE"]; And then check your RPT to see what _rndPos is.

Description Thread dedicated to Sa-Matra's Wasteland for ArmA 3. Thread is currently in state of placeholder, will be expanded later. Mission will be available for hosting for other communities later when we will reach stable state of the mission. It will be either semi-public or fully public, we did not decide yet. --- Wasteland for ArmA 3 by Sa-Matra reached final development stage of public testing, we invite all ArmA 3 players that enjoyed our Wasteland in ArmA 2 to help us with playtesting. Sa-Matra's Wasteland is proper ArmA 3 Wasteland built from ground off with almost everything rewritten and reworked with all our develpoment and administration experience of making Wasteland for ArmA 2 taken into account. Some of the key features of our Wasteland: 1) Gun store with ability to buy everything from repair kits and fuel cans to guns and equipment as well as ability to sell it 2) 9 new towns to spawn in, all buildings spawn loot inside them ranging from food\water to repair kits, fuel cans, backpacks and rarely ammo crates 3) Reworked food\water system which now regenerates your health if you have 100% hunger and 100% thirst status 4) 7 missions including underwater missions 5) Custom handling of vehicles locality which helps with access to equipment inside vehicles. (In most cases you will not have to drop stuff on ground before taking it) 6) Lots of features from ArmA 2 Wasteland are intact: you can spawn in helicopters, on base defense radars, forming groups, etc. Known bugs: - "NV Goggles" spawned inside crates and vehicles cannot be taken, this is ArmA 3 bug again: http://feedback.arma3.com/view.php?id=7886 - General problems with inventory are still in the game, they are not related to Wasteland (items duping, being unable to get certain items off crates or bodies, etc.) Servers

Can't see where GUI_GRID_H is defined, is it even defined?

It does work. You need to define fnc_killLights function somewhere and then pass vehicle that you want break lights for as argument (myvehicle call fnc_killLights).