Zumbi

Awesome! And before anyone says this is unrealistic: (Sorry, couldn't resist xD)

Dwarden, is there any hope of re-enabling the old method (logging everything)? Maybe an option in server.cfg to disable packet encryption? Since the hackers got around encryption and it isn't helping us anymore, it would be nice if server admins could monitor all the client-server traffic again. :) It really gave us a lot more power to be able to log everything, not just hackers but it helped us catch team-griefers on non-DayZ servers by seeing who drove what vehicle etc... Although the BE filters have come a long way since 1.62 came out, getting our logs back would really help us stay abreast of the newest hacks, by seeing all the scripts that they execute on our servers, without having to go on their stupid script kiddie forums and look at the hacks in order to catch them. Actually, I think the more advanced ones run some scripts on the clients to check them, but the "99%" referred to both log-based and script-based solutions, so it is still correct.

Thank you again, Dwarden. Can't wait to try this one out! I have one sort of nitpicky request, not a criticism at all - but when a version isn't BattlEye-supported yet, could you put the emphasis on the "NOT YET supported" instead of "not yet SUPPORTED," or no capital letters at all? Sometimes the word "SUPPORTED" jumps out at me and I think, "yay!" for a split second until I read the fine print. :p

Thank you for the great work Soner, this is a really awesome tool! :) Report: When scrolling through the player list with a high number of players, sometimes the name at the top or bottom of the list starts repeating over and over again in the direction you're scrolling, then that section of the list disappears. The problem is fixed by reloading the player list, but it can be annoying when you have lots of players connected and are scrolling back and forth. http://imageshack.us/a/img24/8228/listbug.gif Report: When trying to load a banlist with over 650 bans, the connection crashes every time. Auto-reconnect works like a charm but the banlist is unloadable. I can add and remove bans but can't actually view the list. Had this same problem with regular BERcon. If you want, I can PM you my server's rcon login info to check it out yourself.

Sorry to bring up an old thread, I just wanted to clarify something. Not from us, no one needs permission to borrow a mod that dozens of different people have worked on. With Takistan Life: Revolution we put all the serverside files in the PBO itself so anyone can start a server (thanks eddieck for the suggestion), and we do not claim to have copyrighted our work; I believe that would be a violation of the EULA. Only an ignoramus could claim the "Life" mission code as their own when much of it dates back to earlier versions of the mod from ArmA 1 or even OFP. If it weren't for all the clannish protectionism, all the effort that's been wasted on locking down various forks of the old Life mission and making it hard for other people to host it on their servers, the mission might be much better developed by now, maybe even celebrated like DayZ instead of derided by most ArmA 2 players.

I recently switched my server from a E3-1270 (quad core, 3.4ghz) to a E5-2690 (eight core, 2.9ghz) machine. The new box is better or identical most respects, except of course in raw processing power per core. Both are on Windows Server 2008 R2 with 8GB RAM. I believe the core count may be a problem because the new server is performing significantly worse than the old server, encountering enormous desync with 60-80 players, and server FPS dropping to 0 within 60 minutes of uptime .. we had lag before, but the worst server FPS would be 3-4 with 80 players. Now with 0 FPS it is just unplayable at the client end. The server process insists on only using 2 cores, regardless of any combination of parameters like -cpuCount, -exThreads, etc. On startup it runs smooth, mainly using one core, then it starts using another core until they are both maxed out at 90-100% CPU usage, but it never begins using a third core, it just leaves the other cores idle as the server FPS plummets. Changing the server process' priority and affinity settings had no effect either. Does anyone know if ArmA 2 server can actually use more than 2 cores, taking advantage of a 4-core or 8-core processor? Or is it stuck on 2 cores and I made a huge mistake with the server configuration? Also, disk write speed appears to max out during desync, but that is probably an effect and not a cause, since the server is writing to the .RPT file messages like "2012/09/02, 20:59:06 Server: Network message 144eb74 is pending."

And where would that be? I'm straining my eyes here (http://www.arma2.com/beta-patch.php) and there does not appear to be a 96495 download. A google search for "1.62.96495" only brings up this thread, and proof that a number of servers are in fact running it.

to clarify, I'm looking for the server version.

I have noticed some servers running beta 96495 but the latest available download I can find is for 96493 here http://www.arma2.com/beta-patch.php. I was also at a loss to find 96063, which several servers were running, when 96061 came out. Searching online just yields server information about servers that have the new beta. Does anyone know where to download the latest version?

