madkowa@gmail.com

Sounds like you have a bone to pick with the guys running the DayZ Community Banlist, not the developers of DayZ Anti-Hax. Take this issue up with them, or continue to complain here where no one can help you and talk shit to people who are just trying to make your server a better place to play. Your choice.

Not entirely true; if the managed server provider is willing to have an instance of the parser run on a per-server basis, which is certainly possible, then it can be done. The problem is some providers don't understand this or simply aren't willing to do so.

I am indeed busy and unable to tackle any of this right now, but I am more than willing to add you as an administrator of the project on Google Code so you can make your own commits and submit your own zipped-up downloads for people to enjoy. Private message me with your primary email address, ideally a gmail one, and we can discuss this further. Thanks.

I actually do not automatically unban folks who were at one time banned on the DayZ Community Banlist, but that feature was planned -- and the solution would be rather easy. Again though, my time is limited as of late and my own server is likely going down sometime this month for a while, which makes development of this solution quite difficult. That multi-bans.txt solution sounds great and would certainly save everyone a lot of headaches...

The set of "bad" scripts intersects with the set of "good" scripts, which makes the type of detection I believe you're describing very difficult. If it was just the matter of filtering out the "bad" things and leaving the "good" or filtering out everything that isn't "good", this tool wouldn't be very useful at all; the problem is it is hard to determine what is "good" and what is "bad". I hope that made sense. It sounded a lot better in my head. I'm glad to hear you managed to unban yourself and I'm sorry the process is rather annoying. Do note though that DayZ Anti-Hax does not submit/push bans to the DayZ Community Banlist, it simply receives/pulls them, so being banned from a server running DayZ Anti-Hax alone (including your own) does not necessarily and, in fact, does not at all mean your GUID was added to the DayZ Community Banlist. Frankly, I'd rather see some of DayZ Anti-Hax's features rolled up into BattlEye...at least the ability to ban players for suspected hacks instead of just preventing them from executing and kicking the offending player. That would make development of this tool significantly easier and the solution a lot cleaner.

I'm not actively developing DayZ Anti-Hax at the moment, but seeing as this appears to be a new feature with one of the latest beta patches, it should take some time for servers to transition over to this anyway. This is definitely something I'd like to see considered for a future release though...I just haven't been monitoring my server or keeping up with DayZ in general as of late, so I don't feel comfortable fiddling around with my own source code at this point. Great suggestion though, thank you -- hopefully someone else has a look at it in the meantime.

'Object Access Flooding' detection is an experimental feature that may result in false-positives during heavy desync and when clients are executing many actions at once. Any servers frequently encountering this issue are advised to disable the feature by editing DayZ Anti-Hax's 'config.cfg' file and setting 'shouldCheckForFlooding' to 'false' instead of 'true' (it is enabled by default). Keep in mind this will make you more susceptible to hackers though.

Assuming DayZ Anti-Hax has been installed properly, it could be related to this issue posted about a week ago, in which case I fear there's very little that can be done until the BattlEye guys step up their game yet again, because it seems the script kiddies might be one step ahead of us (again). I'd be surprised if this was true. Are you seeing the items appear in createvehicle.log and they just aren't being banned or does stuff not appear in the log and you're seeing the items in-game? If it's the latter, I'm afraid there's very little me or anyone else can do...

It's when a client attempts to remotely execute code on the server or another client (e.g. spawning hacked weapons). Often times, this is intentional and malicious. DayZ Anti-Hax filters out some possible false-positive detections, then bans anyone caught attempting any type of remote code execution. It is only since recent BattlEye updates and ArmA II OA beta patches that this has become possible.

This is certainly possible as it hasn't been updated in some time, however I would strongly advise only using the file I include with each major release of DayZ Anti-Hax. Using filters from anywhere else, including the DayZ Community Banlist, can result in false-positives and other unintended consequences. It is, however, safe to use any scripts.txt file you please, as neither scripts.txt nor scripts.log is touched in any way by my parser. I'm quite busy as of late and probably won't have time to look into any such issues for a while. The solution is open-source, so I would appreciate it if someone who knows C# and is familiar with advanced DayZ server administration could take over things for now...

Sup. I created DayZ Anti-Hax. The system isn't perfect, and thus false-positives can happen from time to time, but assuming DayZ Anti-Hax is installed and configured properly -- ideally right after a fresh server install so that things like these hacked weapon boxes don't exist on the map prior to the parser being run -- everything should work as intended. I'm sorry anyone has had any problems using the system, but as I've mentioned many of times, it isn't for everyone. Anyway, that's my two cents. I'll look into this, but to be honest, 'Remote Code Execution' is one of the most sure-fire detections I have available to me and has never been proven wrong before...

First off, stop the DayZ Anti-Hax parser, then proceed to do as you did before, removing the applicable entries in bans.txt and remoteexec.log and/or createvehicle.log according to what got those users banned, which is listed in DayZAntiHax.log. After you've done this, restart the parser. If they are still banned, you've done something wrong. If they are banned *again* as soon as they join or something, which is entirely different, check DayZAntiHax.log for the time, date and log file to look in to see what's getting them banned and report that to me either here or in a private message and I'll try to help you out.

You should submit a support ticket to your host explaining what you're looking to do and including links to this thread as well as our Google Code page, which includes a download link and instructions/usage guide. It is possible to use this solution under a manager server and not a dedicated one as long as your provider is willing to do so, as the solution is entirely automated when used in conjunction with Battleye Extended Controls (BEC), as explained in the installation instructions.

A blind spot? You just provided a perfect example yourself of why parsing scripts.log can be quite dangerous, which is why my parser doesn't do it. Also, the log flooding detection can be turned off simply by changing a value in the included configuration file, it's just turned on by default as I've never had a problem with it.

If the first block of stuff you posted was in scripts.log (i.e. what appeared to be from all players), which I strongly suspect it was based on what you've explained in your post, anyone who uses this tool is fine, as the parser does not ever read/write from/to scripts.txt or scripts.log. At this time, only remoteexec.log and createvehicle.log are parsed for hacker activity. In other words, I appreciate your concern, but I can assure you DayZ Anti-Hax is immune to silly attempts by script kiddies like this.