venthos

Probably because the guy was looking to replace the hacked-in weapon with a legitimate DayZ weapon. You cannot get globally banned for having a hacked in weapon (only for being the one to spawn it in), but many server admins run checks or will be more apt to ban you locally from their server if they find you're using a hacked in weapon. The guy was probably just doing his best to go legit and it was easiest to just hot-swap guns on your body than try and destroy the gun. It's up to you on whether or not you use the G36 SD, just be aware admins will be suspicious of whether you're a hacker and you run the risk of being locally banned on some servers for using a hacked in weapon that cannot be legitimately obtained in DayZ.

There is a very simple workaround to this bug. Whenever you obtain a new backpack type (including going from no backpack to having a backpack), STOP, and immediately logout/log back in. If you do this, you'll never lose your backpack again due to skin changes (This includes going between bandit/normal/hero and putting on/taking off a ghillie/camo/soldier skin) The bug is that whenever your skin changes, the game sets your backpack to whatever you had when you last logged onto the server. By making sure you relog whenever you change backpack types, you'll ensure that the bug 'resets' your pack to the pack you already have -- thereby preventing any negative consequences. This doesn't dismiss that the bug needs to be fixed, but with the above cautionary step you never have to be the victim of it again.

Hacking aside, I will never ever understand why anyone ever uses links provided in YouTube videos to download anything... legitimate or otherwise. It blows my mind.

Since there's already an official poll thread on the forums from DayZ staff about removing barbed wire from the game, I don't feel too awkward posting this here. But, you can easily prevent barbed wire from being placed on your server with the following createvehicle.txt restriction: Anytime a player goes to deploy barbed wire, they'll instead be kicked. They can then just immediately rejoin if they want. This obviously doesn't help with previously deployed wire fencing, but will prevent new deployments. It'd be one thing if people had to actually farm the fencing they deploy. But, with the vehicle inventory/tent duping problem people can fill tents with wire and just coat entire buildings in wire.

Regardless of anything else in the post, I just have to laugh at the "nefarious little bro" persona showing its head. "Little bros" getting peoples accounts banned seems to be a more rampant problem than hackers if you go by the amount of "but it wasn't my fault!" posts on the forums. Ah, hilarious.

Fair enough. With the stated relaxation on the some public hive rules, though, I feel a kick is not unfair here. The only thing I don't like about this solution is it doesn't clearly say why they were kicked. It's just the generic kick with # like all other BattlEye filters. If this method becomes more popular, then hopefully it can become common knowledge of what's happening. I would not condone banning players through this method. That doesn't make sense and I would side with anyone who complained about being banned for having a hacked item on their person. That is, as long as their excuse was that they did not know it was hacked and would happily destroy it otherwise. If their excuse is "I didn't hack it in, therefore I should get to use it forever and ever" - AndreasB. then I think they're just being a douche bag. Sadly, banning for being a douche bag isn't something anyone should do on the public hive ;) But, I'd smirk as the filter kicks them constantly until they dispose of the hacked item(s). I'm also unsure about whether it actually will block the hive saves, just like you I'm skeptical. It's yet to be confirmed. I destroy all the hacked weapons I come across so I simply don't have anything to test with ;) Either way, a kick for this stuff is sufficient in my eyes. The hive save block would've just been a bonus.

