Yeah, this 100% ...and then some -- i just hopped on with some rare motivation to update my old UI after seeing all the pretty stuff on the wiki, and honestly I was surprised that the GUI Editor still has gone so neglected, for so long...2012 is the last editor update according to the help screen! Moricky! We need you, please.

Although automatic BB conversion would be nice, perhaps the best solution is to simply not use the Steam description in-game:

if you've subscribed via Steam, chances are you've had the opportunity to read the full Steam description - thus in-game may only need a brief rehash, or the otherway around; either way, it would give the mission designer the final choice in representation.

In addition to that point, urls i put in Steam are not likely to be viewable in arma anyway (or not desired), no sense in cluttering up the in-game desc. with non-functioning links.

Thanks @muf, looking forward to your solution!

i'm not disagreeing that the game should handle the error correctly, but simply responding to your title that 'values beyond 2047 are broken' - only the error handling is broken; i could have phrased my sentence better

if the server only supports 2047 internally, it only supports 2047 (regardless of x64 linux), and to put a larger value is intentionally trying to break it, in other words, 'undefined behavior' - it is not to be expected in a real operating scenario.

that said, the wiki needs to be updated to clarify which options and defaults apply to only the Game, and Server; for example i believe the game actually supports 3072 (unless that never made it out of dev-branch - http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2721184&highlight=maxmem#post2721184 )

edit:
+1, title is technically correct :D

servers are still limited to 2047

while i think arma should better report its errors, it otherwise would not be expected that a server be run with incorrect settings

tried running wireshark on your local network to see what the congestion is? (ie, from steam server listing responses, or arma server)

without units in vehicle? there is a note on the wiki page for it (returns false if no gunner)

i have an edit of that page in progress, i'll wait a bit before publishing incase theres an issue

odd, if i set up a ah-9 or 99 w/o ammo, both seats return false; with ammo returns true with a player seated. (stable build)

sorry, i must have skipped over that

wiki history shows that description dating back to 2006, so its possible that hasn't been the function since a couple arma's ago. if you or someone else could test the functionality in A2, and/or OFP, i'll update the page

+1

you can view chat history by pressing page-up/down after hitting the '/' chat key (arma 2 + 3)

Sweet timing - you all rock! Thanks for testing it out KK...i wasn't even aware of setHitPointDamage command yet :)

Dev Changelog Today:
"Fixed: M-900 had a wrong set of hit points"

This ticket can be marked FIXED.

it all depends on how the vehicle is setup, some won't require it, others will.

lucky(ish) for you in the vehicle configs there is a property to turn on the engine when the turret moves, so if it really bugs you, and BIS doesn't add an option, you could always make an addon that turns it off.

for general reference, its the "startEngine" property in the Turret class of the vehicle.

In addition to light points created with createVehicle, i am experiencing this with a pistol-slot weapon using class Flashlight{} when benched on a flying heli (single player) so this is more than just an attachTo issue.

light point (including visible 'bulb' (scale[]) stutter upto 2m behind its expected point, if facing forward, will cause unit with flashlight & parts of helicopter to be rear-illuminated.

there is a pilot unit (C_man_pilot_F) but it seems to have been overlooked for the config ('crew' value i believe, oddly enough 'typicalCargo' lists a B_Helipilot for the M900). i'm sure this will be fixed soon enough. +1

no noticed difference - 125% forces a vertical scrollbar in-addition to horiz., but 150% only forces horiz. scrollbar (might not be new)

solutions imho:
-removing duplicate button icons (each has 2) would save significant width;
-allowing window resizing; or,
-set window width based on the right edge of controls (buttons and panels -are- sized & scaled correctly)

Well done - everything fits that matters (only issue is rightmost icons under-lap the folder buttons, but interferes with nothing); Calling it closed, thank you Tom & Co.

Edit: odd, i remember us previously having the ability to mark our own tickets as fixed/closed; get a access denied...

Confirmed, thats great!

All thats left now is the main Arma 3 Tools window, and this ticket will be closed

if you were not already aware, usually this would be added on vehicles with commands such as

this animate ["addDoors",1]; this animate ["addBenches",0];

and they have opening animations, but at the moment, doors on the littlebird seem broken (they used to work, so i'd expect this to be fixed eventually - the animations are still listed in the configs)

i noticed this also, especially having switched from the dev branch back to stable just prior to the update. I as-well had audio device settings cranked up, and reducing them as suggested helped eliminate the stutter (but also noting that the same audio settings were applied prior to the update with no freeze ups)

i'm downvoting just because you've bumped your own ticket some 30+ times.

you're not the only one who would like to get their tickets resolved, and you just help bury tickets that are for real issues.

i get this error too. acknowledged mean it is a bug or its not?

you tried with a laser?

if this is solved please close your ticket

you can close the ticket yourself, there is a button where you have the option

those approximate to the actual kg weights of the equivalent aircrafts: A-164=A-10 - 20000kg CAS, buzzard=L-159 - 8000kg

nm, duplicate: http://feedback.arma3.com/view.php?id=17801

the control tool-tip suggests the command is supposed to tilt forward. You are looking for "Increase Thrust" controls, yes?

so please change your ticket category to one of the campaign issues ("Campaign Episode x: "), and update your description to reflect what this issue is for and where...vague descriptions help nobody

can you provide a repro mission? is this a mission you've made or downloaded?

i experience the fire mode change when disembarking a vehicle, but not when opening or closing the map...

confirmed in dev branch - i wonder when that broke...hasn't been like that forever.

maybe if not noticed in another week ill drop a mention in the development thread (dont wanna help choke that thread up), should be bumped high-priority

can you include your RPT file? you can find the latest in C:/Users/{user}/AppData/Local/Arma3

you forget how much time is wasted sorting through crap tickets like this one, and differentiating what are real bugs and what is someone who posted a ticket without understanding scripting or doing research first. or checking for duplicates.

-due diligence is required on the part of bug submitters, otherwise you're just wasting their time-

that and they've repeatedly said they were not going to be doing huge changes or fixes until all the campaign components were released as to not potentially screw up the missions before the bugs can all be properly tested.

in a sandbox this size tiny, seemingly unrelated changes can potentially break functionality and flow without raising an immediate error.

the community could assist by going through all their old tickets thoroughly re-test to confirm they are infact still bugs. there are a shit-ton of irrelevant tickets clogging up this site.
--many bugs have been squashed without being indicated or marked as so!!--

Have you checked or tried adjusting the Playback Format in Advanced tab of windows sound? There were others that had a similar stutter/choppy in MP (including me) for multiple sound sources - that ended up being a result of the format being set too high, thus putting huge demand on the cpu

thats about how far, if not farther i'd stay away from a burning tank with flames that big - that screen shot shows flames 15-18 feet tall. thats a big fire in real life.

-maybe i could suggest a heat-wave effect for the players screen when they get in that radius, but prior to damage

your missing the point that waypoints are placed on initialization - and thus placement radius. cycle should loop the waypoints placed, not reinitialize them.

but eitherway, agree or not, it is the current functionality, described clearly in the wiki, and to change it could potentially break other missions and backward compatibility. so i'd recommend requesting a new feature, or use one of the many easy ways to accomplish what you are trying to do

a good example would be a patrol mission that should have random waypoints on mission start, but when you are patrolling the waypoint loop, it should be the same waypoints to walk around and guard...thats how personally i expect cycle to work. these are my waypoints. cycle them.

So it was broken and now has recently become fixed : )

It is called 'placement radius' not 'move-to radius' (although something to that effect would be handy; but considering the ease with which that can be scripted, i doubt they'll build it into the game anytime soon)

If you'd like to change this ticket title to requesting that sort of random mechanic be included i will support it, otherwise i'd say this ticket should be closed as its not a bug.

I agree it may seem that should be the result, but if you check the wiki it has always been that way:

https://community.bistudio.com/wiki/Mission_Editor:_Waypoints#Placement_Radius

"Placement Radius
This option works in a similar way to a objects placement radius. The waypoint will be placed at random within a circle of the given radius, in meters. Note that the waypoint's position is set during mission initialization, so a group that uses a Cycle loop to go to a waypoint with a placement radius more than once will always move to the same location. If the waypoint is attached to an object, the waypoint HUD marker will appear at a random location for players, until they know of the object it is attached to, when the HUD marker will reposition itself onto the object."

i see what you're saying, but is this not default windows/gpu behavior, to lose application priority and resources when alt-tabbing out of a game? And are spawn loops not mostly independent of frame rate, and more on cpu availability?

fps seems more of a sister-symptom than directly related - so if windows cuts down cpu priority, theres no guarantee you'll be able to execute all your spawns in any given, expected, nor reasonable time-frame - unless arma were guaranteed high or realtime(nope) cpu priority while minimised (risk being a runaway script could cripple or crash a system) - as far as i understand the situation...

i certainly respect your skills in this area tho, so if there is a fundamental concept i'm misunderstanding here, im certainly open

--

aside from the specific issue discussed, i'd like to suggest perhaps in general such high-load, time dependent scripts need to consider proper resource management -especially ensuring- they do not attempt to overload a system that cannot realistically handle the load at any given moment in time, including when minimised (there are a few simple methods to accomplish this (ex: loop scaling based on instantaneous fps.)) just my personal opinion in responsible script design.

[2289.72,5828.9]

lets make their job easier...

I played with this for a bit - the texture seems to not be preloaded by the game so the first time or two you fire the missile the flame textures just show up as white, but after that none of the shots show the white anymore.

load a mission editor, fire a missile, observe the white 'flame'. fire again, (second time was 50/50 in my testing) once flame texture is loaded in memory, you have to exit the game and restart to show the white again.

i would change your ticket, this doesn't fall under the category "design-sandbox" - it belongs in the "Campaign Episode 2 - Adapt" category

-edit, i misunderstood the issue

you have a high ping between the local computers, but not with anyone else right? and when you're playing its not actually playing like its 10,000 ping, but something far less?

...and, if your server is accessible from the world, when you connected to it from home, did you use the public address, or your inside private address?

if thats the case it could be an issue that your client is requesting gamespy ping the private IP address, thus the ping rate is enormous because gamespy can't talk to that address and every ping drops.

(also some routers by default drop incoming icmp messages (sometimes a separate option from the firewall) check that too)

setting it to TRUE ensures its activation regardless

and oddly enough, sideChat and groupChat are not working on my end either, and im running the Dev branch (1.11.114607)

running the commands directly without a trigger through the debug console produced no output either (error or otherwise)

did all the players die and then you got that message, or did just some but not all players die and still randomly got that message?

you haven't really shared alot of information about whats running script-wise. can you upload the mission its happening on?

--

i see they fixed a respawn scripting error related to BASE, do you have your markers set up correctly?
"Fixed: Scripting error when no respawn position was found"

when i tested last night boundingboxreal registered the player in prone, if i recall it was the z-value in the second array, i'll check when i get a minute later tonight

---

ok, i see, you're right, it doesn't change for crouched. i guess thats a ticket too :D

---

so the civilian head height is correct, but the soldier's is oddly low - i uploaded a screen shot with height comparisons input into spheres next to the unit's head

that appears to show the current height correctly, if you stand a civilian next to a soldier, i get your same numbers, but notice the solder is hunched forward and lower, thus the height difference ( ~ 6 inches? )

although on second thought, 5'7 does seem a tad tall for an average civilian :)

just to mention, i notice boundingboxreal returns consistent values for both civ and soldier despite posture - would be a good reference for an indicator

i'll tell you now you're gonna need to share more information, nobody will beable to help you just based on a vague 'it dont work'

Upload a copy of your RPT file - you can find this here: (typically)

C:\Users\ {yourname} \AppData\Local\Arma 3\

The file you're looking for will have a format like this:

arma3_2014-01-24_01-41-18.rpt

upload the latest one (the game generates a new one everytime it runs). that contains invaluable information for the developers.

as for customer service, i've never had an issue before with them, but do keep inmind they just did $1 mil in humble bundle sales, so im sure they are swamped.

well thats sure interesting! -
i've experienced this for quite a while (it only would happen when first loading the game and clicking multiplayer; while the game was still open MP screen would load quickly after the first long wait. Closing and reopening the game would have the wait again).

Astaroth, all i did today, was confirm twice that it still had the long wait...then tried switching mp servers to steam...once. since then i cannot for the life of me reproduce the long wait despite the game still defaults to gamespy when loading. So just switching to steam once and back to game spy seems to have fixed this entirely for me. including after sys reboot. No matter which server now, no issue. Awesome, but confusing :) it was a guarantee wait before i tried that today.

(dev branch)

i noticed your squad xml is in ANSI format...doesn't it need to be UTF to support kanji?

edit: yeah, the characters in the remark line show up on my computer as :3, which is 0x333a - 'square pensu' yes? perhaps squad generator isnt saving the characters properly, or isn't rendering them properly.

i stand corrected! and i appreciate the math DarkWanderer, that does make it clearer

i first want to point out that a3 does infact implement this, if you pay close attention the heading of the plane changes slowly with a bank (and no other controller input, using the a-143) it does seem slow, i wont lie

but, if i recall, doesn't centripetal force affect fighter jets significantly less? (again assuming no control input) and since the game doesnt have any slow movers yet, its hard to guestimate what the implemented effect is. 3rd party mods can't be expected to have properly implemented phyx yet.

your wiki article does also point out that in order to complete a bank turn, it requires the pilot to increase lift, otherwise you're just side slipping and losing altitude - this matches whats currently in the game.

as far as fighter jets go, i'm just remembering that as something i had learned once, but i can't find any clear info at the moment that doesn't require math i can't do :)

(my vote undecided until more i see more info, and other airplanes)

---

someone who plays this game has flown jets. anyone with that experience want to chime in?

no bug here, move along

:D
i'd rather this not be 'fixed'

there should be some measure implemented for situations like Goomer said ^

it doesn't happen often, but i've had it happen a few times. condition should be something like: (sudo code)

if(( !touchingground && height < 10 ) && ( velocity == 0 ) && (!engineOn))

i figure < 10 meters, 30 feet as a height you'd realistically survive falling if you had to jump from a stranded heli.

As it stands, i'm thumbing this down for the eject-in-flight.

still present...grumble...

The issue is the use of:

Position ([0,0,0] NearestObject 457070)

remove that line from the radio trigger and a vast majority of the freeze is gone.
the way nearestObject is setup, when you use ^ that ^ format, the search range becomes unlimited, and its starting that huge search from the middle of the ocean

only the stutter left is from loading in a new object that wasn't originally included in the mission on load (any large or complex object does this, not just AI units)

confirmed, same results using onMouseButtonDown. /up

1. Altis was supposed to be that location, didn't they switch it to the general mediterranean area after the incident? . The coordinates in the map config are incorrect, they currently point here:

https://www.google.com/maps/preview#!q=-35.152%2C16.661&data=!1m4!1m3!1d17104275!2d10.992055!3d-30.614957!4m14!2m13!1m12!3m8!1m3!1d57860!2d-71.4211805!3d41.8169925!3m2!1i1920!2i934!4f13.1!4m2!3d-35.152!4d16.661

i believe all thats needed is to change -35 to +35, drops Altis dead center of the mediterranean sea

2. first mention was saying that the mapArea and latitude and longitude in the configs are incorrect. the second mention was a reminder that the function bis_fnc_posUTMtoDeg returns an inverse set of coordinates than standard (lat/lon): [longitude,latitude]

i'd also like to add that if mapArea is in utm, not lat/lon, it seems to still be incorrect for the mapZone. I'm no cartographer, anyone have experience?

No, i'm not sure, i just know its whats in the configs, and it doesnt match where its suggested it should be.

the -35 is claimed to be the latitude, so north/south

can you point to where it says that? its confusing as to why they would invert longitude

@Gekon, a situation to consider -

I have a mission that originally allowed saves (not for any reason, i just hadnt disabled it), I later added enableSaving false, about the same time i first experienced the issue described above (month or two ago) and now reading all the above, it sounds like the old save games might be the issue...

BUT, since i've disabled saving now, could the game now trying to automatically attempt to load either an old version of the mission or the save? and because its disabled i have no restart button, so i can't force a new mission, does hitting 'play' on a no-save game that used to be a saveable game ensure you're getting a clean mission?

when i had cleared my steam mission cache the problem would go away, and the mission would run fine, until the next time i updated the mission in the editor (even if no changes are made). other players of my mission experienced the same thing.

thanks!

@SaOk, i checked on my computer, its getting the latest pbo without asking for admin rights

i'll be the first to admit i still try bool==bool with odd regularity, despite knowing better :) but it doesn't bother me that i can't use ==, less typing anyways!

As it stands currently it kinda makes sense: a bool is the answer to its own expression. theres no point in comparing true == true, when true is already the result.

But I'll /upvote for behavior predictability

even a simple tag-strip would be nice...the BIS_fnc's already exist to do so ;)

more like you are the duplicate ;) but i'm glad it got assigned either way, certainly took long enough (woot!)

