galzohar 31 Posted March 2, 2016 How do you get the magazine in a grenade launcher attachment? How do you get its ammo count? How do you add a non-full magazine to a unit? If there aren't commands for this, it would be very nice to have them. Share this post Link to post Share on other sites
Larrow 2822 Posted March 2, 2016 Vanilla UGLs are not attachments but secondary muzzles. Although no particular command there are enough to work it out. How do you get the magazine in a grenade launcher attachment? _secondaryMuzzleMag = if ( count getArray( configFile >> "CfgWeapons" >> primaryWeapon player >> "muzzles" ) > 1 ) then { _mags = primaryWeaponMagazine player; if ( count _mags > 1 ) then { _mags select 1 }else{ "empty" }; }; How do you get its ammo count? _secondaryMuzzleAmmoCount = if ( count getArray( configFile >> "CfgWeapons" >> primaryWeapon player >> "muzzles" ) > 1 ) then { player ammo ( getArray( configFile >> "CfgWeapons" >> primaryWeapon player >> "muzzles" ) select 1 ) }; How do you add a non-full magazine to a unit? player addMagazine [ _type, _ammoCount ]; Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 3, 2016 How do you get the magazine in a grenade launcher attachment? How do you get its ammo count? _primaryWeaponInfo = getUnitLoadout player select 0; _GLInfo = _primaryWeaponInfo select 5; if (_GLInfo isEqualTo []) exitWith {hint "No GL"}; hint format ["GL Magazine: %1\n\nGL Ammo: %2", _GLInfo select 0, _GLInfo select 1]; Share this post Link to post Share on other sites
Larrow 2822 Posted March 3, 2016 getUnitLoadoutNice, when did that get put in? I must of missed it. I see its in the current stable supportInfo although there is no mention of it on the wiki in either Arma3 or All commands page. Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 3, 2016 Nice, when did that get put in? I must of missed it. I see its in the current stable supportInfo although there is no mention of it on the wiki in either Arma3 or All commands page. That is because it is WIP and can theoretically change at any time. Once it is finalised the documentation will be added. Share this post Link to post Share on other sites
R3vo 2654 Posted March 3, 2016 getUnitLoadout Interesting, guess that's for 3den or the Arsenal..(hopefully). Is there already a command to set the loadout? Share this post Link to post Share on other sites
fn_Quiksilver 1636 Posted March 6, 2016 love the new event handlers reloaded getinman getoutman seatswitchedman keep em coming personal wish is a serverside 'EntityCreated' mission event, where entity and owner are arguments, to compliment EntityRespawned and EntityKilled 1 Share this post Link to post Share on other sites
das attorney 858 Posted March 6, 2016 Just a note about "reloaded". Attached to a man, it fires when the animation is complete (reloading finished), whereas attached to a vehicle, it trips as soon as the old mag runs dry and reloading starts. It would be nice if it fires when there are no more mags left as although the unit/vehicle is not reloading another mag, it would be a better way to determine if unit is out of ammo for their gun rather than say adding a "fired" eh and checking if there is not ammo and no more compatible mags (imo). Share this post Link to post Share on other sites
mad_cheese 593 Posted March 6, 2016 Just out of curiosity, I was wondering why the new commands getRelDir and getRelPos require an object as the first parameter, vs the old respective functions BIS_fnc_dirTo and BIS_fnc_RelPos handling both objects and positions. This is nitpicking for sure, but it would be nice if the new commands could handle positions as well, given that they are faster. :] May I say that I am extremely pleased with the progress that is being made in the commands department (and others of course). THANKS! Share this post Link to post Share on other sites
Greenfist 1863 Posted March 6, 2016 Just out of curiosity, I was wondering why the new commands getRelDir and getRelPos require an object as the first parameter, vs the old respective functions BIS_fnc_dirTo and BIS_fnc_RelPos handling both objects and positions. This is nitpicking for sure, but it would be nice if the new commands could handle positions as well, given that they are faster. :] They're not returning the same thing; the functions don't take the originating object's direction into account. Those functions are now replaced with getDir and GetPos. Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 6, 2016 Just out of curiosity, I was wondering why the new commands getRelDir and getRelPos require an object as the first parameter, vs the old respective functions BIS_fnc_dirTo and BIS_fnc_RelPos handling both objects and positions. This is nitpicking for sure, but it would be nice if the new commands could handle positions as well, given that they are faster. :] May I say that I am extremely pleased with the progress that is being made in the commands department (and others of course). THANKS! What Greenfist said. getRelDir for example is equivalent of BIS_fnc_relativeDirTo not BIS_fnc_dirTo, and it says so on the command page. Share this post Link to post Share on other sites
mad_cheese 593 Posted March 6, 2016 oops.. I did mean BIS_fnc_relativeDirTo of course but anyways I misunderstood something :ph34r: Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 6, 2016 oops.. I did mean BIS_fnc_relativeDirTo of course but anyways I misunderstood something :ph34r: BIS_tnc_relativeDirTo also requires object as param not a position, just like getRelDir, or did you mean something else when you said it should accept position like the function? Share this post Link to post Share on other sites
Sniperwolf572 758 Posted March 6, 2016 Just a note about "reloaded". Attached to a man, it fires when the animation is complete (reloading finished), whereas attached to a vehicle, it trips as soon as the old mag runs dry and reloading starts. It would be nice if it fires when there are no more mags left as although the unit/vehicle is not reloading another mag, it would be a better way to determine if unit is out of ammo for their gun rather than say adding a "fired" eh and checking if there is not ammo and no more compatible mags (imo). I wouldn't use reloaded for that, seems out of scope for reloaded. As for the begin and end reload stuff. The tense used in the name of the event handler suggests that the man implementation is correct and the vehicle implementation incorrect. As a suggestion, before this hits stable, it might be wise to split it into ReloadStart and ReloadEnd as I'm sure there are various cases where you'd use one or both. For example, ReloadStart to do fire stuff like bolting anims and ReloadEnd to manipulate the mag state post reload. Share this post Link to post Share on other sites
das attorney 858 Posted March 6, 2016 How would you suggest detecting when all ammo is used up? (aside from loop or use of fired eh). Share this post Link to post Share on other sites
Sniperwolf572 758 Posted March 6, 2016 How would you suggest detecting when all ammo is used up? (aside from loop or use of fired eh). New commands and new event handlers probably. I suppose whatever they use to track ammo low/out of ammo flags for the AI and UI. Ammo being used up needs a wide coverage, not just when fired. Ammo removal from the inventory, etc. I'm just saying that the game firing a reload EH when a unit is out of ammo in inventory due to firing a weapon would be inappropriate for what the EH is supposed and expected to do. Share this post Link to post Share on other sites
das attorney 858 Posted March 6, 2016 I get that, no worries. Currently I'm trying to think of better ways of keeping tabs on vehicle mags than loops etc. Thanks for coming back to me anyway, hopefully they'll think of something. I've just thought of a poss workaround for vehicle mags using reloaded eh. It isn't perfect but it might pan out ok so I'll do some tests and see. Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 7, 2016 and the vehicle implementation incorrect. How is that? If vehicle has an artificial delay not allowing user to fire for certain amount of time after reload, this has nothing to do with the magazine being reloaded already. Delaying EH firing while magazine is already reloaded would probably not be very helpful. Share this post Link to post Share on other sites
Grumpy Old Man 3546 Posted March 7, 2016 A neat addition for Eventhandlers would be to pass the EH ID to the code as additional parameter for easier EH removal for one time only eventhandlers. Cheers 6 Share this post Link to post Share on other sites
Sniperwolf572 758 Posted March 7, 2016 How is that? If vehicle has an artificial delay not allowing user to fire for certain amount of time after reload, this has nothing to do with the magazine being reloaded already. Delaying EH firing while magazine is already reloaded would probably not be very helpful. I see. I understand that the reload mechanic isn't the same between man and vehicle internally. However, in game, both reloads are presented as following phases: 1. You hit reload 2. You are unable to fire for a certain time while the action is performed 3. Reload is complete and you can fire Sometimes you want to do things as the reload is starting, other times you want to do it as it has ended. How the engine deals with it internally at times is not helpful when you need to do things visually. For example, you might want to eject a shell casing after the reload has been completed. Currently, you'd have to read reload length for the mag and manually delay whatever you want to do. However, for the soldiers, you might want to things before. And so on. Still, if we're at the awesome point where the reload EH is finally being implemented, there are various reasons (some listed above) to have predictable EH's and split into pre and post variants. Additionally, the term "reloaded" in it's tense, suggests that it's going to happen after the action has completed, but that's just semantics. As I said earlier, if it's possible to implement a pre and post reload EH's as "ReloadStart" and "ReloadEnd" and to keep the behavior consistent between vehicles, it would be awesome. If not, it might be worthwhile to separate them into something like "ReloadVehicleStart", "ReloadVehicleEnd". "ReloadManStart" and "ReloadManEnd". I'm pretty sure implementing pre and post reloading EH's as such would not cost anything meaningful, but we would gain flexibility and less need to deal with other case. Share this post Link to post Share on other sites
fn_Quiksilver 1636 Posted March 7, 2016 A neat addition for Eventhandlers would be to pass the EH ID to the code as additional parameter for easier EH removal for one time only eventhandlers. Cheers great idea, an EH counterpart for _thisScript private var. 1 Share this post Link to post Share on other sites
Foxyy 16 Posted March 10, 2016 A neat addition for Eventhandlers would be to pass the EH ID to the code as additional parameter for easier EH removal for one time only eventhandlers. Cheers Also having the source client id passed to public variable event handlers would be great. Share this post Link to post Share on other sites
gossamersolid 155 Posted March 11, 2016 I remember hearing something about non thread blocking extension calls some time ago. Are those still planned or was that just a cruel joke. While we're on it, async loadFile would be nice too. Share this post Link to post Share on other sites
bumgie 49 Posted March 15, 2016 What is this? The PreloadFinished Event Handler was not working in the multiplayer environment Share this post Link to post Share on other sites
killzone_kid 1331 Posted March 15, 2016 What is this? new missionEventHandler "PreloadFinished" Share this post Link to post Share on other sites