LAMBS Improved Danger.fsm

[Carlos Leung 0]

HI, How to force enable LAMBS Danger FSM enhanced behaviors using unit init?
 

[nkenny 1057]

@Disgusting_Man
I'll look into it. We have a version we use in nopryl.no that I could make public. 

@tyreyalv
I keep my skill settings at the default. As I have investigated elsewhere, I find the biggest difference being the weapon carried-- particularly when mods are compared to each other. On our server we run custom settings, but closely linked to 'veteran' or 'expert' settings. In the end it is a matter of preference. A cross-section of the deadliness of gameplay that you or your community want to have.  Arma3 settings are unfrotuantely rather opaque in this regard, so there is little other option than experimenting youself or trying one of the mods that specialise just in that regard. 🙂

-k 

[nkenny 1057]

@Carlos Leung
No configuration necessary. Mod runs automatically on all units. Even modded ones, provided they inherit from vanilla units.

-k 

[autigergrad 2034]

I just started testing LAMBS a few days ago and you have done outstanding work @nkenny  Really impressive stuff.  I just wanted to pass on some well deserved kudos and I'm definitely excited to see what future additions will hold.  Well done.

[nkenny 1057]

LAMBS Danger.fsm

New Release: Current version 2.4.0

Requires
CBA_A3 3.15.0 or later

 

Changelog

Added Port all Strings over to Stringtables so that they can get Localized
Added Vanilla EventHandler wrapper for all current Events
Added Nearby friendly fire check for Suppression with configurable setting
Added Nearby friendly fire check for vehicle suppression and assault functions
Added Maximum Reveal value setting
Added CBA Version dependency
Added Player only setting for Task Creep/Hunt/Rush (these modules can now hunt enemy AI)
Added SortByHeight, Teleport and Exit Condition setting to TaskGarrison
Added Teleport setting to TaskCamp
Added Remote compatibility to Task Assault/CQB/Camp/Creep/Garrison/Hunt/Patrol/Reset/Rush Zeus and Editor Modules
Added Rewrite of Task Artillery to make it multiplayer compatible
Added Various performance optimizations to danger FSM
Added Immediate Action state
Added fnc_immediateAction with smarter movement routines to avoiding fire
Added fnc_indoor to only recognize buildings
Added Units with ACE3 medical AI enabled will exit FSM
Added Tweaks to fine-adjust suppression position
Added Improvements to re-manning static weapons
Added fnc_leaderAssault, fnc_leaderFlank, fnc_leaderSuppress, and fnc_leaderGarrison*
Added fnc_leaderStaticDeploy, fnc_leaderStaticPack and fnc_leaderStaticFind (units will now dynamically deploy static weapons and more reliably man nearby ones)
Added fnc_doSmoke, fnc_doUGL (functions to throw smoke and shoot flares respectively)
Added FSM fix to prevent units from reacting to allied weapon fire
Added FSM reaction state will now only trigger on dangerous events**
Added FSM better support for ACE3 medical AI by delaying healing when unit is threatened by nearby gunfire or forced movement
Added FSM faster and more aggressive movement when 'forceMove' variable is enabled
Added units which call artillery will now attempt to use binoculars and stay in position to direct fire
Added settings to disable dynamic weapon deployment and remanning

 

Changed All number edit boxes in ZEUS Modules to sliders
Changed Module Artillery Dropdown to Side Selector
Changed Make use of CBA_fnc_getPos from CBA 3.15.0 update
Changed Moved various settings such as speed and search range from FSM to function for easier editing
Changed Increased threshold for doing suppression while suppressed from 0.5 to 0.75
Changed FSM priorities for bulletClose increased from 3 to 6
Changed fnc_fsmExitVariables to use fnc_isAlive
Changed Default settings for CQB range from 50 to 60
Changed Radio minimum range settings from 200 to 20 based on user input
Changed Gestures used to indicate initial reaction (from 'cease fire' to 'freeze')
Changed fnc_hideInside, reduced range units without cover would retreat from 45-110m to 10-55m
Changed Debug information variables are now global if `Debug Functions` setting is enabled

 

Fixed An issue with ShareInformation
Fixed That Task Creep/Rush didn't use user set Cycle Times
Fixed Error in fnc_vehicleSuppress (vehicles would fail to engage)
Fixed Assaulting units from occasionally looking into the ceiling
Fixed Global variable in suppression part of FSM (timeout)
Fixed Increased APC dismount range from 180 to 250 meters
Fixed Tightened range which units check for CQB buildings in CQB mode (No need to check out to 250 meters)
Fixed fnc_react - reaction state stances were reversed
Fixed fnc_suppress - override setting would also override intelligent target adjustment based on visibility
Fixed fnc_zoneMarker - marker is now created local only
Fixed FSM issues with doWatch and doLook
Fixed FSM leader state Contact! Now uses distinct gesture and collects troops better
Fixed FSM improved performance, moved more code to functions, and clarified priorities
Fixed move command in fnc_leaderFlank would override the current waypoint
Fixed Flying Waypoint in TaskGarrison
Fixed A possible issue with group counts overflowing max group limit with some taskX Modules/Waypoints

 

