naizarak

https://community.bistudio.com/wiki/allowDamage make them invulnerable during the drop

i don't think the bmp2 ever had an fcs

make a game logic and use attachTo

your script runs only once at the start, so allunits would only include the original AI spawned in the editor. you'd have to run your script again each time new ai were added also you should use a switch block to check unit type instead of iterating through allunits a dozen times which will kill performance a more practical way of creating a gear script is to filter units by a user specificed parameter(such as a string label), rather than object type for example gear.sqf: if (!local (_this select 0)) exitWith {}; private "_currentUnit"; private "_type"; _currentUnit = (_this select 0); _type = (_this select 1); removeAllWeapons _currentUnit; removeAllItems _currentUnit; removeAllAssignedItems _currentUnit; removeUniform _currentUnit; removeVest _currentUnit; removeBackpack _currentUnit; removeHeadgear _currentUnit; removeGoggles _currentUnit; switch (_type) do { case "sl" : { _currentUnit forceAddUniform _uniform; for "_i" from 1 to 2 do {_currentUnit addItemToUniform "30Rnd_556x45_Stanag";}; _currentUnit addItemToUniform "16Rnd_9x21_Mag"; _currentUnit addVest "V_TacVest_blk_POLICE"; for "_i" from 1 to 4 do {_currentUnit addItemToVest "30Rnd_556x45_Stanag";}; for "_i" from 1 to 2 do {_currentUnit addItemToVest "30Rnd_556x45_Stanag_Tracer_Red";}; for "_i" from 1 to 2 do {_currentUnit addItemToVest "rhs_mag_m67";}; for "_i" from 1 to 2 do {_currentUnit addItemToVest "rhs_mag_mk84";}; for "_i" from 1 to 1 do {_currentUnit addItemToVest "SmokeShell";}; for "_i" from 1 to 1 do {_currentUnit addItemToVest "SmokeShellGreen";}; _currentUnit addHeadgear "rhsusf_opscore_01_tan"; _currentUnit addGoggles "G_Bandanna_oli"; comment "Add weapons"; _currentUnit addWeapon "arifle_TRG20_F"; _currentUnit addPrimaryWeaponItem "acc_pointer_IR"; _currentUnit addPrimaryWeaponItem "optic_MRCO"; _currentUnit addWeapon "tb_p_g17_G"; _currentUnit addHandgunItem "tb_acc_m6x_LLM"; _currentUnit addWeapon "Binocular"; for "_i" from 1 to 2 do {_currentUnit addItem "cse_bandageElastic";}; for "_i" from 1 to 2 do {_currentUnit addItem "cse_bandage_basic";}; for "_i" from 1 to 2 do {_currentUnit addItem "cse_packing_bandage";}; _currentUnit addItem "cse_tourniquet"; _currentUnit addItem "cse_morphine"; _currentUnit addItem "cse_personal_aid_kit"; _currentUnit addItem "cse_keycuffs"; _currentUnit addItem "cse_earplugs"; comment "Add items"; _currentUnit linkItem "ItemMap"; _currentUnit linkItem "ItemCompass"; _currentUnit linkItem "ItemWatch"; _currentUnit linkItem "rhsusf_ANPVS_15"; _currentUnit addItem "ACRE_PRC343"; _currentUnit addItem "ACRE_PRC148"; }; case "rifle" : { _currentUnit forceAddUniform _uniform; for "_i" from 1 to 2 do {_currentUnit addItemToUniform "30Rnd_556x45_Stanag";}; _currentUnit addItemToUniform "16Rnd_9x21_Mag"; _currentUnit addVest "V_TacVest_blk_POLICE"; for "_i" from 1 to 4 do {_currentUnit addItemToVest "30Rnd_556x45_Stanag";}; for "_i" from 1 to 2 do {_currentUnit addItemToVest "30Rnd_556x45_Stanag_Tracer_Red";}; _currentUnit addItemToVest "SmokeShell"; for "_i" from 1 to 2 do {_currentUnit addItemToVest "rhs_mag_m67";}; for "_i" from 1 to 2 do {_currentUnit addItemToVest "rhs_mag_mk84";}; _currentUnit addItemToVest "SmokeShellGreen"; _currentUnit addHeadgear "rhsusf_opscore_02_tan"; comment "Add weapons"; _currentUnit addWeapon "arifle_TRG20_F"; _currentUnit addPrimaryWeaponItem "acc_pointer_IR"; _currentUnit addPrimaryWeaponItem "optic_MRCO"; _currentUnit addWeapon "tb_p_g17_G"; _currentUnit addHandgunItem "tb_acc_m6x_LLM"; for "_i" from 1 to 2 do {_currentUnit addItem "cse_bandageElastic";}; for "_i" from 1 to 2 do {_currentUnit addItem "cse_bandage_basic";}; for "_i" from 1 to 2 do {_currentUnit addItem "cse_packing_bandage";}; _currentUnit addItem "cse_tourniquet"; _currentUnit addItem "cse_morphine"; _currentUnit addItem "cse_personal_aid_kit"; _currentUnit addItem "cse_keycuffs"; _currentUnit addItem "cse_earplugs"; comment "Add items"; _currentUnit linkItem "ItemMap"; _currentUnit linkItem "ItemCompass"; _currentUnit linkItem "ItemWatch"; _currentUnit linkItem "rhsusf_ANPVS_15"; _currentUnit addItem "ACRE_PRC343"; }; //etc etc }; this would be run by [this, "rifle"] execVM "gear.sqf"; where first parameter is the unit to modify and the 2nd is the gear label you can run this on each unit(player or AI) after its creation for better performance the script should be compiled into a function note: i don't know how ALIVE spawns its AI, so this may require tweaking to make it compatible with its implementation

