fourjays

Don't take this as official word, but a few of our members updated to v3.5.0 by accident and haven't experienced any issues with running the ACRE plugin.

To those having issues with radios cutting out unexpectedly in an op, our group used to have this problem too. The fix, as someone already suggested, was to run with the terrain coefficient set to 0. However, since ACRE released the new "Signal Mode" option we have switched to the "Simple LOS" option which allowed us to set the terrain coefficient back to its default value. We've been running 20-30 player operations daily for a few months now with this mode and it has been fantastic. I posted our working CBA settings on the ACRE Github here: https://github.com/IDI-Systems/acre2/issues/264#issuecomment-598664706 @ACRE_Team It looks like Teamspeak have released version 3.5.0 with a new plugin API version. Do you know if we need to wait for a plugin update?

Last night we did op preparation like we would any other night. Zero idle kicks. So looks like setting votingTimeOut, roleTimeOut, briefingTimeOut, debriefingTimeOut and lobbyIdleTimeout to -1 disables it. The odd thing is the kickIDs don't seem to match the documentation as I explained above. However, as we barely ever use admin kicks in our group we have that set to a short timer for now. Hopefully the kickIDs can be better structured in the future so that manual kicks can be made more permanent without them applying to the fairly common signature check failures too. Our final config is as follows: kickTimeout[] = { {0, 60}, {1, 30}, {2, 60}, {3, 30} }; votingTimeOut = -1; roleTimeOut = -1; briefingTimeOut = -1; debriefingTimeOut = -1; lobbyIdleTimeout = -1; Hopefully that helps other groups out.

This might be an unforeseen consequence, or a documentation issue, but it seems that signature checks are not being handled under "kickID 3" as the Wiki suggests but instead "kickID 1". With the same config as above, we just had a member (Cerven) join the server a while after a signature check failure, only to get the "until mission restart" kick. If the documentation is right this should be a 30 second timer with the above config. 16:20:41 > Player [CPT.] Cerven connecting 16:20:42 > Player [CPT.] Cerven connected 16:23:15 > Player [CPT.] Cerven: Signature check timed out 16:23:15 > Player [CPT.] Cerven kicked off: 16:23:15 > Player [CPT.] Cerven disconnected 17:14:28 > Player [RCT.] Polarium kicked off, Steam ticket check failed: Steam authentication failed. 17:14:28 > Player [RCT.] Polarium disconnected 17:14:32 > Player [CPL.] Caitlyn disconnected 17:19:58 > [CPT.] Cerven uses modified data file 17:20:02 > Player [CPT.] Cerven connecting 17:20:02 > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart 17:20:02 > Player [CPT.] Cerven disconnected 17:20:21 > [CPT.] Cerven uses modified data file 17:20:25 > Player [CPT.] Cerven connecting 17:20:25 > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart 17:20:25 > Player [CPT.] Cerven disconnected 17:22:56 > [CPT.] Cerven uses modified data file 17:23:00 > Player [CPT.] Cerven connecting 17:23:00 > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart 17:23:00 > Player [CPT.] Cerven disconnected 17:27:23 > [CPT.] Cerven uses modified data file 17:27:27 > Player [CPT.] Cerven connecting 17:27:27 > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart 17:27:27 > Player [CPT.] Cerven disconnected It could be related to the -1, but that side does appear to be working so far. Not seen any idle kicks at all since setting that. I've asked members to not avoid it tonight to try and make sure.

It looks like setting those variables to -1 might disable it. At least, we didn't experience any idle in our operation last night with the following settings: kickTimeout[] = { {0, -1}, {1, 30}, {2, 180}, {3, 30} }; votingTimeOut = -1; roleTimeOut = -1; briefingTimeOut = -1; debriefingTimeOut = -1; lobbyIdleTimeout = -1; Could also be that it didn't occur because our members are now pushing through quickly just to avoid the idle kicks.

Setting the kickTimeout values to 0 does not appear to work. It results in the same as -2 (kicked until server reboot). We're checking to see if it is already implemented, but would be good if lobbyIdleTimeout, etc could be set to -1 to disable it entirely.

Can the roleTimeout, briefingTimeout, debriefingTimeout or lobbyIdleTimeout be disabled in any way? While these settings are probably great for KOTH servers, they are already a major headache on our group's coop server. Our typical operation starts with organising members into roles on the slotting screen until all necessary roles are filled, then proceeding through to a spawn area where the mission is planned. These settings are kicking members who are just waiting for us to get ourselves organised. Additionally, is there any idle timer running once in-mission? A couple of our members have been kicked after going all the way through with messages indicating that it is again an idle timer. They probably were idle (people often go AFK at this stage) but this isn't something we want. Thanks

Awesome, thanks!

@firewill Just wanted to let you know about a problem with both the GR7 and GR9 variants of the Harrier - they won't stop when taxiing. 😅 No matter how much I try, they will not go below 12km/h. If I spawn them via Zeus, they immediately start rolling too. Otherwise it is a fantastic mod. 😁

First of all, thanks for another awesome 3CB mod. 👍 Just wanted to give a small bug report - it seems the T-34 is not being drawn beyond 300m unless you zoom in (right-click zoom or magnified optics). Other tanks in the pack appear normally above 300m ranges. EDIT: Divaya beat me to it. 😅

I have been looking at VCOM AI (mod) for our group and am overall really impressed with it. I've had a few bugs with 3.1 that are fixed according to the changelog for the 3.2 pre-release, so I was eager to give that a go. However, while a load of options appear in CBA's Addon Options with v3.1, none appear at all with v3.2 (in editor, single player or while running on a dedicated server). Is this a known bug with the pre-release? Thanks

Think you mean 1.84? But it would be: In your Steam Library right-click on Arma 3 and go to Properties. Go to the Betas tab. In the "Enter beta access code to unlock private beta" field enter: Arma3Legacy184 Click Check Code. It should now say that the code has been accepted. In the select list above the code field, you should now be able to select "legacy - Legacy Build (1.84)". Click Ok. In the library it should now say "Arma 3 [legacy]" and it will begin downloading the rollback.

So should we expect a hotfix soon?

Yea. While our group doesn't use mods that are no longer maintained, I know a lot do, and there's a lot of mods that will never get new keys. Hopefully it is a small oversight on BIs end and will be fixed soon.

We had to disable the signature check too. I'm not sure if the actual check is broken, or if mods need to update their keys.