7erra

Okay here are the basics: An eventhandler is a piece of code that is executed everytime the event happens. HandleDamage fires when a unit receives damage. Every EH has arguments passed to the script. They can be found here: Arma 3: Event Handlers. The parameters for HandleDamage can be found here. Furthermore, if you return a number at the end of the HandleDamage EH this number will be the new damage. damage >= 1 will kill the object. To increase the damage incrementally we can do some simple math: this addEventHandler ["HandleDamage",{ _rocketClassname = _this select 4; _damage = _this select 2; if (_rocketClassname == "classname_of_your_rocket") then { _damage * 2 }; }]; With this code in the init line of the tank, the tank will receive double the damage when hit by a rocket with your classname. You can adjust the "2" to lower or higher values. I usually test my code even when I'm sure it works. Multiplayer is a different story though.

With this statement you are deleting the group and not the units. exit_1 setWaypointStatements ["true", "deletegroup searchgroup"]; The correct statement would be: exit_1 setWaypointStatements ["true", "{deleteVehicle _x} forEach units SearchGroup"]; To avoid the global variable you can use thisList (see setWaypointStatements) exit_1 setWaypointStatements ["true", "{deleteVehicle _x} forEach units thisList"];

Actually here is a function: TER_fnc_findIDC = { /* Author: Terra Description: Execute the script and wait for the message "IDC finder initialized on displays: [display array]". Then you can hover above any button and see the IDC of the control. The tooltip might not be accurate everytime because of control groups. Systemchat output is more reliable. Parameters: 0 - Delay between execution of the function and activation (NUMBER) Default: 5 1 - exclude displays. (ARRAY OF IDDs) Default: Standard displays 0, 46 (Game display), 12 (Map), 49 (Escape menu) Example: [] spawn TER_fnc_findIDC; */ disableSerialization; params [ ["_delay",0,[123]], ["_exclude",[0,12,46,49],[[]]] ]; _exclude = _exclude apply {findDisplay _x}; uisleep _delay; _displays = allDisplays -_exclude; { { _x ctrlAddEventHandler ["MouseEnter",{systemChat format ["IDC: %1",ctrlIDC (_this select 0)]}]; _x ctrlSetTooltip format ["IDC: %1",ctrlIDC _x]; } forEach allControls _x; } forEach _displays; systemChat format ["IDC finder initialized on displays: %1",_displays]; };

Another option would be to go through the ingame config viewer. Most of the displays start with "Rsc" and so does "RscDisplayArsenal". After searching a bit through the entries you will find the buttons you are searching for here: configfile >> "RscDisplayArsenal" >> "Controls" >> "ControlBar" >> "controls". Whatever is easier for you.

To prevent the tanks from blowing up because of minor damage you can add a damage threshhold: this addEventHandler ["HandleDamage",{ if (_this select 4 == "classname_of_your_rocket" && _this select 2 > 0.5) then {1}; }];

Okay let's make a cutRsc: (tl:dr at the end) Create a description.ext Put this in it: #include "GUI\defines_A3.hpp" class RscTitles { class Default { idd = -1; fadein = 0; fadeout = 0; duration = 0; }; #include "GUI\heliOverlay.hpp" }; Create the defines_A3.hpp: defines_A3.hpp (@drive.google.com) Create the folder path and the file Put this in the heliOverlay.hpp: class RSC_NAME { idd = IDD_NUMBER; movingEnable = 0; onLoad = "0 = _this execVM ""GUI\onLoadHeliOverlay.sqf"""; duration = 1e+6; // lasts for 1.000.000s, change to 5 then you don't need the "sleep 5; "" cutFadeOut 0;" command in the onLoad script (see below) fadein = 0; fadeout = 0; class controlsBackground { }; class controls { }; }; Change the RSC_NAME to something you like, idealy with your TAG and Rsc: TAG_RscHeliOverlay. Also change the IDD to a number. Don't use any IDD that is already in use like 0,12,46,49 and some more. Pick a random number but don't worry it is highly unlikely that you will notice any problems since there are hundreds of IDDs in use. The higher the number the further it is placed in the front. Go ingame and use the GUI editor. Create the display you want. (I hope you know how to use it but it is not that complicated) Create the onLoadHeliOverlay.sqf: disableSerialization; _mainDisplay = _this select 0; _yourControl = _mainDisplay displayCtrl IDC_YourControl; _yourControl1 = _mainDisplay displayCtrl IDC1_YourControl; _yourControl2 = _mainDisplay displayCtrl IDC2_YourControl; //... _yourControl progressSetPosition 100; _yourControl1 ctrlSetStructuredText parseText (_text_1); _yourControl2 ctrlSetStructuredText parseText (_img); sleep 5; "YourLayerName" cutFadeOut 0; (I'll skip some steps as there are enough tutorials for this purpose out there and I'll focus on the cutRsc command) Now if you've done something wrong then the game will tell you by crashing to desktop ;) Also when working with the description.ext you have to go back to the editor everytime and save your mission again. You can create the display with cutRsc: "YourLayerName" cutRsc ["TAG_RscHeliOverlay", "PLAIN"]; Or in your case: ["YourLayerName",["TAG_RscHeliOverlay","PLAIN"]] remoteExec ["cutRsc",crew _heli]; There we go that's it. My tests worked so far but not tested in MP even though I am confident this should do. tl:dr: Create a dialog with the attributes of a Rsc Use the cutRsc command with remoteExec onLoad will do the trick Additional information, general tips for dialogs: That's all. Easy, eh?