Okay, nevermind then. Thanks Lokyi and thanks again Eddie

Does anyone know if a solid-state drive (SSD) improves performance for ArmA 2 servers, and if so how much? I have found a few threads about SSD's notably improving game performance for clients due to fast read times on compressed files, but nothing specifically about running a server, except for some spotty and conflicting reports here and there. I know that loading would certainly be faster at the start of the game, but any improvement in loading speed would be bottlenecked by the load times of players connecting. I'm more concerned about the server's ongoing performance while games are in progress. I have found that writing to scripts.log, if lots of false positives are being detected, can significantly hurt server performance.

The newest remote script detection/blocking features do not appear to be working on my server, which is running the latest official release, 1.62.95251. I have remoteexec.txt and createvehicle.txt in my BattlEye working directory, but they are not creating any .log files, even though the server is being ruined by hackers constantly, and there should at least be some false positive detections from createvehicle.txt. From looking around online, it sounds like I must update to a recent beta like 1.62.96061/1.62.96063 for remoteexec.txt and createvehicle.txt to work. However, my game server provider will not let me run a beta version, because they don't allow renters to change the .exe, and they don't believe that a critical security update would come out in a beta version, absent an official release. Would a BIS employee/representative be kind enough to explicitly confirm that this is the case (beta required for remote logging/blocking)? This would really help non-DayZ server renters like myself to convince our providers to let us update to the beta.

Thank you, Prodavec! I can confirm that scripts.txt restrictions are not case-sensitive. Can anyone help me with this possible false positive? This keeps coming up for 1 "setdamage 1": 11.08.2012 10:07:50: ***** (*.*.*.*:*) ************************ - #0 "if (alive player) then { player SetDamage 1;};" It happens so often, to so many people, I doubt they're all hackers. That line does not appear anywhere in the mission file. Does anyone know if this is some in-game code? Or maybe it is a hack but it's only showing up for the victims.

I have been trying to use scripts.txt to catch hackers, who have made my server (Takistan Life: Revolution) unplayable half the time. I used to catch 99% of hackers using packet logs but that is impossible since 1.62. Please forgive me if I sound frustrated here, I'm not trying to "rage" or "rant," I understand the hard work done by BIS and BE, and realize that scripts.txt helps people on rented VM servers, I am not looking for an infraction or ban, etc. I just want to be able to catch and ban hackers as quickly as I previously could using a packet sniffer. My scripts.txt was recognized and renamed scripts_old.txt, with a number of restrictions set to "3" (report to console and log). However, 24 hours later, not a single restricted script was detected, despite hackers having a field day on the server. Hundreds of A-10's and M1A1's were spawned, raining from the sky, but nothing was logged or reported, despite the classnames for these vehicles (A2 and OA versions) being restricted. All players were being remotely killed with "setdamage 1" over and over again, but this was not being logged. Finally I put "3 call compile" in there, because I know they try to hide their scripts with that. Suddenly I got a 300mb scripts.log file, full of false positives. It's basically like a very primitive and incomplete packet log. "setDamage 1" came up a bunch of times,which made me wonder if the upper-case D was the problem. So here is my question: is it true that the restrictions in scripts.txt are case-sensitive? And can this be changed? Because I have seen hack scripts in aLterNaTiNg cApS while searching packet logs before, I am afraid they may be sailing past the restriction but still getting recognized by the server and broadcast to all players. and is it possible in the next update for server owners to toggle packet encryption on/off? Maybe it is my own failure to master scripts.txt with the documentation available (and server owners' understandable reluctance to give out their scripts.txt files), but I find the new script restriction method to be a huge step backwards. The only way it is actually useful is if I restrict "Call compile" or "call broadcast" to create a giant virtual packet log, and search that. I would much prefer to go back to logging packets with a packet sniffer like I used to - it was easy to catch hackers this way, easy to manage the log file, and I didn't have to think of every possible thing they could do beforehand.

I believe you can require CO by putting -mod=arma2;expansion;ca in the server's startup parameters. I am actually working on a CO update for Takistan Life: Revolution right now, feel free to borrow it from the original server once it's up, might have some kinks to work out at first though. It'll say (CO req) in the mission name, should be up tomorrow.