Zumbi

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."

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 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?

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.

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.

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.

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 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.

You already have the mission - probably saved in C:\Users\[your username]\AppData\Local\ArmA 2 OA\MPMissionsCache if you use Windows. Be careful, some people will try to ddos and bruteforce your server like crazy. I would delete your personal info from that post, there's one script kiddie who hates any and all "Life" admins with a vengeance and he will dox you if you make his acquaintance. Also, don't expect to have an easy time catching hackers. They're having a field day on the RPG servers right now as independent admins struggle to adapt our anti-hack solutions to a patch the hackers have already mastered. Expect some very demoralizing weeks or months before your server sails smoothly, but it will eventually get there if you have a lot of patience.

For me and a few other non-DayZ server owners, it was the only effective solution because the hackers constantly came up with new scripts, and if the person searching the packet logs knew what they were doing, 99% of hackers could indeed be detected and banned that way. While running the Takistan Life: Revolution server, I banned over 100 hackers using packet logs, and there were only two cases (2!) of a hacker who we couldn't catch. I believe that I could have caught them too if I had a more nuanced knowledge of Arma scripts and what exactly they were doing. True, but that is how the vast majority of havoc was wreaked. Thank you for that. I really look forward to being able to actively scan packet logs again though; it didn't just let us keep pace with hackers, able to catch them immediately when they had new ideas - it also let admins on non-DayZ servers, where teamplay is enforced, to look at the history of the game in progress and catch griefers, teamkillers etc. by seeing who had particular weapons, who drove particular vehicles etc.

Don't look at the size of this post and just ban me for ranting, because I appreciate all you've done for the community, and I believe the BIS team is working hard on the new linux release, which I am looking forward to patiently. However, I think you should be a bit more polite, or hide your anger at the ranters, if only because any negativity will send more linux people into ragemode crying "we have been screwed by DayZ/Microsoft/etc!" I've been doing my part telling people to calm down and wait for the update, but I kind of resent the "given to him for free" comment. Yes, we get free server updates for you - and everyone with a brain appreciates the awesome service and continuing improvement of the game from BIS. But Linux admins are not freeloaders. I for one have spent almost $1000 hosting a server that, until it emptied out a couple days ago because of the Steam update, had been full with 64 players for the last month whenever it wasn't getting DDoSed (takistan life revolution), keeping people playing arma 2 MP when they get bored of DayZ. I have even kept paying for the server now that I've been laid off and living out of my car for a while, unable to play the game on my laptop, I haven't gotten a penny for it. So I think I have given a little bit back to the community and the game's replayability. I would happily pay for a server license too. EDIT: And if we are angry at anyone it should be Steam, IMO, for making it impossible for people to downgrade to 1.60 while we wait.

A hacker came on to my server today, griefed and teamkilled until he was killed by other players, then he raged, spawned parachuting cows, ran Setdamage 1 on other players and froze them with DisableUserInput. I found his IP address with tcpdump, but his GUID simply was not recorded, I can't find it neither in the .log files nor the .pcap files. Apparently there was no GUID check whatsoever despite that the server runs verifysigs=2. I'm guessing his IP address is long changed, and the PID is just about useless, because I don't even know how to check for the PID's of current players, aside from regularly searching the current log file. Is there anything I can do to ban or stop this guy? This is all that I have on him: 11:51:37 Havid Dasselhoff uses modified data file - Arma 2: British Armed Forces (Lite);Arma 2: Private Military Company (Lite);Arm 11:51:37 Player Havid Dasselhoff connecting. 11:51:37 BattlEye Server: Player #18 Havid Dasselhoff (IP removed) connected 11:51:38 Player Havid Dasselhoff connected (id=8498950). and again: 13:03:52 Player Havid Dasselhoff disconnected. 13:04:02 Havid Dasselhoff uses modified data file - Arma 2: British Armed Forces (Lite);Arma 2: Private Military Company (Lite);Arm 13:04:02 Player Havid Dasselhoff connecting. 13:04:03 Player Havid Dasselhoff connected (id=8498950). 13:04:03 BattlEye Server: Player #18 Havid Dasselhoff (IP removed) connected

Yes please! That would help admins so much!!

Thanks for responding. What would you do next if you were me? Is there a chance his GUID was logged somewhere else? He was on the server for hours. Can I somehow change BE settings to more aggressively check for a GUID at the expense of server bandwidth? Also, do you know if there is still a way to check the PID's of players currently in game, as they don't always display on connection? Or ban a PID for that matter? I know they're easy to spoof, but it's all I have to go on. Thank you again for your help!

Women soldiers with all the same animations as male ones. I can't be the only Arma player whose girlfriend has protested that the game is "sexist" :mad:

More complex and dynamic AI hostility settings please! Add mission scripts that can make AI units hostile to individual players, or make the "renegade" and "captive" triggers side-based. Currently, if a Civilian or neutral Independent unit kills a couple OPFOR units, BLUFOR will target and kill him because he has gone renegade, even though he killed their enemies. It would be nice if attacking a side only made you a "renegade" for that side instead of all AI units in the game. This would give more freedom to mission editors to create all sorts of new mission types with dynamic, script-triggered AI hostility settings, from deathmatch, to espionage, to more complex insurgency and RPG maps.