currentWeapon player; currentMagazine player;

the controls are too twitchy, same problem with the bmp's

what's wrong with setcaptive?

you can run "currentWeapon player" to get that

are there plans to integrate it by default?

it's a beta update, there's a lot of WIP assets

the new stuff is very impressive, congrats on the release

the init code should work, there's something else in your mission conflicting with it. upload your mission for us

Is there any way to disable auto lock-on in missiles such as the titan or dagr? I've noticed that most(if not all), also have a secondary SACLOS guidance mode which requires constant target tracking by the shooter. This is much more realistic and engaging for the player than the alternative of pressing a single magic button, and I'd like to make it the only guidance option.

add this to the init if (isServer) then { clearMagazineCargoGlobal this; clearWeaponCargoGlobal this; clearItemCargoGlobal this; clearBackpackCargoGlobal this; this addWeaponCargoGlobal ["tf47_m3maaws", 1]; };

the eventhandler accepts global arguments, so even though players aren't local to the server, you can still use them for your event handlers. whenever a player shoots their gun, the handler will only execute on the server however, because that's where the eventHandler was added. another example is multiplayer event handlers. they have both global arguments and effects. what this means is that your handler will be executed on all machines in the game, regardless of where it was actually added. going further, if you add the same MPeventhandler from multiple machines, then the handler will be executed that many times. a common mistake is adding an MPEventHandler in the init.sqf, which causes it to be added on every machine, and so in a game with X players, the handler code will be executed X times on each player's machine https://community.bistudio.com/wiki/Arma_3:_Event_Handlers your publicVariable implementation seems sound, there shouldn't be any problems. publicVariable itself is a reliable command, there's no bug with its implementation. i was just referring to a hypothetical situation where clients try to access public variables that haven't been broadcast yet, in which case you'd have to use waitUntil or a public variable event handler to launch code

The "addEventHandler" command has global arguments and local effect. You can add an event handler to any unit, but the actual handler will only execute on the machine where the eventhandler was added. In the first code block, all the eventhandlers would be added from the server's perspective, and so the eventhandler would only run on the server as well. if you wanted each client to have the event handler as well, you'd need to remove the "isServer" restriction yes you can access remote units, such as other players, if the commands you run support global parameters. "distance" is global so that would work to calculate, for example, the distance from a remote player to an object, executed on the server likewise AI can be manipulated by clients, again, if the commands support global parameters. an alternative is to use bis_fnc_mp publicvariables are accessed through their names. if i run x = 5; publicVariable "x"; on the server, then clients would then have an "x" variable equating to 5 locally, that they could access like any other variable. if an "x" variable already existed, then it would be overwritten with the broadcast value if your client scripts rely on a publicvariable, then execution timing is important. you have to make sure the publicvarible is broadcast before clients try to access it. if you're running your "publicVariable" command in a scheduled envrionment(via spawn or execVM), then code execution order isn't guaranteed, and you should use "waitUntil {!isNil "var"}" in your client code, which halts execution until the variable exists. or you can use a publicvariableeventhandler on clients which will automatically launch code when it detects that a public variable has changed

there's no way a virtualized computer will run better than the host. the performance figures are probably being compared to those same games running natively in linux

probably referring to the new dayz engine that supposed to work on consoles also what i got from that interview was a lot of "no's" and excuses

run your setovercast, setrain, setfog etc commands every X seconds or so in a loop to override the random weather changes

so how frequently can we expect beta stuff to be pushed to the main stable branch on pws?

use forceweatherchange instead of simulsync

are you sure it's a cse issue? you seem to be the only one reporting it

most of the medical functions i've tested return incompatible data types that require conversion to string and back again to make them work

is your signature an indication of things to come? ;)

because vehicles have have significantly longer engagement ranges than infantry. tank combat can happen from well outside 2000m in this game, so vehicle crews need to uncache then whereas most infantry engagements happen within 500 meters. currently you either set everything to uncache at vehicle distance(bad for performance), or remove vehicle groups from caching(still bad for performance but not as much)