SicSemperTyrannis

Polite bump. Even some sort of hacky fix would be preferable to all the alternatives.

1) You're better off using setVariable on a specific unit. player setVariable["killStreak", 0]; // Init Then when they get a kill: player setVariable["killStreak", (player getVariable["killStreak", 0]) + 1]; 2) You put the code in the init file (and maybe respawn event handler?), but you should call removeAllWeapons (and items) You can view the API resources here: http://community.bistudio.com/wiki/Category:Scripting_Commands_ArmA2 https://community.bistudio.com/wiki/Category:Arma_3:_New_Scripting_Commands_List 3) You can increase the user's "killStreak" variable in the "Killed" event handler. You can check if they are an actual player or AI in that callback. 4) if((player getVariable["killSreak", 0]) > 10) then { /*allow them in things*/ } else { /*don't*/ }; 5) Same as above. 6) Can't answer 7) You can place as many choppers as you want?... 8) You would have to make specific variables per each "support" thing. "hasUsedChopper", "hasUsedArty" and set them to true/false accordingly. 9) That... I'm not sure about. I'm almost certain there's a way to add to the score but I don't remember the API for it right now. All that said, you should practice the fundamentals before trying to take on something like this.

I'd like to see ATMs I guess. Perhaps a safe, too.

Alphas are meant to hunt down bugs. You are correct. Information about bugs are gathered by playing the game, though. If you can't play the game without the server being bombed I'd argue it very severely interferes with the alpha.

There's already a topic about that, they're keeping BattlEye. Most people would be fine with that, too, but it's not here. They said it will be added at a later date. That's all the information they have.

I have spawn protection code that looks like this: /* Simple Spawn (Humans and vehicles) Protection Script by SicSemperTyrannis Use: [_unit] execVM "spawnProtection.sqf"; Unit is any human or vehicle object! */ _dist = 250; //Edit this to be the size (in meters) which you want to protect from spawn marker. _unit = _this select 0; if(isServer) exitWith {}; if(isNull _unit) exitWith { diag_log "Spawn protection called on null unit!"; }; _unit setVariable["spDist", _dist + 1]; diag_log format["!! Spawn Protection was issued to object (%1) !!", typeOf _unit]; if(isPlayer _unit) then { _unit addEventHandler ["Respawn", {[(_this select 0)] execVM "spawnProtection.sqf";}]; _unit addEventHandler ["HandleDamage", { _dmgUnit = _this select 0; if((_dmgUnit distance getMarkerPos "respawn_west" < (_dmgUnit getVariable["spDist"]))) then { false } else { true }; }]; }; while{true} do { scopeName "spawnProtectLoop"; if(isNull _unit) then { diag_log "!! Killing protection for obsolete unit object !!"; breakOut "spawnProtectLoop"; }; if((_unit distance getMarkerPos "respawn_west" < (_unit getVariable["spDist"]))) then { _unit allowDamage false; } else { _unit allowDamage true; }; sleep 1; }; It's applied to each object on the client's side, but when people crash helicopters sometimes they will continue exploding... forever, and only outside of the spawn protection zone. Meaning that by this point "allowDamage" should be set to false on any and all clients (the event handler doesn't apply to vehicles) Then I saw this video: yAe7cHSQofM I'm starting to think it's related to the API itself.

Well, as you can see I only enabled the event handler when they were a player and I still got it. I think it also does it with client-side allowDamage.

Nothing that I said is hard to understand. The models and textures are clearly different.

Breaking news: Internet user confirms guns look the same. They use the same configuration (stocks + rails + etc), maybe they were inspired or something, other than that guns will be guns.

We could discuss it over skype or something if you like, I'd be happy to explain more.

I know so. You can't detect kernel-mode drivers with user-mode modules. It's a permissions issue. If every user-mode module was able to access kernel memory space you'd have a lot of inherent security problems in your operating system. User-mode executables cannot access kernel-mode memory. It's how windows is designed. Nothing short of a critical windows security exploit being used or your own driver to combat it would solve that problem. I'd like you to provide some evidence to the contrary. And if it isn't public? Then what happens? I could also go on to explain how the script reporting from client to server works with battleye, since I do know, but I won't because I'm not irresponsible. I know all scripts sent to the server to be executed on other clients can be filtered and banned, that's always been the case. However, for example: (vehicle player) addEventHandler ["handleDamage", {false}]; Executed on the client-side isn't detectable. Sure, the BattlEye client sends that data to the server, but the client doesn't have to send that data to the server. If you just don't send it, there's no problem. That's because the client controls if the client dies, you aren't required to send it to the server but for detection. I'm not here to be hostile or get into an argument, the problem is that BattlEye can't realistically fix all the flaws in ARMA's engine. It's like trying to plug a sinking boat with paper towels. That isn't to say the game is bad, it's a lot of fun. It's my favorite game. However, it doesn't matter what anti-cheat software is protecting it, unless the ability to exploit these vulnerabilities is patched. It's also true that some mod developers inadvertently include insecure code, and I agree it's their fault, but being that there is ways to execute malicious code even without those exploits existing... I don't think it's the primary issue.

Dwarden, that is disingenuous. Why would anyone here know how to get an undetected hack? They do exist though, clearly. If you can't believe it, maybe try actually spending some time playing ARMA2...

Most people don't understand that it's really not BE's fault that hackers can do such crazy things. The engine itself is inherently insecure. Even if BE could stop all malicious scripts such as lock keyboard, spawn vehicles, teleport people around, make them do stuff being transmitted to other people by blacklist it couldn't stop things like god mode, unlimited ammo and such because that's never transmitted over the wire (well, client-side execution of scripts ARE transmitted to the server but it can be prevented). The only hope left at that point is actually detecting the hack itself which is hit or miss and plenty of people will leak through. It's just the way the engine works, to save resources on the server, or for some reason unknown to me, most of the game is client-side and includes a built-in remote execution exploit for scripts (by design choice) which can only be filtered by the server through blacklisting or whitelisting. The only thing that would prevent hacks to the scale we're used to seeing is a core rewrite of ARMA which we are apparently not going to see in this iteration of the ARMA series. As for Dwarden saying VAC can't detect kernel-level hacks... neither can BattlEye. Currently, very few anti-cheats are capable of this because they operate in user-land.

Raider Battalion plays custom PVP and Co-op missions pretty much all the time. That's the only place I play, so...