Results 1 to 6 of 6

Thread: How to check if group is attacked?

Hybrid View

  1. #1

    How to check if group is attacked?

    I have a dynamically created group, that is controlled by an fsm.

    What would be the simpliest way of making an "is group attacked?" condition?

    My closest bet is the "findNearestEnemy" command: if it returns something, there is an enemy near.
    But this won't tell if my group has been attacked already, or just spotted an enemy.

    I would need a condition, that returns true, if the group is attacked: that is shots have been fired upon them.

    I guess it is not that hard, since the engine knows this, I just can't figure it out how.

  2. #2
    Have a look at these two functions I've written for my RUBE library.
    That might give you some ideas (or maybe they're already fine for your purposes):

    fn_getEnemyContact.sqf:
    Spoiler:


    fn_isEngaging.sqf
    Spoiler:
    scripting: RUBE library | missions: RUBE Fire Ants (SP)

  3. #3
    Gunnery Sergeant zapat's Avatar
    Join Date
    Mar 1 2010
    Location
    Hungary
    Posts
    440
    Author of the Thread
    Thanks Rübe, I've seen these: I thought there is an easier one though, and the first script doesn't tell if they are attacked or not either.
    This would go to an FSM condition, with like 4-5 other conditions, run on around 20ish number of groups all the time. So light-weight is essential.

    Although I like the engaged script: if the group is attacked, they fire back, right? So I guess I can get a working method by a simple currentCommand check. A bit of delay (between being attacked and really firing back) is tolerable.

  4. #4
    Quote Originally Posted by zapat View Post
    This would go to an FSM condition, with like 4-5 other conditions, run on around 20ish number of groups all the time. So light-weight is essential.
    Well, then maybe it's time to restructure the flow of your fsm. Do one check after another and break that flow of checks if one of them fires/triggers...

    Another strategy is to have an ideling delay-loop (lowest priority on the main-loop) with a delay-condition (time - _t > _delay) as only way back to the main-loop, so all the "heavy" checks are only run all 2 or 3 seconds (or even more and maybe slightly randomised).
    Not everything needs to react immediately and often such delayed reactions are absolutely fine. Maybe you need to run two fsm, one without and one with such delays, though there comes an overhead with this, so I'm not sure this would be actually a good idea... haha

    But I wouldn't worry too much about performance until you actually see a problem.

  5. #5
    Gunnery Sergeant zapat's Avatar
    Join Date
    Mar 1 2010
    Location
    Hungary
    Posts
    440
    Author of the Thread
    Quote Originally Posted by ruebe View Post
    Do one check after another and break that flow of checks if one of them fires/triggers...
    This is why I love to ask questions in the forums! This is a cool thing, and it is highly probable that I would have never thought of this simple idea. Time to reFSMize my mission!!

    Demoinzed: yeah, this could be a good method too, I may combine them...
    Last edited by zapat; Aug 16 2011 at 17:03.

  6. #6
    Warrant Officer Demonized's Avatar
    Join Date
    Nov 16 2010
    Location
    Back from afk 2013
    Posts
    2,614
    Another way is to check combat mode:

    AI groups change to beheaviour mode once they are engaged, and revert to original mode once "safe"
    If unit is in aware by default, its most likely being engaged or engaging if its in combat mode.
    This check will ofc fail if units move around in default combat mode.

    Code:
    if ((beheaviour groupname) == "COMBAT") then {hint "group is in combat"};
    Above is sqf and not fsm, but you probably know the equivalent to fsm.

    Edit: brainfart resulted in me typing combatmode and linking to that, but i meant ofc beheaviour mode to be combat. above fixed...
    Last edited by Demonized; Aug 16 2011 at 17:19. Reason: edit.
    My scripts:
    Spoiler:

    what to do when posting any kind of code dammit!!

    Any new mission editor or scripter in Arma2 should have read Mr Murrays Editing Guide Deluxe at least once, it still applies for A2 even though it was made for Armed Assault.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •