fabrizio_t

Hi, you'll have to put config.sqf in this exact position, to be loaded: <your ArmA3 main folder> / @bcombat / config.sqf so you have to create a folder named @bcombat into your ArmA3 main folder. Then put config.sqf there. ---------- Post added at 12:56 ---------- Previous post was at 12:55 ---------- Bottom of config.sqf, set: bcombat_startup_hint = false;

Correct. Thanks Jackson Snow.

As long as you play with AI which is local to server (e.g. COOP) there's no need to install on clients. ---------- Post added at 12:25 ---------- Previous post was at 12:22 ---------- I'll consider mentioning MP features into first post, thanks. Ignore the fancy anims, they're just a couple rolling animations i've added in order to add some variety to AI behaviour. Whether they work or not does make any functional difference. ---------- Post added at 12:32 ---------- Previous post was at 12:25 ---------- I'll consider your suggestions, yet they'll require some effort to be coded. ---------- Post added at 12:33 ---------- Previous post was at 12:32 ---------- Thank for support serjames, you're actually the bCombat MP authority ;)

Native bullet detection works only with latest ArmA3 DEV builds, as far as i know. As reported by many people, bCombat already works on dedicated server, except for minor issues (fancy animations).

Yes. Nice feaure.

Still not solved. Looks like primaryWeaponItems is broken on some units, such as mk8 mortar (possibly other static weapons too). It basically does not return an array as expected. Looking for a workaround. EDIT: fixed with a "isNil" check. Published. By the way, did you ever try issuing a FIRE ARTILLERY command to a mk8 mortar unit within your group positioned on a slight slope (position cursor over target, press F-number of unit, then FIRE ARTILLERY) ? It's broken, horribly broken ... try yourself and see him rolling over.

Looks like it's some modded weapon. Scripting command "primaryWeaponItems" fails on it. However i think issue is now possibly circumvented, try merging this updated common.sqf: https://github.com/fabrizioT/bCombat/blob/v0.18/lib/common.sqf Downloadable v0.18 is already patched for others. Let me know whether the fix works. Ty.

Thank you for your feedback. We ( you, Ollem and me ) had good times working together on shaping suppression for ArmA3. It was pleasing, instructive and interesting. Now the PROs are finally moving. It was about time ;) ---------- Post added at 11:28 ---------- Previous post was at 11:17 ---------- UPDATE: bCombat v0.18 FINAL released on GitHub and Steam Armaholic release following soon. Branch overview Changelog Release notes: Debug / dev mode is OFF by default NVgoogles now not removed by default Surrendering now disabled by default Regarding WithSIX: to anybody of the SIX staff eventually stumbling here: please refrain using GitHub package for WithSIX bCombat version, use this .pbo packed version instead. It's the same as Steam Workshop package, hence you'll not be able to configure it via config.sqf (not bundled), unless you download and save it seperately. However, i strongly recommend GitHub version of the mod to "power users".

Hi Juhak and welcome. Regarding SIX, please consider i'm not the person packaging the mod for distribution, nor i have real control on what's released there. One limitation of SIX is that requires mods to be put outside ArmA3 folder, which clashes with the opposite requirement by bCombat (we may debate whether this is orthodox or not, but there're reasons on my side for this choice). The bcombat.sqf error isn't really a bug, but a consequence of the package not being installed on WithSIX as per-instructions. If that's not possible, the way around would be to distribute via WithSIX a packaged version of the mod, which can be mantained, updated and released by me (albeit with a lesser frequence). I do this already for Steam workshop version of bCombat. Don't get me wrong, i'm not bashing WithSIX nor criticizing the wise people managing it, it's just that how bCombat is handled there is something out of my control.

Thank you, looking into these now. EDIT: Error #1 was fixed, as it was a simple typo i missed. Fix is published on GitHub, only change was in line 1928 of lib/common.sqf Error #2 is sneaky, thought it was fixed already, but it wasn't. Looking for the culprit. EDIT2: Also the second error is gone i guess. It could be caused by uninitialized units disembarking from vehicles, or by units spawned at runtime. Incomplete initialization was the culprit for both cases: i reworked a semaphore to take care of the issue. Download updated package from GitHub to get both errors fixed: https://github.com/fabrizioT/bCombat Sorry for inconvenience, thanks Kremator for reporting.

Teams not groups, just to be clear ;) Now i've witnessed some really brutal 2 vs 2 squad fighting in the forests on Gorgona (go gheck this little, but beautiful map: http://forums.bistudio.com/showthread.php?188076-Gorgona-Italy-(terrain)). I've had a few intermittent errors popping up, other than that upcoming version is playing really fine imho. ---------- Post added at 23:40 ---------- Previous post was at 21:58 ---------- Ok, after some thorough testing, i finally decided to release an update to bCombat v0.18 BETA. The updated files are available only on GitHub: https://github.com/fabrizioT/bCombat Changelog to be updated. The intended audience are bCombat enthusiasts ;) Other people may want to wait for a fine-tuned, polished official release. Debug mode is ON: you know the drill, set bcombat_dev_mode = false;. Files are subject to change before v0.18 FINAL release. I noticed no major showstoppers, still problems may occur: install and try at your risk. ONLY if you're running latest beta, try setting in config.sqf : bcombat_ballistics_native_handler = true; This in order to run the brand new BIS-powered close-bullet detection instead of bDetect.