i agree, some errors shouldn't be suppressible.

this had fixed itself once and seems to have broken again. there was a period recently where this wasn't an issue anymore.

confirmed today in dev branch - tested with a rifle squad, when im group leader none will release their parachutes once on the ground (they will float to my MoveTo commands tho), and only release their parachutes if i murder a couple, then they drop them immediately to kill me.

if i place my self as a subordinate, the rest of the group dies instantly upon parachute deployment.

this simulation does seem quite finicky

---

oh, and please do try to remember you're competing against 6000 other tickets - they do infact care.

oh yea. please?

i'll further with a future-request that the 'rope' texture be selectable (hiddenTexture? not my realm...). possible examples - hemp rope, wirerope, knotted bedsheets (prison break?), fishing line :)

I decided to keep this bug private as i don't know, and didn't want to test or make public the extent of what is potentially possible between those characters

well, i have an opinion, and a suggestion:

1. this ticket should be closed, on the grounds that original subject applies to the specific rain effect that is no longer included in the game.

2. it would be nice if rain could get, 'heavier' - i found that setting fog to 0.08 or somewhat above that gives a good simulation of visibility during heavy rains without appearing like fog.

considering that the drops are currently rendered with decent depth (i can see it), i really don't want arma attempting to render millions of rain drops any further away. i think you'll find just adding the fog does alot. BIS should include that when the rain value gets above 0.75 or something.

