Oh, I had it so that every AI issue gets assigned to me ;)

However this one is known, thanks for reporting it anyway! More info about this issue can be found in this thread prior to this post http://forums.bistudio.com/showthread.php?159710-AI-Discussion-(dev-branch)&p=2679062&viewfull=1#post2679062

We are sorry about the inconvenience thru the prolonged period (incl. weekend). The fix has been prepared since Wednesday, but due to national holiday it will be published in the Development branch only on Monday.

The issue is not present on the current Stable Branch, I suggest switching to it for the meantime (It is more or less than same, minus the AI waypoints issue)

I haven seen anything about it in the dev changelog yet.

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2826104&viewfull=1#post2826104

I'm running on 1.34.128075 and i'm not in the dev branch.

The next stable patch that will include this fix should be deployed before Xmas.

Works for me, in the dev branch, of course my FPS drops but not to 0.

Yes, the particles can eat a lot of performance and we're investigating whether we can improve that as well. The stuttering and freezes were sound-related and they should no longer happen.

Do you still experience the issue? Do you run Development Branch of the Arma 3?
Could you please send me the revision number of the build? ("LCtrl+/" in the game to copy i to clipboard)

Should now be fixed on the dev. branch. Thank you for helping us make the game better!

Thank you for the report!

Without knowing the circumstances it's hard to tell why the AI reacts that way. Once a player in the command of an AI dies, the AI becomes fully autonomous and will start engaging targets - if it knows about any - and completing assigned objectives on its own.

