7erra

I'd make a dialog with a RscEdit or a keypad consisting of a few buttons. The dialog would be created with an addAction. When the correct pin is entered the action is replaced by your options (or another dialog is opened with the options in a list).

For less headaches in SP and MP you can better use this function: BIS_fnc_taskSetState. You can read more about the whole task framework here.

The second parameter of the addAction requires either code or string. In this case you have to drop the {}-brackets. Otherwise the path of the file will get treated as a normal string and not as a path to the script.

Ah now I see the difference 😃 I was wondering why my code didnt work but @johnnyboy's did...

Simple: add the action to the player with the condition "_this in my_boat". Disadvantage: Performance. The condition is evaluated all the time. Better: Use a GetIn EH (or GetInMan) to add the action when the player enters the boat. This would also require to remove the action with GetOut (GetOutMan) EH.

The _actionID is a number and therefore only used for removing the action from an object. You could set a global variable at the end of the addAction script: tasks_lights_on = true; And the trigger could wait for the variable to exist (condition): !isNil "tasks_lights_on"

That point is not always important. There are some cases where the script returns true and suddenly you are not able to reload your weapon or similar. I only found that this is possible by searching through BI scripts as it is not documented on the UI EH BIKI site. I'd have to gather some more information before editing the entry with confidence in my knowledge.

https://community.bistudio.com/wiki/Arma_3_Respawn This link should give a good overview of the respawn system and how to handle it with commands and configs. All of your points are achieveable as it was like this in the Apex campaign (with some minor differences). The 3den Editor also includes a variety of respawn options so messing around with those should bring you closer to your goal.

There is more than one wiki page for this control type. https://community.bistudio.com/wiki/DialogControls-Menu This link has more information about them and I should know because I wrote it 😁

Yeah. You can create a HUD with the cutRsc command. It is basically a dialog which leaves the player in control. For updating the information on this dialog a simple loop is good enough.

A simple counter should suffice. Script is not tested. ShootRocket = findDisplay 46 displayAddEventHandler ["KeyUp", { params ["_display", "_key", "_shift", "_ctrl", "_alt"]; if (_key == 19 && soldier1 == player) then { if (isNil "shot_counter_missle") then {shot_counter_missle = 0}; shell1 = createVehicle ["M_Vorona_HE", position car1, [], 0, "CAN_COLLIDE"]; shell1 setPos (car1 modelToWorld [-0.02,3,0.2]); shell1 setdir getdir car1; shell1 setvelocity [100 * (sin (getdir car1)), 100 * (cos (getdir car1)), 3]; if (shot_counter_missle >= 3) then { _display displayRemoveEventHandler ["KeyUp", ShootRocket]; shot_counter_missle = nil; ShootRocket = nil; }; shot_counter_missle = shot_counter_missle +1; }; false }]; Also some other thoughts: Do you need to access the missile outside of this script? Otherwise it would be better to make the shell1 variable local (_shell1). Also: the global variable names are really simple. It might lead to problems when other scripts are using the same variable names (soldier1, car1, ShootRocket). Use a tag (TAG_soldier1) to prevent accidents. It is also smart to remove global variables from existence after not needing them anymore. Removing my (shot_counter_missle) variable is neccessary if you want to use the script more than once. As for the EH itself: Is there any reason you are not using the "KeyDown" EH as it fires as soon as the key is pressed leading to a more "natural" feel? The return for key handlers should be a boolean. True to overwrite engine behaviour and false to allow it. Returning neither defaults to false.

Imma be honest I have no idea how particle effects work. I used the 3mitter Editor mod to create a particle effect with the parameters from the config (configfile >> "CfgCloudlets" >> "Blood2"). The script does work for me (classic) and this should be the result: During my research I also looked at the mod Blood Lust by Xorberax. He is using actual models which he created for the mod which then get created when a unit is hit. The new object is then set into motion with the velocity commands. This might be less perfomant than a particle though. EDIT: My god I have just seen your BBQ script... No surprises there 😜

Those effects are created by a particle source. There is a path to the following model: "\A3\data_f\particleeffects\universal\meat_ca.p3d". Creating it as a simple object does not work though. Creating it as intended, as a particle effect, does work. Therefore: Meat fountain _emitter = "#particlesource" createVehicleLocal (player modelToWorld [0,2,0]); _emitter setParticleParams [["\A3\data_f\ParticleEffects\Universal\Meat_ca.p3d",1,0,1,1],"","SpaceObject",1,2,[0,0,0],[0,0,2],1,22,1,0.05,[1,1],[[1,1,1,1]],[1],0.1,1,"","","",0,false,0,[[0,0,0,0]]]; _emitter setParticleRandom [0,[0,0,0],[0,0,0],0,2,[0,0,0,0],0,0,0,0]; _emitter setParticleCircle [0,[0,0,0]]; _emitter setParticleFire [0,0,0]; _emitter setDropInterval 0.15; This also explains why there are different sizes of meat chunks depending on caliber.

Oh, yeah. Was too focused on the task at hand and didn't double check ^^. I assumed there would be another text going with it like km/h or similar.

Wouldn't round be the better option? Not that it makes that much of a difference... Regarding performance: Is floor, round, ceil or toFixed better?

My approach would be to use the ContainerClosed EH. This structure might give you a general idea: // Init field of the box if (isServer) then { this addEventHandler ["ContainerClosed", { params ["_container", "_unit"]; // Get the container cargo (?) // _cargo = itemCargo _container; //??? profilenamespace setvariable ["your_cargo_var",_cargo]; }]; }; The code would be executed everytime the box was accessed and items potentially altered. Saving the contents periodically seems unneccessary as it only affects performance while the items shouldn't change without any player interaction. Getting the cargo is another story though. I think I saw some code here on the forums but couldnt find it so far. Using profileNamespace is also not the perfect way as it clutters the users profileNamespace. It is the easiest option for persistency though.

