Freghar

Something I noticed today, might be worth fixing - the UK3CB_RPK74_60rnd_545x39 magazine (and similar) seem to use ammo = "UK3CB_762x39_Ball_Red" which itself inherits caliber and "hit" value from B_762x51_Ball. Other than looking into the "caliber" and "hit" values (which should probably be less for 7.62x39 than for 7.62x51), the magazine is using the wrong CfgAmmo. It should probably use ammo = "UK3CB_545x39_Ball_Green".

Hello, could you please pack configs and scripting in a separate pbo (like ie. RHS does) that wouldn't be obfuscated using Mikero's tools? We recently had an issue with randomized gear and suspect some of the UK3CB_* functions - looking at them, there are some more things that could conflict with other mods, but we cannot debug the issue when the functions/configs are obfuscated. I'd understand obfuscating assets (models, textures, etc.), even if you can export them un-obfuscated from the game if you know how, but it doesn't really make sense for configs/scripts. Thanks!

Note that I may have found the culprit: https://community.bistudio.com/wiki/Arma_2:_FSM_Danger_Causes (The feature would make sense if it didn't propagate through building walls and instantaneously, even mid-burst-shot.) So I guess there's really no way to disable it via scripts/config if even custom scripted FSMs can't modify this.

The problem is that while this could be scripted away for some scenarios (ie. artillery) by spawning an enemy unit on [0,0,0] and setting it as the shotParent (even though it would make AI look towards [0,0,0]), I can't think of a way to work around this for a "stealth mission". If I set shotParents to objNull or to a unit from the target's side, the AI obviously doesn't react. If I set it to somebody from the attacker's side, all units within 80 meters still get alerted (run around, go prone, etc.), even if I forgetTarget right after the unit being hit. Even if I was to construct some logic that can forgetTarget without causing an alert (by switching sides / using captive / CARELESS / etc.), I can't reliably tell between a situation where the AI should spot the shooter via its spotting capabilities (outlined in my post above) or if the target got spotted via "magical" bullet hit spotting. My issue is not necessarily the unit(s) knowing who shot the target, but that the fact that target was shot is broadcasted to other groups. Even though the two may be connected. Thanks.

The only active mod is a tiny one that does the changes described in my post. And CBA that I forgot to disable for the video. I wouldn't be posting here if the issue wasn't reproducible on clean vanilla game (it is), it's just harder to provide such a nice demonstration of the issue with fully active AI spotting and engaging.

Hello, I've been trying to debug AI soldiers "magically" reporting targets, when hit by a bullet, to any groups within exactly 80 meters, ruining any attempts at a "stealth mission", but so far no luck and I may need somebody with engine source access to confirm this. What happens: When a soldier is non-fatally hit, it instantly transmits the shooter info to any nearby groups When a soldier is instantly killed (headshot), this does not happen This does not affect non-soldier vehicles, AFAICT Soldier audibly shouting (or not) has no effect on this Soldier actively spotting shooter has no effect on this (only bullet hit) Inventory content (ie. ItemRadio) has no effect on this What I've tried to narrow this down: Set "audibleFire" and "visibleFire" for both the CfgAmmo and muzzle_snds_* to 0.0001 Set "camouflage" and "audible" for the shooter to 0.0001 Set "sensitivity" and "sensitivityEar" for all soldiers to 0.0001 Set all skills to 0, I even modified CfgAISkill to make sure skillFinal is 0 Used disableAI on all skills (not shown in video) Set "fsmDanger" and "fsmFormation" to empty string for all soldiers Experimented with "dangerRadiusBulletClose", "dangerRadiusHit", "visibleFireTime", etc. for the CfgAmmo Removed all possible runtime EventHandlers from the soldier and checked Config structure Searched thoroughly for any relevant keywords and numbers through all game PBOs None of this changed the "magical" spotting - the AI is dumb and cannot see/shoot me, but the "targets" lists of nearby groups still get updated with the shooter. If anyone (oukej?) can shed some light on this and whether the spotting can be disabled/reduced/delayed, I would love to know. Thanks!

Any idea how would I assign "ctrl+alt" as a keybind? .. I used to have it for ACE door opening, but now nothing happens when I press it on the key-assignment screen. Is there some profile variable I can put the keycodes in? Thanks.

