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

This v1.58 update seems pretty disastrous from a server admin point of view so far and also has a pretty major flaw/bug that basically requires the server be rebooted to change missions and retain a difficulty. Prior to this update our group has each difficulty set with the same custom settings in the server profile. This was done as mission makers frequently forgot to set the difficulty. With 1.58 this no longer functions on anything but the "Custom" difficulty, set via the DifficultyPresets class in the server profile. Ok, so that's a minor backwards step and people just have to remember to set it again. Except now they can also edit those settings and they get saved to the server profile. Meaning if someone makes a change (by accident or otherwise) that change is permanently saved to the server profile. I have yet to discover a way to disable this because there is no documentation on what options there are for configuring the new difficulty system for the server. The biggest problem though, and I am sure this is a bug, is that once #missions has been used from within game the difficulty options are disabled and the difficulty set to Regular. This means everytime the map is changed I have to reboot the server to have a difficulty other than Regular! If I could set what options are used for Regular difficulty like before this wouldn't be an issue, but that option was apparently taken away! How can I fix this mess? All I want is fixed options, that can't be edited and are retained between missions. The old system provided it, while the new one has turned difficulty options into a free for all server rebooting mess. Sorry if this is a bit rant-y, but I'm pissed off after spending two hours trying to guess what options I have because Bohemia doesn't document anything, and discovering what seems like a pretty huge and obvious flaw that should have been uncovered by Bohemia themselves.

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.

While our group really likes both NIArms weapons and JSRS, we don't use large quantities of the NIArms weapons and only have the (rather large) All-in-One pack for the JSRS compatibility. Is there any possibility of the NIArms compatibility PBO being broken up to match the individual weapon packs? E.g. compat_aks.pbo, compat_m4s.pbo, compat_g3s.pbo, etc. Or if that is not possible (I appreciate it may be a lot of effort), is the source code for the compatibility files available anywhere so I could build our own PBO with just the packs we use? Thanks

Ok, solved it. Answer was that requiredAddons needs to have cba_settings defined. The UI errors are because of the way I have RscText, etc defined within the mod. Now have to figure out how to inherit RscText, etc instead, whichever for whatever reason has never worked the way I'd expect it to based on other inheritances in Arma. But that's nothing related to CBA.

I'm trying to add a custom CBA setting to handle something new I'm doing in one of our groups mods. I've followed the instructions here on how to add your own settings, yet they never appear in-game. In my config.cpp I have added the event handler like so: class Extended_PreInit_EventHandlers { class bwi_armory { init = "call compile preprocessFileLineNumbers '\bwi_armory\XEH_preInit.sqf'"; }; }; With requiredAddons set as follows: requiredAddons[] = {"A3_Modules_F", "A3_UI_F"}; And then in the XEH_preInit.sqf file I have the following code: diag_log 'BWI Armory PreInit...'; [ "BWI_Armory_Test", // Internal setting name, should always contain a tag! This will be the global variable which takes the value of the setting. "LIST", // setting type "Test", // Pretty name shown inside the ingame settings menu. Can be stringtable entry. "BWI Armory", // Pretty name of the category where the setting can be found. Can be stringtable entry. [ ["A", "B", "C"], ["A", "B", "C"], 0 ], // data for this setting: [min, max, default, number of shown trailing decimals] 1, // "_isGlobal" flag. Set this to true to always have this setting synchronized between all clients in multiplayer { params ["_value"]; hint format["Armory says %1", _value]; systemChat format["Armory says %1", _value]; diag_log format["Armory says %1", _value]; } // function that will be executed once on mission start and every time the setting is changed. ] call CBA_Settings_fnc_init; The RPT has the diag_log message logged, so the XEH_preInit.sqf file is firing correctly. But CBA_Settings_fnc_init doesn't appear to be doing anything (no setting, no errors, no logs). All of the settings from ACE/BWA/STUI appear normally, so I don't think the problem is with CBA itself. I read in an issue that it could be caused by starting Arma with -world=empty, but I've always run with that and settings from other mods appear without issue. Tried it anyway, and it makes no difference. I looked through how bwa3_navipad handles it to see if I was missing something (as it's a much simpler mod to understand compared to ACE's macro mess). Other than the script_macro.h/script_component.h/xeh_prep.sqf files I don't see anything. I looked through the code in those files and all I see are constants defined for the UI elements and macros for logging errors. Checking in Extended_PreInit_EventHandlers in Config Viewer, I see no difference in the resulting init line that is being set compared to the ones for ACE/BWA. I tried the same implementation in a mission file instead (description.ext + XEH_preInit.sqf), and that works fine once the mission is run. The settings set via the mod still don't show though. Can someone offer any advice here? The instructions on the CBA site make it seem so easy, yet I'm getting nowhere and can't see what I'm missing. EDIT: Forgot to mention that adding "cba_settings" into requireAddons results in errors about UI elements as soon as the game starts. There's a lot, but they're like this: 14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.textureNoShortcut'. 14:08:37 Warning Message: '/' is not a value 14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'. 14:08:37 Warning Message: No entry '.left'. 14:08:37 Warning Message: '/' is not a value 14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'. 14:08:37 Warning Message: No entry '.top'. 14:08:37 Warning Message: '/' is not a value 14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'. 14:08:37 Warning Message: No entry '.right'. 14:08:37 Warning Message: '/' is not a value 14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'. 14:08:37 Warning Message: No entry '.bottom'. 14:08:37 Warning Message: '/' is not a value

