As far as i have noticed it is while in the cover/overwatch drill which makes AI unresponsive (which only triggers under danger). I had some *satisfactory* results by disabling it via formationFSM (allowing me to more arbitrarily give move orders to AI)**. In any case this could only be seen as a workaround, the engine should definitely provide both a scripting and a player accessible command menu order to bypass current self assigned AI moves and orders (see currentCommand) even when its in danger.

**(this is a hint a for you to explore fabrizioT and your bCombat mod)

Edit: Please take a look at
0015297: Ability to dynamicaly set searchPath parameter values (via scripting or command menu) (http://feedback.arma3.com/view.php?id=15297)

^^ pretty much, but i am optimist, it appears some flexibility is coming, i keep seeing "global" and "per-unit" words in bold, this as i see it, hints at some proper dealing of the issue.

btw:
0013229: Ability to individualize setBehaviour type commands to group members
(http://feedback.arma3.com/view.php?id=13229)

i did not know the following but:

"Division by zero (an operation on finite operands gives an exact infinite result, e.g., 1/0 or log(0)) (returns ±infinity by default)." from the wikipedia article

(+infinity and -infinity)

We actually have it: https://community.bistudio.com/wiki/Number#Number_Type

someone needed a place to keep track of the sign, but for those parsing numbers might get ugly.

Experiencing similar symtptom, in my case debug console relentlessly recovers last values* whenever launching the console. Even after A3 shutdown.

*as in the same that i had before the 1.07.112324 dev update was in effect.

Curious mind of IanBanks posted 2 relevant threads concerning this ticket for 2 reasons:

1. Visual impact of actual texture blending the engine implements:

Figuring out the blending between satmaps and ground _co's and where things go wrong
(http://forums.bistudio.com/showthread.php?168452-Figuring-out-the-blending-between-satmaps-and-ground-_co-s-and-where-things-go-wrong)

and

2. Engine's limitation in regard to modding surface textures of a given island

Surface _mco textures aren't actually used by ARMA 2, only the middle ground _mco is
(http://forums.bistudio.com/showthread.php?168549-Surface-_mco-textures-aren-t-actually-used-by-ARMA-2-only-the-middle-ground-_mco-is)

1. disproves my wrong assumption of the blend mode being overlay, being multiply instead. Actual values are presented experimentaly. In any case the main point stands the same: Extending the area where the resulting blend is more effective instead of a simple linear transition.

2. informs my suspicion that one cannot easily mod surface textures without incurring in ill advised methods or without mp deployment consequences.

^^ Clouds on "Low" does aggravate this specific appearance. Yet i've seen this type of artifacts with higher settings too.

"As for the ticks, isn't it safe to assume that we are just seeing the interval at which the AI share information?"
If i do believe that solving the target sharing interval will help in significantly decreasing the symptom shown on this ticket, the Tao's issue stands. To prove it is his first repro where there is no friendly AI reporting.

Specifically in regards to it, i think it is only a matter for AI to distinguish how close to itself the soft cover is affecting its own likelihood of shotting. (this reminds me how helpfull could the perceived position accuracy return of nearTargets be to represent this likelihood - and does it increase sufficiently as soon as LoS is false)

I agree with Taosenai in emphasising the need to deal with them differently.

unrelated notes:
[I've been doing some testing and some of my assumptions are not correct. There appears to be some actual limits implemented. I confirmed that the sharing of targets is not made to all members of a group simultaneously in every case. The point stands though since it is still too fast. Will further test this.

For anyone reusing the LoS script i uploaded: the script is bugged due ASL/ATL positions overlook on my part when adding the possibility to use a custom target list as opposed the one provided by neartargets. Working version on the way, but beware.]

@Taosenai
"This bug with close bushes seems to be an unintended side effect of that behavior when combined with that ticks of perfect info obtained from a spotter (explained below)."
Exacly my thoughts.

@maturin
"However, I don't know why you are describing these position updates as 'ticks' of information when they are simply radio contact reports received from the teammate."
If i am not mistaken he is refering to ticks (as in engine loop cycles). No one, but devs, really know what is the fraction of time these translate to. But it is observable that the perceived position (also actual position since the reporting unit has LoS) is being shared with a much faster rate than would be humanely possible by radio reports.

I've seen some issues now where current AI Target Sharing abilities really appears to facilitate misbehaviour, an example is "Grouped AI is aware of kills even when they shouldn't notice" (http://feedback.arma3.com/view.php?id=10143)

Let's sample a human target sharing:
<Threat seen>
"Contact, vehicle 2 o'clock"
2 secs later
"Enemy technical, 300 meters out... unware of our presence"
4 secs later
"Bearing 53, moving slow northbound. Infantry supported"

Current AI sharing:
tick1 - [[[2555.33,2535.33,1.32708],<generic class>,unknown,0,unknown]]
tick2 - [[[further updates position],"Class",EAST,214222,EAST 1-1-A:1]]
tick3 - ...

Between ticks we have fractions of seconds. Stressing that transmission of this information is humanly impossible at the observed rate, accuracy and immediacy.

Additionaly the whole group becomes aware of threats simultaneously with no degradation of information whatsoever. Independently if they have radios or are just shouting out to whoever is nearby to hear, independently of current occupation (ie. shooting - no one attempts to report while shooting), independently of general surrounding noise.

As in a hive to which they all contribute and access information from. Making me think there is no individual AI threat database at all.

Now removing this ability from AI should not be without it's other consequences. It is not surprising that there will be AI systems relying in this unrealistic behaviour providing the current "acceptable" balance, which would then become broken.

*there might be some assumptions here but they are according to my general experience. I'll try and make actual repros of these.

I think it would go a long way in individualising the threats database, limit the sharing of information to much slower updates, and also limit the span of information per update (once type of threat, once direction and distance / grid position, etc)

Added a LOS check to the repros (see attached file).

Notes:

• Player unit is now named "observer"
• Player unit moved closer (still in cover from affected units), to facilitate changing to Spectator mode and better check the LOS (it is difficult from internal camera)
• only "badguy" is checked for LOS but more units can be added to "GAM_unitsToCheckCoverage" array (check init.sqf)
• added hint coverage information as a percentage (result is an aggregate of all threats being checked against)
• coverage script is run processing an actual threat position, in the alternative mode it will only check against perceived position of known targets (returned by nearTargets), to activate this mode the line

"[_x, 500, true, allUnits - [observer]] call checkCoverage" should be changed to
"[_x, 500, true] call checkCoverage"

Comments:
I agree with maturin when he states that "The AI should retain full knowledge* of the enemy's position, but they should not be able shoot at it with a high degree of accuracy over long ranges. The basic behavior is correct and human, but the precision is ridiculous"

*Full knowledge is an overstatement though specially when there is no friendly additional info, even in which case it should never share the information neither at the rate, accuracy, and immediacy to which it does.

Another point is that while shooting through foliage should be an expected behaviour, we should further distinguish when that foliage (or other kinds of soft cover) is closer to the shooting AI.
IF COVER IS CLOSER TO TARGET
i agree with maturin, prediction routine should serve the purpose (with a lower level of accuracy as stated)
BUT
IF COVER IS CLOSER TO THE SHOOTING AI
the prediction routine should be even less accurate because being closer also means a higher range of possible wrong positions. This decreased level of accuracy should only be mitigated by the AI actually updating the perceive position to an actual position, since in this case it is also easier to move a smaller distance to see between intervals in foliage.

So this repro mixes some issues:

• Rate, Accuracy, and Immediacy of Target sharing (ingroup)
• Accuracy of prediction routines
• Likelyhood of shooting under low expectations of success

related to: http://feedback.arma3.com/view.php?id=13184

In the repro mission you have set Combat Mode to "Hold Fire", which will remain so until you set it to "Open Fire". You also have "dostop this" on the unit's init which should also be interfering.

I did notice sometimes the engage order would make the unit turn away from the target apparently in a flanking manouver.

Attached file AI_engage_bug_far.Altis.rar only has an empty folder inside.

^^
press Winkey > type "dxdiag" > press enter
you should get an info dialog but proceed.

then you have the button "Save All Information"
choose a suitable place to save the txt file.

I can totally wrong but thinking of this issue it occured that there might be a difference between the simulated lens of TrueSky and RV4. Are they using different aproximations for projection functions leading to different screen mappings?

http://epaperpress.com/ptlens/lensCorrect.html (for real example)

http://photoropter.berlios.de/phtrdoc/techback_geom.html (lens geometries but specially the section "Different focal lengths for fixed viewing angle")

Just adding the repro mission (is it possible to remove edit Additional Information and remove that?). Script is slightly updated to detect only the player

accTime/decTime: it would be just a matter of the command accepting negative values. But there is potential for a can of worms there in regards to the various simulation systems working in reverse.

There are mods that do this... :whistle:

This functionality partially exists despite with cumbersome access to a player. mission scripters can use:

UnitCapture
UnitCaptureFiring
UnitCaptureSimple

along with

UnitPlay
UnitPlayFiring
UnitPlaySimple

I wouldn't be surprised if some camera mod would show up and implement such functions to fit the purpose of this op.

Confirmed.

the alternative command to put the item in the inventory does not work either:
player unassignItem "G_Diving"; // same error as in OP

For the time being one can removeGoggles to get similar effect (this won't put the goggles back in inventory though as would unassignItem)

Independently of the implementation (be it coloring or house division categories), the gist of the idea could help improve CQB.

not sure if still valid (not reason to think otherwise)

"Note: Currently, the precision is derived from a skill as follows:

precision = skill*1.8-0.8

The result is clamped into 0.1 ... 1.0 range.

(The "skill" here is the combined skill which is a result of a unit skill as given in the editor and the skill given in the difficulty settings.)

Precision affects AI abilities aimingAccuracy and aimingShake, all other abililities (including aimingSpeed) are affected by a skill (see http://community.bistudio.com/wiki/setSkill_array)" - Suma
2y ago (here - http://dev-heaven.net/issues/27851)

basically meaning we should consider the value defined by the player via difficulty menu different from the one set for a mission in editor. I think it is reasonable for the mission editor dinamically spawning a unit to assume an editor skill which will likewise be further modified by player settings.

(in any case Bohemia as revealed in the forum they are addressing this issue supposedly in a wider form)

"I suggest it should use editor default 0.5 or use a random value between 0.1 and 1."

I think it is more rational to default to editor. A random value can lead to confusion imo.

^^ in the meanwhile try the attached fn_spawnGroup_patched.zip and call the function with

[code]
spawnGroup_patched = compile preProcessFileLineNumbers 'fn_spawnGroup_patched.sqf';
_group = [params] call spawnGroup_patched;
[/code]

it solves mentioned bugs

I've seen this too (beta branch as of 08/18), i wouldn't have guessed BIS_fnc_spawnGroup was the culprit. I also noticed the function was ignoring the direction to spawn the group to as input by the 8 parameter.

Edit: on closer inspection of the function, the thing is that the azimuth is indeed set for the individual unit, but the whole group will keep a northbound azimuth.

temporary fix of the azimuth issue:

[code]
private ["_relPos"];
_relPos = _positions select _i;
_relPos = [_relPos, 360 - _azimuth] call BIS_fnc_rotateVector2D; // added line
_itemPos = [(_pos select 0) + (_relPos select 0), (_pos select 1) + (_relPos select 1)];
[/code]

Edit 2:

only to add that the currently the function does:
_unit = _grp createUnit [_type, _itemPos, [], 0, "FORM"];

which suggests an array type creation, and in wiki:
Object = group createUnit [type, position, markers, placement, special]

which suggests that the parameter 3 is placement radius ("0" in the function) not skill as per the normal alternative creation method.

Edit 3 (temp fix until the createUnit function in array mode does not mess with the skill):

[code]
_unit = _grp createUnit [_type, _itemPos, [], 0, "FORM"]; commented out
_type createUnit [_itemPos, _grp]; using old mode
_unit = (units _grp) select ((count units _grp) - 1); fetching the unit from group
_unit setDir _azimuth;
[/code]

I just tested:
_unit forceSpeed 20;
_unit doMove _pos;

with _unit integrated in a group with speedMode "AUTO" with success.
The unit was originally following the leader formation at 15 (normal run), with forceSpeed i got it to turn about and increase it's speed to 20, the unit won't make the whole path at that speed depending on turns.

But i agree with the facility to set it with setSpeedmode too. Up voted.

^^ stressing the default behaviour considerations mentioned by Giorgy...

One way out of remaining doubts could be to activate native intergroup communication (and target sharing) only under the condition of High Command module being activated in the mission (if it is implemented for A3 as it appears it will), this could translate to functionality brought by the module itself. The functionality is easily implemented with scripts (loosing the scripting control over how this happens is actually where I lay my worries).

btw the command to let other groups know about other group's targets is the reveal command.

I'm keeping my self neutral for now, reason:

Internal group target "sharing" is already unrealistic and originating problems, unless the issue of this OP is looked at taking this point into consideration (check - http://feedback.arma3.com/view.php?id=10143) or we're in for additional trouble ... I advise a great deal of caution, the other issue should be sorted out with priority imo.

I believe this is intended behaviour, we have setFriend for side manipulations. The command does by default what is to be expected, the group parameter is there to set the group, NOT the side of the unit. It is only an afterthought the usage mentioned in the OP.

and to make East and West not kill each other:
EAST setFriend [WEST, 1];
WEST setFriend [EAST, 1];

more at - https://community.bistudio.com/wiki/Side_relations

One of the first things i remember being taught when running is to control one's breath. You don't simply open up your troath to dust and cold/hot air coming in, you breathe through your nose in a regular fashion with increasing intensity.

The current effect reflects someone absolutely exhausted as soon as is started (troath breathing) and it only gets worse towards the last stage.

Please remove tong clicks and pharinx air ressonations altogether, they actually run against "suspension of disbelief" of the player (and aggravate misophony as someone well put it). We're very close to the uncanny valey here, resulting disconfort must be considered.

It's overdone, allow us to separatly adjust this effect's volume or, at the minimum, reduce it significantly (-1Db/-2Db).

^^ those correspond to a misinterpretation of results. Check http://youtu.be/Rkvbt7Crluw (this might justify another ticket), which shows that the detecting AI does not get the position of the killer enemy as described in this ticket. If that was the case a single killing shot would trigger the effect. But according to the related video of that post there is a 2nd shot required for the mentioned "misbehaviour", 2nd shot which can be seen by detecting AI and inform accurately of enemy position.

Imo the issue as described in this ticket is indeed solved. But i appeal for consideration of a similar issue:
http://feedback.arma3.com/view.php?id=10143 (currently unassigned)

I am unable to test this on dedi. But ceeeb should be right the 1st reason he mentions, but also "the spawn version may create more complicated pathfinding".

Check issue 0012695: createUnit (array) creates AI with skill 1 by default (http://feedback.arma3.com/view.php?id=12695)

which indeed should activate more demanding routines from the AI.

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

I can reproduce this with beta branch as of 08-22.

Thanks for pointing this out Alwarren.

I think this can be generalized to the way group members share target information (check - http://youtu.be/e-zjWzg9-PI | beta branch as of 08-22).

It is not just what triggers the sharing/communication of targets (in this case the group member killed doing the communication)

It is also the accuracy and the nodelay amount of time with which the information is shared.

I am abstaining for now to make a specific ticket for the latter, i do welcome advice from a mod.

you're right... when i made the tests only tried 100 and 200. And these are accepted and updated. The command has exacly these as minimum and maximum values, anything outside is reset. 150 is accepted, 50 or 1000 are not.

(tested with Shadow settings: Low | Very High | Ultra)

confirmed working with today's devs.

but Xendance is right: it is limited to 200m. (devious wiki examples)

^^ the example in wiki mentions 1000 :)

Still present in dev 1.07.112166

@battlelunti
It actually makes sense. Some (if not all) AI threats have additional meta information associated (ie. position, entity causing the threat, etc...). In the case you tested the Minefield-Module is "neutral" as if the causedBy meta information was the "editor" (and not the player). This is the logic i see in it, it is still speculation though.

Kudus japapatramtara! :)

but i noticed:

EH return when triggered ie.

[BIS_fnc_setObjectVar_object1,33a3b900# 164238: dummyweapon.p3d,"NVGoggles"]

and

allUnits return

[BIS_fnc_setObjectVar_object1]

side BIS_fnc_setObjectVar_object1

WEST

assuming this is as a consequence of the new implementation, isn't it a bit risky to let the auxiliary object show there? It is easy to exclude it from the list but some allUnits usage may not account for it.

Edit:

player == BIS_fnc_setObjectVar_object1

true

just noticed this is the player itself. Which probably points to this originating elsewhere.

(version DEV 1.03.110951)

To keep it only two eventhandlers (Put and Take), one could condense them into...

PUT:

• item slot* TO inventory**
• subcontainers*** TO inventory

• inventory TO ground

• item slot TO ground
• backpack TO ground

TAKE:

• ground TO inventory

• ground TO item slot
• ground TO backpack

• inventory TO item slot
• inventory TO backpack

*item slot represents also weapon slots, magazine slots, NVG slot, Glasses/Goggles, etc.

• inventory represents combat fatigues like items
  • subcontainers represents carriers and backpacks like items

Basically the biderection would be:
PUT == inner TO outer
TAKE == outer TO inner

the scripter would only require to make an additional check onto which level (of 3 possible) the item was placed.

^^ I trust your experiments. I left some room for mistery since these events suggest a biderectional, hence 2 places possible. Yet between ground, inventory, associated slot (and subcontainers), those make at least 3 distinct places. In theory the events can only distinguish so much.

upvoted.

But maybe there is some obscure logic to it. Maybe we just need to know what that logic is.

^^ the above can be seen as a workaround, but this should be definitely native.

I would see logical to have the fire rate tied to an expectation of sucessful hit on target which can relate with nearTargets returned value position accuracy. Or with a supression order from the leader of group.

Consider it solved, unable to reproduce as of 08-17.

It might just be a parameter tweak, from time to time they appear to follow the rule and expected behaviour.

I lost all my composture of seriousness demanded by AI ticket reviewing with this repro. Good job Katulobotomia Attenborough. Voted.

As far as i have noticed it is while in the cover/overwatch drill which makes AI unresponsive (which only triggers under danger). I had some *satisfactory* results by disabling it via formationFSM (allowing me to more arbitrarily give move orders to AI)**. In any case this could only be seen as a workaround, the engine should definitely provide both a scripting and a player accessible command menu order to bypass current self assigned AI moves and orders (see currentCommand) even when its in danger.

**(this is a hint a for you to explore fabrizioT and your bCombat mod)

Edit: Please take a look at
0015297: Ability to dynamicaly set searchPath parameter values (via scripting or command menu) (http://feedback.arma3.com/view.php?id=15297)

Thank you for the info, it is one of those that shouldn't be here, down voted the issue accordingly. Can we mark this as solved?

I am noticing the weather settings to be kind of "temperamental". There are thresholds of certain settings in order for the others to take effect. Some of these are pretty obvious (ie. it must overcast > 85 to rain > 0, as constrained in the INTEL panel in editor). Also try your dynamic weather system with "manual" and "auto" and see if it gets more responsive for your scripted settings.

I had trials where wind was responsive, but later on changing into a halt where it does not accept more setup anymore.

The current weather engine is probably under heavy tunning, i suspect.

I don't confirm in absolute the ticket description.

In my testing the overcast value does change (responding to ie. "50 setOvercast 1"), but it apparently ignores the first term, the duration for the transition set by the command.

We're not in disagreement at all in regards to the need of this. But i think you're underestimating the underlying complexity of the whole issue.

I wouldn't be surprised that even if an absolute value for value syncing was made by scripting means, the end result would still be some discrepance, due to the eventuality (pure speculation) of cloud generation not being deterministic, and showing in different ways to players, and in border cases even raining >< not raining instances.

Also BI is dependent on a 3rd party technology which may even further delay progress/debugging.

The only reason i come up with is network overhead. Specially since it will affect moslty JIP players, specially since the legacy weather was not as spectacular visually, and therefore less noticeable.

^^ good enough.

I was reading on nextWeatherChange command http://community.bistudio.com/wiki/nextWeatherChange and

"Return the remaining time (in seconds) over which the current weather change will occur. When a weather change finishes, the game engine will automatically generate a new _random weather change_ over a realistic time period (minimum of 90 minutes).

Multiplayer: Each client and the server can have differing weather."

So this is, since old time, left to the mission maker to assure syncing. I maintain my view this would be probably best done at the engine level. Specially since visually relevant weather parameters may not all be obvious to the scripter.

Tachi's point is very relevant i believe. Anyone testing this in MP environment should control and check the client's daytime where weather desync is observable. Current desync issues _may_ simply come down to this.

^^ agree with PolarisUK. This issue should have a level of priority.

@ Make Love Not War
Listen fela: you may feel free to disagree, what i will not tolerate is for you to insult.

Level your disagreement in mature way, and i might bother to clarify.

I wouldn't call it perfect. But lack of shadowing and saturation is exacly what one expects when overcast.

Was able to reproduce this also in if pressing CTRL+A (or D) when the transition animation is running from any and to any of the 3 lower stances.

The sliding (floating) direction and speed differs in each case, but appear tied to the transition itself *not* to the A(Left) or D(Right) directions.

This also appears to be a duplicate of issue # 577 (http://feedback.arma3.com/view.php?id=577)