Nice map, i'm enjoying it while testing bCombat. Shame my measly notebook can't handle the forested area near the cimitero.

I've just finished a long playtesting session on v.0.18 release candidate. 3 major improvements are coming with this version: Ability to choose between bDetect and BIS native close-bullet detection ( i hope the latter will finally render bDetect obsolete ) Better fulfilling of tasks: units are prioritizing way more their assigned tasks, especially MOVE tasks and special actions. Dynamic teamplay: units are now able to dynamically merge / split teams: given their task, reciprocal position and planned destination they are now able to choose whether to go alone, or in teams. I'm particularly proud of the latter feature. More fine-tuning needed, in order to flawlessly "integrate" investigate behaviour into the new logic. ---------- Post added at 18:08 ---------- Previous post was at 18:04 ---------- Please doubleheck installation instructions: https://github.com/fabrizioT/bCombat Be sure there are no old leftovers before reinstalling. In my opinion, it's likely you're not installing bCombat into ArmA3 main folder, or bCombat folder is not named as expected. Let me know if issue persists.

Speed is useful for handling ricocheting bullets differently, for instance. Direction of bullet would be useful for adding RTS elements ( already coded them in bCombat): effect on morale of suppressive fire from flank, back or higher ground (sky also) can be tweaked. Some vehicles move fast, so i can't simply rely on derivating direction based on checking actual position of shooter and position of bullet. ---------- Post added at 12:13 ---------- Previous post was at 12:08 ---------- Thanks, let me know. I find it strange having an unit which was detected already to be repeatedly re-discovered each few seconds, i think the way it worked originally ( a single enemy was just detected once ) was better. Increased frequency for near enemies check would be a better solution imho.

Nothing released for the moment. BIS own engine based bullet detection is working fine within internal bCombat test build. That's good. A newly introduced setting will allow switching between bDetect and BIS native ballistics check: bcombat_ballistics_native_handler = false; Setting it to true will activate BIS engine based close-bullet detection (shutting down bDetect). Default will be false: This way we won't lose backward compatibility. I'm still testing some other features, namely some logic constraining AI units to assigned tasks. More to come.

Ok, _dangerCause = 9. An important question: are we able to access to the bullet object itself via some variable from within danger.fsm? At least speed and direction will matter. Awaiting some answer on the DCEnemyDetected vs. DCEnemyNear matter. Ty.

Good news. I'm testing an updated version, which fixes this issue and allows to hook the brand new close-bullet detection introduced by BIS. If that's proved working it may definetely help framerate and render bDetect obsolete.

It's due to the changes made to ArmA3 BETA builds within the last 3-4 days ... Issue does not affect stable ArmA3 build. I'm looking into it.

Sounds good, eager to hook this into bCombat for a comparison ... Another question, somewhat related: some weeks ago i think frequency of enemy detection within danger.fsm ( DCEnemyDetected ) was drastically increased. At least that's what i noticed. I'm still wondering way DCEnemyDetected was tweaked instead of DCEnemyNear, can you give any insights on this choice? Thanks. EDIT: one more ... i can't see mention of dcbulletClose into danger.fsm ( characters_f.pbo, "scripts" folder). What's its _dangerCause number? 9 ? Ty.