You'd probably be better off making a dialog.hpp and then remoteExec cutRsc with an onLoad script (function). Otherwise you can do this: [[],{ /* Your code goes here */ }] remoteExec ["call/spawn",crew heli];

Another option would be to return the created emitters via the variable on the logic: _emitters = _myLogicObject getVariable "effectEmitter"; This returns an array of emitters in case there was another one created. Then you can delete it with your forEach command. This option might be more elegant since you can precisely delete only emitters that were created with the module. If there is another emitter nearby then your function would delete those as well.

this addEventHandler ["HandleDamage",{ if (_this select 4 == "classname_of_your_rocket") then {1}; }]; Put this in the init of the tank. Change the "classname_of_your_rocket" to the according classname. You can get it by first adding this EH to the tank: this addEventHandler ["HandleDamage",{ systemchat (_this select 4); }];

Actually an eventhandler can contain a variable from the script. I learned that from KillzoneKids blog a few days ago when I was examining the compile command. This is what you can do: _myVarInScript = 100; player addEventhandler ["Fired", format ["systemChat str %1;",_myVarInScript]]; http://killzonekid.com/arma-scripting-tutorials-a-few-tips-and-tricks/ As it seems there are some limitations though. Sometimes the variable can't be passed if it contains spaces.

_this removeAllEventHandlers "Fired"; _this addEventHandler ["Fired",{ _this spawn { _projectile = _this select 6; _lastPos = [0,0,0]; waitUntil { if (isNull _projectile) exitWith {true}; _lastPos = getPos _projectile; false }; _nearObject = nearestObject [_lastPos,getText (configfile >> "CfgAmmo" >> typeOf _projectile >> "submunitionAmmo")]; _mrkDest = createMarker [str _lastPos, _lastPos]; _mrkDest setMarkerShape "ICON"; _mrkDest setMarkerType "mil_dot"; _mrkDest setMarkerText "SPLIT"; _lastPosFinal = [0,0,0]; waitUntil { if (isNull _nearObject) exitWith {true}; _lastPosFinal = getPos _nearObject; false }; _mrkFinal = createMarker [str _lastPosFinal, _lastPosFinal]; _mrkFinal setMarkerShape "ICON"; _mrkFinal setMarkerType "mil_dot"; _mrkFinal setMarkerColor "ColorRed"; _mrkFinal setMarkerText "IMPACT"; }; }]; This script will create a marker on The position where the shell gets replaced Where the new shell impacts Might lead to some undefined behaviour when you use it on a shell that doesn't split.

_bomb = "BombCluster_01_Ammo_F" createVehicle ((getpos curatorCamera) vectorAdd [0,0,-1]); _bomb setDir getDir curatorCamera; _bomb setVelocityModelSpace [0,50,0]; // let the bomb fly a few meters This creates the whole clusterbomb. The classname you used only created the subammo type resulting in only one bomb. setting the damage to 1 seems to disable/delete the object. The bomb automaticly dispenses the smaller bombs.

[missionNamespace, "arsenalClosed", { player setVariable ["ready",true,true]; }] remoteExecCall ["BIS_fnc_addScriptedEventHandler",[0,-2] select isDedicated]; waitUntil {{_x getVariable ["ready",false]} count allPlayers >= (playersNumber west +playersNumber east +playersNumber civilian +playersNumber independent)}; systemChat "DONE"; Run this on the server. I only tested it with a hosted server and only with myself on it.

Try this on your units: getObjectTextures unitName; If it returns [] you can't retexture the object. I tested it with the civillian journalist ([], no texture changed) and the BLUFOR ammobearer (worked).

Make a switch: params ["_newUnit", "_oldUnit", "_respawn", "_respawnDelay"]; _texture = switch (side _newUnit) do { case east: {"textures\texturefilenameEAST.paa"}; case west: {"textures\texturefilenameWEST.paa"}; /* case independent:{"textures\texturefilenameIND.paa"}; case civilian:{"textures\texturefilenameCIV.paa"}; */ default {"textures\texturefilenameEAST.paa"}; }; _newUnit setObjectTextureglobal [0,_texture]; //---OR---// if (side _newUnit == west) then { _newUnit setObjectTextureglobal [0,"myTextureWEST.paa"]; } else { _newUnit setObjectTextureglobal [0,"myTextureEAST.paa"]; }; Only use one of the options. The second one is faster but the first is more flexibile. In your case there are only two options I guess, so the second one is sufficient.

