7erra

That is a very interesting find and I would never have known that... Added this information to https://community.bistudio.com/wiki/Arma:_GUI_Configuration#Exit_Codes

Random lines I suppose? Then this should be what you are looking for: selectRandom

put those into quotes really bad idea to use displayRemoveAllEventHandlers on the mission display. this will mess up all the other scripts that added an UIEH to it. better save the return from displayAddEventhandler and use displayRemoveEventhandler with it.

yes, with https://community.bistudio.com/wiki/User_Interface_Event_Handlers#onKeyDown what main menu? the one you see at the start of the game?

uiNamespace getVariable "ctrl" though I would suggest you choose another variable name, since this name is easily overwritten

First thing I could find was this framework: It allows you to save the cargo of objects with saveObject and loadObject functions: https://github.com/code34/oo_pdw.Altis/blob/master/DOCUMENTATION.txt. The saveObject function has to be called periodically or when the server shuts down. The loadObject function has to be called from initServer.sqf I guess.

you have to get the variable from uiNamespace with getVariable

You can use the LBSelChanged UIEH for that You can only use a button UIEH on a button. Listboxes are not buttons. lbAdd does not return a control. it returns the index of the added entry. also: using the first syntax instead of the second one is unreliable.

For some reason exitWith will not overwrite the event. try if else instead: _displayHandler = (findDisplay 46) displayAddEventhandler["KeyDown",{ params ["_display","_key"]; if (_key == 1) then { true } else { false }; }]; // or even more simple: _displayHandler = (findDisplay 46) displayAddEventhandler["KeyDown",{ params ["_display","_key"]; _key == 1 }];

That might be because the FAK gets removed twice for normal players, once the action starts (my script) and once the action finishes (engine). Maybe adding a check to see if the player has a Medikit before removing the FAK would solve that issue, so something like //--- player has enough FAKs to heal if ("Medikit" in items _caller && _caller getUnitTrait "Medic") then { _caller removeItem "FirstAidKit"; }; false Can't fight the engine, so no. But you can overwrite the engine behaviour by returning true at the end of your code.

