[WIP] bCombat infantry AI Mod [SP]

[ebarstad 18]

An hypothesis is that due to fhe fact bCombat allows for farther enemy detection, this issue is triggered sooner / more often. I'm investigating more.

That's interesting. I notice that it hasn't happened to the autorifleman or the team leader, so I wonder if that bug only affects certain classes? Maybe I'll try the mission again, replacing the other two units with autoriflemen or marksmen, just to see if there's any difference.

Edit: I replaced them with marksmen and they didn't get stuck, but I only ran the mission twice.

One thing I have noticed almost every time time I run the mission with bCombat is that the team leader will flank around the hill to the west. I thought he was going to engage the guys on the hill, but he's actually just circumventing the OPFOR units to get to his waypoint [screenshot]. This is actually pretty cool behaviour, but each time he's done it he's left his team mates behind to keep fighting, which isn't as cool. Is this expected behaviour? If I had slow_leaders enabled, would that make a difference? Or if I'd used a different kind of waypoint?

Edited November 25, 2013 by ebarstad

[bravo409 13]

ebarstad Great videos... Have you all notice that vanilla Ai uses grenade launchers and Bcombat doesnt?...What do you think causes that to happen? I did see in some of my test Ai do try to use houses but only to go to other side to flank. Although one test was way different my blufor where looking for the last guy and they where ambushed by him he shot them from house window. So there are some great things and great potential here.

[fabrizio_t 58]

That's interesting. I notice that it hasn't happened to the autorifleman or the team leader, so I wonder if that bug only affects certain classes? Maybe I'll try the mission again, replacing the other two units with autoriflemen or marksmen, just to see if there's any difference.

Edit: I replaced them with marksmen and they didn't get stuck, but I only ran the mission twice.

One thing I have noticed almost every time time I run the mission with bCombat is that the team leader will flank around the hill to the west. I thought he was going to engage the guys on the hill, but he's actually just circumventing the OPFOR units to get to his waypoint [screenshot]. This is actually pretty cool behaviour, but each time he's done it he's left his team mates behind to keep fighting, which isn't as cool. Is this expected behaviour? If I had slow_leaders enabled, would that make a difference? Or if I'd used a different kind of waypoint?

It's possible that leader is ordering units to engage enemies which are farther than their weapon maximum range and this is causing problems.

However i noticed that stuck units having ATTACK command do have a null assignedTarget, so it looks like a bug indeed (attack who?).

I am double checking whether bCombat is unassigning any targets, to better highlight the culprit of the issue end reliably reproduce it.

EDIT: what about this issue:

0013952: An AI unit refuses to engage a distant target when ordered to or runs far away

http://feedback.arma3.com/view.php?id=13952

Looking somewhat related to the behaviour i see.

I noticed too those units moving towards opposite direction of the enemy before being stuck.

---

The reason leader goes ahead almost alone is probably due to units (those ordered to attack) being temporarily stuck.

Consider than even a single stuck unit can lock in place all the following ones, as long as it's formationLeader for them.

Easy check: put into leader's init field the command:

(group this) enableAttack false;

I bet units won't be stuck anymore this way, since leader is no more issuing orders.

Sadly this is not an all-arond workaround: while it's suitable for CQB (better group cohesion), this behaviour hinders flanking and spreading in the open.

---

I'm pretty sure slow_leaders is not making any difference.

---------- Post added at 21:34 ---------- Previous post was at 21:23 ----------

ebarstad Great videos... Have you all notice that vanilla Ai uses grenade launchers and Bcombat doesnt?...What do you think causes that to happen?

Nothing in bCombat explicitly locks grenade launchers, but this may be some kind of side-effect. To be checked.

I did see in some of my test Ai do try to use houses but only to go to other side to flank. Although one test was way different my blufor where looking for the last guy and they where ambushed by him he shot them from house window.

Yes, units are able to fire into and out of windows, they check line-of-sight in real-time.

At the moment units may enter some houses if bcombat_allow_cover = true, but they don't occupy preset building positions.

They are able to follow known units into buidings as long as they're close and bcombat_allow_targeting = true.

---------- Post added at 23:08 ---------- Previous post was at 21:34 ----------

UPDATE

I can confirm that the unit "stuck" issue is a vanilla bug.

After revealing one OPFOR unit to BLUFOR leader i see most BLUFOR units advancing, while one of them gets stuck behind, with ATTACK command active.

Possibly some out-of-range deadlock.

Bad news is that till now i've found no way to override ATTACK command in order to somewhat circumvent this problem.

