Jump to content

royaltyinexile

Former Developer
  • Content Count

    778
  • Joined

  • Last visited

  • Medals

Posts posted by royaltyinexile


  1. I can confirm this is the behaviour. When they lose LOS with the player, they plan a waypoint to the next coverpoint. (a sandbag or whatever). If they turn the corner, and player is there, they're still moving to the cover point before engaging the target.

    The AI is limited sometimes, but other times it really does impress me. Its often the disconnect between it making the right strategic moves and some of the limitations up close that really may break the experience.

    Take this repro mission for example, which produced this behaviour:

    JAC_AI_PREV_1.jpg

    • At the start of the mission, I reveal myself to the enemy by moving up and shooting off a few rounds by their feet
    • I Move back into cover and wait
    • The commander will (most of the time) set up a flanking attack, where he sends the rest of his fire team around the building.
    • He maintains cover on my last known position, ready to blow my head off
    • Little by little, he advances around the corner to check if I'm there
    • He starts shooting quite quickly once he spots me, and I have to turn and kill him

    Then.. it goes a bit wrong. :o

    JAC_AI_PREV_2.jpg

    This is all non-deterministic behaviour based on decision making under uncertain conditions, which is hard to get right. The fact the AI is capable of making the choice to plan an attack based on the information they discover demonstrates the strengths of our AI.

    The trouble is in the execution stage, where the clunky planning creates situation where the AI will prefer to finish getting to a coverpoint before engaging the threat (you). This leads to the silly looking video posted earlier in the thread, and a generally accepted narrative that 'the AI is dumb'.

    However, that analysis doesn't consider range. If the AI is told to move to a cover point, and he spots an enemy target, say, 300m away, the best choice would be to get to the cover, and fire from this position. The AI shouldn't always break from their path because they spot an enemy in this case. In CQB, the priorities change, if the enemy is 5 meters from you, it makes no sense to move another 10 meters to get into cover before moving.

    Since the majority of engagements in Arma are not CQB, the AI will more often than not make the 'correct decision'. The question is whether it is feasible to introduce an (engine-based) decision about moving to coverpoints based on the distance to target; e.g:

    [table=width: 500, class: grid]

    [tr]

    [td]Range[/td]

    [td]Priority[/td]

    [/tr]

    [tr]

    [td]<25m[/td]

    [td]Engage Target[/td]

    [/tr]

    [tr]

    [td]>25m[/td]

    [td]Move to Coverpoint[/td]

    [/tr]

    [/table]

    I'd also add that fleeing behaviour greatly affects the impression of the AI. In the repro mission, if I kill two of the fireteam, the remainder will flee. When fleeing, they completely ignore the player, meaning that even if I shoot at/around an AI - even run with one holding hands while fleeing - they will not choose to engage me.

    Anyway, we have something concrete to take to our programmers. There's absolutely no promises, but at least we can isolate behaviours and suggest a way forward.

    Isn't it beer o'clock in Cz?;-)

    You know, I do believe it is.

    Best,

    RiE


  2. The problem seems to be the proximity thing and not prioritising shooting at a seen enemy above all else. As Azzur33 noted - "The problem: one of them just went in front of me, seeing me, then run further trying to get behind the sandbags, which I generously allowed.

    The one flanking me from behind, did the same, instead of shooting me while he had the chance, he went searching for cover from the sandbags, then tried to sneak closer, and died." Seen exactly the same behaviour.

    Anyway - keep it improving please!

    I can confirm this is the behaviour. When they lose LOS with the player, they plan a waypoint to the next coverpoint. (a sandbag or whatever). If they turn the corner, and player is there, they're still moving to the cover point before engaging the target.

    An additional problem is, if I kill, say, two guys in a fireteam, the group does appear to flee. When they're fleeing, with a move order, they also aren't engaging the player as one might expect in real life. Both of these issue (which are somehow the same root issue) are readily seen on the video in this thread.

    So, we can chat with the programmers on monday about it and consider what would be possible to do in these situations.

    Best,

    RiE


  3. ...And in the interests of getting back on topic, let's dive face-first into that horrific video :)

    .

    One thing that is actually good in the video is that, at around 14s, the AI react quickly and try to shoot the player. It's actually going well up to this point. Without actually debugging the values, I'd guess that:

    1. The AI heard the player approaching
    2. Fired when they knew that the target was an enemy
    3. Continued to fire where they 'guess' they player was, after they lost line of sight
    4. Take out their pistols when they know it's a CQB situation*

    One way or another, all 'as designed' so far. It starts to get real ugly when they move and engage. We'll try to get a clean repro of this problem. We've tried to repeat the situation internally, in case you missed the post:

    I tried the exact same setup (except the waypoint directly on the group leader, that may cause some issues on its own) and the result was pretty much the same as yours. BUT. The AI had quite low AI skill setting. Raising it to 1 made them flank the building and shoot me from behind, while 3 guys guarded their side of the building, holding their ground and opening fire as soon as I turned the corner. [emphasis mine]

    1. Turn speed. You are still able to follow an AI who can't shoot at you.

    2. Flee conditions. Sometimes AI refuses to shoot at you, sometimes even running away. Is it flee? If so, make it drop the weapon or an explicit surrender animation. Else make it shoot.

    3. Gunshot/sounds detection - they don't care if you shoot behind them, they don't turn around to check sometimes. If you shoot after corner they get past the corner not looking.

    4. Cover detection - related to enemy direction.

    I think AFP is right in highlighting these four issues and, again, if we can get a clean repro of each that demonstrates the behaviour, we can debug that and find out what's going wrong.

    We can 'design' AI behaviour in the abstract, at the descriptive level (the given that general situation, the ai should usually react like this'), but we need to debug what's actually going on (these specific inputs resulted in this set of actions).

    Bring a programmer a story, his eyes will glaze over; bring him a repro, he can try to teach the AI correct behaviour.

    Damn... really tried to insert 'fish' into that sentence. :cool:

    Best,

    RiE

    *which you might disagree with, but it's a simple config value, which determines if and when they'll switch to the side arm - making that a data issue, rather than a program one (hello, Task Force Balance


  4. Just a quick note. It really helps us in this thread when you provide considered feedback to the changes in progress, or clean repros missions that highlight some repeatable AI behaviour.

    Our programmers tend to get lost when the discussions trail off into other areas, like headless client, etc. This thread can't both function as a place for feature requests and discussion and as a place to discuss the active development. It's one or the other, gents, and I'd like to be able to pass as much useful info to our guys as possible! :)

    Anyway, I'd also like to thank you guys that have provided feedback and repros (beyond those examples I've linked to above). When we get this balance right, we can really make modest refinements that improve AI behaviour.

    Best,

    RiE


  5. Thanks, I was just getting confused about the various Optics settings. I have defaulted my keys back and now I understand how it works. Thanks for the help

    T

    The Field Manual is also a good resource in these cases.

    I do believe that we added an entry specifically about optics mode following some feedback during the alpha.

    Best,

    RiE


  6. Ignore my puny ramblings...

    For example, AP rounds should probably technically perhaps not penetrate frontal armour/turrets of IFVs, but may penetrate the sides (and then not exit through the other side).

    ...our Top Dentist speaks the official word on this matter:

    You'll find yourself incapable of penetrating side armor of AMV even with standard 12.7 rounds. You'd need at least 12.7 sabot to pierce through the side armor, and depending on angle frontal armor would also be able to deal with 30mm sabots.

    The turret is much less capable of stopping bullets. You'll see yourself being capable of penetrating it with anything better than Zafir, except the front armor which is sloped quite much and should provide better protection.

    The Marid has remote controlled turret, that means you'll have to penetrate hull armor to kill the crew and passengers. Still possible with heavy sniper rounds.

    Panther armor is so thick you'll find yourself in trouble trying to penetrate it even with tank cannons, though this depends on angle ;)

    Kamysh armor is not better than AMV and Marid, but its enormous agility and maneuverability gives you chance to utilize the vehicle more tactically.

    Dev tags inbound.

    Best,

    RiE


    • Decreased use of prone stance when target is close.
    • Decreased use of crouch stance when moving
    • Decreased use of crouch stance in stealth

    These adjustments should:

    decrease the AI's use of crouching/prone while moving in combat. They'll be more likely to crouch when they're static in combat (not deterministic, just a more likely behaviour), and shouldn't go prone if enemy target is known and very close*.


  7. RiE and other Devs - do we have any ETA for fixing the "If it's Combat I'm a crawling" AI issue?

    I can't be entirely sure which build, but some work in the pipeline (i.e. not in current dev branch).

    Dr. Hladik intends to ...

    decrease the AI's use of crouching/prone while moving in combat. They'll be more likely to crouch when they're static in combat (not deterministic, just a more likely behaviour), and shouldn't go prone if enemy target is known and very close*.

    One 'limitation' is that if a bullet hits the ground near/ is fired nearby AI, and they don't know where the shooter is/if it's a threat, they're still likely to choose to go prone (find source, evaluate threat).

    Perhaps the ideal state would be that when shots are fired they quickly move to cover (more organic response, harder to wipe out groups), but 1) this is actually a completely different issue to the above, and 2) there are some technical challenges (some of which are related to data; for example, in an open field with rocks around them, AI may not be able to compute rocks as cover properly, due to size/rotation of models).

    Perhaps it will make it into the exe tomorrow, but we'll have to test it first, so no promises. :)

    Best,

    RiE

    * i.e. If you put yourself in the editor facing the enemy**, depending on your range, they should choose to shoot you before changing stance (unless you are further away, in which case they may choose to take a knee).

    ** If you start behind them and jsut start shooting, they're likely to go prone first until they know whether the shots fired are a threat/where the threat is.


  8. MP wise it would be a great laugh

    still be interesting if a dev (RIE?) could specify if it was do able or if there was someway they could implement something that could make it do-able.

    :D

    It's already possible. A notable example is the FDF mod that make epic

    .

    However, it's not at all a simple process and the new pipeline we've created for splendidisingâ„¢ the protocol isn't particularly community friendly at the moment.

    Anyway, let's keep this thread on track. :)

    On a semi related note, I've noticed the latest dev build 108432 has all friendly units yelling "Do not fire!" twice if you shoot them.

    Yes, we were missing a "ceasefire" for units in combat mode from our original four actors. Not sure about saying it twice :confused:. But, come to think of it, we do have a combat shout that would probably be more appropriate ("check your goddamn fire"). Will prod our Audio Lead when he has a spare second (he currently has -9000 spare seconds).

    Fire geometry is considered WIP, our Top Dentist is working splendidly on it. Still need to address issues of projectiles penetrating but not exiting/only penetrating the correct places (i.e. not frontal/turret armour).

    If these issues can be solved (hello, disclaimer), you'll be the

    . :cool:

    We should see some splendid progress by our Top Dentist on this feature in today's build, REF:

    • Improved penetration model of Marid / Marshall

    For example, AP rounds should probably technically perhaps not penetrate frontal armour/turrets of IFVs, but may penetrate the sides (and then not exit through the other side).

    Best,

    RiE


  9. So how much of the current state is supposed to be a placeholder that can be mass-replaced like radio protocols like you previously mentioned in the thread, and what exactly is unfinished about the current system?

    It's not comparable. Radio protocol structure is 'final', it's drag and drop of data to extend it (ok, also few rogue programmer-dependent tweaks, too).

    Capacity is more of a moving target that needs to be carefully tested, and one of our designers has this assigned as his current task. Making him the official Senior Cat Herder atm.

    I'd find it difficult to estimate how many cats he's herded so far - and how many might have escaped - but I trust that it is at least moving in the right direction.

    Best,

    RiE


  10. also when changing voice in profile. does not work in game.

    Yup, known issue. Waits on program fixes, unfortunately.

    type 01 and type 05 are the same

    type 02 and type 06 are the same

    type 04 and type 08 are the same

    when can we expect more speaker voices from like the UK and other regions??

    The data is currently duplicated so that we have the structure in place, and we just need to mass-replace when the samples are prepared.

    We've got 4 new US and 3 new Euro voices in the pipeline, in addition to the first Euro voice in game now.

    I would not expect to have any new UK in the release (aside from Male00) :cool:

    Best,

    RiE


  11. BIS are you going to change increased error of AI crouching and crawling all the time while in combat? I can't stand that. Playing this game is not fun for me anymore because of current AI.

    There was an initial change that increased chance of prone and crouch generally, but then an update which modified this behaviour so that they're mainly selecting prone when in stealth mode.

    I'll dig out some revisions via Dr Hladik, but the current goal/target state is to have AI taking crouch/prone while stationary and under fire (so that they are more difficult to hit), but not doing this when moving to cover or given a movement waypoint (so that they remain mobile).

    Notice how the current really doesn't take into account how close the enemy is (from my observations)

    As Coulum correctly points out, the AI do not currently take distance of enemy into account when selecting stances when moving/moving to cover. However, it should be possible to change this behaviour, and tweak the values so that when enemies are closer, e.g. CQB, they are less likely to go prone.

    Dr. Hladik is a bit busy fixing some crash opportunities atm, but he'll take another look at the state when he gets a chance.

    Best,

    RiE


  12. Can we get some parentheses or a more specific formula? :D

    Indeed, I hoped to offer a general description of the behaviour, rather than a precise formula. That being said, the random value is a multiplier applied to both x and y coordinates.

    I could dig out a more precise formula, but feedback on the behaviour in game will generally will be more useful to our programmers, who should better know how best to adjust values based on feedback to actual situations.

    I wonder why this is only done when one of the team was killed.

    Apologies, this also applies to when they're hit or bullets impact close to AI Units. Community reports mostly were dealing with kill repros. Updated Changelog info.

    How is this handled when a member of the group is killed through a satchel charge ? Same information about the killer ?

    No, this is handled in a similar way to the AI discovering a dead body.

    As they have 0 visibility of shooting, AI takes random position around explosion spotter (they will check surroundings, default error used is 200m)

    Best,

    RiE


  13. Change log notes, v.08339

    Increased error of player position, when AI is killed by player

    If you kill/hit/bullet impact close to an AI unit, your position is disclosed with some error. Now the error is bigger and based on range, so it is harder for the AI to find you after one shot.

    So, if I fire from, say, 300m away, AI's guess of my x, y position is based on a default guess error (of 100m) plus my distance (300m) multiplied by a coefficient (0.25), plus a random value (between 0 and 1, applied to x and y).

    This individual calculation doesn't currently factor in my weapon type, but my visibility remains a product of that, so - if I've used, say, an enormous sniper rifle instead of an smg - the AI is more likely to spot me, when looking in the right place.


  14. Yup, it's a fair point - what' we've done is hijack strings that already exist in the database, as we have some constraints about creating new ones at the moment.

    I'll note it down in the feedback and the great gods of localization shall make their decree.

    Best,

    RiE


  15. It would make a lot of sense for the target menu to use the same info and be consistent with the protocol report; i.e., [type] - [cardinal direction] - [distance].

    Update: we managed to sneak in a quick 'fix', which at least enables players to tell the differences between targets in terms of distance.

    target_menu.jpg

    We didn't have a whole bunch of time to invest more in the feature, but the basic behaviour is that each time the menu is opened, the distance/direction values will update (i.e. it will not update while the menu is open).

    Best,

    RiE


  16. 29-07-2013

    EXE rev. 08296

    Size: ~227 MB

    • ADDED: Distances added to target and get in menu
    • FIX: Fixed disappearing of objects viewed through the open doors when inside the buildings
    • FIX: AI and rangefinding: ballistic prediction
    • FIX: Tweaked flight model of all helicopters
    • FIX: fixed and improved UH80 lights
    • FIX: playback speed of ladder animations matched to vertical movement speed
    • FIX: CSAT technicians have loaded correct colour of tracers into Kamysh
    • FIX: Typo in few values in building destruction smoke
    • FIX: Color of dust in mortar fire effect tweaked
    • FIX: Grass parts in the tracked vehicle dust effect tweaked
    • ADDED: Vehicle weapons empty cases on medium particle quality
    • ADDED: Respawn loadouts in CfgRespawnInventory are no longer conditioned based on 'show' parameter. Instead, new functions BIS_fnc_addRespawnInventory and BIS_fnc_removeRespawnInventory are added to manage the loadouts in the same way as respawn positions are handled
    • FIX: Vehicles marked as respawn points using "Respawn Position" module were not recognized upon mission start
    • FIX: BIS_fnc_respawnTickets sometimes didn't update the value correctly and caused too large network load
    • FIX: Wrong hint class used in Showcase: Scuba
    • FIX: undefined variable error when engaging the spotters in Showcase: Infantry
    • FIX: no artillery rounds were hitting the village at the end of the mission in Showcase: Infantry
    • FIX: Various tweaks in Showcase: Vehicles: more sunlight, exfil task position, player can get in the boat before his driver now
    • FIX: Mission fail is now reliable in more situations in Escape from Stratis
    • FIX: Various issues with tasks in MP missions on dedicated server
    • FIX: Fixed missing name in MP lobby. (Headhunters, Escape from Stratis)
    • ADDED: Corpse removal for Escape from Stratis
    • FIX: Changed: Showcase: Supports should end a bit sooner now
    • ADDED: Added: "Defend" mission type (used for example in "Defend Kamino") is now using unified sectors. Mission ends when enemy side holds all sectors on the map.
    • FIX: CoF Green: Switched to plain version Mk. 20
    • FIX: Quadbike has been naughty and got some driving model improvements
    • FIX: Co-driver of HEMTT is no longer a designated role
    • FIX: Silenced Scorpion has correct fire modes
    • ADDED: Launcher magazines now display their purpose in GUI to make the right choice of magazines
    • FIX: Dust effects for community made airplanes are no longer under the terain
    • FIX: Tracked APCs were called "tank" in radio protocol
    • FIX: louder sounds for characters
    • ADDED: New respawn inventory system for Defend: Kamino
    • FIX: Small glitch in texture fixed
    • FIX: Thistles have different model
    • FIX: Trunk textures of some trees have been tweaked
    • FIX: Adjusted sounds for offroad
    • FIX: HEMTT and Zamaks have better cargo poses
    • ADDED: Player's name to respawn menu
    • FIX: Mk.20 magazine has now correct shadows
    • FIX: Change physx vehicle wheel radius collision
    • Firing Drills Changespam:
      (Someone is just showing off)
      • FIX: Firing Drills: 3D CP indicators now scale and alternate color to attract attention
      • FIX: Firing Drills: CP center, area and shooting box markers implemented

        • Training: CPs always shown
        • Competitive: previously activated and first next CP shown only
        • Cleared CPs indicated

        [*]FIX: Firing Drills: Target markers implemented

        • Training: always shown
        • Competitive: active CP targets shown
        • Post-completion: always shown for both rule sets as AAR
        • Normal, no-shoot and bonus targets indicated
        • Hit and missed targets indicated

        [*]FIX: Firing Drills: Systems now terminate on competitor death (impressive achievement!)

        [*]FIX: Firing Drills: Fixed broken hint in CoF: Orange

        [*]ADDED: Firing Drills: Competitors are healed with every reset / restart

        [*]ADDED: Firing Drills: CoFs now select the correct default weapon with every reset / restart

        [*]FIX: Firing Drills: Competitor weapons were not properly reset when more weapon types were available during the CoF

        [*]FIX: Fixed undefined variable in CoF: Blue

        [*]FIX: Fixed undefined variable in CoF: Green

        [*]ADDED: Firing Drills: FM records with introduction, rules and tips added

        [*]ADDED: Firing Drills: bonus & penalty logic between Training and Competitive made consistent

        [*]ADDED: Firing Drills: first version of PiP feedback added for accuracy targets (currently for all)

        [*]FIX: Firing Drills: Restarting within a CP would leave the IGUI element active

        [*]FIX: Firing Drills: Medal icon sometimes shown using Training rules

        [*]FIX: Firing Drills: Now using symbology on selector targets

        [*]ADDED: Firing Drills: Ability to immediately quit at the end of CoFs added

        [*]ADDED: Firing Drills: Added audio cue when going over the next medal time

        [*]FIX: Firing Drills: Conversations all switched to radio again

        [*]FIX: Firing Drills: CP briefing target box now follow different logic: top value (targets remaining) and bottom value (bonuses remaining, if any)

    :icon_twisted:

    I'm stuck in traffic

    Read: Heading down the

    that leads to Brno's door.

  17. ... detailed feedback ...

    Thanks for the great feedback. I'll ping Vespa (if he's not already stalking these forums) :)

    Now I'm assuming this is a new set of geometry for infantry collision and it applies to both pistols and rifles.

    Ah, actually, I believe it's only for rifles; pistols represent the old state. I thought I'd disclaimed that somewhere .. my disclaimer firehose must be dry. Ach, it's a hot summer.

    :o Ok, you're right. But let's make a deal. When we say:

    "Oh hai guys! We just hopefully did something cool! Here you go! Enjoy!"

    I'd request at least 5 minute 'grace period', where you are not allowed to break it. Or even try to break it. At least, not tell me you've broken it. Or, hell, just use the secret code word: The Banana is Dancing in the Hot Summer Sun.

    After that 5 minutes is up.. hell, let rip. But give me that 5 minutes for the sanctity my soul. :D

    Best,

    RiE


  18. Making changes/refinements to AI doesn't just rely on programmers, but proper configuration of the data is also essential (what we call balancing).

    Recent tweaks of config values affecting vehicle handling are part of this work. Pre-Alpha, a certain set of config values were used, but as the game develops, so we must continue to refine things like predictTurnPlan and predictTurnSimul

    Drivers have gone to training lessons to improve their driving capabilities

    AI drivers are now able to better predict the way and expect turns in longer distance while still maintaining the momentum long enough.


  19. I don't see much difference except that now i can SHOOT THROUGH Panther with 30mm ap rounds(they enter from one side, exit from the other)

    Yes, crew inside armoured vehicles has the possibility of being hit by AP rounds.

    Fire geometry is considered WIP, our Top Dentist is working splendidly on it. Still need to address issues of projectiles penetrating but not exiting/only penetrating the correct places (i.e. not frontal/turret armour).

    If these issues can be solved (hello, disclaimer), you'll be the

    . :cool:

    Best,

    RiE

×