fabrizio_t

Sure. It's already available on GitHub, see: https://github.com/fabrizioT/bCombat/tree/v0.16 ( direct DL link: https://github.com/fabrizioT/bCombat/archive/v0.16.zip )

Thanks for reporting, i'll doublecheck this.

I agree on what variable says. When some unit is detected and endangered it should be allowed to react (open fire) whatever the ROE. It works already so. Only notable exception i would like to see to this behaviour is to allow to disengage / withdraw, or more in general to force move. In this case movement should take priority over returning fire. A force move command would suffice.

Speaking of HOLD FIRE, the main difference between vanilla and bCombat is that the latter clears units to open fire ALSO if they're generally fired upon (e.g. bullets hitting near or flying by very close). Vanilla ArmA AI units *DO* break HOLD FIRE commands as soon as they feel "compromised", meaning they know enemy units detected and identified them as foe. Not sure whether this is a bad thing actually, looks to me more a (raw) feature than a bug. It's possible to force units to HOLD FIRE by script ( unit setCombatMode "BLUE" ), but that's a different story. Do you care to elaborate? I don't understand the question.

A further clarification on how various bCombat versions work Whatever the version you download (Armaholic, WithSIX, GitHub, Steam), you don't need to install anything else to play (except for CBA). Just if you wish to override defaults you have to edit config.sqf. All bCombat versions, except Steam Workshop version, already include an editable config.sqf for this purpose. STEAM only: If you have Steam Workshop version of bCombat and wish to customize your install, you have to separately download config.sqf from here and put into your @bcombat folder. I'd suggest to put auto-update off for bCombat if you are running an edited configuration (or your config.sqf will be wiped on mod update). ---------- Post added at 09:31 ---------- Previous post was at 09:29 ---------- It should work, basically.

If you wish to get rid also of those startup hints then change bcombat_startup_hint = true to false, line 287. Then add bdetect_startup_hint = false just below. ---------- Post added at 22:36 ---------- Previous post was at 22:35 ---------- Yes, removed ( I hope temporarily ) in order to get Steam packaging done and not needed anymore. All the mod is packaged into .pbo, as of v0.17 RC. Nothing more is needed, except for custom configuration ( in Steam case then you'd need config.sqf, to be put into your @bcombat folder). ---------- Post added at 22:38 ---------- Previous post was at 22:36 ---------- It's a feature, but i do agree that it would be better to have it disabled by default. Solution already posted, though (thx redarmy). ---------- Post added at 22:46 ---------- Previous post was at 22:38 ---------- Ditto ;)

Hi panther42, i think that part of Biki documentation is slightly outdated, regarding ArmA3. HandleDamage should now work like explained here: https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#HandleDamage So behaviour for HandleDamage is indeed different in ArmA3. I'd say that returning _body_part_damage for the player, from within the bcombat_fnc_eh_handledamage function, would suffice to solve the issue in ArmA2.

Hi panther42, nice to see that some oldtimer took some time to fiddle with bCombat files. Two quick remarks: * there's a (very simple) function checking for silenced weapon already within bCombat (bcombat_fnc_weapon_is_silenced). It has to be tweaked for ArmA2 though. * Not sure about the "Handledamage" issue, this EH is bound to bcombat_fnc_eh_handledamage function for any units. Also within ArmA3 player is definitely killable :) I think a bCombat ArmA2 version may be of interest for the community. For sure i woudn't be able to actively mantain it, too much effort. So if you're eventually willing to release an ArmA2 replica version of the mod, in the interest of community, then you're welcome. The only single thing i would ask is releasing an ArmA2 version being an (almost) 1:1 replica of ArmA3 version, features wise. Of course overall mod features may be discussed: you mentioned something you altered, now i'm curious on what you changed and why since this may be of interest for everybody. You may post back about this here, no need for PM. Thank you for your time.

