killswitch

No, that parameter does not work in Linux. Not yet. However a BIS developer has noted that they are working on "a fix" for that.From the "Linux Arma Server" Skype chat, on May 15, 2014:

This appears to be a bit of a Heisenbug. You state that: so it is not just the new RC1. Also, there appears to be two issues here (possibly related): * The server sometimes never starts up fully. This happens both with RC1 and beta5. * The server crashes when you are setting up one of the default BIS coop missions and both CBA and RAV_Lifter is loaded. I'm scratching my head here, but I'll keep trying to figure out what the issue is. EDIT: I see you are launching the server with -exThreads=0. Try removing that or use -exThreads=1

I am so far unable to reproduce this. Three questions: Exactly what is a/the "default BIS COOP mission"? (There are more than one coop mission delivered with A3) Are you running the stable branch (1.18.124200) or the dev branch when the crashes occur? Is your server using a full A3 client install or the dedicated server package (the latter having Steam App Id 233780)?

No, no ideas.We'll need your help with this. Systematically remove addons until you can isolate which minimal combination of CBA A3 RC1 and <specific addon or mod here> crashes.

Most of that output is normal, but not that one. Make sure you haven't got any other processes using port 27016.

OC0, OC1 and OC2 represent three different measurements of the number of objects in a running mission (OC = Object Count). If you look at the ASM.ini file you can see the default script commands that are used to update these values: OC0 is the number of objects currently in the mission (vehicles, players, AI, crates, tents, bunny rabbits and so on...) OC1 is the number of vehicles in the mission. OC2 is the number of "mission created objects" (*). You can use OC0-OC2 to report any three values you can think of by changing the script commands in the ASM.ini file. EDIT: OC0-OC2 must be positive numerical values. See Fred41:s comment below. (*) See allMissionObjects

Unfortunately, the Arma 3 server is compiled against a newer version of the C++ runtime libraries than what CentOS has. Fixing this can be done by 1 - using a Linux distro with a newer libstdc++.so.6 (CentOS won't have this until RHEL 7 / CentOS 7. For example, recent Fedoras, Debian 7 and Ubuntu 12.04 have it) 2 - looking at post #67 in this thread. 3 - building a newer set of runtime libs for your CentOS and use that when starting the Arma 3 by way of LD_LIBRARY_PATH. This is not for the beginner. 4 - finding someone who has done #3 and has a new enough libstdc++.so.6 you can use. I am someone. Here: libstdcpp-for-arma3-centos6.tgz. Unpack that archive into the folder where Arma3 is installed. Then set LD_LIBRARY_PATH accordingly. For example: export LD_LIBRARY_PATH=/path/to/arma3/lib PS. Don't run the A3 server as root.

LeMalk, that's the error you see if the server(s) you connect to do not allow CBA.

No, wait I can actually reproduce this. Without having CBA loaded, or any other mods for that matter. Here are the steps: Launch A3 and enter the mission editor Place an AH-99 Blackfoot with the player as gunner. Set "Special" to "Flying". Preview the mission and try the optics view. This will just zoom in the view. No optics. Abort the mission and go back to the editor Preview the mission again and try the optics view. The optics are back - the TV overlay is shown. Conclusion: not a CBA bug. The problem can be reproduced with a clean, vanilla ArmA 3. Also, the problem was reported in the A3 issue tracker two days before it was attributed to CBA in this thread. See: 0018732: AH-99 Blackfoot optics won't work ArmA 3 version: 1.18.124200 (stable branch)

I have done exactly that and cannot reproduce the problem:1) In the A3 mission editor, place a flying blufor attack heli with the player as gunner. 2) Start mission. 3) Tap right mouse button to enter optics view. Result: I see the gunner optics ("TV" screen overlay) both with and without CBA_A3 b5.

Yes. There is a 100% chance that it will be looked at. Unable to reproduce it using ArmA 3 1.18.124200 and @CBA_A3 beta 5. Please add a detailed description of how to reproduce the problem to that ticket.