Removed fnc_leaderManoevure replaced by fnc_leaderFlank

 

Group Tactics

A big addition in this release is the introduction of a more extensive set of group level actions. These are called when the AI assesses that enemies are holding in garrisoned buildings or in otherwise weak tactical positions. The unit can respond in four ways: Flanking, suppressing, assaulting, or attempting to garrison its own or enemy building. The exact tactic being employed depends on the unit's own combat mode, available cover and distance to target. These new states replace the more limited fnc_leaderManoevure. 

Reaction state

The second major overhaul is how the AI will enter the reaction state: Units that expect enemy contact are less likely to flinch. By default they will now only enter a reaction state when the unit is hit, unit spots a new enemy, nearby explosion or bullet impact, seeing unit from their own group killed, hearing another unit being hit, or bullet whizzing by. Units set to  FULL speed mode or STEALTH behaviour will not trigger reaction and hiding responses.

Special thanks
The team would like to extend thanks to @BadGuy for help with adding User Interface elements, @R3vo for the German translations and @madrussian for spotting an error with waypoints being deleted.
 

Discord

Got questions, suggestions or other feedback? Come hang with the cool kids on our Discord. 

From the team:
diwako / joko / nkenny
 

--- 
STEAM Workshop

---
GitHub

---

Discord

[cpt.ghost 104]

lets dance 😄

[LSValmont 789]

2 hours ago, nkenny said:

Reaction state

The second major overhaul is how the AI will enter the reaction state: Units that expect enemy contact are less likely to flinch. By default they will now only enter a reaction state when the unit is hit, unit spots a new enemy, nearby explosion or bullet impact, seeing unit from their own group killed, hearing another unit being hit, or bullet whizzing by. Units set to  FULL speed mode or STEALTH behaviour will not trigger reaction and hiding responses.

From the team:
diwako / joko / nkenny

 

Congrats on what is a MAJOR release @nkenny @diwako joko!

 

May I ask how do you detect nearby bullet impacts?

 

PS: Updating my suppression and knowing new methods often improve performance ALOT.

 

Thank you!

 

[madrussian 347]

1 hour ago, LSValmont said:

May I ask how do you detect nearby bullet impacts?

 

PS: Updating my suppression and knowing new methods often improve performance ALOT.

 

Basically, by overriding the vanilla danger fsm, you get access to these extremely powerful and efficient Danger Causes:

 

Quote

1DCEnemyDetected (0)

2DCFire (1)

3DCHit (2)

4DCEnemyNear (3)

5DCExplosion (4)

6DCDeadBodyGroup (5)

7DCDeadBody (6)

8DCScream (7)

9DCCanFire (8)

 

Also:

Quote

10DCBulletClose (9) - Bullet whizzing close by

 

^ Based on my testing, DCExplosion detects nearby bullet impacts.  But if you override the danger fsm, you lose the (somewhat obscure) vanilla danger fsm functionality, so you might also then want/need to create your own AI mod.

 

That's why I advocate for Lambs team to pass all the "danger cause" info through for mission and mod creators.  There are many ways to accomplish this.  Imo, ideally it could be passed (optionally per unit) via BIS_fnc_CallScriptedEventHandler every time a new danger happens, so we can capture it via BIS_fnc_AddScriptedEventHandler.  Alternately, Lambs could provide continuous access to the fsm local _queue variable, which would then need to be preserved (otherwise not wiped out) somehow.
 

[LSValmont 789]

1 hour ago, madrussian said:

 

Basically, by overriding the vanilla danger fsm, you get access to these extremely powerful and efficient Danger Causes:

^ Based on my testing, DCExplosion detects nearby bullet impacts. 

 

Is there any way to intercept a unit's change in DCExplosion (4) via script?

[diwako 413]

33 minutes ago, madrussian said:

 

Basically, by overriding the vanilla danger fsm, you get access to these extremely powerful and efficient Danger Causes:

 

 

Also:

 

^ Based on my testing, DCExplosion detects nearby bullet impacts.  But if you override the danger fsm, you lose the (somewhat obscure) vanilla danger fsm functionality, so you might also then want/need to create your own AI mod.

 