while there are a few other simple ways of checking this, it would be handy if isKindOf and TypeOf worked on most configs

well, by definition, 'last man standing' IS just a deathmatch with no respawn...

"Seriously?"

well (1), its a beta, so please don't share your snide surprise. its seriously known that there are bugs.

...especially since you didn't want to reproduce, or provide any other info.....and its not clear from your low-res screenshots if there is a possibility a unit spread out to the side and can actually see you...

(2) for the record the rock in question is at position [2584.6,5785.46,0.00125885]

(3) in my testing bullets did pass through this rock's edges, seemingly at the rock vertices (also noted that only tracer rounds were the ones that actually provided hits on the player).

use this code in the player init to tell which part of the body is being hit and with what (laying where you were provided mostly right-side hits):

this addEventHandler ["hitpart",{hintsilent format ["%1",_this]}]; this allowDamage false;

(4) as of 8/15 in the dev branch they reported still working on rock collisions, so if you're in stable branch.....

yes ^^^ documentation really is the key. sqf has its quirks, like -all- languages. The difference being its not common, and you can't lookup 10000 ways to accomplish a task by googling. thus all learning stops with the wall we all know well, "fuck this, its too hard. {x} is a stupid language. whos idea was this??".

not knowing a command exists (or wiki wont give it up), or have documentation with incorrect parameters or returns is extremely frustrating, beyond just learning to interact with the uniqueness of arma (a challenge alone). It forces bad implementation and practices, and gives the appearance that sqf is broken and bad, when in reality it just requires a mixture of self-education, practice and art.