[] spawn {while {alive vehicle player} do { _displaySpeed = speed vehicle player; [format ["%1", _displaySpeed toFixed 0],-0.99,-0.15,9999,0,0,202] spawn BIS_fnc_dynamicText; sleep 0.1; }; }; https://community.bistudio.com/wiki/toFixed

Another day month another update. v2.2 is out now. v2.2 - "Namespace Explorer" Update + Added "Namepsace Variables" in the "Tools" folder. This feature will enable you to browse through the different namespaces and see what variables are used. + "Namespace Variables" button in the Debug Console. ~ Custom Commands, More Watchfields and Live Debug now operate in missionNamespace. ~ Custom Commands: Remote execution now gives an appropriate message.

I just tested it and I have the opposite case. When I press a key it goes to the first entry. This is the class: class RscListNBox { idc = 1500; deletable = 0; fade = 0; access = 0; type = CT_LISTNBOX; rowHeight = 0; colorText[] = {1,1,1,1}; colorScrollbar[] = {0.95,0.95,0.95,1}; colorSelect[] = {0,0,0,1}; colorSelect2[] = {0,0,0,1}; colorSelectBackground[] = {0.95,0.95,0.95,1}; colorSelectBackground2[] = {1,1,1,0.5}; colorBackground[] = {0,0,0,1}; maxHistoryDelay = 1; soundSelect[] = { "", 0.1, 1 }; autoScrollSpeed = -1; autoScrollDelay = 5; autoScrollRewind = 0; arrowEmpty = "#(argb,8,8,3)color(1,1,1,1)"; arrowFull = "#(argb,8,8,3)color(1,1,1,1)"; drawSideArrows = 0; columns[] = {0.001}; idcLeft = -1; idcRight = -1; class ListScrollBar: ScrollBar { }; style = ST_MULTI; shadow = 0; font = "RobotoCondensed"; sizeEx = GUI_TEXT_SIZE_MEDIUM; color[] = {0.95,0.95,0.95,1}; colorDisabled[] = {1,1,1,0.25}; colorPicture[] = {1,1,1,1}; colorPictureSelected[] = {1,1,1,1}; colorPictureDisabled[] = {1,1,1,1}; period = 1.2; x = 0; y = 0; w = 10 * GUI_GRID_W; h = 10 * GUI_GRID_H; class ScrollBar: ScrollBar { }; }; This is the script I wrote to test it: params ["_display"]; disableserialization; _listbox = _display displayCtrl 1500; _alphabet = "qwertzuiopasdfghjklyxcvbnm" splitstring ""; { for "_i" from 0 to 2 do {_listbox lnbaddrow [_x];}; } forEach _alphabet; lbsort _listbox;

The control type is wrong. You are using 5 which is the normal listbox. What you are looking for is the ListNBox (type = 102): https://community.bistudio.com/wiki/DialogControls-ListBoxes#RscListNBox

Yeah I messed something up in my code. I already have a fix ready but have to get back into coding again after such a long break 🙂 Technical explanation: There are different namespaces in which you can operate (missionNamespace, uiNamespace, profileNamespace and parsingNamespace). When declaring global variables they are saved to one of those namespaces. By default that is the missionNamespace. I am using global variables myself in the mod but need them saved in the uiNamespace. Thats why when you try to return a missionNamespace variable it will show up as undefined. You can still return a missionNamespace variable with the getVariable command: missionNamespace getVariable "TestVarGlobal";

No need to add the killed eventhandler: // init.sqf addmissioneventhandler ["EntityKilled",{ params ["_killed", "_killer", "_instigator"]; if (isNull _instigator) then {_instigator = UAVControl vehicle _killer select 0}; // UAV/UGV player operated road kill if (isNull _instigator) then {_instigator = _killer}; // player driven vehicle road kill if (_instigator != player OR !(_killed inArea your_trigger) OR !(_instigator inArea your_trigger)) exitwith {}; // Add your code here: _money = _instigator getVariable ["your_variable",0];// get the variable, if not defined use default (0) _money = _money + 500;//add kill reward _instigator setVariable ["your_variable", _money]; "You received 500$" remoteExec ["hint",_instigator];// execute code local on the pc of the killer }];

Both bugs noted. I have some ideas why the problem might occur.

The mission eventhandler is not bound to a single unit. It tracks every unit which is killed. You can check if a unit is inside of the trigger with the inArea command so the script could look like this: // init.sqf addmissioneventhandler ["EntityKilled",{ params ["_killed", "_killer", "_instigator"]; if (isNull _instigator) then {_instigator = UAVControl vehicle _killer select 0}; // UAV/UGV player operated road kill if (isNull _instigator) then {_instigator = _killer}; // player driven vehicle road kill if (_instigator != player OR !(_killed inArea your_trigger) OR !(_instigator inArea your_trigger)) exitwith {}; // Add your code here: }]; You just have to name your trigger your_trigger.

Anything that is available in the normal arsenal is also available in the shop so it does work with mods. I am not sure what you mean with adding classnames? Of course you have to manually add the content of the shop either by script or with my mod. Regarding the money system: VASS only includes the shop version of the arsenal but nothing more. You will need to use another money system (like the one from HoverGuy's Simple Shops). VASS allows you to interact with said money system through the TER_fnc_VASShandler function. Well addMissionEventhandler ("EntitiyKilled") together with a condition (inArea command) should work.