We are really sorry. This limitation is unfortunately going to stay in Arma 3 :( At least in the foreseeable future.

Thanks a lot for your understanding

Thank you for the report!

Is now fixed in the dev branch.

Thank you for helping us improve the game!

The leader was fleeing (probably got scared of snakes outside of the safety of his wagon ;).

Should be fixed in the next dev. build.

Thanks a lot!

Thank you for the report. It seems to be affected also by the location (I wasn't able to reproduce it on the airport). Can you pls confirm?

Thanks for the report!

I wasn't able to reproduce this issue on my side. The control bindings should reappear once the controller has been connected again (before launching the game).

Afaict it could have gone wrong in case the Windows assigned the same device a different ID. (can be checked in the registry or easily using the USBDeview)

Please, report back if you manage to find any further info!

Thanks a lot!

The AI has a vision dependable on the current light conditions, NVGs, optics used and the AI skill. The AI also has an audible reception. And then there's the engagement range dependable on optics and weapon's AI fire modes.

The maximal detection range is also dependable on the visibility range defined in Video options (so the AI doesn't shoot beyond player's visible range)

If you see a specific situation where the detection was clearly impossible but still happened, please report it with an attached repro scenario (as simple as possible).

Thanks!

Thank you for the report and links!

Will continue about this issue in 20934.

Hey, thanks for the feedback!

We are aware of the issue when AI aims at the pilots and is very effective at killing them. It comes from the configuration of crew vulnerability in the vehicles (which also allows the AI to even fire at the vehicle with small arms). While it makes sense that AI aims at the crew positions in a ground soft vehicle, it does not make that much sense when aiming at a fast moving air vehicle.

We'll see if an improvement is feasible.

If the AI hears a shot or a bullet hits a ground around the AI, it will start scanning the horizon for a possible threat, eventually also entering the combat behavior.

The closer the source the better direction estimate. So instead of scanning the horizon, the AI turns immediately to the source. It already knows that there's a possible threat from the audible information, so once it has a visual confirmation it can immediately open fire.

However the AI shouldn't be able to place a precise shot because at that point it's still penalized by distraction and the fast turn.

Could you please provide more detailed info? (ideally a repro mission where a clearly wrong behavior would reliably happen)

Thanks a lot!

Hey, thank you for the feedback!

Could you please write down the repro steps or attach a repro mission where it happens?
Thanks a lot!

Should be back to "normal" :)

Thank you for the report!

Was introduced by recent AI fixes/optimizations. We're on it!

Thanks, based on the vid I was able to reproduce it somewhat by altering two "move to a position" orders and confuse the AI to the point it stopped moving.

Hey, thanks for your feedback!

I currently can't reproduce this issue. I believe this was fixed with recent pathfinding improvements.

Could you please confirm?

Has been done properly in the engine, no need to fake the correct behavior :)

Thank you for the report!

Fixed some time ago

Thank you for the report!

There are several AI pathfinding improvements inbound. Unfortunately they also introduced this severe bug. The issue will be fixed in the nearest Dev build update. We're sorry for the inconvenience.

It's currently working like that - camera shake in difficulty options disables all camera shakes (explosion, vehicle passing, G-loading, scripted...).
Subject to review, but we can't promise anything.

Please see http://feedback.arma3.com/view.php?id=21609#c102215

Please also check the comment here - http://feedback.arma3.com/view.php?id=6888#c74964 - for solution.

Thanks for the feedback!

Hey, thanks for your feedback.

Try switching off the TrueView in TrackIR configuration and see if it helps. Please, let us know!

Glad to help!

...there's no fantastic difficult task
Smart AI must use everything in the game.

http://www.bistudio.com/company/careers ;)

Hey & thanks for the list of ideas.

I will quickly reply with some notes.

1. AI NEVER SHOOTS IN THE INFANTRY FROM MISSILE LAUNCHER.
   • can be configured (and was like that in early Alpha), but it's better when the AI saves the valuable ammo for the real threats

5. AI NOT ABLE USE LASER SIGHTS.
6. AI NOT ABLE USE FLASHLIGHT.
   • better left out as an option for the designer but not autonomous AI behavior (you may not always want them to do it)

10. AI OF UAV OPERATOR CLASS, NOT ABLE ACTIVATE ANY DRONE.
    • can be ruled out, not possible

