j0nes

May try https://community.bistudio.com/wiki/BIS_fnc_addStackedEventHandler tends to handle things better on DS

It wouldnt have too much effect on performance at first, but after several hours it would probably start to hang. My question is why have them rearm? Most times, with a mission like what youre talking about, the units are despawned and spawned back in based on some criteria, when spawned back in they would have their original loadout with all of their ammo restored. If theyre in an engagement and using ammo, theyre probably getting shot back and wont be around long enough to run dry. There might be a few occasions, but I can't recall a time when ive heard an AI dry fire.

The following code is untested, but iirc theres no way to toggle 1st / 3rd person availability except for the difficulty settings. That being said you should be able to fake it by forcing the camera into first person every frame. Its not *that* CPU intensive, but its still a loop so use with caution. ["forceViewEH", "onEachFrame", { //force to first person camera if the player is on foot, inside the trigger, and not aiming down sights _inTrigger = ["myTrigger",player] call BIS_fnc_inTrigger; if((vehicle player) == player && _inTrigger && camerView != 'GUNNER') then { (vehicle player) switchCamera "Internal" }; }] call BIS_fnc_addStackedEventHandler; This will run constantly throughout the mission. There should be a way to make it more efficient by only having it fire from the trigger itself, but I cant remember the code. Hopefully this will be good enough to get the ball rolling for you! Also check on the DS behavior of "addStackedEventHandler", it may need to be removed and re-added each time a player is killed / respawns.

Beautiful work! definitely looking forward to seeing this develop. Had the opportunity to glimpse the V280 when they were doing trials a couple years back. I hope it holds up better than the osprey. only gripe I have are the rotor proxies dont seem to pop in when the props are at speed, looks kinda chunky, but still one of my favorite things to fly.

still working on a solution. but the reason youre encountering problems with "screentoworld" is the horizon. if theres no terrain to project the coordinates on it doesnt return proper values

sounds like a cool concept, best of luck! dont add the menu to the scroll wheel if you dont have to. this seems something much more suited to using the inventory screen. this is all extremely untested, just spitballing.. but in theory https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#InventoryOpened use inventory Opened EH. player opens vanilla inventory when inventory is open find the inventory display and controls get mouse right click if mouse right clicks on an applicable weapon, create a small drop down menu over the mouse click position player then selects "Modify Weapon" from the drop down tab your custom modification UI is overlayed over the vanilla inventory screen options for the selected weapon pop up player modifies weapon player closes your custom modification UI and the vanilla inventory screen is revealed underneath player closes vanilla inventory

if memory serves the captured enemy units already do this. if youre wanting to transfer it over to civilians, I would start there, because the animating of them doesnt interfere with ACE or any other function.

to make sure im understanding this correctly you want to place something on the players mouse position, but projected, for example, 2 meters in front of the players face? floating in mid air?

Type: None Activation: Any Player Activation Condition: Present Condition: this On Activation: yourZombieModuleName setPos (thisTrigger call BIS_fnc_randomPosTrigger); untested. let me know if it works! this should put the module at a randomly selected location within the boundaries of your trigger. welcome to A3 scripting! and remember. good code is 90% other peoples code

Thank you everyone for the overwhelming support this early in the project, and we hope to continue inspiring the same support as we more forward! From the vehicle department Im pleased to be able to release a small WIP of an upcoming asset. This is a capture of the completed mid-poly model. Not optimized for in-game use, but with enough detailing to split into the low-poly and high-poly models needed to bring you the same high fidelity assets that you've now no doubt come to expect! While work on both the high and low poly iterations have progressed substantially, they aren't quite ready for debut. The military designation for this vehicle is yet to be determined, so for now it will remain nameless. However, we are planning on having several variants, each with unique offerings to gameplay and lore. More details on these will be released as their corresponding modules are completed, but with recent improvements to multiple aspects of Arma 3, it should allow groups and individuals of multiple play-styles to make the most of this family of vehicles.

L2A4 and several variants to be disclosed at a later date :)

@Rossmore its been so long since someone asked about vehicles, im honored to answer this. Though its changed a couple of times, the current versions are set as CV9030s on the MkII chassis. Weve taken some cues from the norwegian cv9030s, and ours will be designated as CV9030AST to meet our specifications. Aside from the standard variant, we are also planning one with a 12.7mm RWS mounted on the main turret.

this might sound stupid, but just thought id check. when you load in game, have you checked in the config viewer to make sure that the config of the superhornet actually reflects the 500,500,500 values youve put into it, and that for some reason its not still using the default values?

from the Test_Heli_01 sample model in the BIS tools this will do some of the simulation work for you, however, a good portion of the handling of any vehicle is also done through the weight distribution in the geometry of the model itself.