I tried this as well to no avail. It seems setdamage.txt and setpos.txt are informational only and do not have kick capabilities built into BattlEye for them :(

They're almost certainly hacked in. The latest round of weapon spawning involves some wonkiness that requires spawning the gun locally on your character and then dropping it to the ground to have it register as existing for the server. Then, you pick it back up. Therefore the automated hack tool to do this just automates this and results in a big loot pile being generated. This method avoids the need for bypassing BattlEye or using scripts. If the player were to logoff/disconnect, all loot they personally set on the ground would be deleted (as is the case with all loot a player has placed on the ground when they disconnect)

Unfortunately there's no way for a server admin to have log proof of somebody using a maphack. Maphacks strictly are a "read only" mechanism for the local client's data. They never write anything to memory, and thus could never trip anything off server-side like a setpos. We have to rely upon BattlEye to detect the maphack processes client side and issue global bans accordingly.

There will be far more shitty private servers run by self-entitled admins whose entire excuse is "I pay money!" than quality private servers. Some of us don't care about the money and would rather see people having fun on our server. But that's the necessary evil to allowing private servers. No way around it. There will be folks like me who run a quality server and will simply congratulate you on a job well done killing me/raiding my camp/stealing my vehicle/whatever. It's just going to take some time for people to find out what those servers are. It's a self correcting problem that just involves a bit of heart ache on the part of its players as they wade through the mountains of self-entitled admins' servers until they hit the good ones. The second someone says "I should be able to <blank> because I pay money for the server", you should just run the hell away as fast as you can. Find servers run by admins like myself who consider the server fee a personal entertainment expense that we don't feel we "deserve" anything in return for. We just want an opportunity to have a good server community with people having fun.

I was pondering this, and I realized that this rule set may actually prevent the player from saving the hacked item to their character on the hive since it's tripping on the hive saves. Therefore, if someone OBTAINS a hacked item on your server (hacks it in, loots from a crate/tent, loots from a player corpse, whatever) then the hive save will be blocked and they'll be kicked. This effectively prevents someone from even abusing your server to grab a hacked item and take it to another server. The only way someone would get to keep the hacked in weapon is if they already had saved it to the hive from having it on another server first that didn't have this rule set. Kind of interesting. By this rule set blocking hive saves of hacked in gear, the garbage should slowly filter out of the hive if more people kick for this stuff. I'll work on expanding the list beyond just a "top offenders" weapon list. It's just annoying that since you can only block on variable name OR value (not both), I have to make this a blacklist vs. just whitelisting known good DayZ items.

I don't think DayZ Mod will ever be officially supported and developed for the private hive community. I could be dead wrong, of course, but it would involve too much development time taken from standalone and even more time supporting it. I just can't see that as a realistic or even logical step forward. What does make sense is what it seems like Rocket will do, slowly relinquish control of it to the community. I could even see him turning down "The Hive" and just letting the community do with it what they will. I could see a small group of people stepping up to run the Community Hive in its stead to give some semblance of the former Hive. At that point, not even the current public hive servers would be "supported". That's how I see this going down, and how I'd want this to go down. I don't want Rocket stepping back, I want him driving forward while "looking back" to what we're doing with the mod as a community for testing and ideas. That frees up all DayZ resources to drive forward with DayZ Standalone, while letting people play with the mod and potentially test/experiment with ideas they want to see in standalone. To me, if we start "officially supporting" anything (public or private) past DayZ Standalone release we're just holding back DayZ and delaying ourselves getting new features more quickly.

√ "But I pay money for my server" √ Insanely high response time expectations for a free mod run by volunteers √ Lashing out when he realizes making irrational demands only works for him in big box retail stores ...and people criticize me for calling a significant portion of the Server Admin community self-entitled. I feel like I should create a "Self Entitled Admin" BINGO card so we can at least get some amusement out of these threads. Maybe I will... and I will buy DayZ standalone for whoever posts most BINGOs by DayZ standalone release (the forum poster who gets the most bingos, not the server admin who acts the worst and gives out the most bingos :P)

I have growing concerns about the hacking problem in standalone. I inappropriately assumed that the ARMA engine was going to have the scripting portion of it torn out, or at least essentially disabled/removed from the client, for DayZ standalone. It turns out, from one of Rocket's posts, that this is not the case. The script interpreter will persist, just they are going to lockdown the method hackers use to call upon their own custom scripts. The problem with this is that this can be (and is presently being) circumvented by not loading a script at all -- just calling the actual script functions (createVehicle, addWeapon, etc) direct in memory. When Rocket was posed this question, that entry point was deemed a role for the anti-cheat engine to watch over. Since the current method doesn't even require a BattlEye bypass because of how it's done, this means I hope BattlEye extends its realm of protection or Rocket can get standalone on Steam fairly quickly to leverage VAC's established expertise in this area. Still, even with something like VAC, leaving that much trust in the client is still worrisome and just begs to be hacked. While these steps will make great strides, the TLDR of this is that the current hack tool available *right now* that employs this newish method of spawning things/killing players/etc would take all of a few hours at worst to adapt for DayZ Standalone if the script functions for ARMA remain in the client executable and trusted by the server. Anti-script loading technology doesn't help in this situation where a script is never involved. I know tearing out the script engine from the client executable would be a lot of work, so I just hope what's being done will be enough. So, I went from having no concerns to being concerned via that thread ;)

Rocket has already stated in no uncertain terms that he condones and prefers Private servers. The reason stated (in that thread) is that it means the hive doesn't get as loaded and they don't have to worry about it as much. Basically, do whatever you want -- private or public. It's all good. /thread

I would certainly consider creating server-wide safe havens for storing/duping/farming mass items at zero risk to then utilize on public hive servers a damaging effect. Wouldn't you? As you say, DE 1026's server admin should just setup a private hive. I would hope, if DE 1026 does not remove this, that their server is blacklisted. I don't understand why they're not on a private hive in the first place if they want this. As you say, it's condoned and even preferred by Rocket now.