That's why I advocate for Lambs team to pass all the "danger cause" info through for mission and mod creators.  There are many ways to accomplish this.  Imo, ideally it could be passed (optionally per unit) via BIS_fnc_CallScriptedEventHandler every time a new danger happens, so we can capture it via BIS_fnc_AddScriptedEventHandler.  Alternately, Lambs could provide continuous access to the fsm local _queue variable, which would then need to be preserved (otherwise not wiped out) somehow.
 

Funny you are mentioning BIS_fnc_AddScriptedEventHandler. We use those and CBA events, however currently not possible access the queue and danger causes at the moment.

https://github.com/nk3nny/LambsDanger/wiki/Event-handlers

[madrussian 347]

1 hour ago, diwako said:

Funny you are mentioning BIS_fnc_AddScriptedEventHandler. We use those and CBA events, however currently not possible access the queue and danger causes at the moment.

https://github.com/nk3nny/LambsDanger/wiki/Event-handlers

 

Thanks for the response, here's my take.

 

So obviously to you Lambs team guys (but not so obvious to non fsm-folks):  Danger causes are presented (for a particular unit) at the start of the fsm, and also via the _queue variable for use while the danger fsm is running.  Once danger fsm is running (on a particular unit), it cannot restart until the danger fsm completes.  Thus during this time (while danger fsm running), the only way to monitor new danger causes would be via that _queue variable.  Lambs regularly delays inside the danger fsm (via timeouts), so likewise any new danger happening during those times could only be monitored via the _queue variable.  But Lambs also regularly wipes out that _queue variable.  Thus the way Lambs is structured currently, we'd have to get creative to allow for continuous passthrough of danger causes.  How about this:

• Store _queue variable on the unit (optionally per unit), so we can monitor this array in real time (as whatever rate we wish).
• Anytime you go to delete the _queue, (also optionally) store what's getting deleted (also on the unit), so we don't miss anything.

