Edit: The concept its similar to an other older request i just found:

http://feedback.arma3.com/view.php?id=17012

I think mine its a bit more complete, but are related nevertheless

The issue its a bit deeper than keys, sometimes changing loaded addon or even addon load order can result on the server soft-lock the same way.

But its really hard to probide a repo for it because the combinations that cause it seems to be totally random

If you read my last sentence, what i said its that i don't see that as "optional", its a really important part, as important as been able to add new inputactions.
Btw that loop using waitUntil its unreliable when client its under heavy load ^^(you will lose the keypress if isn't hold enought time), perframehandler its a bit more reliable(but still can fail if there is a dramatic client fps drop), but even more performance intensive. I already made a lot of testing trying to find out the best way to handle user input.

Totally agree with this one, it's a feature that got requested a lot of times and got anwsered on A2 with the "1-20 user actions" keys, that are pretty limited.

One thing Sniperwolf572 forgot to mention it's that, right now, to detect the key presses its really troublesome, since you need to attach your own keyhandlers to the main display. That method makes detecting special actions like joystick and mouse buttons really tricky, you need to do it by using hacky methods.

Been able to define new inputActions would be good, but will still need to check the keypress with by constant pooling(using inputAction), that would be either totally unrealiable(if donne with a simple loop) or could impact performance (more intensive loop like using perFrameHandler)

The custom keys should be able to be defined by config, as they are now, but you should be able to attach them to function that its called when the key it's presed and other when its released(and when i say key i mean the one that the user selected for that action, that could be a joystick button, axis or a mouse button), just like a keyup and keydown events.

I won't call that part optional since it would be a real improvement on how you define actions and how you can can handle the user input in your addons

Edit: Ops, srry for the edit spam :P

I totally agree( btw thats a copy paste from my A2 ticket? https://dev-heaven.net/issues/39421 XD) .

Also there are other non stackable commands, most of them starting by "onXXX" that would be really useful, like onEachFrame, onMapSingleClick, onTeamSwitch , ...

The implementation of this would greatly improve addon and script compatibility, since right now you can't use any of those commands if you want to asure that your script would be compatible with others.

I agree, maybe make it an option so we can for example for lower difficulty show yourself in map, regular just that aproximate position with the circle and on veteran/elite dont show anything.

But just leaving it as a difficulty option would please everyone the default settings doesn't matter too much.

I see it a feature and really have a purpose:
1- The only way to move only the weapon without moving the rest of your body its doing this or enabling the game option for it that its above "head bob"(don't remember the name exactly), so if it was removed there would be no way to do it

2- This movement its really usefull on some situations, people that aren't used at arma may not even notice, but looking with freelook not has the advantage that you only move your head, so you are less noticeable if you are hidden. If you aim around normally you will rotate your full body and will stand out more.

So if you can use this feature to only move the weapon, so you are also less noticeable to your enemies( applies both to AI, totally confirmed, and players, depends on where you are obviously).

May appear dumb, but could be usefull. And i dont really see a downside of having it ... i mean if you don't like just dont use freelook while on sights lol, not that hard.

I think that some of you are totally missing the point of the ticket, this is not about how many attachments you need to have. Its more about the config solutions we need, and yes you may need to explain some rail system but don't go to deep into that.

The problem its that the current implementation heavily limits a lot( if not totally) the compatibility between comunity made attachments. Let it a bit more clear for those what doesn't even know what config means:

Right now if someone makes attachment A ( lets say super sniper cool scope) and makes it compatible with a weapon ( lets say a M16). If another modder does a new attachment for that weapon, that 2 mods would conflict and one would overide the other( only 1 of the 2 attachment would work)... Basically its a huge limiting factor for addon compatibility.

Another note that i would say that seems like no one mentioned. The way the attachments are saved on the weapon its ridiculous and hacky. I mean it just replaces the weapon for a different one... so you will need tons of classnames for each weapon with each attachment... its just insane( well better than A2 where you would need also tons of models just of each weapon with each attachment combination).

So why just not make them real objects, accessible and with contents( like a backpack) and treat the attachment as contents. Obviously its not the same as a backpack i am just saying the way of storing the data.

The problem right now its that the weapons are still always handled as static classnames(well the classname change when depending on the attachments... LOL).

They should just implement the same thing that is planed for DayZ standalone and make them real items in the world. That would allow access them directly ( allow play animations, store variables on them,....), and the attachmets would be just a property.

next request, katanas and be able to tomahawks 100m away and kill someone...

I don't see this priority at all, this is not a ninja game, nor a CoD. You can't run into someone throught a field and stab him...

Ok you may argue that you can sneak behind someone on a CQB environment, but that happens in really really rare situations.

Said that, implement some kind of melee mechanics on the game engine could be cool so if a moder wants to create melee weapons he can without needing to do stupid things(EG: reloading a hatchet on Dayz mod ¬¬), but never as a priority

@papy.rabbit.08 yes it's the same, but i don't know if you noticed:
1- The image quality on the screen computer on that car( and same for mirrors) its just awfull even at high PiP quality.
2- It has a major performance impact( try interior vs exterior camera while on that seat)

So use the same would just suck, quality and performance wise. That's why i said it would need a major work to optimize it perfectly.

Its a nice idea, but i think that implement it properly( a lot of games just hax it ... outside of the optics view shouldn't be also zoomed in) would need a lot of work and would need a lot of optimization and the realism/awesomeness we win doesn't deserver that much work

Its one of a long list of things that i would say that are great ideas, but the time/work that will need to make them ingame properly, doesn't compensate what we win.

Thats why i am not voting up neither down this one.

+1 and also FFS allow to run with binos in your hands!, it have been the same way since OPF

aim while looking at the compass? (insert genius meme)

No offense but its much important to be able to easilly see the bearing than anything else. You should only look briefly at the compass, and as in real life, while you are looking at your compass ... why would you need to aim your weapon? lulz.

Maybe the perfect solution an scale slider/selector just as you can choose the GUI size. But as i said i would never see a problem having the compass to big, its never big enough! :)

I would say that yes, but always as an option so you can disable it. If you have 3rd person disabled, sometimes it's hard to know your exact stance, and that would help (i really like most realistic settings but on real life you will now your exact stance...)