You can use inGameUISetEventhandler: TAG_fnc_handleHeal = { params ["_target", "_caller", "_index", "_engineName", "_text", "_priority", "_showWindow", "_hideOnUse", "_shortcut", "_visibleMenu", "_eventName"]; if !(_engineName in ["HealSoldierSelf", "HealSoldier"]) exitWith {false}; if (items _caller findIf {_x == "FirstAidKit"} == -1) exitWith { //--- No remaining FAKs hint "You do not have any First Aid Kits"; true }; //--- player has enough FAKs to heal _caller removeItem "FirstAidKit"; false }; inGameUISetEventHandler ["Action", "_this call TAG_fnc_handleHeal"];

There is a tool for publishing missions directly built into the editor. Top bar >> Scenario >> Publish to Steam Workshop.

No, I meant the isNil command (modified example 4 from the BIKI): 0 spawn { systemChat str canSuspend; // chat shows true [] call { systemChat str canSuspend }; // chat shows true isNil { hint str canSuspend }; // hint shows false };

If you are calling code from a scheduled function (which you are otherwise you could not use waitUntil) then that called code will also run scheduled. to run unscheduled code from scheduled environment you have to use isNil. Kind of weird but that's how it is.

yeah in this case just passing the code is fine. Another unrelated tip: you don't have to use spawn and waitUntil. this can be simplified to if(!isServer) exitWith {}; params ["_newActiveAreas", "_civArray", "_soldierArray", "_vehicleArray", "_vehCode", "_civcode", "_soldierCode"]; if(_newActiveAreas isEqualTo []) exitWith {}; { // forEach _newActiveAreas [_x, _vehicleArray, _vehCode] call activateVehicles; [_x, _civArray, _civCode] call activateCivs; [_x, _soldierArray, _soldierCode] call activateSoldiers; } forEach _newActiveAreas;

BIS_fnc_removeRespawnPosition takes two parameters. the first specifies whose respawn will be removed, the second one is the id of the respawn. I assume that you got respawn2 as a return value from BIS_fnc_addRespawnPosition so if you pass it as is to BIS_fnc_removeRespawnPosition then it will get removed from everyone that got the respawn position via your addRespawnPosition call. Instead you should only remove it from the player that died: [player, respawn2 select 1] call BIS_fnc_removeRespawnPosition;

Already solved but here's some more things to know: 1) Pass the code directly (as you did) tag_fnc_test = { hint "hello"; }; tag_fnc_callThis = { params ["_fnc"]; [] call _fnc }; [tag_fnc_test] call tag_fnc_callThis; 2) Use the variable from missionNamespace tag_fnc_test = { hint "hello"; }; tag_fnc_callThis = { params ["_fnc"]; [] call (missionNamespace getVariable [_fnc, {}]); }; ["tag_fnc_test"] call tag_fnc_callThis; The second option might be marginally slower but the huge advantage of it is if you want to remoteExec tag_fnc_test on another client (or even all clients). In the first case you would send over the code which can be quite huge. in the second case you just pass the function name as a short string and get the code on the client. i.e. this scenario: [tag_fnc_test] remoteExec ["tag_fnc_callThis"]; // code is sent over network // vs. ["tag_fnc_test"] remoteExec ["tag_fnc_callThis"]; // string is sent over network

What is your script supposed to do? There is the loadAbs command to return the weight of all items a unit is carrying

The error is triggered because you are trying to suspend the script with sleep in a non-scheduled environment. To avoid this you can spawn the EH code: _this spawn { params [... // Check if instigator is player and the killed unit was on the same side with the instigator/player if ((_instigator isEqualTo player) && (playerSide isEqualTo (side group _killed))) then { // Get the amount of friendly kills of the player private _nKills = player getVariable ["YOU_nKills", 0]; _nKills = _nKills + 1; // Increment (friendly) kills // Check amount of kills if (_nKills >= 2) then { removeAllWeapons player; hint parseText "<t color='#FF0014'><t size='1.1'>!FRIENDLY FIRE WILL NOT BE TOLERATED!</t>"; playSound "alarm"; sleep 1; v1 sideChat "Vančo have you gone completely nuts?! You'll face consequences for this!"; sleep 3; ["lose",false,5,false] spawn BIS_fnc_endMission; }; // Set the variable with the new number of kills (this is in case you didn't finish the game of course) player setVariable ["YOU_nKills", _nKills]; }; }; NOTE: This code is not copy-pasteable because you probably missed the first lines when copy pasting

Can you check the output of the variables like this? diag_log [_instigator isEqualTo player, playerSide, side player, side group player, side group _killed]; From my own experience I am pretty sure that the side of the killed unit in the EH is ALWAYS civillian because it's dead

The side of killed units is always civillian. You have to check the side of the group the unit belonged to: if ((_instigator isEqualTo player) && (playerSide isEqualTo (side group _killed))) then {

Units will be considered hostile when their rating drops below -2000: https://community.bistudio.com/wiki/ArmA:_Armed_Assault:_Rating_Values You could use the HandleRating EH like this: // initPlayerLocal.sqf player addEventHandler ["HandleRating", { params ["_unit", "_rating"]; if (_rating < 0) then { 2 * _rating } else { _rating }; }]; According to the table on that page it should be enough to kill two firendlies already, you might have to use another value than 2 to get your desired result

Hmm I don't seem to have any mods that would showcase this best. I'll take some examples from CBA: https://github.com/CBATeam/CBA_A3/blob/master/addons/accessory/script_component.hpp#L2: #include "\x\cba\addons\main\script_mod.hpp" This is a file that resides inside of one of CBA's addons. The path points to a file inside of the "main" folder (this could also be a video, image, etc. for scripts and configs). Now if we look at the "main" addon we can find the script_mod.hpp. Inside of the main addon is also the $PBOPREFIX$: x\cba\addons\main This is the path that is used in the include statement. Also have you opened your pbo in a pboviewer to see if all the files are there? I can recommend this one by @SteezCram:

I am slowly running out of ideas as this is what I do for my mods. maybe you can check out CBA's repository and compare your setup with theirs: https://github.com/CBATeam/CBA_A3

whoops I thought that the units and weapons arrays were optional. I updated the originial answer. Also finally found the correct BIKI page to give an introduction to creating addons: https://community.bistudio.com/wiki/Arma_3:_Creating_an_Addon (this is a new page and still WIP). After a bit more reading I think the P drive is not really necessary for such a small mod but if you want more info here you go: https://forums.bohemia.net/forums/topic/190353-howto-work-drive-setup-bulldozer/