You are escaping the closing double quote there. Remove the last backslash. Is that from the server log or your ArmA 3 Windows client log? That looks like you try to load a mission that uses the ALiVE mod along with a few other third-party aircraft addons and whatnot, but neither the ALiVE nor the other addons have been loaded in the client (or server, depending on where that message appears)Are all of those addons included in the many 8th<something> mod folders you have listed in the -mod parameter?

File and directory names on Linux filesystems are case sensitive - for example, "Hello.txt" and "hello.txt" are two different files. (In Windows file systems, there's no such distinction). The Linux dedicated server expects files and folders it reads to be in all-lowercase. Make sure all the files and folders you upload have their names changed into lowercase letters. Then, edit the -mod parameter accordingly.

The savegame problem with ST HUD, which is not caused by CBA, has been fixed - use the March 2014 (or later) version: ST HUD thread

No. What kju means is: which of the mods, apart from CBA, is it that gives you "save breaking" with CBA A3 b5 but not with b4? Also, what exactly do you mean by "save breaking"? What is it that happens (or doesn't happen, if that is the case)?

The 05 release of the addon has a broken .bisign signature (it does not pass a DSCheckSignatures.exe check) X:\@VTS_Weaponresting> dschecksignatures addons Keys Signature addons\vts_weaponresting.pbo.vts_key.bisign is wrong

v3.1.0 has the following config error, as reported in the Arma 3 .rpt file: File outlw_magrepack\Configs\MagRepack_Dialog_Main.hpp, line 507: '/MagRepack_Dialog_Main/Controls/MR_ButtonClose.h': Missing ';' at the end of line

v2.3 has the following config.cpp errors, taken from the ArmA 3 .rpt file: File tao_foldmap_a3\config.cpp, line 78: '/RscTitles/Tao_FoldMap/Tao_FoldMapStatusBar.sizeEx': Missing ';' at the end of line File tao_foldmap_a3\config.cpp, line 88: '/RscTitles/Tao_FoldMap/Tao_FoldMapStatusBarTextRight.sizeEx': Missing ';' at the end of line File tao_foldmap_a3\config.cpp, line 98: '/RscTitles/Tao_FoldMap/Tao_FoldMapStatusBarTextLeft.sizeEx': Missing ';' at the end of line

I don't know what "3.7" and "4.7" are. There was a CBA_A3 beta 3 and now there is a CBA_A3 beta 4. You should use CBA A3 beta 4 from here on your server - download either the 7zip archive or the Zip archive.

No. It is not caused by CBA. It is due to the the status HUD addon running a script that has dialog-related variables. When a game is saved, any and all spawned scripts that have variables referencing GUI items will stop. The fix for this problem can be seen in step 3 in post #43 above. One has to detect a save-then-reload and then re-launch the "ICE_HUD" thread.More background reading: loadable permanent GUI? More formally expressed by Str in disableSerialization: "Scope with disabled serialization is discontinued after load, even if there's endless loop inside."

Removed arma3 folder entirely. SteamCMD still said "Success! App '233780' already up to date". Wiped the whole thing and reinstalled. It's at 1.10 now...

When will 1.10 show up on Steam? This is from a recent (today) SteamCMD session: Steam>app_update 233780 Success! App '233780' already up to date. Steam>app_update 233780 -beta Success! App '233780' already up to date. The server files are still at 1.08 after this.

Please provide a proper bug report with steps to reproduce the savegame issues you are seeing. Saying "something about data not connected or something" makes it very difficult for us to find the problem.

Yep, that's the same issue tpw experienced - the postInit script in cba_common tries to run the CBA_fnc_hashEachPair function on a variable that has not yet been initialized. I've changed that script to wait until all needed variables are initialized.

I think I know what it is. I'll look into it when I get back from this thing they call work...EDIT: Could be a script scheduling issue. See #73678. Do you have a reliable way of reproducing the error?