@rogerx - thanks for the links!
@DarkWanderer - PM inbound (method - http://goo.gl/KVxUQ2 )
@Xerrass - yes, it's confirmed. TrackIR is being returned reliably.

Just as a Sugestion make A refresch button so if a user wants to he can Refresh but for me i cant change any Keybindings in MP and this is shi.. so if im playing with a new Profile its Hilerius ( restarting the game for like 20 times to put in all nessesery keys.

regards Xerrass
p.s.: sorry my english is not that good

@oukej: sent a response... I've successfully reproduced the effect in a test console app, it looks like it is a memory allocation issue affecting DirectInput. Details in reply PM.

Possible workarounds on player side:
1.Start with a low value of MaxMem, say 512 or 768 (can someone please test if it helps?)
2.Use Stratis to perform test flights and assign the keys

Xerrass: Although this controller refresh applet button sounds like a great idea, the applet button will still be obviously only a hack (or workaround) for users. Users will then need to go into the configure panel each time this bug occurs (or every minute or so) and click refresh while still trying to fly the simulated aircraft. This workaround/hack will likely not have a happy ending! It was a good thought though.

for me it only happens if i go do controls i have now a flytime like 400h and my stick never disconects midgame only if i go to the controls then i lost him btw

Hmm did someone know if tis happens on windows 10 also !?

@Xerrass: Yes, me! I have the same problem like you have. My controllers only disconnect when I open the controls settings.

On Windows 10 TP (actual and also in january) this didn't happen!

Problem only exists on Win 8/8.1! Win 10 no problems!

Guys, I have reproduced this issue successfully in a C++ console app. It's a DirectX memory-related issue. Basically, once you have used enough memory in your application, DirectX functions stop reporting ANY devices to the game. TrackIR is detected differently, I suppose, so it stays; but the game can't query for controllers anymore.

Here is a small executable to test (run with joystick attached; WARNING! You're downloading an executable file, do it at your own risk):
http://1drv.ms/1DQ5ptA
Source of that program:
https://gist.github.com/DarkWanderer/3ac07a213bfc8a02932d

I don't know why it is specific for Win 8, but it looks like an "endemic" DirectX problem indeed.

I suppose the only workaround would be to not query for devices when opening options - either optionally, or as a change to default behavior.

Thank you for your time and investigation!

I suppose the only workaround would be to not query for devices when opening options - either optionally, or as a change to default behavior.

We have considered this before. Any newly plugged in or changed controllers wouldn't be reflected by the game then. It is still better than when they disappear, but we'd loose some functionality. An option to switch the behavior is something to be considered.

">> I suppose the only workaround would be to not query for devices when opening options - either optionally, or as a change to default behavior."

AFAIK this is how 90% of the games i know behave, and I think this is the best solution.

Every game I know, also very old games, only detect a controller, when it is plugged in before you start the game. Every control plugged in afterwards won't be recognized by the game.

I think this would be the best solution. (my personal opinion)

i will sugests phoenix opinion asswell

@oukej: You're welcome, it's an honor to help.

you can, for example, add a command-line switch - "-noControllerChangeDetection", that'll both workaround the issue and preserve the functionality. Just an idea.

@DarkWanderer / @oukej: Do you know if it is possible for me to add this line that DarkWanderer mentioned, for myself, to test if it works ingame? If yes, in which file and line should we add this?

Or is it only possible for the devs?

ph0enX: No. The "-noControllerChangeDetection" is merrily a suggested addition to the code base.

I would suggest adding a configure option within the Configure panel for "Enable real time USB Controller Detection" with a boolean (ie. on/off) box.

Again still a hack or workaround, but seemingly more sane? On the flip, we're still wasting coding resources with this configure option, and the proper coding may only incur a slight overhead in coding resources. This is what oukej I think is stating in his brief words.

As oukej has stated, real time (USB) controller detection is a feature! It works wonderfully as I like to hide my toys so what I play with in my free time does not conflict with my profession. As such, I frequently forget a controller is detached after starting the game and real time detection helps.

Any chance we are going to see a fix for this, until yesterday I was using Win 7 and never had a problem, but since getting updated to Win 8.1 I cannot use my devices in game anymore. Honestly guys - this issue has been around since 2013 and it hasn't been fixed?

@rogerx: problem is, BI can't fix it. It's a DirectX or Windows issue. They can only workaround it, that's why I suggested the workaround.

Can someone test that exe file by the link above on win10 machine, please?

@sim | from time to time thear are things that are not that easy and if you hav read some postes this is mainly a windows 8.0/8.1 error where Windows dont give back what everybody is expecting, a list with joistycs, but only get a empty list. BIS only can find a Workaround so calm down pls we all hope that they fix this issue asap, but i think its not the only bug in arma ^^

Sim: I do not know when (if ever) this bug will be fixed. Given what you see from the time line of this bug, I would strongly suggest to stick with Windows 7 and not upgrade to Windows 8/8.1. But do not blame me if BI fixes this bug tomorrow. This is why I enjoy and use Open Source software almost all of the time, as bugs are fixed much quicker and quicker than I even can!

Guys - Windows 10 is on the horizon and will most likely share a lot of similarities with Win 8 - so BIS better get this fixed. A workaround isn't a fix - and saying "calm down" when something has been screwed for 2 years is concentrated bull.
Also, saying "change your operating system" isn't a fix. Other games do not have this issue and they use DirectX as well, so its a Arma 3 issue.

Yeah, this is getting rather frustrating. I haven't been able to play for quiite a while now, arma without vehicles is not Arma. Can we get a proper dev update on this?

@SIM/@Syn : On Windows 10 This error don't heapen, it only hapens on Windows 8/8.1 and only on Altis so just don't play Altis ^^

Turns out there's a difference in behavior when launching application under debugger, even in Release configuration (as I did when launching it locally). This resulted in the test not reproducing the issue in some cases where it should.

Updated the test utility accordingly and added some more output. Available at the same link (http://1drv.ms/1DQ5ptA). Let me know what it shows for you now.

This was suggested long time ago and is not working.

@DarkWanderer: Personally I am very happy that you also discuss with us. Someone that has the knowledge and is helping, is very nice to see.

If i remember correctly, it happens in both islands for me. I'll check again today. An OS replacement is in no way or manner an acceptable fix. It's been long enough, I think. Bohemia needs to stomp this one out.

I have this same issue and must say that when I goto get in heli/jet I realise the joystick/throttle aren't working THEN i check the controller panel to verify the game is no longer seeing my HOTAS X.

oukej, if it's so hard to fix, give us the workaround. It's the best option.

Make the game only check devices once started.

Plugging in a new device when playing is NOT something that happens often by any means.

The only downside? You need to restart the game ONCE. Instead of multiple times with the current situation. Worth it.

I agree with FrankHH

I would be fine with that solution too. Current situation very annoying

Only problem if USB devices are no longer able to be detected after the game starts, then with the current game version Track IR USB devices will no longer be detected as the Track IR USB device is for some reason not being detected while the game is initially being started.

Users must currently open the Game Configuration menu and then the Controller menu for the Track IR USB device to be detected.

See Bug #24199, "TrackIR not being initialized upon Game Execution" for further information.

The last three responses mainly suggest, "Throwing out the baby with the bath water." Why stop at throwing out the bath water, when we can just throw the remainder of the code out and just move to native Linux code which would effectively resolve this problem and many others once and for all?

(If people only knew the size of source code and expenses for developing such a simple feature, unless the code was simply copied or GPL code!)

not sure if this is possible, but one way to fix the controllers being lost, is to rescan when going to the controller section of the options menu. that way, it will scan for a controller, and it will be a temporary fix for the problem about them dissapearing.

Pesoen: The Configure Controller menu already rescans for added or removed USB devices. The problem arises due to the module or function of source code segfaulting or giving a segmentation fault. Once this happens, this section of code becomes dysfunctional or non-operating. Technically what should happen, the code should just quit running until the bug is fixed, but Windows has workarounds (to prevent wasting time & money) for such bugs.

• Begin of Snip ---

"Why won't my code segfault on Windows 7?"
http://stackoverflow.com/questions/4629551/why-wont-my-code-segfault-on-windows-7

Best Answer:

Windows has non-portable language extensions (known as "SEH") which allow you to catch page faults and segmentation violations as exceptions.

There are parts of the OS libraries (particularly inside the OS code that processes some window messages, if I remember correctly) which have a try block and will make your code continue to run even in the face of such catastrophic errors. Likely you are being called inside one of these try blocks. Sad but true.

• End of Snip ---

• Begin of Snip ---

Segmentation_fault Wikipedia:
"On Microsoft Windows, the offending process receives a STATUS_ACCESS_VIOLATION exception."

• End of Snip ---

In brief, the section of code likely quits making controller detection no longer possible. From previous speculation, caused by memory faults or memory addressing. (Shrugs, improperly referencing a pointer? And located within Windows 8/8.1 specifically? ;-)

It's not a segfault. It's that a function asked to allocate a piece of memory (malloc or VirtualAlloc or similar) cannot do so, and somewhere in the chain of calls this situation is handled incorrectly - specifically in Win8.

There was no answer so far from BI on the investigation results I have provided, don't know if that issue was abandoned or still worked on.

Speaking of code size, it's actually not so big - see the piece of code I gave a link to above. Listing DirectInput devices only takes around 20 lines.

And as for TrackIR issue, TrackIr is detected via separate mechanics, so no one forbids to keep it detected every time you open controls but detect joysticks only once on start - win-win for everyone.

If someone could launch the test utility by the link above on Win7 and/or win 10, that would help to confirm or reject my theory.

rogerx: the TrackIR not being detected at startup is happening from time to time here but is quite rare. While the joystick disappearing when entering menu is systematic.
And especially very annoying on servers where pilot slots are rare ressource.

So after >15 months, having an option to workaround this - even though not perfect - would be a good step ahead.

DarkWanderer: Nice follow-up. I speculate too TrackIR is using a separate mechanism. But you have to realize if the advanced coders (or initial authors) were laid-off, and a beginner coder gets into the code commenting some lines of code out having to deal with auto-detection, they may likely inadvertently break other features. If I'm not mistaken, TrackIR doesn't appear to have problems under Windows 8/8.1, but shared code between the two types of devices may unknowingly occur at some point. We don't have the code, so we won't know until they reedit, recompile and release the executable to us. And if somebody without past experience edits the code as such, we can almost surely bet there will be additional problems. Another possible scenario, if a command line flag is given for deactivating auto detection, it may inadvertently disable TrackIR or other device detection.

Not to get into an argument but personally, if the section of code works under Windows 7 and Windows 10, and only Windows 8/8.1 is afflicted, I would call Microsoft and ask for a refund! Obviously something was changed within Windows 8/8.1, and maybe reverted in Windows 10. (Reference DarkWanderer's Comment #0092502 "BI can't fix it. It's a DirectX or Windows issue. They can only workaround it") Upstream bugs can sometimes take forever to fix, if ever be fixed. If it is an upstream bug, you can rest assured this bug will very likely never be fixed or worked around. (ie. View almost any other program's bug history showing the cause as "upstream".) Workarounds tend to promote code bloat and incur further maintainence , etc.

I agree, the silence on this issue is deafening without further notice from the developers after apparently DarkWanderer's technical work here.

I'm lucky, I can revert to Windows 7, with never having to use Windows 8/8.1.

Concerning the number of source lines involved, we can only speculate because (again) the code is closed source. Auto detection may only require 20 lines, but error handling and other features, tends to easily bloat source code. I would more likely expect if what we speculate is true, a command line flag maybe added to workaround auto-detection. It's the most safe option in my opinion.

If a command line flag is added to work around a broken Windows 8 DirectX layer, it will likely include not just one module of the code but several.

Again, DarkWanderer needs those complaining about this bug to test his compiled code for error resolution! I'd help, but I only work with open source code. (And I only have Cygwin for compiling under Windows. If I can compile the test code under cygwin, then I'd test it. Is there another free compiler which works with your code snippet? Sounds like I'll also need the Windows 8 SDK library/includes?)

2015.05.22 04:07 UTC - Also note, they (BI) might be working on DirectX-9 support, for supporting Linux. If so, a directx9 command line switch (or version specification option) might also likely work around this issue, if the problem lies within Windows DirectX layer.

@rogerx: yes, compiling requires Windows SDK installed, DirectX SDK is part of it now. I haven't tested compilation with anything but Visual Studio 2013. I'd say it should be compilable with anything recent enough, though (C++11 features used)
You're welcome to try it - source is available at https://gist.github.com/DarkWanderer/3ac07a213bfc8a02932d I intentionally packed everything into single file, to allow those wanting to try it but not risking downloading .exe's to give it a shot.

Let me know if it works for you.

Sigh. Ran into a venerable MS bug. I have a ton of "Microsoft Visual C++ 20* x64 Redistributable" packages installed likely preventing Windows 7 SDK from installing. (Dumb packaging bug.) Not to also mention the Win7 SDK and Visual Studio Express will take a while to download tonight.

While I'm uninstalling & resolving the above, the free Visual Studio 2013 Express/Community should be able to compile the code correct? (Why can't everything just be Cygwin or Linux?)

As of today, I can reproduce this issue with 100% reliability. Meaning I can't play multiplayer anymore. :(

@tulx

Same here, it's a real shame. The dev silence is pretty uncool.

Ditto above... played Arma3 since launch for many hours (Win 7) with CH Pro Pedals, X52 Pro and TrackIR5 - no problems and good times.

Just updated to a new PC (Win 8.1) and get instant loss of all but TrackIR when in SP and MP but otherwise nothing else different on my setup except for OS - well except new PC has significantly better spec than my old one.

Earlier posts seem to indicate Win 10 may be okay... is this what we are now hoping and waiting for?

NB Steadily trying same combination of peripherals with other flight games just for heck of it... for the record 'Elite Dangerous' is fine on my box with Win 8.1 (I will test others e.g. DCS, ToH, Rise of Flight etc.) BUT sadly it's Arma I really play full time.

It is definitely Bohemia's bug.
Yes, it could be because of DirectX, Windows, Microsoft, hardware but the bug is Arma related only, there are no similar problems with other applications.
So Bohemia could have just 2 ways, fix it or fix it.
When you develop for iOS for example, they deprecate code, sdk are changing all the time, rules are changing all the time. But everybody are searching for their own solution and fix what is wrong. So blaming Microsoft is bad idea in this case.
Of Course if other game titles has this bug, than some mails to Microsoft and the next update would bring the fix, but no, it's Arma only...

On Linux, everything is backwards portable except for Python and SystemD!

Logitech RumblePad 2 \ Wn8.1 - the problem occurs, too vanishes in attempt to renominate management. Often restart of Arma3 \ Arma3 DEV does not help to find the device in access the joystick.

FYI: Looks like Windows 10 will be a free upgrade, and fixes this problem or bug. My guess, Windows 8/8.1 will be very short lived if it's not already so obvious. I plan to upgrade my Windows 8/8.1 and will await to see if the Windows 10 version is any better than Windows 7. From reviews already and past experiences, looks like I maybe sticking with Windows 7 for awhile still for stability reasons. Those whom already have bought newer hardware are likely inherently stuck with Windows 8/8.1 and like Windows 10 dilemma. Really, I'd love just to stick with Windows XP as it's a very simplistic operating system if nobody looks under the hood!

Does anyone know if this also impacts head tracking devices such as TrackIR or Freetrack?

No. This bug does not affect TrackIR, but the last game version release did introduce a bug with detection with both Windows 7 and Windows 8.1. (ie. Bug #24199, "TrackIR not being initialized upon Game Execution")

Please search this thread using "track" as a search term before posting? ;-)

Similar problem here. Joystick disappearing after entering MP game
http://feedback.arma3.com/view.php?id=24463

BadVolt: Bug #0024463 is a duplicate of Bug #0014924

Yeah, looks like it's same bug

Well for what it's worth those personal, rough test results are in... with Win 8.1 my CH Pro Pedals, X52 Pro Stick and TrackIR5 all appear to work happily with DCS, Rise of Flight, Take on Helis!!!, Elite Dangerous, MS Flight Sim X and X-Plane 10. But sadly not on Arma3 (the only game I really actually really play). Found an odd wrinkle in that A3 often -though not always- seems to accept my pedals IF I unplug my joystick before playing, but the same trick doesn't appear to work if I unplug my pedals instead.

It seems many of us are hanging on for Win 10 -which is at least imminent - though many of you have been waiting rather longer than myself. Well good luck guys, see you on the other side!

[Apologies for duplicating this earlier in the BI forums by accident]

Good luck waiting for Windows 10 to solve all of your problems.

As for me, I'm sticking with Windows XP and Windows 7, until I'm sure Windows 10 will work as expected.

Dunno. windows 10 is working very good on my Rig. Just stay in Slow Ring, and no Probs here.
The Only Thing is, that I can'T update to Build 10130. But My Rig is always reverting the Update, because of, no function :)

In early versions of the game, I could make the joystick setting at any time. He did not vanish from the game.
It worked fine in Windows 8.1 earlier.

Lex: This bug was submitted on 2013-09-25. It is possible you just never noticed this bug.

Bought a joystick yesterday. Sad to see that this problem is over a year old

Same issue here:
Mine will work for a few minutes in a MP match then the joystick disappears.

I've yet to hear anybody check-up on this method, but try starting the game with and without the ARMA 3 Launcher, to see if you're still getting a loss of detection of the joystick.

Same issue. Sometimes, not all the time, in multiplayer, singleplayer and even the editor I loose my joystick input. The device is gone from the devices tab in settings and the controls are gone. This really needs a fix!

BTW, does all reporters have only 1 joystick?

I've the same problem here... When we will have a fix ? A Day ? Maybe ?

dl3d: No pun intended, but I really doubt this bug within Windows 8/8.1 will be fixed, as the bug here is fixed (and reportedly elsewhere) within Windows 10.

This bug appears to be an upstream bug with Windows 8 and Windows 8.1 only.

Windows 10 is a free upgrade from Windows 7, Windows 8, and Windows 8.1 owners.

Although there might be a workaround, it sincerely looks as if this bug will not be worked around at all. On the flip, BI developers suggest holding-off upgrading to Windows 10 for stability reasons. (Here for the most part, I see few problems, and the only problem I've seen can be easily worked around.)

I'm waiting w10 to test. I really like playing Arma 3 and i want to fly with my controllers in Arma 3 (Thrustmaster Hotas Warthog + Saitek Pro Combat Rudder Pedals + Track IR5) but no solutions found on internet works this is too bad...

So its time to fly in DCS and wait...

Ok just update to W10 yesterday and it works now but i got a new problem.

When i play with the controller in a plane or in a helicopter the controls are really slowly. To make a roll the sensitivity is better with the keyboard.

Try updating your joystick drivers.

Saitek appears to have updated theirs, but only guessing as their file name is in an odd format, unlike past versions. Other manufacturer's may have likely also updated their hardware drivers for Windows 10. The updated drivers likely contain only very some very minor apparent fixes, with no other apparent real migration to updated libraries needed for the Windows 8 to Windows 10 migration.

(Sheesh! Wish Windows' developers would stick to a decent file naming standard! ie. Manuf-HWModel-OptDriverName-DriverVersion. Including a dated change log entry text file?)

Hi,
Windows 8.1 and I cry each time I've forgotten to bind a key on my joystick...
Logitech Extreme 3d pro (software from them useless), Usb is in power mode(but exact same issue as reported).

On Win10 problem is solved. The joystick is working as it should, you can change settings on the fly.

Just should not unplug the joystick after the joystick is plugged in, or else a CPU or IO (Input/Output) run occurs. Again, upstream bug with MS Windows 10 or Saitek's driver.

Symptoms: After joystick is unplugged, mouse input is displayed as extremely slow, and a shutdown/restart of the operating system almost always hangs.

Hardware: Saitek X52 Pro (Unknown if rudder pedals or other Saitek hardware is affected, but I suspect so as somebody elsewhere complained of a slow mouse.)

Workaround: Refrain from unplugging the joystick, after the joystick is already plugged in.

Hi, I recently switched to Win10 and I can report that with my Saitek x52 pro, Saitaik Pro flight rudder and EDtracker (poor man's trackIR) there are no more sudden disconnects and loss of input when trying to change settings in ARMA3.

Punany: That's great, however try disconnecting the Saitek X52 Pro within Windows 10 and reconnecting. Try several times and you'll notice there's now a CPU run, or a rogue kernel task creating a slow mouse issue. Safely rebooting and/or shutdown is lucky, if not impossible.

Basically the joystick(s) is/are unstable and still unusable within Windows 10.

If you can reproduce the fore mentioned bug using the Saitek X52 Pro, also please try repeatedly unplugging and reconnecting with your Saitek rudder pedals and any other joysticks to see if this affects other USB hardware.

So, it looks as if it's very unlikely there will be a fix for 8.1, upgrading at least fixes the loss of controls problem, but if you unplug your joystick/throttle it creates a new problem... Looks like I'll be upgrading to Win 10 and just never unplug my HOTAS.. I'm pretty new to Arma so I'm still going to the control options a lot to either change key bindings, add something to the HOTAS, which normally spells disaster in the air.. Controllers I use are Thrustmaster x55 HOTAS, Logitec G13 advanced gamepad, Trustmaster tx racing wheel, Fanatec CSR elite pedals, Trackir 5, and normally everyting disappears except the trackir.

Matter of fact, I'm seeing mouse movement degradation even within Windows 7 and running ARMA 3 after awhile. (Most wouldn't notice, and would consider this simply as lag.) Looks like there's something going on with mouse movement performance, where Windows 10 might makes exasturebates the issue far worse.

If somebody can get more exact logging or document more specifics, might want to open a new bug? The Windows 10 mouse bug with Saitek controllers is probably good for documenting, but I'm only using Windows 7 now and converting to other platforms hopefully soon.

It seems my joystick dissapears upon my death (amongh other things) , if that helps the devs.

For what it's worth I also changed from Win 8.1 to Win 10 a month ago and since then my joystick has worked perfectly (i.e. as before when I used Win 7).

My X52 Pro stick and CH Pro pedals are permanently plugged in so I haven't (wanted to) test the unplugging issue.

Hope this helps (or partly reassures) anyone thinking about moving to Win 10.

Re. 'Slow' responses to control input as noted above. I found this elsewhere but you could try disabling any alterative input commands (eg for keyboard) used for the same manouever e.g. my own 'rudder' pedals were very sluggish in yawing until I removed the alternative twist-stick rudder control from my stick. Might be irrelevant re. the above, but it worked for me.

Good luck all.

CrebZephon: Duh. I didn't think of unmapping my rudder axis from the joystick, to resolve the full/half range issue of more than one controller attached sharing an axis issue! Now after all of my debugging, I now have to figure out the action missing 'A' and 'D' key mapping for moving left/right after a parachute is deployed. (Seems since I do have the actions mapped within helicopter controls and the action is still not performed, I may have spotted another bug with the configuration file!)

Will be fixed on devbranch in coming days.

https://youtu.be/2bosouX_d8Y?t=20

Still happening to me in 1.54.133597.

And, words fail to describe my level of sadness when it does.

Still happening on the dev branch. Is the fix released?

This is still happening. Any chance for a fix?

https://forums.bistudio.com/topic/140837-development-branch-changelog/page-34#entry2939525

The game should no longer re-initialize the controllers when opening the controls options. Instead now there's a "Refresh" button in the controllers tab that allows you to re-init. the controllers manually.

Means the loss of controllers shouldn't be happening anymore :/
Could you please also try the RC branch?
https://dev.arma3.com/rc-branch
Steam branch access code: Arma3Update156RC

Thanks for the response. This is still occurring for me. All joysticks become unresponsive after several minutes of simulation. Then about a minute later they come back. TrackIR is not affected. I'm on the latest Steam dev branch.

For example,
In editor I create a helicopter and play the scenario. After about 5-10 minutes, stick and throttle not longer function but TrackIR still works. If I hit escape and wait about a minute, the stick and throttle become available again. The same will happen without hitting escape and waiting about a minute.

I wonder if it is related to Saitek. I will try an old Logitech controller tonight and see if it does the same thing.

May be a completely different issue. The one we were dealing with in this ticket was about loosing controllers after entering the Configure - Controls menu.

If a controller is lost mid-game, please create a new ticket for that.

My issue is not related to this one. I swapped USB hub with a different one and have not been able to reproduce the problem. No more issues with disconnects. Thanks for all the support!

From my past experience, either a faulty USB hub or under-powered USB hub. No pun intended, but the Saitek hubs long ago were faulty for some odd reason. The Saitek hubs were also non-powered hubs.

Ever since, I've only purchased powered USB hubs and those from well known manufacturers. (Which reminds me, I'm missing a powered hub around here. Shrugs.)