(Thats not to say there isn't a TON of info in the wiki, its just more like a api reference than a place to learn; and quite fragmented)

i'll pass on lua, please.

this was brought up in the forums recently as still broken.

I was able to observe that the characters lips will tweak-out -very- briefly at the end of the sound generated with say or say3d with a lip file (same sound/lip works fine with kbtell)

-using wavtolip included with a3

to clarify his ticket:

A & D are assigned to 'cyclic left','cyclic right' by default, BUT if you try to use A or D in another key assignment, the warning text in red says 'bank left', 'bank right' instead of cyclic.

i would imagine the 'bank...' text comes from airplane controls which aren't included yet...although clearing the cyclic assignments clears the warning.

i agree with the first solution and the 3rd - disable those channels if you have no radio; document it.

@ozdeadmeat - works for me, but im in the dev build

[@landmines "In my opinion, all balancing should be done by the mission editor, if one side has better tanks you simply give them less tanks."]

^^^my opinion too.

tactical limitations (firepower in this case) should always be a consideration, and not necessarily a hindrance against a larger, better equipped opposition.

unbalanced? fight smarter not harder

@izaiak, definitely needs to aim higher because you cant see any light from the pilot seat in first person, but i dont think it should be as much as OP is requesting, heres a good reference photo for a transport class personally i think would work well:

http://media.defenceindustrydaily.com/images/AIR_CH-47F_FOB_Bastion_Afghanistan_Night_Landing_USDoD_lg.jpg

it is a landing light, not a flying light to be clear

i've noticed this in the Dev build too, seemed extra-crawley, even when no enemies were detected (way over a hill top, but that information wasn't available, nor any triggered on it). had to force them repeatedly to stand-up, wouldn't follow orders to copy my stance either.