Basic behavior can also be heavily altered by the mission design. (way the AI gets created, what WP it initially gets, assigned to the player, what's done in extension if player in the command dies, how they are re-assigned to the player after respawn)

Would you be able, please, to provide more detail, ideally a simple repro mission with an incorrect AI behavior?

Thank you!

Did this happen to you just once? Were you issuing some orders to the AI when it was climbing down the ladder? Could it possible been shot during the climb anim.?

I've tried several ladders and situations (behaviors, enemies, being shot at) with AI subordinates and wasn't able to repro it so far. Any further info would be helpful!

Thank you and thanks for the report!

Hey and thanks for the report!

(my issue was happening during the showcase)

From the pic it looks like a Commanding Showcase. The AI is probably focused on the enemy boat.

Once the AI sees an enemy threat, it ignores the watch command and aims at that threat (an actual AI unit needs to have a clear visual (shared report is usually not enough) on the target to ignore the watch command and try to aim or shoot unless on hold fire).

Could you please confirm, that this could apply to observed situation? Let us also know what you think. Thanks!

Hey, thanks for the feedback.

You probably meant the ambient occlusion (HDAO in Arma3)?

Could you please add <member id="DEV1" nick="DEV1"></member> entry to the broken XML on your server?

Some of the issues are mentioned in repro missions in http://feedback.arma3.com/view.php?id=18324. The issues should be improved a bit in the next Dev Branch update. Otherwise, please, give us feedback about any specific spots, where the AI reliably crashes in http://feedback.arma3.com/view.php?id=18324

Thanks for the feedback!

I'm using the Xonar with DDLive @ home myself and have no issues with it. Arma gets the speaker count from the Windows. (Which can cause issues if the surround device reports as 2-channel one under the Windows)

in XAC set:

• Audio Channels set to 6 or 8
• Checked SPDIF w/ Dolby Digital Live

And you should be fine.

(like http://cdn.overclock.net/d/d7/350x700px-LL-d77d9a74_asusaudiocenter.png )

Also ref.

http://xboxforums.create.msdn.com/forums/p/22533/675219.aspx

http://answers.microsoft.com/en-us/windows/forum/windows_7-gaming/has-xaudio2-been-fixed-for-dolby-digital-yet/304c4dc9-ea55-48f4-b08b-9946700763fe

And you've guessed it ;)

Perhaps ARMA 3 is looking for sound configuration in windows settings

E.g. with Xonar the DDLive singal going into the SPDIF is encoded "only after" - from the signal present in channels in Windows ("Speakers" remaining the default audio output). Realtek takes that as a part of SPDIF/dig.out functionality, but in fact for Windows the SPDIF remains a 2ch audio.

We're looking into the issue. Thank you for the detailed info!

Thanks a lot for the reliable repro mission. (In the end it seems the bug is valid for more vehicles than just Marshall, but neither all armored nor wheeled armor only.)

Oh, almost forgot. This should be already fixed in the dev. branch.
Thanks again for the report!

Could you please create and attach a repro mission? Or add more details (type of vehicle, enemy units, subordinates, weather, time, environment).

I wasn't able to reproduce it and the AI were always happy to engage the enemy units.

Thank you!

Hey, thanks for your feedback.

This should already be possible - when you fly as a pilot, you can designate a target for your gunner (or AG weaponry) centering on it (center of screen/crosshair) with your view and using the [T] key. (Uses the simplistic targeting, currently without any HMD indicator over the selected target)

This should be fixed in the next dev. branch update.

• skills set in the mission.sqm (default or adjusted by the slider) should now be correctly broadcasted
• skill getters should now get the correct values also remotely
• client can set skill only to a local AI unit
• server can set skill to any unit
• in both cases only the Difficulty/AI Level values set on the server are used to process the skill into skillFinal

If you have any further questions please direct them into http://forums.bistudio.com/showthread.php?159710-AI-Discussion-(dev-branch)

Thank you for improving the game with us!

There were also some changes related to current desync issues:

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2757314&viewfull=1#post2757314

In data:

Fixed: Enormous network traffic caused by Simulation Manager module

(Are you by any chance utilizing our simulation manager module?)

In engine:

Removed network message spam when a unit is in Sync state
Multiple ObjectSetVariable commands are grouped into one big ObjectSetVariablesCollection which significantly decreases the amount of network messages

This could also help. Please, let us know, whether this bugger is finally gone or still plaguing the game.

Oh, I am sorry for I probably forgot to click the "Add Note" button a week ago.

And JIP was exactly what I wanted to ask you about.

Because this "could" solve the issues (however, if that happens just for a limited time it can be due to a server overload / FPS). Let us know, please.

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2737850&viewfull=1#post2737850

[*]Fixed: Problems with create message ordering for JIP

Alright, the race is still on then.

"Vehicles flying all over the place is still actual, doesn't look it was improved a bit, still happen fairly often."

Does it happen to all vehicles or just characters (ev. characters in cargo?)
I remember experiencing such issues with data desync and disparity, but that should not rly happen in the retail builds.

Could you please check the situation on current Dev build?

The isolated issues have been fixed, but it may not cover all the situations.

Repro reliable have we now, hmmm. On it we are now, yes ;)

There should be some improvement regarding the road AI paths on Altis in the next Development update (fyi there's none today, possibly tomorrow). It won't fix all the issues, but at least some of the most deadly curves on Altis should no longer be so deadly.

Please let us know about any further issues you encounter. There could even issues introduced when the AI vehicles are passing each other in opposite directions. (note it is an improvement attempt, not 100% fix)

Thanks!

It may possibly happen shortly after the AI's initialization (making it more evident in Zeus, where you place units dynamically and use them right after their placement). However, they should behave the same in a long run.

The AI occasionally does make it thru even if when encircled by obstacles. Afaik it is more of an edge case (when the AI is far, not under focus, with time speeded up etc.) and currently I can't tell if we're going to do something about it in the near future. (We have some repro's, but would probably need one where it is reliably way too obvious and disturbing)

Buildings are a little bit different issue - AI tends to go thru walls when exiting a building. We've been on this issue ever since and we're really sorry and it makes us sad pandas that it's still in the game :/ I'll keep you informed if there's a progress.

I believe this has been significantly improved by introducing the aiming error and suppression.

Thank you for the feedback.

The performance impact of PiP is not dependent that much on the amount of PiP screens, but mainly on the amount of PiP sources. Unless really necessary there's usually only one source for PiP in vehicles positioned in such way, that it can equally fit (and equally does not fit) all the PiP screens.

For performance reasons we'd lean towards keeping it so.

Oh, I see, you need to be running the development branch to see the fix. It will get to the default stable branch only with the next patch. The fix was introduced too close prior to the last one (1.16) to make it into it and moreover it ain't perfect yet and there are still some minor issues with it. (ailerons, effect on AI control...)

I am sorry about marking it as fixed for that patch, my fault and my apologies.

Was fixed by our engine lords and the fix should already be on the Dev branch.

"Rudder/flaps/ailerons/elevators can now only be controlled when engine is ON. They can be controlled even when the airplane is on land and does not move"

Strange, could you please check the revision of your game [Ctrl]+[/] ?
Should be
Type: Public
Branch: Development
Version: 1.17.116549

---

Also issue with necessity of having the engine on got fixed as well.
Expect the fix to appear on Dev Branch soon-ish.

The vision aids have been disabled in all presets except Recruit (upcoming Dev Branch update)

See http://feedback.arma3.com/view.php?id=14905#c98233

Thanks for the repros

http://www.reddit.com/r/arma/comments/31z67j/bis_is_on_the_right_track_with_ai_suppression_but/cq6yv7f

Thanks for the report!
Please try to find a repro mission. It would definitely help us!

Reg. the vegetation and grass cover:
http://www.reddit.com/r/arma/comments/2one47/ai_shooting_throigh_grass_tress_bushes/

they will indeed shoot some rounds through bushes hoping they will hit you

I can confirm that. AI keeps shooting at the target (max. about 6 seconds) even after the loss of LOS, especially if the target disappeared behind a soft cover.

Hey, thank you for the feedback.

Afaict (and it's bitter to admit it) the issue has been around since Operation Arrowhead and sadly it may not be up for an easy fix.

For the meantime I'd suggest avoiding use MIDDLE stance on unarmed AI wherever possible. We are sorry for the inconvenience.

This has been fixed as a part of https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-3#entry2831466

Thank you for helping us improve the game.

;)

I have to agree with 81057 and we are avoiding any partial tweaks to our current system which has been deemed insufficient. On the other hand, fact is, as for now an overhaul isn't in the roadmap :/

Closing this ticket. Please follow http://feedback.arma3.com/view.php?id=10323

Should be fixed, thanks for the report!

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2695731&viewfull=1#post2695731

Thank you for the report!

int.ref.: 4392

I unable to reproduce it anymore.

Forgot to close. Thanks a lot for the feedback on this!

http://forums.bistudio.com/showthread.php?176441-Flashlight-vs-no-flashlight-results-will-shock-you

Please, could you create a repro-mission (with as limited amount of AI as possible, ideally just one)?

Pls try with AI with and without FL and also try to eliminate the influence of

1. sound (AI hearing you)
2. skylining
3. ambient light

I've tried several scenarios, using both AI with and w/o flashlight and the advantage of FL didn't appear so big to me. It seems quite ok to me: http://youtu.be/3dkFAvxlRaM

Thanks a lot!

No problem. Thank you for the report.

I will close it here. The AI has to be a bit indeterministic which makes it usually hard to isolate what's wrong. If you encounter any situation where this applies, please, feel free to reopen the issue.

Confirmed appearance, however I am unable to reliably reproduce it. Will investigate, you can track the progress in the linked thread (closing this as dupl.)

Thank you for the report!

Does it happen instantaneously (loosing the joystick input) or does it just disappear from the Controls configuration?

I have almost the same setup here, but afaict it has never happened to me.

Otherwise I would generally recommend

• use direct motherboard sockets if possible (3rd party hubs can occasionally be troublesome)
• disallow the computer to turn off the USB device in order to save power in system settings

Hey and thanks for the report! ;)

The nametags should no longer be displayed with open action menu or commanding menu.

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

Regardless the settings they are always displayed with lock-on icon. Please, for now, consider this as an IFF abstraction.

Hey, thank you for the report.

See https://community.bistudio.com/wiki/doMove for more info.

Have you tried using doStop after the unit reaches the destination? That should do the trick.

After the briefing in the guerrilla base you (and your subordinates) are given a default/recommended load-out for the following mission.

If you already have a weapon suitable for the upcoming mission (decided by your leads ;) stored in the boxes it will be given to you. If you don't, you may receive a new one.

Similarly the subordinates you'll start the following mission with - they get their weapons from your ammo-boxes.

You can always change your own load-out using the ammo-boxes prior to going to the Assembly point.

(!) You can adjust your own load-out & also the load-out of your subordinates in the Team Inventory in the Map Briefing in the beginning of the actual mission (after it's been loaded).
You will find it in TEAM tab, under each character's details ([Inventory])

You can only adjust the load-out of yourself and your subordinates.

Load-out you have on the guerrilla camp prior to each briefing is not taken directly to any of the main missions, but you'll take what you currently have with you if you leave the camp for some lone-wolf Scouting.

What you bring back from the Scouting, or what you or your subordinates bring from any of the missions, will be stored in the ammo-boxes (or briefing Team Inventory) even if you throw it in the camp on the ground (the guerrillas care for each other's equipment ;)

-----

There are last few remaining bugs (fixed in the 1st patch) when an unit outside of your team will get his hands on your weapons and items you have stored ;)

-----

Please note, that uniforms, helmets, vests, backpacks and items (GPS, map, NVGs...) are not (currently) stored in Kerry's own possession.

You have to be driving the vehicle at the end of the side-mission to have it's cargo stored. Can you please confirm you were driving the vehicle, when the side-mission ended?

We are sorry, but uniforms, helmets, vests, backpacks and items (GPS, map, NVGs...) are not (currently) stored in Kerry's own possession.

Kerry should always find a vehicle in the vicinity of guerrillas' camp, but if he brings back any, the other guerrillas will use it for other purposes.

But any weapon, weapon attachment or magazine Kerry brings back in his pockets, backpack or vehicle to the camp is stored and will be retained for his own or his squad mates use only.

One exception currently not working is a backpack inside a vehicle - to be fixed.

Developers are acting theire is no problem........

Not true.

Pls avoid off topic discussions.

For the record

I can assure you that driving AI issue is like a thorn in the backside of Bohemia

Is still valid. Please bear with us.

(to fix the link after forums update)

https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-4#entry2882974

Improved: Tank drivers reversing
(Disclaimer - may not be perfectly fluid at all times)

It's "acknowledged".

I created new ticket, beacuse this one is just like ignored.

Please don't do that. It creates an unnecessary additional workload and doesn't help solving the issue in any way.

Yeah, i created new ticked, and its closed automaticly

It's never closed automatically, it's done either by a dev or a moderator. Please read: http://feedback.arma3.com/how-to-user.html

"Before you report feedback, please use search function in the Feedback Tracker (FT). Should you not find a similar report in the FT database, please report it. If you do find it in database, you can use voting to support it."

Thank you for your understanding.

Hey, I'm sorry for I've forgotten to acknowledge this bug.
Sadly we are aware of this issue ever since we've introduced the tracked vehicles.
It came with a different simulation of vehicles that was introduced in Arma 3.

I have to admit that we still struggle to draw this close to an adequate satisfaction and we apologize for the inconvenience :/

Will keep you informed

Let me know if this is sufficient or you have any further questions. (about the mission AI management techniques please consult the forums, I won't be able to provide more detailed info about mission design here)

Otherwise, if it's sufficient, I'll close this issue. Thanks for the feedback & inquiry!

Couple of important (some obvious, but jic) notes regarding spawning of the AI:

AI receives a part of each frame's time - less FPS less time for any AI action.

AI takes some time to initialize and create all its "webs" - spawning AI rapidly should be avoided. Quick consequent spawning adds up to the initialization queue. (In the repro mission it can take several minutes before all the units create full awareness)

There is no fixed maximum of the AI units (and yes, excessive amounts cause serious issues) nor officially recommended (everyone has a different PC, some use the dedicated AI client and also PCs get better over time).

1. Mission designer should utilize any means possible to maintain reasonable frame-rate (several parts of the engine do not work ideally under low FPS conditions)
   1. By e.g. removing dead or unused units (and respawning them later), disabling various unnecessary AI properties, using only what matters, etc...

We could say to stick max. to around 100 active AI units (others disabled,...), but that is a very rough estimate and shouldn't be regarded as anything near any official recommendation ;)

Has actually been done :)
https://www.bistudio.com/blog/arma-3-roadmap-201415

We'd still like to reserve a right to be silent about anything until we're pretty sure we can deliver it with some acceptable quality. Thank you for your understanding

That should be fixed by https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-4#entry2904371

The repros seem to work fine (with that weapon switching only when AI needs to use the weapon).

Thanks!

Thanks for the feedback and an update.

The issue does not seem to be present in the first repro mission, however it appears in the second. Once the units are about to engage in a combat they switch to their primaries correctly.

I am not sure whether they should always try to check what primary weapon they currently have and switch to it if possible. (Unit has its prim. removed and is left wit a pistol only for a split second so it switches to it) As long as the AI doesn't have to think about what weapon to use, it stays with what it currently has. But it may introduce a tactical disadvantage when the AI starts switching once engaged.

Is this still happening, pls?

Fixed in https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-5#entry2968995

Thanks a lot for helping us improve the game!

Just a note:

"Get out" waypoint --> synchronized with "transport unload" waypoint of the heli.

It's better not to synchronize these waypoint because this way you are duplicating the orders and the AI can get stuck waiting on the other one (e.g. Get Out) that may never get completed (cargo got already out by the first WP)

Have you tried disabling fleeing by using allowFleeing command? https://community.bistudio.com/wiki/allowFleeing

It should help. If not, please, let me know.

Thanks for the feedback. This was solved some time ago and the inventory should be available to anyone.

There was a fix related to this back in alpha. Glad to hear it helped here too, thank you for the confirmation.

And it should be now finally resolved. https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-4#entry2910911

Thank you!

Is this still valid?

This difficulty option is incorrectly named. By disabling it you don't disable the missile's ability to lock, but you disable the artificial helpers that are configured for specific weapons (e.g. MGs on vehicles)

Titan was intended to work in two ways - SACLOS and Fire&Forget.

This has been fixed during the early summer this year. Everything now should work as you'd expect.

Thank you for helping us improve the game!

Thank you for the report!

Has been fixed some time ago. The LGB are able to hit lased targets quite reliably once the lock is achieved. Locking is possible on all difficulties.

I'm sorry but we won't be implementing JSBSim middleware into Arma 3. (not feasible)

Forgot to close this one. Was fixed some time ago.

Fixed quite a long time ago. Thanks a lot!

Thank you, but we'll need more specific data to try to reproduce the error on our side. Could you please list exactly what settings you have (or provide Arma3.cfg & *.Arma3Profile from Documents/Arma 3 folder) and provide DxDiag with your HW specifications?

Thank you!

Hey Sgt Andrew!

Thank you for the report!

Can you reproduce this issue or did it only happen once?

Do you have any additional info that could help us find and reproduce this issue - e.g. in-game video settings, global graphic card preferences (especially any overriding the in-game settings), dxdiag, Rpt&Mdmp.

Thank you!

No problem, happy to help. Anyway, you've made a good point.

This should be handled now more intuitive.

Hey Andy,

thx for your feedback.

Is your progress in campaign still blocked by this issue?

Your progress is saved into C:\Users\UserName\Documents\Arma 3\Saved or C:\Users\UserName\Documents\Arma 3 - Other Profiles\Saved. Each in-game profile has it's own progress saved. Could the disappearance of previous saves be caused by using another profile, accidentally cleaning the previous one or not having the "write" permission?

Could you please provide steps you took as detailed as possible? (e.g. clicked "campaigns", opened the tree structure of "The East Wind", doubleclicked it/clicked "Revert/Continue/Replay"...)

"I finished the first mission the game put me back to the main menu."
This is intended behavior when a single mission from campaign is replayed, but should not happen when playing the campaign structure ("continue" or ev. "revert"). Could you have used the "Replay"?

Thank you!

Extended armor (damage reduction for player and the members of his group) will be limited to Recruit in the upcoming dev branch update. Other presets have the option disabled and not changeable.

Also you can't even zoom in when you are looking side to side.

Please try switching the TrueView off in your TIR settings and see if it helps.

Thanks for the feedback. We are aware of missing or incomplete 6DOF functionality and we're sorry for the inconvenience. Will see if we can do anything about it and will keep you informed!

Afaict this has got fixed by the target and ammo selection improvements over past months.

Thank you you for your help here!

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.

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

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.

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

I am sorry but I don't have any update about this.
In http://feedback.arma3.com/view.php?id=14924#c87859 I mentioned that Windows 8 return nothing when the game asks for available controllers.

Every time you open the control settings the game does this check with Windows. A solution could be to perform the check only at the start of the game. On the other hand that would mean that the game could not reflect changes in controllers that happen mid-game.

So far the only recommendation is not to open control settings while you are playing.

I am really sorry to disappoint you, but the next stable patch won't contain a fix to this issue :/

What concretely misses you to fix this bug?

Uhh, I am sorry that I've forgotten to change the status.

You've provided us will all the feedback we needed and we're grateful for that!
Our programmers are trying to find a solution / workaround to why Win8 return nothing when asked about controllers under certain circumstances.

Fat_Lurch: The only problem with the above report, developers may falsely believe the mulitplayer or push to talk button to blame!

The repro actually helped to reproduce it more reliably :) (actually mapping a button in the process & using that mapped button) The repro steps may lead to some assumptions, but debugging the code is what really shows where the problem is. The most important is to have reliable steps to trigger the bug.

Please give an update

Currently we have some technical issues with debugging this on Win 8.1, but we still aim to fix this bugger asap.
For now I'd recommend just not entering the Controls mapping outside of the main menu. Because of that I also wanted to make sure the controls don't disappear in the middle of the game.

We're sorry about the inconvenience :/

@ armatech - so it disappears in MP just by launching it, even without going into configure/controls?

Let me assure you it wasn't abandoned and it's definitely been among the high prio issues we're on.

However, even with the same setups as you have we're unable to reproduce the issue in 100% cases. (With mentioned steps - Opening the controllers from main menu, launching an Altis scenario and opening the controllers from pause menu)

It may require a change in how the controllers are acquired by the engine (Every time you open game options the engine "re-checks" the available controllers. For some reason it can fail.)

Let's sum up what we have so far (please correct me if I'm wrong)

• happens only in Win8/8.1
• happens only when opening configure/controls from the ingame pause menu (has the controller loss happened to anyone when just playing?)
• happens only if the scenario is on Altis (strangest point - could it lead towards RAM available?)
• disabling the Enhanced Power Management in Device Manager && in the registry for all affected devices does not help (does it at least reduce the probability?)

One more thing I'd like to ask you to try is unplugging the device, plugging it in and opening the configuration/controls again to see if the devices re-appear even without restarting the game.

Thanks a lot for your help. I'm sorry that fixing this issue takes so long.

One possible workaround, that could help is switching off the EnhancedPowerManagement of the USB device.

---

Try only on your own risk!!!

1. You can download USBDeview here http://www.nirsoft.net/utils/usbdeview-x64.zip (info http://www.nirsoft.net/utils/usb_devices_view.html)
2. Right click on the problematic device, click "Open in RegEdit"
3. Open the Device Parameters of the opened device
4. Change "EnhancedPowerManagementEnabled" from 1 to 0
5. Please report back if it helped

Unless you feel rly comfortable with doing this change at your own risk, please do not attempt it. We'll still try to find a solution on our own side.

Thank you!

If you are still experiencing this issue, could you please provide your dxdiags (and eventually also .rpt right after it happens)? Thanks a lot!

@Andanteh - are those two the only controllers you have? (but you don't see the G13 in the game even right after the start anyway, right? A disabled device shouldn't play any role.)

Could we rule out the necessity of multiple controllers or presence of xbox360 controller for this bug to be reproducible?

We're struggling to isolate this nasty bugger. If you are aware of any circumstances that always trigger it, please let us know.

Thank you!

It has happened to me randomly as well, however - do you have any reliable steps to reproduce the loss of controllers 100%?

Does it happen in 100% cases to you?