I've some questions too: 1) how close a bullet should fly in order to be detected? 2) detection of close bullets works whatever the distance of unit from the shooter? 3) does detection consider bullet speed (so excluding grenades, ricochets) ?

They took their time ... However, that's good news.

I'm already working on radios, i think they're a worth addition. Please consider that any groups on the battlefield are "attracted" by gunfire already. As long as bcombat_allow_hearing = true, bcombat_allow_hearing_coef controls how far units can hear gunfire ( distance = muzzle speed / bcombat_allow_hearing_coef, about 300-500 meters in average). Then bcombat_investigate_max_distance controls how far groups are eventually allowed to dispatch units to check the source of gunfire. There are some constraints to investigate behaviour though, for instance current waypoint proximity, waypoint type and combat mode are taken into account. This means for instance that a group which is given GREEN/BLUE combat mode won't ever investigate, while a group with a HOLD or SENTRY waypoint will investigate in close proximity. Groups with RED combat mode and a SAD waypoint, on the contrary, will investigate a larger radius (the hardcoded maximum radius is 1000 meters at the moment, in order to avoid firefights syphoning groups from all over the map). I guess i'll have to write a post on the matter ...

There are many ways. Speaking of gaming style, these tips may be obvious to any experienced bCombat players, but still i think it is worth mentioning them: Split your forces and attack simultaneously from multiple directions at once. This will multiply the suppression effect, as fire from flank / back conveys more penalty (up to +100%). Identificate targets, then open fire from distance. Units attacked from unknown sources suffer an additional penalty. The most effective way to stay (relatively) undetected for longer time is putting in as much distance as possible, so machinegunners are most suitable for this task (given their better range). Attack from higher ground whenever possibile, as this adds another suppression penalty to the target. Things work both ways: be careful when attacking enemy sitting on top of a hill ... Suppress enemy by firing over his head, don't aim at nearby ground! That's important, as bullets hitting ground disappear quickly and there's a higher chance for them to be missed by the suppression routine. bDetect can catch bullets flying up to 6 meters over units' head, by default. Suppress enemies for long time and with short bursts, rather than with a high concentration of fire for short time. Suppression effect per-second is capped, not simply directly proportional to the number of bullets flying by in a single second. Suppress leaders! You'll hinder enemy group effectiveness and maneuvering. Also you'll provoke loss of leadership: this may cause units to surrender if you're close enough and their morale is shaken. Be careful when fighting skilled enemies, as they're harder to suppress. They may actually end up suppressing you! My favourite tactic is to split my group into a "recon" and a "fire" section, the latter including the machinegunner(s). I lead the "recon" section as we look for enemies. We find and identify them, while keeping undetected and holding fire. Then i command the fire section to some position suitable for attacking from distance: on flank or back of enemy, at about 400 meters. Beware, it's crucial to pick a safe approach path for them! Finally i order the "fire" section to open up, while i lead the "recon" section in a charge to point blank from a different direction. Usually i pop some smoke in order to conceal our initial movement. Normally enemy suffers very high casualties by doing so ... If that's not enough, you may choose to go the the hard way, by changing the config: Raise bcombat_penalty_bullet value, this directly affects the morale hit caused by any bullet whizzling by close. Reduce bcombat_incoming_bullet_timeout: any units won't register more than a single suppressing bullet within bcombat_incoming_bullet_timeout seconds. By default this means 1 bullet each 0.1 seconds = 10 bullets per second. Be warned that reducing bcombat_incoming_bullet_timeout may increase CPU load in pitched firefights. There's a lot of other settings you may tweak, by these two alone have very sensible effects. let me know if anything i wrote helps improving your playing experience. I hope so.

You're welcome.

It is odd indeed, i'm double ckecking it. Thanks for reporting. ---------- Post added at 18:19 ---------- Previous post was at 17:15 ---------- Repackaged the .pbo for beauty, now internal path is a bit more streamlined ;) It's available on Github (not critical to update, since it does not fix anything other than some ugliness).