13. AI NOT ABLE USE REPAIR.
    • Already available. AI with repairing ability can be ordered by a group leader to repair an immobile vehicle that is assigned to the group (It won't repair friendly vehicles around the battlefield at random). AI with a repair (rearm/refuel/heal) vehicle and a SUPPORT waypoint assigned will be called in by friendly vehicles.

14. AI NOT ABLE TO USE SELF TREATMENT, WITHOUT ORDER.

It is when it's its own leader. You don't take a poo unless the leader allows you to.

Leaving the rest unanswered for now. Please bear in mind that more autonomous AI != better AI. Some of the described actions are better left out as scripting commands or as modular options as they may not universally fit.

Has been fixed as a part of field of view improvements, description has been update accordingly.

Thanks for the report!

Was fixed in https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-3#entry2831466

Thanks for helping us improve the game!

^^ and let us know pls

https://forums.bistudio.com/topic/140837-development-branch-changelog/page-35#entry2961647

Missing status or dev'v comments don't mean we are not aware of the issue, request or bug or we haven't read what you write. We read everything :)

You may find some answers in here: https://www.reddit.com/r/arma/comments/2snr1o/arma_3_update_138_rc_release_candidate/cnry64c

I'd also like to ask you to use our Forums (forums.bistudio.com) for discussions.
Please avoid posting any comments on Feedback Tracker that do not contain relevant information, add details or are not useful for identification or solution of a given issue. Such comments neither help us deal with the issues nor make the process any faster.
Try to keep it strictly technical and to the point ;)

Thanks a lot for your continuous support and working with us on improving the game!

Yup, found out this applies to both gunships in the game (even without the command they still climb when flying (not just hovering)). The others are fine.

Hey! Thank you for the report.

Have you observed similar behavior on any other helicopter than Ah-99?

Hey! Kju is right, I've had it made so.

Thanks for the suggestion. We'll see if we can do something about it.