Edited November 25, 2013 by fabrizio_T

[froggyluv 2130]

Bad news is that till now i've found no way to override ATTACK command in order to somewhat circumvent this problem.

Anyway to advance this issue to the AI Dev's?

[Make Love Not War 10]

Accuracy has not been raised, actually it has been lowered.

Similar to what some others reported earlier, the AI accuracy seems to have gone up considerably in the latest build. I was testing version 1.3 on the usual Assault on Charkia yesterday and ran into an issue were the firefight was ending very rapidly. While previously in build 1.2 there was a great deal of protracted CQB within the city itself, in this latest batch of testing, with the config.sqf uncommented and running no other mods other than bcombat, blufor always wiped opfor out before making it off the hill and past the town outskirts. Tried four or five times with the same results. I'm on dev build, so I'm wondering if BIS made some sneaky changes to the AI. Or, prehaps, it's not a question of increased accuracy, but rather a much higher volume of fire from the AI. Also, how many grenades are other testers seeing being thrown? I've yet to have the AI throw one, but then again, like I said, didn't see much close quarters action in the Charkia scenario yesterday. Maybe something is set up incorrectly on my end; I'll have a closer look tonight.

[gammadust 12]

Bad news is that till now i've found no way to override ATTACK command in order to somewhat circumvent this problem.

I haven't either, but i can suggest a workaround, though a bit cumbersome:

When a group member (or members) are assigned a doFSM, currentCommand returns "SCRIPTED", and when i tested this these units are not assigned any further orders by leaders ("SUPPORT"/"ATTACK"/etc.), as long as the fsm is in effect. If this hasn't changed (or i didn't jump into conclusions at the time) you have to possibilities:

- create a dummy fsm, which does nothing, but keeps looping until you tell it not to, with the objective of disallowing any "ATTACK" orders from being issued to affected unit. (This becomes an on demand per unit "enableAttack false/true", beware that any other engine issued orders would also be disalowed!)

- enableAttack false, and implement yourself what it adds to AI behaviour (ie. a flanking manouver - default one is not very useful either as per mentioned ticket), via said doFSM method.

Ideally we would have an handle on the engine issued currentCommand FSMs which we could terminate at will. I would be interested not only in interrupting ATTACK orders but SUPPORT/HEAL orders too, these freeze the units in the better part of the times.

*also sorry for not being able to contribute my bCombat tests feedback, hands quite full atm*

Edit:

Anyway to advance this issue to the AI Dev's?

ticket created, please vote:

0016299: [Request] Ability to terminate group leader issued orders execution (currentCommand)

Edited November 26, 2013 by gammadust

[fabrizio_t 58]

I haven't either, but i can suggest a workaround, though a bit cumbersome:

When a group member (or members) are assigned a doFSM, currentCommand returns "SCRIPTED", and when i tested this these units are not assigned any further orders by leaders ("SUPPORT"/"ATTACK"/etc.), as long as the fsm is in effect. If this hasn't changed (or i didn't jump into conclusions at the time) you have to possibilities:

- create a dummy fsm, which does nothing, but keeps looping until you tell it not to, with the objective of disallowing any "ATTACK" orders from being issued to affected unit. (This becomes an on demand per unit "enableAttack false/true", beware that any other engine issued orders would also be disalowed!)

- enableAttack false, and implement yourself what it adds to AI behaviour (ie. a flanking manouver - default one is not very useful either as per mentioned ticket), via said doFSM method.

Ideally we would have an handle on the engine issued currentCommand FSMs which we could terminate at will. I would be interested not only in interrupting ATTACK orders but SUPPORT/HEAL orders too, these freeze the units in the better part of the times.

*also sorry for not being able to contribute my bCombat tests feedback, hands quite full atm*

Edit:

ticket created, please vote:

0016299: [Request] Ability to terminate group leader issued orders execution (currentCommand)

Thank you gammadust,

i like the idea of the dummy .fsm.

Cumbersome, but may help.

I would avoid fully disabling enableAttack within bCombat, since rewriting from scratch AI movement is out of the scope of the mod.

Moreover, this kind of custom AI behaviour is likely to break existing missions / campaign.

By the way, regarding per-unit "enableAttack false/true", i think unit disableAI "target" is doing about the same.

Thanks for the ticket!

---------- Post added at 09:26 ---------- Previous post was at 09:21 ----------