Sure it does. Every grenade throw shows up as GrenadeHandTimedWest. The 40mm launchers show up as G_40mm_HE with the various flares/smoke as things like F_40mm_Green. A couple of grenades throws spaced out with enough time between to be legit throws could be legit. The same with 40mm launchers being spaced out appropriately and within reasonable numbers. The volume of grenade throws in the period of time shown by the copy/paste above, though, is clearly a hacker. Note that Medbox0 in createvehicle is not necessarily a hacker. The way loot works in DayZ is that the player in proximity actually creates the loot for the server. Therefore, when a player walks into a town with a hospital and it's time to spawn a medbox, the player "createvehicle"s it. The only exception to this is helicopter medboxes, they're spawned by the server on server start. Players don't spawn them. So you cannot just ban outright on Medbox0 alone since there are legitimate cases where players "spawn" them as hospital loot. You would need to extrapolate the coordinates of the spawned medbox and see if it's at a hospitlal location. If it's not, then it's a hacker. With this knowledge in mind, though, all a hacker has to do is walk into a hospital and spawn the medbox of weapons in there to disguise it. It's tough to ban for Medbox0 as a result. I usually use it as an indicator to check for that player in my other logs to see if any other nefarious behavior shows up. Usually there is.

With Vilayer you basically have 3 options. DayZ Public Hive Vilayer Public Hive Private Hive From what it sounds like, you were placed on the Vilayer Public Hive. This is public amongst all other Vilayer customers who chose this option. So, you and your playerbase could hope to any other Vilayer Public Hive server and your character would persist. It sounds like you need to order a DIFFERENT package from them if you want the DayZ Public Hive. If you run your own Private Hive (just your server, no other servers) then you could do anything you want to it. But, your character would only exist on your server and nowhere else.

I don't understand the point of this thread. If you're running a private hive for your clan, why not just password lock it anyway? If you are intending for this utility to be run on DayZ Public Hive servers, then this breaches the rules and permits your clan to farm all loot/have unraidable camp sites and then drop over to public hive servers and wreck havoc. This creates an unfair safe haven for your clan mates. As Nik21 said, just make your own private hive and no one will care what you do with your own server. Running this app on a public hive server is grounds for blacklisting, though, and you've so conveniently provided the server name (DE 1026).

Sure, go ahead and send me a PM. I'm kind of curious what questions you have that you wouldn't just ask in the thread ;)

Given private hives are sanctioned and even encouraged/preferred by Rocket (helps keeps their hive from being overloaded), the only reason to really decide between public/private hive would be the obvious pros/cons of such. With the public hive, you have access to more population. People are more likely to just join up with your server at random. With a private hive, people know they're starting from square one on your server. Also, if you shut your server down all their work is lost. Because of this, they may be less inclined to join up. You'd have to work more on getting a population. But, a private hive also means combat logging becomes less enticing (eventually they have to log back in at that same spot) and there is no server hopping. Definitely a personal decision based on what's most important to you.

Good catch. The list I copied over is direct from Gotcha-Antihack. So, this means Gotcha-Antihack by default is kicking for the M16A2_M203 as well. I'll edit the original post and remove that gun from the kick list.

I'm testing my theory, but so far it seems that the only "legit" setpos may be things like: Basically, always client ID #2, object id #1, and the coords 1000, 10, 0. Any other setpos I've seen has so far been confirmed hackers. Either by me witnessing the teleporting myself or by them coincidentally being caught by other filters for performing nefarious actions (trying to place a hacked in BAF_ied_v1 explosive or what not). client ID #2 seems to be "server owned" things as best as I can assume. Therefore setpos for 2:### means they've teleported a server owned object. In most cases, this is going to be teleporting a vehicle. This is further reaffirmed by Xforce's log snippet. I've seen this myself on my own server, too. Seeing a 'setpos' of anything other than the client ID of #2 would suggest a player has been teleported. Regardless who was actually teleported, though, the name in setpos.log would be the person performing the teleportation. Not the victim(s). I'm testing a setpos.txt filter that will autokick teleporters based on the above information. This is as simple as: (It kicks for all setpos except for teleporting client #2, object #1, to location 1000,10,0. Which, as above, I'm convinced is innocent) Be aware this is untested in the field, as I've yet to see any setpos come across the log since I added it. Use at your own discretion.

I'm sure you'll find a reasonable amount of servers who do not care what weapons you use on their server. You're welcome to play on those servers. There are those of us who wish to stick to only items that are legitimately obtainable. I don't care if the only difference between the hacked gun and legit gun is that one has a small sticker of a kitten on the side. I only want legit weapons on my server ;)

I'm sure you're already aware of this, but the latest round of hack methods doesn't rely upon using ARMA2's script interpreter at all. No SQF or what not required. They just locate the address of the ARMA2 function in memory (like addWeapon, createVehicle, etc.) and call that directly. They never have to load/replace/execute a script. This also means they don't even have to try and bypass BattlEye since a conventional script is never called and BattlEye never even sees the attempt. As you've already stated, the server must distrust the client entirely on everything it feasibly can. Anything that can be offloaded from the client (the server spawning/controlling all zombies and items, for example) would be all for the better. Again, I'm sure I'm preaching to the choir on this and you're well aware of it all and pursuing things accordingly. But, I felt like it couldn't hurt to mention it in passing. At worst, you say "Yep, we know" ;)