Hi, just got back from Hong Kong. Massive jet-lag ... Now i'm going to start replying to questions, thanks for patience. ---------- Post added at 14:31 ---------- Previous post was at 14:25 ---------- bCombat uses setUnitPos in order to have units temporarily crouch or go prone in order to escape incoming fire. A lower priority command, setUnitPosWeak could be used, but i found it to be quite unreliable. It would be possible to exclude some units altogether from bCombat routines, but that would create some balancing issues. ---------- Post added at 14:32 ---------- Previous post was at 14:31 ---------- Almost ... hope to release v0.17 FINAL in the next few days. ---------- Post added at 14:45 ---------- Previous post was at 14:32 ---------- True. Default config.sqf is already packed into the PBO, so you need it only IF you are going to customize bCombat features. In general Steam workshop version is a good fire-and-forget solution, thanks to the auto-update feature. It comes with limitations though. Steam package does not include config.sqf, because workshop allows distribution of just a single PBO package. That's quite a limitation, as for instance no traditional readme, icons nor changelog can be bundled with it. If you are willing to customize your Steam Workshop bCombat addon, you can grab config.sqf from here: https://raw.githubusercontent.com/fabrizioT/bCombat/master/config.sqf Then you have to put it into your existing @bcombat folder. WARNING: Keep in mind that on any mod update steam will wipe your @bcombat folder and recreate it, so your custom config.sqf will be deleted. You may overcome this by setting auto-update feature off for bCombat within ArmA3 launcher. ---------- Post added at 14:51 ---------- Previous post was at 14:45 ---------- Well i guess that some bCombat features may collide, yet i have really no insight on VcomAI. bCombat is designed to cope with missions, campaign and higher level AI mods (e.g. those handling waypoints, strategic layer, etc.), while it would obviously collide with other mods micromanaging single AI units. ---------- Post added at 14:57 ---------- Previous post was at 14:51 ---------- Ty. I'm aware of this ZEUS issue, as it was reported by another user before. Basically bCombat self-disables itself for any units being "player", but within Zeus you are somewhat "possessing" them and not being registered as "player". Hence AI routines stay active for possessed units and collide with your commands. I've posted about this issue within the editing subforum (see: http://forums.bistudio.com/showthread.php?184170-Quick-question-how-to-check-if-some-unit-is-remotely-controlled-by-player-(ZEUS)), so far i know no workaround, yet it think this problem can be solved.

Yes, it should be working, the only problem is probably with defaults override.

Ok, 1) is wrong and the reason for config.sqf override not working. PWS alters the planned install path. You may try these simple steps: 1) create a @bcombat folder within your ArmA3 installation directory 2) put in there just your config.sqf file and edit it at will. 3) run the game. I'm positive these 3 simple steps will solve your issue, since i think it's just a simple path problem.

Plese doublecheck this: 1) do you have your "@bcombat" folder located into your ArmA3 installation directory? 2) Does that folder contain your config.sqf file? 3) are you running the game WITHOUT the -nofilepatching startup parameter ? If you correctly set debug to true within config.sqf, it's sery likely you have an issue with one or more of the above points.

I'm about to leave for a few days journey. So please consider i won't be able to reply for the next few days. I'll be back on the 23th. ---------- Post added at 07:14 ---------- Previous post was at 07:10 ---------- I'm sorry, but i haven't the answer to this problem. I have no clue on what TMR does "under the hood" and not using it myself, hence it's extremely hard for me to tell what's conflicting.

change to: bob = createagent [typeof player, position player, [], 0, "none"]; dostop bob; sleep 0.05; bob moveTo position player; It works?

Yes, at range AI units behaviour may be not optimal, sometimes not significatively better than vanilla. There are objective difficulties, but it's something i'm willing to enhance. ---------- Post added at 11:19 ---------- Previous post was at 11:01 ---------- I understand your concern. Userconfig was disabled in order to make Steam Workshop distribution possible (it has quite some constraints as of now). I'm not excluding reactivating it, but for now i'd like to avoid managing several different packages of the mod because it would be extremely time-consuming. I hope you understand. Then, while i always highly recommend installing bCombat as per-instructions, experienced people may experiment with other options. I've not checked it, but i think bcombat.pbo (which is the whole mod, contained into the addons/ folder) can be put basically anywhere. I would be grateful to anybody willing to check this out, since i can't at the moment. What's critical is config.sqf path, which is supposed to override default settings, not to declare them. Please consider that as long as you don't need to tweak default settings, you can simply omit config.sqf. It's not needed. Otherwise, for tweaking sake, you should necessarily put config.sqf into a folder named @bcombat, within ArmA3 installation directory. Also game should be launched without the -nofilepatching startup param. Hope this makes sense, take care.

Hi, thank you for reporting this (documentation) issue. An undocumented setting is responsible for toggling bDetect hint. Please add into config.sqf, just below bcombat_startup_hint setting line: bdetect_startup_hint = false; This should disable bDetect hint.