Similar to what some others reported earlier, the AI accuracy seems to have gone up considerably in the latest build. I was testing version 1.3 on the usual Assault on Charkia yesterday and ran into an issue were the firefight was ending very rapidly. While previously in build 1.2 there was a great deal of protracted CQB within the city itself, in this latest batch of testing, with the config.sqf uncommented and running no other mods other than bcombat, blufor always wiped opfor out before making it off the hill and past the town outskirts. Tried four or five times with the same results. I'm on dev build, so I'm wondering if BIS made some sneaky changes to the AI. Or, prehaps, it's not a question of increased accuracy, but rather a much higher volume of fire from the AI. Also, how many grenades are other testers seeing being thrown? I've yet to have the AI throw one, but then again, like I said, didn't see much close quarters action in the Charkia scenario yesterday. Maybe something is set up incorrectly on my end; I'll have a closer look tonight.

I'm positive that suppressive fire and fast rotate play a role in increased lethality, as i said accuracy itself went down.

hich difficulty you are playing on?

Would you mind to test again after changing into config:

bcombat_allow_fast_rotate = false;

bcombat_allow_suppressive_fire = false;

This should make quite some difference.

---------- Post added at 10:55 ---------- Previous post was at 09:26 ----------

EDIT

looks to me that it is not possible to override ATTACK command by issue via a doFSM dummy call.

From what i can see the custom .fsm called via doFsm file is normally skipped / ignored when currentCommand is ATTACK.

In rare cases it's triggered, but completely out of sync (seconds late) in respect of the actual call, then promptly overridden by ATTACK again.

So looks like this is not a viable solution.

Please vote gammadust's ticket, so we may have a chance to get this fixed.

So far 3 only votes.

Edited November 26, 2013 by fabrizio_T

[gammadust 12]

looks to me that it is not possible to override ATTACK command by issue via a doFSM dummy call.

From what i can see the custom .fsm called via doFsm file is normally skipped / ignored when currentCommand is ATTACK.

In rare cases it's triggered, but completely out of sync (seconds late) in respect of the actual call, then promptly overridden by ATTACK again.

So looks like this is not a viable solution.

Hum... the "on demand" observation must have lead you to believe it would interrupt. I meant only to say you could do that in a preventive way, to prevent the ATTACK order from getting issued in the first place. You would be gaining only the per unit discretion. Sorry if i mislead you there, hope you didn't spoil too much time around with it.

By the way, regarding per-unit "enableAttack false/true", i think unit disableAI "target" is doing about the same.

In my experience disableAI "target" is of wider relevance, if affecting also "ATTACK" (=flanking) orders at all, it is disabling the leader selecting targets to its group members. Such orders just assign targets, are of higher frequency and do not include movement. (disclaimer: i'm a bit fuzzy regarding this and there is a long time i don't test this, so i may be wrong)

[fabrizio_t 58]

Hum... the "on demand" observation must have lead you to believe it would interrupt. I meant only to say you could do that in a preventive way, to prevent the ATTACK order from getting issued in the first place. You would be gaining only the per unit discretion. Sorry if i mislead you there, hope you didn't spoil too much time around with it.

Ok, i see. No problem at all, it was worth checking.

In my experience disableAI "target" is of wider relevance, if affecting also "ATTACK" (=flanking) orders at all, it is disabling the leader selecting targets to its group members. Such orders just assign targets, are of higher frequency and do not include movement. (disclaimer: i'm a bit fuzzy regarding this and there is a long time i don't test this, so i may be wrong)

What i noticed is that by calling unit disableAI "target" its leader is not issuing ATTACK orders anymore, so unit stays in formation.

Not sure there's much difference, behaviour looks pretty similar to per-unit enableAttack false.

However maybe unit disableAI "target" is doing more than this.

[Bouben 3]

In short looks like that unit has been commanded to attack some enemy, but it fails to approach it.

I have some doubts it's bCombat fault, since it does not issue any "ATTACK" commands, at distance.

Usually this is ordered by AI leader. I suspect this is a vanilla bug, causing units failing to engage far enemies , when ordered to.

Look at a feedback in my signature. I reported this in beta branch already.

EDIT: Oh sorry, have not noticed you already found out.

Edited November 26, 2013 by Bouben

[Bouben 3]

I saw the videos and so far, I am really impressed.

Fabrizio, you are my hero. Amazing work. And guys, great job that you are really testing it and giving a feedback. This looks so promising.

[willywonka 10]

Fabrizio-