I don't know what was wrong with me it seems i didn't read the question at all. Here is a script with the suggestions from above: _random_pos_in_trigger = []; _loopCount = 0; while {_random_pos_in_trigger isEqualTo [] && _loopCount < 100} do { _random_pos_in_trigger = trigger_spawn call BIS_fnc_randomPosTrigger; _random_pos_in_trigger = _random_pos_in_trigger findEmptyPosition [0, 0, "vehicleType"]; _loopCount = _loopCount +1; //Prevents infinite executions with severe hit on performance if no position can be found }; _random_pos_in_trigger should be safe to spawn vehicles on afterwards.

What about the BIS_fnc_randomPos and BIS_fnc_randomPosTrigger? (randomPos is more versatile but i guess randomPosTrigger is faster and sufficient for your purpose) EDIT: this wasn't helpful see below

Another option is to use BIS_fnc_addRespawnPosition. Or the MPEventhandler "MPRespawn" where you can return a position at the end of the script and it will place the player on said position on respawn.

Hello everyone! I wrote a script with which you can turn a dialog config into the format that the GUI editor uses. The goal was to be able to edit an already existing dialog after the GUI editor has been closed. This should make alternating dialog configs easier. Before: After: Currently known issues: Thanks to @HallyG, @HazJ, @dreadedentity! And one second later I discover that ArmA3 already has a system. With the given config path you can press Ctrl+I and insert your path.

Hello everyone, is there a way to return the base class of a display control? Here is my situation: disableSerialization; _ctrls = ""; { _ctrl = _x; _ctrls = _ctrls + format ["IDC: %1, Rsc: %2%3", ctrlIdc _ctrl, /*ctrlRsc _ctrl*/,toString [10]]; } forEach allControls (findDisplay 49); copyToClipboard _ctrls; The only problem is that I can't get the resource the control is built upon. Eg I want to return the buttons from the escape menu as "RscButtonMenu" or something similar. Is there a way to do this?

Time to reveal what I was after: I needed the base classes of the controls to convert them to a format which you can import into the GUI editor. Somtimes I forget to save the GUI as an import format which you get by pressing Ctrl+S in the GUIEditor. I have come a significant step further by being able to get the Dialog class once with _display getVariable ["BIS_fnc_initDisplay_configClass", "displayName"]; and now with my own function: Credits for the export function go to @dreadedentity Big thanks to you! I have been using this function for quite some time now. I am not at my goal yet but it shouldn't be that difficult from now on. With inheritsFrom or BIS_fnc_returnParents this should be possible. Cheers to everyone!

Well I am far beyond that. I want to do it the other way around. Say you got a control and then get what type of resource it uses: _myControl = (findDisplay IDD) displayCtrl IDC; // _rscName = some code to get the resource _rscName //"RscButton" The ctrlType looks really promising. If I do a switch type I should be able to roughly get the Rsc. But since more Rscs use the same type (eg RscVideo and RscPicture and many more) it is not very precise. Thank you very much @HazJ! PS: "Default" call BIS_fnc_exportGUIBaseClasses; Exports the classes as well without so many blank space. If you use "" instead of "Default" you get every class that exists.

this addEventHandler ["Fired", { params ["_unit","_weapon","_muzzle","_mode","_ammo","_magazine","_projectile","_gunner"]; vehicle _unit setWeaponReloadingTime [_gunner, _muzzle, 0]; vehicle _unit setAmmo [_weapon, (vehicle _unit ammo _muzzle) +1]; }]; Add this to the init line of your mortar/artillery. This gives you a nearly unlimited fire rate. You may want to change the 0 to something above 0 because otherwise the AI is able to fire instantly which may lead to some unpretty artillery barrages. Also the last line (setAmmo) isn't mandatory to make it work. This gives the vehicle an unlimited supply of ammunition therefore no need to reload or resupply.

Can you give a link? If you open up an fsm that you created with the editor it should look similar to what was written under the FSM entry on the BIKI. This is one of my FSMs opened in notepad++: What language is this actually?

The only other FSM editor I found was this one: http://www.armaholic.com/page.php?id=1184 Tbh I haven't used it but at least the description is promising. In contrast to BI's editor it has variable identifaction and command autocompletion. What doesn't look so great is the UI in my opinion. Too less space for code. But just as any other editor it may only needs some getting used to. Also it hasn't gotten any update since 2007 therefore the functionality might be broken and commands not up to date. I agree with you that the FSMEditor is not very user friendly because of the reasons you mentioned and it would be awesome if something was done about it yet I haven't seen any FSM in the missions I analysed in the past 2 years even though it is a really handy tool that is said to save performance by avoiding a thousand waitUntil loops. I only started using it recently and I certainly haven't discovered every feature yet.