A lot of work was done today, in order to move towards v0.17 FINAL. Most of the work was done on the investigate behaviour, which is crucial for the next few steps. This behaviour is responsible for recon activity and greatly increases group's environmental awareness. AI leaders are already capable (within v0.17RC) to send out units in order to investigate nearby sources of noise (threats) such as gunfire, explosions. There are fixed thresholds limiting the distance recon units can travel, not to collide with planned waypoints route. The implementation i'm currently working on is a further development of this concept. Hardcoded distance thresholds are gone. The distance some investigating unit is allowed to travel is being defined by 4 dynamic criteria: 1) group behaviour 2) group combatmode 3) waypoint type and completion radius 4) group proximity to its current waypoint / destination. That's quite some difference, a step towards rules of engagement. It means for instance that the leader of a group on a HOLD waypoint and in GREEN combat mode ( = hold fire) will usually avoid sending out scouting units, except for very close (potential) threats. On the contrary the leader of a group close to its SEEK & DESTORY waypoint and having RED combat mode ( = engage at will ) is likely to send out some units to investigate noise, even many hundreds meters away. An in-between case: a group having a MOVE waypoint and YELLOW combat mode is more likely to attack nearby threats the more it approaches its waypoint and viceversa. There's more: once any threats are eventually discovered by investigating / recon units, AI leader may move the whole group to counter them, depending on the outcome of the same criteria. All this basically means that AI groups should be able to adopt more adaptive tactics on the battlefield, without derailing from the planned route (All this logic may be considered as a termporary tactical diversion).

Ty. Tried with BIS_fnc_isCurator so far, no luck. I'll try following your advice ---------- Post added at 21:20 ---------- Previous post was at 21:08 ---------- Tried with this quick and dirty function: fnc_is_curator = { private ["_ret", "_x", "_curator"]; _ret = false; Scopename "isCuratorMain"; { _curator = getAssignedCuratorUnit _x; if( _curator == _this ) then { _ret = true; breakTo "isCuratorMain"; }; } foreach allCurators; _ret }; but myUnit call fnc_is_curator always returns false. Basically curator is bis_curatorUnit and getAssignedCuratorUnit always returns bis_curatorUnit as well (even if player is remote controlling some unit).

You gave me great news. Path looks fine, thanks. Enjoy.

finally! Happy they solved this issue.

Thanks. Please can you or anybody give me feedback about PWS version ? I hope it's working ok, without any path issues.

Thank you. ---------- Post added at 13:26 ---------- Previous post was at 13:25 ---------- In the meantime i've added the 4 download links (Github, Steam Workshop, WithSIX and Armaholic) onto the first page of this thread, for future reference.

Thank you for your kind reply. I've requested the addition of the mod on WithSix myself, about a week ago, so don't worry. I'll claim the mod in order to actively maintain it. For the time being i think it would be preferable to use GitHub version though, since it's already managed directly by me. About MP: it's not officially supported, but bCombat does work fine when used on server only (e.g. coop against AI): i got plenty of positive feedback from people actually running bCombat on their server. Full MP impementation is not in the works as of now, since much has still to be done on SP before ... ---------- Post added at 12:45 ---------- Previous post was at 12:35 ---------- IMPORTANT NOTICE: WithSIX page for bCombat is: http://play.withsix.com/Arma-3/mods/YGrkCgNy4xGOFAAVF72WTA/bCombat-AI-Mod Please consider i'm not yet mantaining the code here nor the information, which is a bit messed. I'll inform you when i get in full control of WithSix page (i have to sort an issue with my BI profile first). In the meantime i strongly encourage using either: GitHub version: https://github.com/fabrizioT/bCombat Steam Workshop version: http://steamcommunity.com/sharedfiles/filedetails/?id=314397752 GitHub version excels for ease of configurability, while Steam version is almost perfect for getting a grasp of the features with almost no effort (subscribe, activate from within official ArmA3 launcher and play). Except for ease of configuration, these 2 versions are identical.

Should be so, still i wasn't able to claim and directly manage the mod onto Six yet. I'd suggest using the GitHub package instead, while i setup the Six account completely. ---------- Post added at 07:27 ---------- Previous post was at 07:19 ---------- You may easily check whether bCombat is running by checking if you see a hint ("bCombat vX.XX has started") at top-right of the screen, when launching any missions. I'd suggest putting the mod into its own "@bcombat" folder into ArmA3 install directory, not to encounter any path issues. For sure "config.sqf" is expected to be there (<arma 3 directory>/@bcombat/config.sqf), so with a different setup it will be ignored (hence mod will run on default settings). That's probably what's happening to you.

Hi, i am aware of that problem, more a hassle than an issue. It's already fixed, you just have to re-download the package from GitHub, or just the bcombat.pbo. See my previous message for reference: http://forums.bistudio.com/showthread.php?171436-OPEN-BETA-SP-bCombat-infantry-AI-Mod&p=2788710&viewfull=1#post2788710 ---------- Post added at 07:10 ---------- Previous post was at 07:06 ---------- Personally i keep damage multiplier to default, since i how BIS will finally fix damage values. Altering it however won't affect anything else than infantry units on foot (it changes the amount of received damage, not the power of the bullet).