I've been browsing the forums a long time, and I finally had to make an account as I was thoroughly impressed with your work. It is possible you would accept another beta tester? I typically play SP, can program on an amateur level, and have many years experience with the series; all the way back to Everon.

Cheers

[fabrizio_t 58]

Thanks for appreciation.

---

To all testers

While i've done some further work on v0.14, i'd like to postpone a bit its release.

I will be off from friday to monday and i still have to double check the new /updated stuff in order to avoid regressions.

By the way, did anybody found useful the penalty variables info posted here: http://forums.bistudio.com/showthread.php?167288-bCombat-test-candidates&p=2563934&viewfull=1#post2563934 ?

Anybody wanting to get insight on something ?

Finally a question: would you consider useful, as an OPTIONAL feature, adding some kind of aiming degradation for player when suppressed?

I'm considering this, but i won't if you think it's a waste of time.

Ty.

[bravo409 13]

this is my numbers on the suppressed ...........................................................................................I changed every 4 to 5

// Suppression-related params

if(isNil "bcombat_penalty_bullet") then { bcombat_penalty_bullet = 5; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_flanking") then { bcombat_penalty_flanking = 5; }; // max relative % of unit skill loss - adding to bcombat_penalty_bullet!

if(isNil "bcombat_penalty_scream") then { bcombat_penalty_scream = 0; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_enemy_unknown") then { bcombat_penalty_enemy_unknown = 5; }; // max relative % of unit skill loss - adding to bcombat_penalty_bullet!

if(isNil "bcombat_penalty_enemy_contact") then { bcombat_penalty_enemy_contact = 25; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_enemy_close") then { bcombat_penalty_enemy_close = 0; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_casualty") then { bcombat_penalty_casualty = 20; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_wounded") then { bcombat_penalty_wounded = 10; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_explosion") then { bcombat_penalty_explosion = 5; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_recovery") then { bcombat_penalty_recovery = 2; }; // max relative % of unit skill loss

[ebarstad 18]

Finally a question: would you consider useful, as an OPTIONAL feature, adding some kind of aiming degradation for player when suppressed?

I'm considering this, but i won't if you think it's a waste of time.

I think the fact that the AI is suppressing now is enough of an effect for me personally. I'm already afraid to pop my head out and return fire, so if you made my aiming worse on top of that, I probably wouldn't have much fun.

[Make Love Not War 10]

I'm positive that suppressive fire and fast rotate play a role in increased lethality, as i said accuracy itself went down.

hich difficulty you are playing on?

Would you mind to test again after changing into config:

bcombat_allow_fast_rotate = false;

bcombat_allow_suppressive_fire = false;

This should make quite some difference.

Was able to sit down last night and give this another thorough testing. Tried the above suggestion of turning off the rotate and suppressive fire, but after a number of playthroughs I found that disabling those features was unnecssary. I've no idea what happened during my weekend testing - whether it was something in that particular dev build or the random number generator had gone on the fritz, but the issue of firefights ending very quickly was completely gone this time around. :)

Did a few run-throughs of the Charkia scenario on vanilla for comparison, and I am happy to confirm that the mod makes a number of fundamental, positive changes to AI behaviour. In particular, (A) AI volume of fire has gone up considerably which is wonderful and realistic IMO, and (B) AI react to incomng fire by taking immediate cover which not only looks great, but also increases their survivability exponentially. I consistently observed that whenever AI would take accurate incoming, they would quickly go into "green" morale mode followed almost instantenously by a "duck to cover" routine, which saved their lives on numerous occasiions. They would also attempt to displace a few meters whenever forced into green mode which was very nice to watch as well. Even cooler, after the AI displaced they would attempt to pop out/up again to take some more shots, and if they kept taking incoming they would go back into their displace-to-cover routine again. Not only would this keep them alive in many circumstances for much, much longer than in vanilla, but it also created a very realistic looking firefight dynamic where continous suppressive fire kept the enemy's heads down, but wouldn't completely paralyze them into doing nothing but cowering behind some rock. Granted, all this behaviour was already present in 0.12, but it seemed to me that it is triggered much quicker and with much greater consistency in this latest build. Really well done, fabrizio!

Only negative notes I can report is that I still have yet to see any grenade tossing (made sure it was enabled in the config), but that seemed to be a function of the fact that even in CQB within the town, the AI rarely got within grenade distance of each other. Besides, almost all situations where the did AI run into one another at very close range required a fire-at-full-auto-till-one-of-you-dies response anyway was the superior choice; trying to toss a grenade in these situations would have simply assured the thrower's death, IMO. So, no real problems there.

The other issue I observed was that after going into the green morale mode, the AI would sometimes give up key cover positions or turn their backs and attempt to scramble away when the enemy had their egress route under direct observation and fire. The first is probably a tactical issue that would be best to address via bCommand, but the second problem of AI turning their backs and moving away in plain view of the enemy could perhaps be solved through a couple of ray casts along the planned route to see if it's exposed to enemy fire? If yes, then the AI should stay at the cover position they're already at; if they're not in a cover position, then either (A) stay where you are and lay down maximum suppressive fire hoping for the best, or, better yet, (B) lay down suppressive fire and backpedal along your route to cover. Key point being, don't give the enemy a clean shot at your exposed back. Maybe some kind of behaviour logic along those lines would be useful?

One final note, I still see AI autoriflemen standing up and firing single shots at distant enemies. Obviously, that's an A3 AI and not bCombat hijink, but might be worth solving? Worth pointing out, that this behaviour could also have been a function of the AR firing over obstacles, therefore being forced to stand in order to engage the target which in turn meant that burst or auto fire would have been far too inaccurate. Sure would be nice to have weapon resting in the game, wouldn't it?

In any case, mod seems to be really doing its job and shaping up very well. Have a great weekend holiday away from coding, fab. :)

[ebarstad 18]

Only negative notes I can report is that I still have yet to see any grenade tossing (made sure it was enabled in the config), but that seemed to be a function of the fact that even in CQB within the town, the AI rarely got within grenade distance of each other.

I've seen some grenade throwing, typically done by AI in my own squad, which is fantastic. However, I've also witnessed enemies tossing grenades and the panic that sets in when you hear one land at your feet is tremendous.

[kremator 1064]

I think the fact that the AI is suppressing now is enough of an effect for me personally. I'm already afraid to pop my head out and return fire, so if you made my aiming worse on top of that, I probably wouldn't have much fun.

Totally agree. No need for player suppression. bCombat already scares the shit outta me.

[Make Love Not War 10]

I've seen some grenade throwing, typically done by AI in my own squad, which is fantastic. However, I've also witnessed enemies tossing grenades and the panic that sets in when you hear one land at your feet is tremendous.

Ah, well, I've only been observing the AI from spectator mode, so the lack of a player squad might be the difference. Thanks.

Finally a question: would you consider useful, as an OPTIONAL feature, adding some kind of aiming degradation for player when suppressed? I'm considering this, but i won't if you think it's a waste of time..

I'm with ebarstad and Kremator on this one in that I don't think it's necessary and probably not worth your time.

[fabrizio_t 58]

Only negative notes I can report is that I still have yet to see any grenade tossing (made sure it was enabled in the config), but that seemed to be a function of the fact that even in CQB within the town, the AI rarely got within grenade distance of each other. Besides, almost all situations where the did AI run into one another at very close range required a fire-at-full-auto-till-one-of-you-dies response anyway was the superior choice; trying to toss a grenade in these situations would have simply assured the thrower's death, IMO. So, no real problems there.

You should be able to see some grenade lobbing, given some prerequisites:

First prerequisite is enemy being OUT of line of sight.

As you already observed, in CQB and with enemy in sight full-auto firing should the best viable solution (in ArmA3).

Compared to vanilla, bCombat grenade handling features a way wider throwing range.

Vanilla units throw grenades when enemy is at about 25-35 meters distance.

bCombat allows for a range of 6 to 45 meters (default).

This way units may lob grenades over small buildings as well as target an enemy just behind a wall.

You may tweak these distances within config.sqf, here is the default call to be added and changed:

bcombat_grenades_distance = [6,45];

6 = min. distance (meters)

45 = max. distance (meters)

Second requisite is unit actually having some hand grenades into inventory.

You may automatically add some more by setting bcombat_grenades_additional_number > 0 in config.sqf.

Example:

bcombat_grenades_additional_number = 3; // adds 3 hand grenades to each unit

The other issue I observed was that after going into the green morale mode, the AI would sometimes give up key cover positions or turn their backs and attempt to scramble away when the enemy had their egress route under direct observation and fire. The first is probably a tactical issue that would be best to address via bCommand, but the second problem of AI turning their backs and moving away in plain view of the enemy could perhaps be solved through a couple of ray casts along the planned route to see if it's exposed to enemy fire? If yes, then the AI should stay at the cover position they're already at; if they're not in a cover position, then either (A) stay where you are and lay down maximum suppressive fire hoping for the best, or, better yet, (B) lay down suppressive fire and backpedal along your route to cover. Key point being, don't give the enemy a clean shot at your exposed back. Maybe some kind of behaviour logic along those lines would be useful?

This is a complex problem, given our limited scripting tools.

First: we have no cheap and reliable way to check whether some unit is REALLY into (hard) cover.

Second: we have zero control on pathfinding, which means we don't know the route an unit is going to take when moving from position A to position B (e.g. moving to cover).

It is likely to pick the worst and most awkward path.

Both problems can't be simply addressed with line of sight checks, since LOS may be blocked by anything: hard and soft cover, smoke, vegetation, insects.

So a route can't be considered safe if shooter's line of sight to target is broken and some unit can't be considered in cover if simply out of sight.

One final note, I still see AI autoriflemen standing up and firing single shots at distant enemies. Obviously, that's an A3 AI and not bCombat hijink, but might be worth solving? Worth pointing out, that this behaviour could also have been a function of the AR firing over obstacles, therefore being forced to stand in order to engage the target which in turn meant that burst or auto fire would have been far too inaccurate. Sure would be nice to have weapon resting in the game, wouldn't it?

In my knowledge firing mode depends on distance, stance and weapon config, given this it's up to vanilla AI to pick the right firing mode.

I'm no expert on weapons config though, so i'd hardly deal with this stuff.

What i sure dislike are machinegunners / autoriflemen firing from distance by standing, on open terrain.

I'm considering some options to lessen these cases.

I think the fact that the AI is suppressing now is enough of an effect for me personally. I'm already afraid to pop my head out and return fire, so if you made my aiming worse on top of that, I probably wouldn't have much fun.

:)

this is my numbers on the suppressed ...........................................................................................I changed every 4 to 5

// Suppression-related params

if(isNil "bcombat_penalty_bullet") then { bcombat_penalty_bullet = 5; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_flanking") then { bcombat_penalty_flanking = 5; }; // max relative % of unit skill loss - adding to bcombat_penalty_bullet!

if(isNil "bcombat_penalty_scream") then { bcombat_penalty_scream = 0; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_enemy_unknown") then { bcombat_penalty_enemy_unknown = 5; }; // max relative % of unit skill loss - adding to bcombat_penalty_bullet!

if(isNil "bcombat_penalty_enemy_contact") then { bcombat_penalty_enemy_contact = 25; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_enemy_close") then { bcombat_penalty_enemy_close = 0; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_casualty") then { bcombat_penalty_casualty = 20; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_wounded") then { bcombat_penalty_wounded = 10; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_explosion") then { bcombat_penalty_explosion = 5; }; // max relative % of unit skill loss

if(isNil "bcombat_penalty_recovery") then { bcombat_penalty_recovery = 2; }; // max relative % of unit skill loss

Are you comfortable with this configuration?

Looks reasonable to me (about 20% more bullet-driven suppression), unless you get many purple / red / yellow balloons quickly.

Can you try some asymmetric fight, e.g. 20 units vs 10 or 30 vs 10?

Those 10 should not be suppressed too quickly by massive gunfire.

Also, depending on the result you want to achieve you can take different routes:

By increasing bullet-related penalties (as you did) you end up giving some further bonus to the side or group owning the most firepower

By increasing bcombat_penalty_enemy_contact you reduce the average accuracy within the very first moments of the fight.

This may be useful, because it allows for less initial casualties and better units scrambling.

By reducing bcombat_penalty_recovery you slow down the rate suppression penalties are recovered, hence allowing then to build-up more during a continued firefight.

---

Thank you all,

see you on tuesday.

---------- Post added at 18:54 ---------- Previous post was at 18:46 ----------

Totally agree. No need for player suppression. bCombat already scares the shit outta me.

Ok i got it :D

Edited November 28, 2013 by fabrizio_T

[bravo409 13]

How can I get the Ai to take other routes seems like they take the same in the start?

[kremator 1064]

Have been testing bCombat on its own, but as a sneaky lil test .....

bCombat + ALiVE (closed beta) = Epic WIN!

[willywonka 10]

Have been testing bCombat on its own, but as a sneaky lil test .....

bCombat + ALiVE (closed beta) = Epic WIN!

Have been waiting a while for Alive to come out super excited to combine these two. Do you have any missions you'd be willing to share, or maybe play some coop?

[kremator 1064]

Working on missions that show off the two :)

[willywonka 10]

I'm anxiously awaiting them ;). Done a few missions myself, just wow is all i can say.