(Even though the chances of this happening are slim, I'm going to at least ask.) Is there any chance of making the per-skill unit sliders inherit the range setting from the vanilla "Skill" control, instead of hardcoding _ctrlValue slidersetrange [2,10]; ? My community uses a customization that overrides the vanilla Skill control to have a full sliderRange[] = {0, 1} and it works for the base Eden/Zeus slider, but obviously not for Achilles. Looking at your code, I don't see an easy generic way of doing it, it seems that you have class RscAttributeSkill: RscControlsGroupNoScrollbars { onSetFocus = "[_this,""RscAttributeSkill"",'AresDisplays'] call (uinamespace getvariable ""Achilles_fnc_initCuratorAttribute"")"; }; and, as Arma doesn't support multiple inheritance, making it use an value from class Skill while keeping the NoScrollbars template would be impossible. One could just look into the config when getting the bounds for slidersetrange, but that feels a bit too ... arbitrary. Ie. vanilla would return getArray (configFile >> "Cfg3DEN" >> "Attributes" >> "Skill" >> "Controls" >> "Value" >> "sliderRange"); [0.2,1] getArray (configFile >> "Cfg3DEN" >> "Attributes" >> "Skill" >> "Controls" >> "Value" >> "sliderRange") apply { _x*10 }; [2,10] Would it be possible to include something like this or does it seem like going too far with compatibility? Thanks.

Has anything changed recently with CfgAISkill? It seems to "work", but the interpolation is no longer based on a simple linear function, ie. with {0,0,1,1} I'm getting (which stays similar across different Y ranges, https://docs.google.com/spreadsheets/d/1GDzxZpVa1IDFP9GAeHUVrKIiGqKR5jv68qvE-0JhMQ0/pubhtml?gid=980503731&single=true ). The wiki ( https://community.bistudio.com/wiki/CfgAISkill ) also mentions however I was unable to figure out how, using ie. {0,0.5,1, 0,0.2,1} (extending the {w, x, y, z} example from the wiki) seems to produce spurious curves. Is there now any way to change the curve shape? Otherwise it doesn't seem possible to have skillFinal at skill 0.5 lower than 0.75 without reducing the maximum (at 1.0). Thanks. (Tested with skillAI=1 and precisionAI=1.)

I think the question was more about fixing/improving 64-bit side of things. For example my game still blackscreens and freezes randomly if I don't have a gigantic pagefile, despite me having 32GB of RAM and Arma using at most 9GB of it, it still needs pagefile for some weird reason, otherwise DX11 OOM error gets logged into RPT.

Is it just me or are "External Apps" arguments ignored when launching bat files? When running a simple echo %* manually, I get C:\Users\user\Desktop>testme.bat 1 2 3 C:\Users\user\Desktop>echo 1 2 3 1 2 3 C:\Users\user\Desktop> whereas arma3sync starts it without arguments: C:\Program Files (x86)\ArmA3Sync>echo ECHO is on. C:\Program Files (x86)\ArmA3Sync> despite those being present in the GUI configuration. It also doesn't seem to run the script if it has a space in its path. Build v1.6.91. Thanks.

(In case you're not aware, Github allows you to upload any files when making a "release" via their web interface, so you don't need to store binary PBOs in the repository itself while having only PBOs in the release - that's how ie. ACE3 does it.)

Hello, it seems that Ares_fnc_ShowChooseDialog is corrupting private variables. This is nothing new (was in original Ares), but in Achilles, it also includes "_pos", which I quite commonly use for ie. [ "test", "test", { params ["_pos", "_unit"]; // _pos valid private _res = [...] call Ares_fnc_ShowChooseDialog; // _pos corrupted } ] call Ares_fnc_RegisterCustomModule; so I was wondering if you could please make the variables in Ares_fnc_ShowChooseDialog private, so the corruption/modification doesn't happen. Thanks!

I assume so, I haven't set it explicitly, but that's what they default to when under fire. I'm not sure if / how long they retain it after shooting stops, but the screenshots above were taken ~8 minutes after shooting stopped (they stuck together for about a minute and then went off like this). edit: Just tested it with disabled AUTOCOMBAT (so I could keep Aware/Combat a.k.a. YELLOW/RED consistent) and it seems to be happening for both YELLOW and RED.

Yes, I'm using 1.0. By "squad splitting" I mean situations like these - http://imgur.com/a/8o3eF which can get even worse when the group(s) are originally on a patrol path.