@DwardenI'll see what I can do, but it may be a while. Given how simple the script in the mod is I should be able to replicate it as just a mission file.

@Dwarden We've got to the bottom of what is causing our Zeus CTDs. It is one of our own mods, but I also believe it might ultimately be a bug in Arma. We have a "respawn template" that deletes dead bodies in the spawn area. This runs "onPlayerRespawn". It seems that the Zeus CTD occurs for any Zeus whose character's FOV sees the body of a Zeus get deleted. Non-Zeus player's do not trigger the crash at all. Hope that helps in some way.

Sorry for the delayed reply. I posted this just after the op where we discovered it, and mid-op I switched to the latest performance binary to see if that fixed it, but it did not. If there's newer ones I'll give them a go tomorrow. Might have more information from tonight's operation. The Zeus reported that it occured when anyone died within his characters FOV (not Zeus camera FOV). So if someone dies in Zeus camera, it is fine, but if they die within the FOV of his player character (even if it isn't in Zeus camera at the time), they get a CTD. We believe this also explains our prior issue where Zeuses respawning kicks the other Zeuses, as we were all standing close to each other. We'll test it further and try to narrow it down to just being base game Arma 3 as we run with a lot of mods. In case these are useful regardless though, these are the RPTs/crash dumps we have so far. One from myself on the 15th October (https://www.dropbox.com/s/bykp90roqfwxno7/fourjays_arma3_x64_2017-10-15_22-32-10.zip?dl=0), one from the Zeus who experienced the issue tonight (https://www.dropbox.com/s/1mqtumhebnhajuq/0mega_arma3_x64_2017-10-21_20-08-58.zip?dl=0). Thanks

Good that the Zeus crash on map opening was fixed, but our group is facing a new crash with the latest hotfix. If there's 3 or more Zeuses, and 1 respawns (via menu, script or plain old death), it will almost always result in the other 2 experiencing a CTD (not the one who respawns). Coupled with the still un-fixed Zeus-not-opening-until-they-respawn bug means that we can't have more than 2 Zeuses at all in our operations right now. :( Has anyone else experienced this or have any information to help narrow it down?

Thank you! I've been trying to find the cause of this issue for months then stumbled across your post and confirmed this was what was causing it. All along I've been thinking it was something wrong with the server hardware or setup. Wonder if RHS will actually fix it.

Are the engines of the vehicles you are targeting turned on? Since 1.70 it seems that the thermal signature of a vehicle is actually taken into account, so cold targets aren't lockable. We're having a problem with laser locking though. Can turn the laser on, can lock onto it, but the missile will not follow the lock and instead goes straight ahead. Almost every laser-capable missile in Arma has the issue since 1.70 - in the case of RHS it is because the hellfire inherited from a class that was changed in the Jets DLC update (although the RHS helicopters can't even lock without a fix). Could it be something similar here?