Jump to content

Freghar

Member
  • Content Count

    142
  • Joined

  • Last visited

  • Medals

Posts posted by Freghar


  1. 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".

     


  2. 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!

    • Like 1

  3. Note that I may have found the culprit:

    Quote

    DCScream (7)

    Scream heard (a non-head hit produces scream, useful to detect a silenced weapon attacks)

    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.

    • Like 2

  4. 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.

    • Like 2

  5. 7 hours ago, Dedmen said:

    You should really test this without mods.

    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.

    • Like 1

  6. 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!

    • Like 4
    • Thanks 1

  7. (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.


  8. 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

    erfYIzb.png

    (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

     

    Quote

    More than 2 pairs of defining values can be used (minimum is 2 pairs).

     

    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.)


  9. On 17. 5. 2017 at 3:17 PM, heavygunner said:

    Well, if there is a bug it will be fixex, aside from that I assume we won't see changes.

    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.


  10. 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.


  11. (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.)


  12. 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!


  13. 33 minutes ago, Robalo said:

    Once combat starts they don't care much about keeping formation. That's vanilla behavior. Are you using combat mode RED ?

    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.


  14. On 23. 1. 2017 at 1:04 PM, Robalo said:

    Version 1.0 should have improved thigs a lot in that regard. Are you using it ?

    By squad splitting, since I did not implement such thing, I think you mean AI leader sending units to attack/flank - that's engine controlled, automatic.

    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.


  15. My current workaround is hooking onSelectionChange and setting a custom variable on each "processed" unit, ignoring them on next selection change. A global variable (list) would be more efficient, but it doesn't get reset on ie. loading a scenario, starting a new scenario, etc., so per-object variables are safer. The only downside is that on a scenario load, any first selection processes all units all over again - this is fine for my use case, but might be unwanted for others.

     

    Still, it would be great if there was an easier way (without using CBA XEHs, etc.).


  16. Hello,

    I know there are Eden EventHandlers, https://community.bistudio.com/wiki/Arma_3:_Event_Handlers:_Eden_Editor , but they oddly seem to be missing the most basic EH I would think of - placing an object (unit). The page mentions "Object Event Handlers" and even the text for RegisteredToWorld3DEN seems promising, but I don't know how to add it to a non-existent object (which hasn't yet been placed) and passing RegisteredToWorld3DEN to add3DENEventHandler doesn't seem to do anything.

     

    Does anybody know how to execute a piece of code when (any) object/unit is placed in Eden, without having the object beforehand?

     

    Thanks.


  17. On 16. 1. 2017 at 4:45 AM, O.Languedoc said:

    I think ASR is in conflict with most garrison command from other mods like ares & ace & mcc. When it starts shooting, people in buildings & guard tower are all moving around. Even the sniper on the roof.. Sometime it's hard to keep everything under control. For me it's the only anoying part of this mod. It would be great to have some basic ASR waypoints. 

     

    There are at least two ways to keep units on the spot, forceSpeed 0 or disableAI "PATH". The former is much older, so it was/is used by various garrisoning scripts. Both seem to work fine with the latest ASR AI.

     

    A bigger problem is what I call "capturing a base, the ASR AI way",

    1. have a fully occupied base, with patrols, waypoints, etc.
    2. go on a nearby hill
    3. shoot a few bullets at the base
    4. retreat, loop around the base
    5. wait 20-30 minutes
    6. walk into an empty base

    Where vanilla AI mostly stays in formations where you last put them, ASR AI is much more aggressive in pursuing the threat, splitting squads and running away from waypoints. I don't know what would "fix" it though, maybe some checking for GUARD waypoint type? Or whether a group has a set WP loop (CYCLE)? The squad splitting is also an issue, because it makes ie. a squad of 10 players encounter the enemies one-by-one, not presenting much challenge.

     

    Despite that, the positives still outweigh the above (for me).

    • Like 4

  18. Hello,

    since attachTo seems to change the coordinate space for setVectorDirAndUp (at least) to be relative to the parent vehicle's direction/up (http://killzonekid.com/arma-scripting-tutorials-attachto-and-setvectordirandup/), how would one go about attaching an object, but keeping its direction/up unchanged w.r.t. global world dir/up?

     

    In other words, how to cancel out the dir/up rotation caused by attachTo?

     

    I tried something like

    /* target: object I'm attaching to, source: object I want to attach */
    private _dir = (vectorDir _source vectorDiff vectorDir _target);
    private _up = (vectorUp _source vectorDiff vectorUp _target);
    _source attachTo [_target];
    _source setVectorDirAndUp [_dir, _up];

    the idea being that I can substract the target's absolute dir/up from the source's dir/up to get a relative dir/up between the target and the source, to be used after attachTo.

    However it doesn't seem to work as the source object just becomes flipped on its side, for some reason.

     

    Can anybody please see what I missed?

     

    Thanks.


  19. On 12/26/2016 at 5:42 PM, Devastator_cm said:

    Hi Robalo,

    I have one suggestion for future if you would like to consider :)
    Can you send the soldiers back to their original position after they disengage? Maybe even setting back their animations if they had any?

    For example, I have a soldier at guard post and I set the watch combat animation. During firefight he leaves his post but after all finished he stays in some other place 

    This is IMO one of the biggest AI problems of Arma 3 - once an AI unit acquires a target, it can never let go. If you look at the "reveal" command, you cannot make a unit "forget" about enemy units/players ("knowsAbout" will always be >0), you cannot ever make it go back to SAFE and resume a previous patrol, the engine just doesn't allow it. Or is the state simply stored in an FSM?

     

    Even if you come up with a mix of disableAI commands that work (and I did break the AI completely using it in a specific algorithm, by deadlocking the FSM) and make a unit retreat away from the enemy, the knowledge never disappears and the unit always switches back to AWARE, unable to calmly patrol in SAFE.

     

    Anyway, probably not something ASR AI can fix.


  20. If "64bit" means switching from i386 to amd64 a.k.a. x86_64 (as an architecture) and assuming most of the engine is written in C/C++, there could be also microoptimization speedups, like ie. the Apache web server had (~10%) due to the extra CPU registers available. Even though you generally waste them on bigger addresses, modern compilers are smart enough to optimize some operations (using ie. 2x eax instead of 1x rax), resulting in less memory or even cache access. Add SIMD extensions to the mix and you can get some decent (~10%) speedup, even ignoring any memory-related benefits.

    It's questionable though, how well the limited compiler in MSVS (compared to llvm/clang or gcc) can do this.

    Of course, it's possible that the engine has been using this for years via hand-optimized assembly or that the code is too obscure and un-optimizable (ie. type punning), so we'll have to see.

    • Like 1

  21. That's probably the case Robalo, but I still feel blaming you directly, for what was the result of a debinarization error, was definitely unfair. It's one thing to say "the rails on the import G36's are gone, is this intentional" and another to say "the rails on the import G36's are gone, that ASDG guy must have removed them because he doesn't know any better"

    Please thread carefuly around this - don't assume the worst possible case by default. This may create a false impression of the other side, which might get unintentionally reinforced by something else and suddenly you get a full-scale flamewar on your hands out of a simple misunderstanding and the evil-by-default principle. Not saying that is(n't) the case here, just that most people aren't "dicks".

    I do OS kernel development (substitute any technical work here) and a cool-headed friendly bit of sarcasm as a reply to a false claim works much better. :) (Generally.)

    • Like 1

  22. thanks, implemented for next release

    Thanks, probably useful for mountain/old/other bikes as well.

    There's a scripting error on engine on/off a Tractor,

    12:57:15 Error in expression <_if(_this select 1)then{_this call RDS_fnc_>
    12:57:15   Error position: <(_this select 1)then{_this call RDS_fnc_>
    12:57:15   Error Missing ;
    
    Also, I managed to finally reproduce the crash after spawning lots of assets, but only on the server (no RPT log at this time, sorry, it's a new server). Will try to get more info.

  23. Cannot reproduce it on a dedicated server, spawning via Zeus (civilians/vehicles), downloaded via the MEGA link.

     

    $ md5sum *
    ac085c4aa5f55507767beee2befaa4ba *rds_a2port_civ.pbo
    556f7845259a062c99b3a7682eddad22 *rds_a2port_civ.pbo.RDS.bisign
    7f2e7cdd0efb30dd0169ce7f86212faa *rds_a2port_cman.pbo
    4d14ca42d3a09fdb3d690c53c85522ea *rds_a2port_cman.pbo.RDS.bisign
    
    $ sha1sum *
    a3e7e971942034bc3c5378e58b7c60d8ee6a5026 *rds_a2port_civ.pbo
    cc07740a190e69f7b421980de4b2b9f1d148dcd4 *rds_a2port_civ.pbo.RDS.bisign
    c696b3db7e1f4305824f87f62030b823ed7907b4 *rds_a2port_cman.pbo
    13bd75c0bc8d4540e784c9d8ad164594deb94265 *rds_a2port_cman.pbo.RDS.bisign
    
    (Maybe double check that you don't have corrupted PBOs.)
×