fabrizio_t

i have an AI targetRange mission i made originally for ArmA2/FlexAI accuracy testing buried somewhere. It would come in handy to doublecheck this if i'm able to find it ... EDIT: the data i posted was calculated based on bullet tracking though (bDetect output).

It does make less difference, yet accuracy is affected, at least in my case. I just did a comparative check, with precision = 0.35 vs "normal" precision (it should be about 0,70). 3 run each on assault on Charkia, bCombat v.0.17RC: precision=0.35: minimum 2 casualties, maximum 4 casualties for 1000 bullets fired. precision=normal: minimum 7 casualties, maximum 12 casualties for 1000 bullets fired. 3 runs is not enough to get reliable results, but i definitely can see some difference.

You have an extremely low precision value (0,45) in game options. Please revert your settings to regular or veteran, this should solve the issue. Take care.

I'm surprised and honoured that bCombat is at the moment the most popular ArmA3 addon of the day (2nd in the week) on Steam Workshop. http://steamcommunity.com/workshop/browse?searchtext=&childpublishedfileid=0&section=items&appid=107410&browsesort=trend&requiredtags%5B0%5D=Addon&p=1&days=1 I't a small thing and will last just for a split-second, but feels important to me. That's incredible. Thank you to everybody who subscribed, i hope you enjoy this stuff. This, as well as support shown from people here over time is really motivating for me. Thank you again, people.

I would say it's influencing AI indirectly, by just altering bullets lethality. Or better said it alters the balance of lethality across sides. Within bCombat accuracy in average is lower than vanilla. This happens primarily because units are usually in a suppressed state, ranging from light to severe. Any suppression state causes degradation in accuracy, courage, skill in general. Wounds also account for accuracy reduction. Another cause of indirect reduction in accuracy is that AI units do suppressive fire (they do it massively in v0.17RC). AI units do blind fire and fire when slowly moving. This kind of shooting is obviously pretty inaccurate. The experimentally verified lethality of a single bullet within bCombat, on regular settings, ranges in average from 0,03 to 0,01, meaning you get 1 casualty each 30 to 100 bullets fired. Compared to vanilla that's a pretty forgiving, conservative percentage. I'd consider this as an improvement, as it allows for tactical movement. Shame accuracy in ArmA3 seems to work contrary to reality: much accurate at long range, way too inaccurate at point blank. I hope BIS will finally nail a better balance.

It's weird, i'm not sure what 556 762 mod is actually doing, but i consider the final outcome to be wrong. BLUFOR is not supposed to win that scenario in my opinion (sure Player can outweight this, but AI vs AI wise that's it). Basically BLUFOR attacks frontally from lower ground an entrenched enemy who has recon units patrolling higher ground. Last but not least balance of forces favours the defender. Looks to me an "arcadish" scenario which is designed to be challenging for the player, but tactically absurd. EDIT: that's my 2 cents obviously.

There would be be locality issues. So i won't encourage doing this.

Thought it. Did it ;) http://steamcommunity.com/sharedfiles/filedetails/?id=314397752 Steam support is a bit cumbersome though. For instance config.sqf (if you manually copy it) is going to be removed on mod auto-update, it seems. Not handy :( ---------- Post added at 17:21 ---------- Previous post was at 17:20 ---------- Thank you, your feedback is highly appreciated. ---------- Post added at 17:22 ---------- Previous post was at 17:21 ---------- Care to clarify? ---------- Post added at 17:32 ---------- Previous post was at 17:22 ---------- You may expect some insights on the features of v0.17, as much changed under the hood, ranging from hearing to investigate behaviour, to prioritization of special actions (heal, support), blind / suppressive fire and fire vs. movement balancing. Explanations will come. For the moment let me enumerate a few new settings introcuced into config.sqf: with the current RC: bcombat_stance_prone_min_distance = 50; // (Meters) Disallows AI to go prone as areaction to suppression events under the specified distance (distance is computed from nearest enemy) bcombat_skill_multiplier = 1; // (0-1) It's intended to reduce skill value at will. Unit skill is multiplied by this value. It affects accuracy as well. bcombat_skill_linearity = 1.5; // (0-1) linearity of skill: final skill is ( <original skill> * <bcombat_skill_multiplier> ) ^ <bcombat_skill_linearity>. It affects accuracy as well. bcombat_skill_min_player_group = 0.5; // (0-1) enforce minimum skill for units in player group. Meant to counterbalance the effectiveness of AI led groups. ---------- Post added at 17:44 ---------- Previous post was at 17:32 ---------- Keep it for ArmA4 ;)

