killswitch

Hi and thanks for making this little nice addon. As mentioned, you don't have to depend on CBA for this.Here's how you do it: 1 - remove the dependency on CBA. class CfgPatches { class status_hud { units[] = {}; weapons[] = {}; requiredAddons[] = {}; requiredVersion = 0.1; }; }; 2 - replace Extended_PostInit_EventHandlers with something like this: class CfgFunctions { class Iceman77 { class HUD { class StatusHUD { file = "\status_hud\ui\hud.sqf"; postInit = 1; }; }; }; }; 3 - edit UI\HUD.sqf so it can be called as a function. Bonus feature: fix the problem where the HUD stops working when resuming a saved game: Replace this sleep 0.005; [] spawn ICE_HUD; with [] spawn { waitUntil {!isNil "BIS_fnc_init"}; while {true} do { _h = [] spawn ICE_HUD; waitUntil {sleep 1; scriptDone _h}; // Wait for save-then-resume }; }; true

That's not it - they are signed with the current (v2) method. It's just that one of the addon signatures is bad - "A3MP_Utils17.pbo.alduric.bisign".The fix is to simply re-generate that one signature file and issue it as a hotfix.

Confirmed - it's a bug with CBA_A3 beta 4 . Problem identified and fixed, see here.Thanks for the report!

Yes. I have re-run the DSCheckSignatures tool on a freshly unpacked @A3MP folder from the three .rar files in the torrent. Same error.

Yep, one of the sigs is incorrect. Verified using BIS DSCheckSignatures tool: D:\>dschecksignatures @A3MP\addons @A3MP\Keys Signature addons\A3MP_Utils17.pbo.alduric.bisign is wrong

Thanks for making this mission! Here's a bug report for b0.52: Problem: One cannot recruit an AI Engineer. Nothing happens when you press the Engineer button in the AI recruitment dialog. Reason: The script support\modules\FOCKRecruitAI\createengineer.sqf tries to createUnit a "B_G_soldier_repair_F" which doesn't exist in ArmA III v 1.08 Fix: change that to create a "B_G_engineer_F" unit instead. And a suggestion: Problem: The FIA Combat Life Savers lack a Medikit from the start. Players have to pick one up from the equipment crates at the base. Reason: Unlike the other factions' medics, the FIA docs don't have a Medikit in their configs. Suggestion: Save players some time by adding a Medikit to the playable medics from the start (and possibly the recruitable AI medics) (unitBackpack _unit) addItemCargo ["Medikit", 1];

No, you should be fine if you install the 32-bit runtime libs. A common, albeit heavy-handed way of achieving that is sudo apt-get install ia32-libs (That'll install a whole bucketload of packages you didn't know you didn't need, though)

The packages marked in red are not part of the standard RHEL 6/CentOS 6 software repositories. Where did you get them from?A stock RHEL 6/CentOS 6 does not have new enough C/C++ runtime libraries that the ArmA 3 dedicated server needs. That is why hlfritz cannot make it work.

This works: class Missions { class Mission1 { template = "becti_0097.altis"; difficulty = "regular"; }; }; Make sure the actual mission file is all-lowercase (ie not "becti_0097.Altis.pbo" but rather "becti_0097.altis.pbo").

Yes, but only if we take the example as a comparison between an E3-1270 and an i7-3770K. However, if, as you noted, the Dell R210 actually has an E3-1270 v2 the CPU:s are same-gen. Then, the 1270 v2 may be preferable for a remote server since it probably sits in a more, shall we say "enterprise:y" machine, with ECC memory and other RAS features.

Your E3-1270 is a Sandy Bridge-era socket 1155 processor which means that it is comparable to an i7-2600 (or i7-2600K) in performance (both the 1270 and the 2600K are four-core, hyperthreaded Sandy Bridges at 3.4 GHz). The i7-3770K is an Ivy Bridge CPU and the corresponding Xeon model would be an E3-1270 v2 (Ivy Bridge architecture @3.5GHz). The Xeon variant and the i7 variant of the same-generation CPU architectures are trivially exactly equivalent, CPU performance wise. The difference is that the i7 has a few features disabled (eg ECC) due to nickel and diming market segmentation by Intel. For your example, comparing the E3-1270 with the i7-3770K, the i7 will be faster due to being clocked higher and it being a later-gen CPU architecture.

This is a problem with the assignments for _originalaccuracy, _originalshake and _originalcourage on lines 12-14 of tpwcas_incskill.sqf. Those assignments can be safeguarded like this: _originalaccuracy = _unit getVariable ["tpwcas_originalaccuracy", _unit skill "aimingaccuracy"]; _originalshake = _unit getVariable ["tpwcas_originalshake", _unit skill "aimingshake"]; _originalcourage = _unit getVariable ["tpwcas_originalcourage", _unit skill "courage"]; A similar thing can be done in tpwcas_decskill.sqf: _originalaccuracy = _unit getVariable ["tpwcas_originalaccuracy", _unit skill "aimingaccuracy"]; _originalshake = _unit getVariable ["tpwcas_originalshake", _unit skill "aimingshake"]; _originalcourage = _unit getVariable ["tpwcas_originalcourage", _unit skill "courage"]; _shots = _unit getVariable ["tpwcas_enemybulletcount", 0];

Thanks Ollem. While you're at it, I found another quirk. It's the last line of twpcas_init: diag_log format ["%1 - %2 Active - tpwcas_mode: [%2]", time, _version, tpwcas_mode]; Do you see it? :-) "%2" occurs twice, so you never see the TPWCAS mode value in the log. diag_log format ["%1 - %2 Active - tpwcas_mode: [%3]", time, _version, tpwcas_mode]; Thanks for your continued support and improving this addon!

It doesn't - there are still references to undefined variables. This is from the log of a dedicated server with TPWCAS 5.5: Error in expression <) && ( isMultiPlayer ) ) then { if ( tpwcas_debug > 0 ) then { diag_log form> Error position: <tpwcas_debug > 0 ) then { diag_log form> Error Undefined variable in expression: tpwcas_debug File tpwcas\init.sqf, line 91 Error in expression <er) ) then { tpwcas_mode = 1; }; if ( tpwcas_debug > 0 ) then { diag_log form> Error position: <tpwcas_debug > 0 ) then { diag_log form> Error Undefined variable in expression: tpwcas_debug File tpwcas\init.sqf, line 42 As you can see, it is the global variable tpwcas_debug that is being referenced before it has been defined. Looking at tpwcas\init.sqf, I believe this issue has an easy fix. The initialization of tpwcas_debug currently happens on line 148, and only on the server. However, tpwcas_debug is checked client-side as well (for example, that happens on line 25 in single-player mode). Suggestion: move line 148 to a spot somewhere before line 10 so as to make sure tpwcas_debug is initialized before it is referenced. Just to be clear - line 148 is this one: if (isNil "tpwcas_debug") then { tpwcas_debug = getnumber(configfile>> "tpwcas_key_setting" >> "tpwcas_debug"); };

No, but the authors are the only ones that can fix the addon and release it in a form suitable for wider public use. (They are the only ones that can sign it properly)

Yes, that is a problem. One cannot edit an addon by opening it in Notepad++ (or any other text editor for that matter) - even if you can see the script contents in there, saving that .pbo again will damage the addon. An addon .pbo file is a kind of archive file with several files in it, so you have to unpack it first and edit the actual files instead. There may be other places in the scripts in the TPWCAS addon where undefined variables are referenced, so it is my suggestion that the original addon makers review the scripts and fix any and all undefined variable references.

Yes, it's a fairly easy fix. Here's one way to do it:Change line 36 from to Line 70 is changed into That's the bug/quirk fix. (A nice feature would be to be able to turn off all the diagnostic logging that TPWCAS does.)

1.63 does break TPWCAS - see post #212 above by Lordprimate. The problem is that in two places in tpwcas\init.sqf, the variable tpwcas_mode is referenced before it is defined, causing the error in question. In TPWCAS 5.0 for ArmA 2, that error occurs on line 36 and line 70 of tpwcas\init.sqf in the diag_log calls.

You can disable mission rotation by having an empty mission list in the server.cfg file. Like this: class Missions {};

Yes, it is.

Yes, I very much like the idea of a smaller island somewhere in the sea near Altis, much like Rahmadi / Sahrani in ArmA. (Doesn't have to be Stratis, but something with a working, AI-usable airfield)

We've found the issue with CBA and the new ArmA 3 beta - the fix is undergoing testing right now. Stay tuned. :-)

This problem has been identified and fixed. Thanks for the report (although it should not have been reported to the BIS A3 feedback, since it was a problem with CBA) :)

The errors with "Obsolete class Animations..." can be fixed by reading post #6 in this thread. The error saying ".verifySignatures: Member already defined" is fixed by removing everything in your server.cfg starting at line 128 - remove ALL of this: //--------------------------------------------------------------- /* Enables signature verification for addons this will prevent pbo hacks by only allowing pbos that pass servers public key checks */ verifySignatures=1; //--------------------------------------------------------------- // Signature timeout fix regularcheck="{}"; //--------------------------------------------------------------- // some ArmA specific stuff - signature verification onUnsignedData = "kick (_this select 0)"; // unsigned data detected onHackedData ="kick (_this select 0)"; // tampering of the signature detected onDifferentData = ""; // data with a valid signature, but different version than the one present on server detected BattlEye = 0; //Server to use BattlEye system