Then we (mission creators & mod makers) can detect all those bullet impacts, whizzes, can fires, everything!  All while Lambs up and running (doing it's many things).

[diwako 413]

1 hour ago, madrussian said:

 

Thanks for the response, here's my take.

 

So obviously to you Lambs team guys (but not so obvious to non fsm-folks):  Danger causes are presented (for a particular unit) at the start of the fsm, and also via the _queue variable for use while the danger fsm is running.  Once danger fsm is running (on a particular unit), it cannot restart until the danger fsm completes.  Thus during this time (while danger fsm running), the only way to monitor new danger causes would be via that _queue variable.  Lambs regularly delays inside the danger fsm (via timeouts), so likewise any new danger happening during those times could only be monitored via the _queue variable.  But Lambs also regularly wipes out that _queue variable.  Thus the way Lambs is structured currently, we'd have to get creative to allow for continuous passthrough of danger causes.  How about this:

• Store _queue variable on the unit (optionally per unit), so we can monitor this array in real time (as whatever rate we wish).
• Anytime you go to delete the _queue, (also optionally) store what's getting deleted (also on the unit), so we don't miss anything.

Then we (mission creators & mod makers) can detect all those bullet impacts, whizzes, can fires, everything!  All while Lambs up and running (doing it's many things).

I do get teh sentiment. Still have have 2 events that might be helpful for mission makers. One is the "lambs_danger_OnContact" which is basically the even when a group goes into combat mod. The other is the "lambs_danger_OnAssess" event which can be used every time the squad leader is making a decision.

[escforreality 35]

Hi quick question, in the change log the item below is stated. But how do you setup an AI unit to be able to use artillery in the first place?

8 hours ago, nkenny said:

Added units which call artillery will now attempt to use binoculars and stay in position to direct fire

[diwako 413]

20 minutes ago, escforreality said:

Hi quick question, in the change log the item below is stated. But how do you setup an AI unit to be able to use artillery in the first place?

Ai can request artillery while they are assessing the current threat situation. However here we decided that not all artillery pieces will be instantly be available inside the request pool. This means you need to register them to be in the pool of available artillery pieces. Either by Eden editor module, Zeus module or via script using this function
 

[group bob] call lambs_wp_fnc_taskArtilleryRegister;
// group or unit supported, make sure that at least one unit inside the group is in an artillery piece

 

[escforreality 35]

2 minutes ago, diwako said:

Ai can request artillery while they are assessing the current threat situation. However here we decided that not all artillery pieces will be instantly be available inside the request pool. This means you need to register them to be in the pool of available artillery pieces. Either by Eden editor module, Zeus module or via script using this function
 

[group bob] call lambs_wp_fnc_taskArtilleryRegister;
// group or unit supported, make sure that at least one unit inside the group is in an artillery piece

 

Much appreciated! 

[nkenny 1057]

@madrussian
Next version will feature an internal restructure. Which is exactly where I would want to expand on the features you are interested in! 

-k 

[LSValmont 789]

2 hours ago, nkenny said:

@madrussian
Next version will feature an internal restructure. Which is exactly where I would want to expand on the features you are interested in! 

-k 

 

I heard rumors of Ai melee support for future versions! If that is true it is AWESOME!

[Asmodeuz 54]

After the latest 2.4.0 update I'm unable to join a server (that uses LAMBS Danger) as a client with the same version of LAMBS Danger enabled. The server keeps insisting that the LAMBS Danger related PBOs "are not signed by a key accepted by this server". This happens even though I did a clean install of LAMBS Danger to the server and for the client unsubscribed, deleted all LAMBS Danger related files and then subscribed again to the mod in Steam Workshop. I also moved the lambs_danger_2.4.0.bikey from my client to the server to see if the server key would be different/corrupted/wrong but that did not help either. If I remove LAMBS Danger from the client's mods I'm able to join the server without problems. What usually gives in situations like this?

[diwako 413]

3 hours ago, Asmodeuz said:

After the latest 2.4.0 update I'm unable to join a server (that uses LAMBS Danger) as a client with the same version of LAMBS Danger enabled. The server keeps insisting that the LAMBS Danger related PBOs "are not signed by a key accepted by this server". This happens even though I did a clean install of LAMBS Danger to the server and for the client unsubscribed, deleted all LAMBS Danger related files and then subscribed again to the mod in Steam Workshop. I also moved the lambs_danger_2.4.0.bikey from my client to the server to see if the server key would be different/corrupted/wrong but that did not help either. If I remove LAMBS Danger from the client's mods I'm able to join the server without problems. What usually gives in situations like this?

Which release did you use. The one from the workshop or the one from GitHub?

[Asmodeuz 54]

3 minutes ago, diwako said:

Which release did you use. The one from the workshop or the one from GitHub?

Workshop version for both the server and client.

[diwako 413]

Statement about the signing issue, as by someone who also had issues on own server:

We have examined the signing issue. The result was everything is working as expected. Reports of keys not working are false positives and we urge server owners to double check the server key. There can be instances that the key is corrupted while extracting the files from the Zip file or from the workshop download (check if the key is 1kb and not 0kb or above 1kb).

Regardless, we thank you all for reporting issues!

[madrussian 347]

9 hours ago, nkenny said:

@madrussian
Next version will feature an internal restructure. Which is exactly where I would want to expand on the features you are interested in! 

 

That sounds awesome, looking forward to it!

 

Related requests here:

Spoiler

Btw- The other thing (aside from continuous access to danger causes) that I'd need for my upcoming Building Path-Finder & Lambs plugin would be some kind of switch for when you would otherwise send a unit into a building.  So I can (optionally) replace your engine-based building entry (& exit) with my smooth/reliable/faster movement building entry (& exit).  If that sounds like something you might like to support, lets collaborate over PM (and I can spell out exactly what I need to make it work).

 

Also considering you're doing a major restructure, ideally for danger causes what I need is a total bypass of all FSM internals.  In other words a complete end around.  If the unit (optimally) has a variable set ("lambs_danger_bypass" or similar) simply pass on the danger cause (via BIS_fnc_CallScriptedEventHandler or similar) and exit the fsm, so fsm can trigger again repeatedly and provide a continuous feedback of these danger causes.  That's the magic that let's my AI guys fight back while indoors. 😄

 

[Asmodeuz 54]

17 hours ago, diwako said:

Statement about the signing issue, as by someone who also had issues on own server:

We have examined the signing issue. The result was everything is working as expected. Reports of keys not working are false positives and we urge server owners to double check the server key. There can be instances that the key is corrupted while extracting the files from the Zip file or from the workshop download (check if the key is 1kb and not 0kb or above 1kb).

Regardless, we thank you all for reporting issues!

I just uploaded LAMBS Danger files along with the bikey from my client to the server. One could think that those would match eh :) Then just to be sure disabled any other mod on the server and on my client than CBA_A3 and LAMBS Danger. And still the server is telling me that the provided key and mod files don't match 🤷‍♂️
Guess there is not much to do than wait for a future update of LAMBS Danger and hope that everything gets back in working order with a new key.

[Coul 11]

Hello @nkenny!

I recently downloaded a copy of the fsm and the scripts through github and noticed an inconsistency, unsure if it was a bug or not so I didn't want to make a github issue incase I was wrong but under the garrison state it doesn't link up to timeout like the rest of them do, is this intended?

Image with red line used to display where I thought the arrow would be

[b0s 18]

Hi and thank You again Ken!

Do I understand correctly that LAMBS Danger does not currently deal with reinfocement calls? What addon do you recommend for that part? LOGIC FSM doest also seem to call reinfocements.
 

With LAMBS danger I see vehicles often firing into ground. Like this AMW firing into a hill
https://imgur.com/a/9pmQq2p