To be fair that's true. AI in ArmA3 is good, otherwise i wouldn't even considered fiddling with it. That said, it has a lot of inconsistencies that seriously undermine its performance. Often AI units struggle in order to comply to different, sometimes colliding commands. Some better kind of task prioritization would definetely help a lot in this area. Of course leader's commands should normally be top priority (hint, hint). That said i think that fixing pathfinding and giving modders suitable commands for overriding combat behaviour alone would help immensely. ---------- Post added at 13:18 ---------- Previous post was at 12:58 ---------- Swapping FSM won't override lower level (hardcoded) AI functions / logic. What i actually did was altering danger.fsm, which in my limited knowledge is some kind of high level "behaviour layer" triggered by lower level AI logic. danger.fsm itself exposes some lower level environmental "events" and contains some very, very simplicistic code for AI event handling (e.g. stop there where enemy is in sight), which looks like drafted / unfinished to me. The exposed AI "events" would be precious, but they're inconsistently triggered at times and also get ignored / discarded for the most part ( they're eventually processed at lower level, but i've no clue / no evidence). Within bCombat i hooked some scripted logic in order to make actual use of events information, so AI gets better situational awareness. Since i found some events (e.g. those triggered by hearing and line-of-sight checking ) to be lacking i modeled own scripted routines to integrate them. Sadly scripting this kind of stuff is not efficient at all.

NOTE: bCombat is being processed for addition to WithSIX. Have a nice sunday, everybody.

Posted small hotfix. Hotfix #1 ---------- * fixed wrong expression into suppression.sqf, line 111 * player not throwing smoke on its own anymore * debug mode is set off by default Github users need to overwrite /addons/bcombat.pbo with latest pbo. Pick it from here: https://github.com/fabrizioT/bCombat/tree/master/addons (right click on bcombat.pbo, save) Steam Workshop users will auto-update soon (for those allowing automatic updates).

You need to fully remove previous bCombat installation (as now mod is packaged into pbo). Looks to me you simply overwrote previous install, so you have leftovers.

Ty. Verified and solved in my local build. Collecting some more feedback before releasing a hotfix. ---------- Post added at 20:45 ---------- Previous post was at 20:44 ---------- It does work, as long as you run it on server only (e.g. no player led AI groups).

Please wait a couple days, it's definiteley possible i made some mistakes (hence fixes needed), feedback will tell ...

Maybe :)

It does multiply default manage by bcombat_damage_multiplier, hence 1 is equal to default. ---------- Post added at 17:01 ---------- Previous post was at 16:42 ---------- UPDATE After endless headaches i finally (hopefully) sorted the Steam packaging. Github branch was updated as well, so bCombat v0.17 RC is staged on both Github and Steam Workshop. STEAM WORKSHOP VERSION * Steam Workshop version includes just the basic package (PBO), ready-to-go: http://steamcommunity.com/sharedfiles/filedetails/?id=314397752 * Install and play: as long as you have CBA properly installed: subscribe, activate the mod from within ArmA3 launcher and run the game. * IF you wish to override default settings you'll need config.sqf, which is not included. Pick it from here: https://github.com/fabrizioT/bCombat/blob/master/config.sqf. Put it into your existing <ARMA3 install folder>/@bcombat/ directory BEFORE running the game. Avoid running ArmA3 with the -nofilepatching startup option or you'll fail to override any settings. GITHUB VERSION * Here is the complete version of the mod: https://github.com/fabrizioT/bCombat * Install as usual, see readme: https://github.com/fabrizioT/bCombat/blob/master/readme.md * Full source is packed, available into the source.zip archive as well as into PBO. * The PBO file itself includes both scripts and default configuration, so it's ready to go. * As usual you may override default settings by editing config.sqf, which is already in place. Just avoid running ArmA3 with the -nofilepatching startup option or you'll fail to override any settings. Please notice that external userconfig support is disabled at the moment, for both versions. Crossing fingers, hope i've not overlooked anything. Now i'll have a glass of water or something, it's about 9 hours i mess with this ... hope you'll enjoy the release. I'll keep an eye on feedback, some insights on this release features later.

Yes, i'm aware of the issue, same bug posted before. I think it's solved in my internal build ---------- Post added at 17:27 ---------- Previous post was at 17:12 ---------- That's a an excellent example of a very basic problem having a very difficult solution. I've tried modeling this behaviour before, for FlexAI / ArmA2. To be fair it did not work 100%, and i considered it a failure, due to a number of reasons: * By the moment some infantry unit is detected by armor is basically doomed, it's like turkey shooting. This because "knowledge" of threats is instantly shared across a group, which is not realistic at all. We can't mod a different behaviour and we can't subtract any individual knowledge, so this issue has no solution for now. Only workaround is hindering armor firing accuracy, to delay the fate of grunts. * Units are still completely unable to withdraw properly. They fail to disengage when ordered to. They arbitrarily refuse to move at full speed. They stop at will, when in combat mode, even if ordered to move to some destination. Overcoming some of these issues is somewhat possible, but awkward. * Choice of withdrawal destination is complex. It implies proper evaluation of terrain features, as well as evaluation of nearby friendly / enemy strength and position.

That's infact what i fear ...

I really hope the package will be suitable for PWS too.