there are times i wish the AI units would just follow their leader and run flatout into combat, 1 or 2 units alternately providing cover fire if required. instead often they all want to stop, go prone and engage

tested this a few ways, not vehicle specific.

even if you spawn a unit 20m or 0m, and dive underwater, it won't go back to being surfaced and breathing air until you hit land. tested with .75.108236

"..... auto rotation IS hovering in ArmA"

• what does that mean? because by definition, no.

" and you cant raise collective and turn off the engines because when you turn the engine off the collective wont work anymore"
"collective won't work if there is no air and increasing collective would automatically start engine on EVERY BIS game"

• If you raise the collective and the engine turns back on, then its not dead and you shouldn't be attempting an autorotation - there is no reason to be shutting down an engine mid-flight in arma.

• ...what situation does the collective not have air?

http://forums.bistudio.com/showthread.php?154567-VTS-Simple-gesture-commo-rose

was released during alpha, unclear if its updated to work with the beta, either way, it exists and works well (communications are passed to AI too as i understand), and could be easy to add this kind of action

i'm voting this ticket down because its for slapping a vehicle as an indication to drive; i agree the other gesture/nonverbal should be implemented, just not this. few reasons, including:

-everytime a vehicle door slams shut a n00b driver will speed-off :)
-most of the time you can't clearly see if a vehicle is full from the outside only
-not likely to be used often enough to justify its own default key-combo, still barely easier than typing "/roll out"
-being nonverbal doesnt matter in this scenario, because the vehicle is loud-as-f*** anyway (on second thought tho, it'd be easier to hear a bang instead of a yell...)
-its -extremely- easy to script this on a per-mission, or per-vehicle basis

(scripting: addaction to vehicle, upon execution could play the hitting-the-vehicle sound, could optionally send a message on the vehicle chat channel too incase someone didn't hear the sound cause they were blathering)

tested in 1.11.114607, apparently fixed - closed.

first off, definitely change your title so its not wasting our, developers, and mods time.

it IS an interesting idea...i think on arma's scale it would be more appropriate to simulate it like most everything else:

ships viewed from >3 miles have their object rendered lower than horizon line, client side only, still based on a flat plane.

BUT, pointing out previous math, this position-lowered rendering wouldn't be significant until much further (i'm in no mood for math, somebody wanna figure out how far away a 60' tall destroyer would have to be to appear 1/2 below the horizon when viewed from a 6' person?

personally, i would love to see spherical maps, But in Arma 4: when they can spend the time to build that _properly_ from the ground up (no pun) and when computers are far enough along to calculate and render everything that comes with such detail and scale (think of large singleplayer AI currently, now give them each their own real gravity and countries to play in, all happening whether or not you see them, not much is capable of running all that while maintaining quality game play (its just hanging on now!))

all ^that^ said, this could probably be scripted in an addon :D

"The trigger doesn't re-check the detecting unit it, it assumes that condition hasn't changed."

thats not true, in timeout mode it constantly checks the condition is true. i double checked earlier (check my last post), if you do the trigger like i say, and have the timeout >1:30, the trigger won't fire, because Detected-by eventually returns back to false. (in the case of a single unit, it seems to be about 1:30)

its not redundant because the logic is correct every time for both cases, you just haven't furthered refined what you are checking for - what KK said isn't a workaround, its just the missing logic of what you are trying to accomplish.

i found that Detected By returns FALSE after about 1 minute 30 seconds (i'm sure thats altered by who they were able to tell before death) - set up a trigger with the condition: 'hintsilent str(this); this', get a unit's attention, kill them, and time how long it takes to turn false again. i would imagine the logic of DETECTEDBY lingers for that time to ensure triggers in missions that only check every 30 seconds for example will not skip by and miss their cue

its not a bug because just prior to killing the independent, he has detected you activating the trigger - you are now known to independent side, so condition remains true through the timeout

https://community.bistudio.com/wiki/trigger

I run the dev build (0.73) and this seems to be fixed (didn't get to test in 0.72), was able to unmap Next Weapon, and map Y instead successfully, and combinations in between. i've experienced this in the past tho,

shot-in-the-dark: you could try opening your name.Arma3Profile and see if 'keyNextWeapon[]={33};' is still there after you've unmapped it in game. 33 is the number for 'F'...change it to 21 for 'Y' and try that.

you can accomplish this via scripting, but at minimum units should use silencers if equipped and set to stealth...

+1

but personally i'm not interested unless its proper standard support for side-by-side full frame 720p60 or 1080i60. Hopes for 1.4b 1080p120 are slim (or finding a card one could afford that would run arma at _any_ of those rates!)