Repro mission, where the AI goes prone reliably in an urban area (exposing itself, limiting its maneuverability) or somewhere in the open (while there are cover opportunities nearby could help. (sadly, many of the rocks on the map are not usable by the AI due to a mistake done in the earlier development. We are truly sorry about that :( )

Thanks for the report!

Have you observed this behavior on a straight road or was there a crossroad on the spot where the AI decided to turn (and turn back)?

Could you eventually pinpoint a location on Altis or Stratis where you have observed this issue?

Thank you!

I've checked it again and it doesn't seem working like I thought it should. However using hideObject on an active unit is still something the command wasn't intended for and it may not be AI-friendly when used so.

So far I can't promise any change in the behavior, but will investigate the issue.

Hey! Thank you for the report.

That is true and it is an intended behavior. HideObject does only hide an object visually. It's e.g. often used with enableSimulation false to hide something you want to enable / reveal later in the mission or to manage performance of the scenario.

The AI only looses the visual detection on a hidden object, however the AI still has audible (and ev. radar) detection. Usually it would be the footsteps what reveals you, on the other hand footsteps should not allow the AI for friend-or-foe identification. Other sounds (fire, shouting) could however.

Hello and thanks for the feedback!

The devices used for guided weaponry target designation (impulses coded in accordance with the ordnance) are often SWIR and are generally not visible in NVGs. (yes, there is a little visible dot our LD creates - that could be considered as a bug)

For a visual target designation, lasers with shorter wavelenght, visible in NV are used ( IZLID http://www.youtube.com/watch?v=EgvuGFaT7Qw ).
I find our weapon-mounted lasers quite fitting for this purpose - what do you think?

@Demongod - good suggestions. The IR strobes may fit in http://feedback.arma3.com/view.php?id=5947 , configurable laser intensity taken into consideration (however I find current lasers relatively strong enough even for fast moving CAS)

@maskedkhan - I am sorry for the confusion. The locking as it is now isn't something we are completely satisfied with and I would generally like to avoid patching up functionality on it until we are able to revise the tech.

Currently it combines two factors - a meta-game awareness helper and an actual part of weapon guidance. The first one works only on lower difficulties (named not so descriptive as "Auto Guide AT").
I guess that is where you'd like the laser targets to be included in the possible target selection, right?

Hey! Thanks for the report.

Players will assume the "commanding" role in a vehicle where there has been only AI (unless he or she is already a subordinate). Afaik Arma 2 had the same behavior and I don't recall any recent change that could have affected this behavior. But I can be wrong - can you confirm please when did you observe a change for the first time?

Waypoints should not be ignored as long as the player does not give any directional move orders.

To check who's in command you can use https://community.bistudio.com/wiki/effectiveCommander

Thank you!

Has been fixed by https://forums.bistudio.com/topic/150500-development-branch-captains-ai-log/page-3#entry2808281

Thank you!

Hey! Thank you for the feedback!

The Health slider currently intentionally fills the hitpoints only up to 97%. I am not sure whether a slider without exact value should allow for changing the alive/dead status of the unit.

Otherwise, for more comfort especially if you want to manage more units I'd generally suggest utilizing forEach and its variants ( https://community.bistudio.com/wiki/forEach ) for more comfort and control. (Run "(_x setDamage 1) forEach [array of units]" )

For now I'll just leave this request open for voting ;)

http://forums.bistudio.com/showthread.php?159711-Development-Branch-Captain-s-AI-Log&p=2940772&viewfull=1#post2940772

Thank you for helping us improve the game!

You're welcome. Enjoy the rest of the campaign! And I am sorry for the inconvenience.

This is strange. However, restarting whole campaign should not be necessary.

There was a update yesterday, can you please confirm that the issue is still happening?

If it is, could you please attach the savegame from your profile in Documents\Arma 3\Saved?

Just in case you can also try rechecking the integrity of local data, but it would be pretty weird if corrupted data had such consequences.

Hey and thank you for the report!

I went thru the mission ensuring that autorifleman and CLS die in the ambush but the leader still went correctly to the Rendezvous point.

Did it happen once or does it happen repeatedly (after resuming the mission from a prev. save) for you?
Couldn't you have possibly some mods enabled? (esp. AI-related ones)

It should be now fully fixed in Dev Branch.
Please, let us know, if you bump into any issue reg. this.
Thanks a lot!

Hey madbull! No worries. It means it has been checked, successfully reproduced and transferred into our internal pipelines.

Now, you may ask what is the difference between "reviewed" and "acknowledged" ;) Acknowledgement may usually (not always) suggest it's been recognized by a dev as a valid issue we'd like to do something about (votes/popularity also plays a role even though it may not always seem so ;)). An update of FT guidelines is planned soon - that should make all these things more clear.

As for this issue - it's still unsure - setPos'd objects work correctly if command is used in the mission init, so it's also a question of the command's use definition/limits.

iac. thanks a lot for the feedback and we'll try to keep you informed about any decisions or ev. fixes!

AIII-11599

Hey, thank you for your feedback.

On an empty helicopter you can use
player action ["collisionlightOn", VEHICLE]
for collision lights and
player action ["lightOn", VEHICLE]
for the search light.
https://community.bistudio.com/wiki/ArmA:_Actions#LightOff

The AI will however manage the lights on its own depending on its current behavior and the searchlight is not included.

Will keep you informed.

Could you please verify that you have

"Optics" or "Optics temporary" bound

Few other tips

1. The "Optics Mode" is a switch - you have to enter the optics to see the result (RMB click or Num0 by default)
2. RMB Hold can be bound as a different action (by default holding breath and zooming in), make sure you only "click" the RMB when switching the optics mode.

I was not able to experience any issues on Apple MB110. What type of KB do you have?

It is not available or is it not working when bound to the "Optics Mode" action?

Could you please attach a screenshot of your settings? (similar to https://www.dropbox.com/s/t1mtd76oif6imst/Arma3Int_DX11%202014-07-07%2018-07-37-46.png )

In the binding menu you should see a column on the right side of the window with available combinations. Look for Left Ctrl+Sec. Mouse Btn. and drag it over to the keys already assigned to the action.

https://forums.bistudio.com/topic/140837-development-branch-changelog/page-32#entry2921906

I'm terribly sorry, but we won't deliver it in 1.52. 1.52 will still contain the offset rotation axis.

The current state on Dev Branch is centered rotation axis in all situations. This won't be implemented in 1.52 and after that we'll be aiming for a kind of a hybrid between offset and centered rot. axis, hopefully getting as much out of our current animation and collision system as we can. In the end it will still be a tradeoff.

Although we'd really like, fixing this completely goes beyond Arma 3's animation system possibilities.

We are really sorry to disappoint you - it won't stay in for the 1.50 patch, but we're still on it, we'll put it back in the dev branch after the release and 1.52 should hopefully finally include as good solution as we can do it within the current limitations.

Can't reproduce. Is this still valid?

FYI the precision of zeroing was improved recently - should be in the next dev branch update.

Hey and thanks for the feedback!

Could you please clarify what weapon is this issue related to?

Hey, thank you for the report. You mention that the issue occurs also in other game types - do you mean Zeus game types (with the Fire Mission WP) or has it happened to you also when using Support modules or even when ordering an arty subordinate to fire at position?

Hey! Thanks for the report.

The completion radius works against AI checks. If the AI has nothing else to check it won't find out that the WP is completed until it securely reaches the very waypoint.

In COMBAT behavior the checks are performed almost constantly making the AI realize a WP has been completed soon after crossing the completion radius.

I agree it probably isn't much intuitive, but I can't tell you now whether changing this behavior would even be feasible.

For now I'll play a dead fish and wait for more feedback/votes ;)

---

Also note that the distance a WP completion is checked by the AI differs according to the type of vehicle used.

The thing behind This is, that there should be an Option to deactivate TrackIR while looking through a scope.

For that (deactivation) please use http://feedback.arma3.com/view.php?id=9816

I'm sorry to disappoint you. We can't do. (the sensitivity of TIR relates to its center (unlike mouse), it wouldn't work nicely if you zoomed in while looking to the side)

Anyway, thanks for the feedback & idea!

I can't reproduce the issue. When I kill the AI behind a static weapon, its fire ceases. Wounding the AI in a static weapon doesn't make it change stance (and it can't as long as it is inside a vehicle).

Could you please add repro steps, repro mission or a video with the mentioned behavior?

No worries. I'll mark it as resolved but feel free to reopen/re-add a ticket if you bump into it again. Thank you!

Hey! Could you please specify the issue?

I'll do a diag_log of these empty detectors prior to delete, and also a diag_log of the time-of-death of players and anything else relevant i can think of.

Any luck?

(you can also utilize the https://community.bistudio.com/wiki/logEntities command)

"Yes, with zero use of 'createTrigger' on server or client, there is still accumulation of 'emptyDetector' at [0,0,0]."

Do you, please, have any such test mission where this could be observed? (I&A uses triggers)
Or should just one simple MP scenario with many playable units and nothing else be enough to reproduce this?

Do you what respawn type/settings were used in the scenario?
Thanks a lot

One more thing - any official modules or functions are used?

Really appreciate your help, thanks!

So it can happen even without triggers created or scripts that could create them or modules (incl. Respawn)?

I've done some testing, but hasn't been able to achieve that so far :/

Hey! We'd definitely need more on this. Could you please attach or send me the mission, rpt and output from the allmissionobjects when such thing happens?

Regarding the EmptyDetector - do I get it right, that you create some on the client side, client disconnects, EmptyDetector gets transferred to the server, you attempt to delete it there but it's not possible, correct?

Does it happen reliably to you? Under what circumstances?

---

Regarding #smokesource and #destructioneffects - under what circumstances has the allMissionObjects returned these? Could you please provide more info - any mods used, config adjustments?

Thanks a lot!

Here you go:

    https://community.bistudio.com/wiki/allMines
    https://community.bistudio.com/wiki/detectedMines
    https://community.bistudio.com/wiki/mineDetectedBy

Thank you for your feedback!

Thank you for the report!

There is an inconsistency in T/R usage because it serves two purposes - creating a meta-game visual aiming aid and also for ordering a gunner to aim at target. We'll see what can be done about it.

In the meantime I'd suggest using the command menu [2] to manually select a target (although it is not as convenient).

Should be improved - http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2721184&viewfull=1#post2721184

The gunner should always aim on a valid alive target designated by the commander.

(All the AI (except general AI issues) get assigned to me automatically ;)

The AI in tanks tries to avoid the sea and usually doesn't go in there intentionally. If you go and take bath they won't follow you.

But it seems buggy sometimes and either the AI plans a wrong path (going thru the deep water) or doesn't brake enough to stop itself from entering the water.

There's a flyInHeight command that should do the trick.
https://community.bistudio.com/wiki/flyInHeight

Let me know if that works for you or if you need additional info.

Hey! Thanks for the report.
As far as I can tell this applies reliably only to some vehicles in specific environments, right? (e.g. Slammer) Or have you experienced this issue regardless the vehicle (4W, 6W, 8W, tracked...) and road type?

Duplicate of multiple other separate reports (18517, 4512, 10726...)
For general feedback please use http://forums.bistudio.com/showthread.php?159710-AI-Discussion-(dev-branch)

Thank you!

It may well report that Autospot is set at 0 but the problem is that Player characters in MP games call out enemy spotted etc when they should not.

That's also what I was unable to reproduce. My avatar doesn't report an enemy even if I'm directly looking at him with the autoSpot switched off. With it enabled the avatar reports a contact immediately.

I'm afraid autospot means also autoreport linked with cursortarget: http://feedback.arma3.com/view.php?id=23023 [^] (see video)

A different issue. To be dealt with in that linked report.
So far the only way how to check what the character is looking/aiming at are quite expensive scripted raycasts. We intend to provide simpler way how to do it.

I'm unable to reproduce the issue on a hosted server. Having a "Regular" preset with autospot=0 the server and with autospot=1 on the client, the server still enforces autospot=0 and it's also correctly returned on both by the script command.

Will try the dedicated later.

In case you have some more detailed info, please let us know.

Got fixed during the development. The AI flinches on every single hit.

Thank you for the report!

True, I am sorry. Have just tested it at work properly with the TIR and roll axis really breaks it even in that case.

Yup, confirming it now. It is still that one particular character (pilot) bug. It seems like we fixed only part of the issue (it only works when the view is centered with slight head movement due to centrifugal force) and it gets broken once you enter freelook or if use head-tracking device.

Try to enter the plane as rifleman and everything will work as it should.

Thanks for the visual cue!

Could you, please, provide a video depicting the issue?

We had this issue previously when the HUD elements were not collimated (if I am getting it right). But that was connected to a wrong memory point in some of the characters' models and was fixed in March.

Just a note - this does not apply to HMDs which do not currently work properly at all in A3.

Please follow http://feedback.arma3.com/view.php?id=19487 from now on

We are really sorry to disappoint you - it won't stay in for the 1.50 patch, but we're still on it, we'll put it back in the dev branch after the release and 1.52 should hopefully finally include as good solution as we can do it within the current limitations.

This should now be fixed in the Dev branch.
Thank you for helping us improve the game!

Got it. It needs correct timing;)
Thank you!

Hey! Thanks for the report.

I was unable to reproduce the issue. Does it still happen to you? Are there any additional specific steps needed (waypoints, actions)?
Could you eventually please attach a repro mission?

Thank you!

Could you please make a video? I am unable to repro the issue.

My driver turns and then keeps the direction correctly.
http://youtu.be/3_wMPd12aSs

Hey, thank you for the report!

Unless the AI is initialized in the vehicle, the gunner's initial watch direction will be north. Once you start moving, unless the gunner has a target to aim at, the gunner AI will try to align the gun in the direction of the vehicles' movement.

Do you find it wrong or were you experiencing a different behavior?

Hey, thanks for the report!

Could you please attach a repro mission? And more details (weapons, optics, time/weather, environment, ...)

In few attempts ranging from 300-500m at night with a silenced Mk18 and conversely with LRR. In both situations the AI didn't have a clue, where I am shooting from. (Mk18 - http://youtu.be/47huD1ZVq_A )

Hey, thank you for the report!

hideObject and hideObjectGlobal are intended only to hide the visuals and do not alter the functionality of an object. (Except the functionality that comes with visuals - e.g. AI unable to visually confirm a target)

I'd probably suggest requesting a command to hide a vehicle from radar instead.

Is it intended behavior, that the hideObjectGlobal command does not work in the editor/ SP, while the global-counterparts of other commands do without any problems?

This should no longer be true and it should work correctly everywhere.

I find them quite deadly or missing the target in a random fashion. Your experience resembles as if the miniguns were incorrectly aligned, but they seem quite ok as well. Could you please eventually try it with different AI skill / difficulty and see at what approx. values the gunners miss too much?

Thanks a lot!

Hey! Thank you for the suggestion.

It's a nice idea. It could however raise an issue - with an ability to create various sets of "Guarded by" triggers it could prove difficult to set and manage their order (and priority).

Leaving the ticket/idea open for more feedback.

Hey, thank you for the ticket. I've quickly tried the road between Chalkeia and Panagia with a mixed convoy (MRAPs, trucks, armor) and it didn't stop at any of the bridges.

(Although still the convoys and bridges present quite an infamous combination ;/)

Your mission seems to be utilizing some custom convoy FSM, could that eventually be the cause?

You may want to try stripping down the mission and see if the behavior is the same with just the convoy and simple waypoints.

Thank you for the report. Have you tried the "Industry Standard" keyboard preset? That should get you as close as possible to other games' layouts without sacrificing much of the Arma's functionality.

Hey, thanks for the report. Unfortunately this is currently impossible because it would also require teaching the AI how properly deal with these responsibilities and pilot/gunner coordination.

Note what difficulty settings do you have selected. On Recruit and Regular the "Extended Armor" option is selected by default making player and AI units in his/her team more resilient

We are sorry, no new EXE is going to be uploaded to today's DEVELOPMENT branch so this issue will still be present. We'll try to get a new EXE with this issue fixed there ASAP.