Well, it's about 11pm here and i'm still actively testing. I finally managed to clearly identify the cause of stuck units as a sideeffect of some setDestination + enableAttack combined use within bCombat. That's good news: knowing the problem is making easier from me to find and test a working solution. I think finalizing all the work will require a few more days, considering that's something i do in my spare time. Again, don't have too high expectations, just consider v0.17 as the natural evolution of v.16, reorganized and hopefully a bit more polished.

I think some clarification of what i did here is needed, not to raise excessive expectations. Healing is something that is handled by some very low level commands. We are able to know which internal commands are issued to AI units (currentCommand), but not to issue them directly, at least till we'll be given some setCommand scripting function. As of now we have a few options to influence the outcome of these commands. What i did here was to remove / unprioritize many mechanics (attack, move, engage) interfering with a subset of these commands, so when they're issued they should have a better chance to be fulfilled. Speaking of self-healing, which is another command of the set, i definitely see some improvements, as it's more easily ovservable and evaluable.

"bcombat_stance_prone_min_distance" is already in the (tested) code for v0.17RC. Just a heads-up: please consider that this setting alone will hopefully make AI avoid going prone under some distance, but since you can't actually force units to go fast in combat mode, its effect on survivability will be limited. You'll still see units move to cover in slomo in some cases, albeit crouching instead of prone. A very special case is AI units with wounded legs: for same reason they still can move around crouching at very low speed, whereas in ArmA2 they were just forced to crawl. Not sure ArmA2 solution was better, sure ArmA3 behaviour looks weird: these wounded units move so slowly and carelessly they just look oblivious of any danger. Crawling + limping in crouched / standing stance would be better, in my opinion.

Thanks for reporting. I suppose this happened episodically, not consistently, right? It happens when some bCombat features are requested for a non-yet initialized unit. I'm aware of the issue. That's edge situations i'm being investigate since a couple weeks. ---------- Post added at 13:33 ---------- Previous post was at 13:25 ---------- Ty serjames. I hope bCombat was not the culprit of your MP issues, if that's the case please let me know. So far 've got no reports of game-breaking issues. Regarding MP aspects of server-only bCombat, i think that as long as AI is local to server you will experience a few cosmetic problems, but nothing functionally broken. On the other side, since my experience with MP coding is very basic, i doubt i would be able to efficiently solve the locality issues connected with running bCombat on both clients / server. (Not sure whether that would be needed though). ---------- Post added at 13:42 ---------- Previous post was at 13:33 ---------- Yes, sorry for the dated files. I announced the candidate changelog just to inform everybody about the upcoming features, so you may get at least a clue of what's tested and coming. v0.17 is not groundbreaking really, but it should fill some existing gaps, in order to be the most complete release to date. --- Today i witnessed some cases of faster self-healing, as well as a case of a medic crawling a few hundreds meters to reach and heal a wounded comrade. He fell dead without accomplishing his missions, a few steps far from his comrade ... That's barely noticeable changes in the heat of a fight, you wouldn't noticed this without closesly monitoring the action. That said i consider features like this a worth addition. --- Testing showed a few persisting issues, such as some units appearantly getting "stuck" during a fight. This needs some more investigation, it should be checked wheter that's bCombat fault, or a vanilla problem. ---------- Post added at 13:43 ---------- Previous post was at 13:42 ---------- I'm preparing a traditional package, as well as a Steam-only package (=raw pbo).

As usual, partial changelog for upcoming v0.17RC bCombat v0.17 RC --------------------- * New: variable "bcombat_min_player_group_skill": forcing arbirtrary minimum skill level (default: 0.5) for any player's group units. * New: variable "bcombat_stance_prone_min_distance": minimum distance to nearest enemy for allowing prone stance after any suppression events. * Tweaked: AI prioritizing special commands (healing, supporting, self-healing, get-in, get-out, hide, rearm, refuel) against low-priority move / fire commands. * Tweaked: grenade throwing accuracy depends more on skill. Misses more likely for untrained soldiers. * Tweaked: enhanced movement to cover ( low-level command moveTo used instead of doMove). * Tweaked: rebalanced probability of returning fire vs. movement to cover. Unsuppressed / lightly suppressed units now more likely to return fire aggressively. * Removed: broken / unused variable "bcombat_skill_multiplier" * Fixed: smoke throwing should not happen anymore at night (interim fix via sunOrMoon command) * Fixed: minor bugfix Some other issues are still being looked in, they can make into v.0.17, more to come. Radio still in the works,it should cope with other features, such as investigate and chase enemy, without causing armageddon. That's not yet the case at the moment. RC internal debug / profiling / playtesting in progress. Hopefully v0.17 will be the first packaged / Steam workshop version of the mod.

While bCombat allows for local diversion (50-150m. depending on group combatMode), it respects active waypoints route (it does not inject any dynamic waypoints). So on default configuration the "feature" you see should be hardly related to bCombat, in my opinion. Let me know your findings.