https://code.google....ers/scripts.txt That, scripts.txt, is the one I've been directed to use, as well as is best tailored/kept up to date for Day Z. If that is incorrect, and there is a better one to use stop here, and reply to this post with the one I *should* be using. Would be beyond appreciated. Now to get on with the issue, and the main reason I am creating this topic, is this, the scripts.txt I linked, is...problematic for me. It consistently kicks everyone who tries to join the server, for differing script restrictions, and I mean *everyone*. Now more than likely I am doing something wrong, or there is another missed issue when dealing with this file. The restriction comes up as #41. I tried searching this out. They said to simply *remove* this line or revert back to a previous scripts.txt file. I decided to go with the first idea so that I can still roll with an updated scripts.txt, albeit missing a line. This didn't work though. Kicks now for #40. This becomes a pattern if I repeat the "remove a line" step. So 3 possibilities: A: PEBKAC error on my part. B: Problem is with the file itself. C: I'm in the green, file is in the green, the problem exists elsewhere. I could very well revert back to an older scripts.txt. However I'd rather have an updated file..than an older out of date one. The site I linked is already well known for its Community Ban list, and the other .txt files work brilliantly too, such as their remoteexec.txt, and createvehicle.txt Other than the older file, I can't seem to nail it down what is exactly wrong, trying a few other things, such as noting the differences between the old and new file, but not knowing enough I'm still left fumbling around. Any and all help would be appreciated. :)

Only solution I found thus far is to revert to an older scripts.txt. I *have* tried the above mentioned solution. But there still appears to be mass kicks for other script restrictions such as 184 or 21. And I know 100% percent these are legit users. Just to reiterate, this is on a 100% official Hive server.

http://code.google.com/p/dayz-community-banlist/issues/detail?id=305#c1 Just found that as well looking into reported issues there. However it doesn't seem anyone responded with any solutions or ideas behind the cause. :/

Well then that is problematic, as it is an official Hive server. Only thing we have modified is what we're allowed to, such as difficulty settings, and well..these .txt files we're discussing. In fact our host is HFB, perhaps they are using different DayZ files? Other than that. we *should* be using a 100% unmodified DayZ server.

Well going back to the newest version and tripping the line again. This is what I get in the .log: And this gets called on everyone who joins. Like I said in my earlier post, everyone, even me. This is all using the newest and up to date script.txt linked. And going to the line you mentioned the difference between it and the out of date file is this:

Until they are fixed so that they no longer respawn during a restart, as well as become much more rare. I vote yes. They are a really interesting addition to the gameplay, but in the current state nothing but a nuisance and clutter that end up coming back again and again after every restart. I don't mind blocked off buildings, or areas, but unable to properly remove them, sandbags, or tank traps is absolutely horrid.

No idea where he said it, but I believe sometime ago he removed it accidentally and just hasn't bothered fixing it.

Tried working this out with support, and they can't seem to figure it out either. So, I decided to make a post here about it to pool other Owners if they're getting the same issue after the new update. *Server is completely up to date, both Beta and Day Z/Hive *Tested multiple times, this isn't the usual derp where the items didn't save. *Very similar bug when compared to the previous Million+ tent issue where the inventories didn't sync to the database. Except this time, its any tent as well as vehicles. *Thoroughly tested multiple situations with other users on the sever. I would normally post a bug report as well, but I'm holding off as I have yet to see any other user/server report the same problem, have tired searching, but perhaps my Google-Fu is weak. This isn't a new server, and as stated, this is A DIFFERENT bug compared to the normal hiccups and lack of saving, positions of vehicles save as well. Its inventories of both tents and vehicles which do not save, either items you take out, or put in. Basically breaking storage all together. So if any other Hosters/Owners/Players are getting this same issue, or have found a post regarding it, please post. I'll put in a formal bug report if itsnot just an isolated issue.(unless a mod wants to move this, this is more directed at server owners, and may only be pertaining to JUST my server.) Any help to this would be much appreciated. :)

Now you're trying to be insulting by calling me a "fanboi," I've done nothing but give you facts, and tell you how it SHOULD be. I told you. The basic plan for HFB with the the Day Z Standard plan, which is a Slotted Server, non-dedicated. Let's you edit the Battleye folder that is in cfgdayz folder. The .txt files I stated are fully editable. I can ban and kick with either DaRT or RCON GUI. I can ban using the HFB CP by editing the bans.txt. All of this on the same 35 dollar basic plan. This is all fact. If you are having problems talk to HFB support. Not us.

I'm on the basic plan. Put in a ticket. You're obviously having abnormal issues.

Not the RCON, the HFB Control Panel has a File Manager. You can edit the Ban.txt, the Scripts.txt, createvehicle.txt, and remoteexec.txt. Or delete and upload your own. This is within the hosting rights. If your RCON Tool isn't banning people that IS NOT an HFB issue. Try DaRT or Arma 2 RCON GUI's latest build. I know this for a FACT.

FYI Pipebombs are legitimate items. A pipebomb is the class name for Satchel Charges, which are mostly definitely in Day Z.

WHAT is preventing you from banning them, please do tell? If you use ANY KIND of RCON tool you'll be able to ban just fine. In fact in the bans.txt you can edit in the HFB file browser and add bans that way. There is not a single way HFB is preventing you from banning anyone other a PEBKAC situation.

wat. Other than following THESE RULES: http://dayzmod.com/forum/index.php?/topic/62195-server-hosting-rules/ Which HFB goes by as well. You can ban people. In fact it won't matter who your host is, as they have to abide these rules too. Stop speaking in fallacies.

I've had friends who had looted one a hacker spawned in and it did not leave a single entry, it only left an entry for those who spawned it in.

He said rifle. You listed a Crossbow, a Hatchet, 2 sub-machineguns, and a pistol. None of them are rifles. :P

I have NEVER heard or seen such a thing. The only thing I know of that involves vehicles and tents on start is that every so often they won't load in due to a random magical error involving connection to the Hive. Nothing else involving players or mission starting affects this. No idea where you might have heard such a thing. The reason any one can legally lock their server is briefly on restart or shutdown for a total of 5 minutes to reduce/prevent flooding. "Before you start flaming, read what I have to say. Almost everyone knows, at least the server admins and hosters, tents and cars aren't loaded correctly after a restart, if players force the the server to start the mission, by clicking "okay"." That right there, just re-read that...and well..I have never heard that, or experienced it. Saying everyone knows something that ISN'T true is quite odd. It is absoultely not true. In fact my server just had a scheduled restart. I log in, hit okay, get the mission start screen where it shows the map. I'm not logged in as Admin. It starts up a hundred percent, a-okay. The only downside other than flooding when logging into a server too soon after restart is a chance to get stuck in perpetual loading.(not the same problem people are getting now)

http://dayzmod.com/forum/index.php?/topic/68181-1725-tents-and-vehicle-inventories-not-saving/ Having the same exact problem. Made a post about it right there. Was thinking it was more of an isolated incident seeing as how tent and vehicle inventories not saving no matter what would be more widespread.

Just a quick bump, as this thread is still the only reports of this, and if there is a major DB issue going on, it'd be neat to know.

Isn't even remotely the same issue. If you had fully read the post you would have read that. We realize tents are bugged. But this isn't the same bug. This is all tents, new old, upside down, whatever. Vehicle inventories too, Vehicles themselves stay put just fine, but their gear does not. I even made note about how this is similar to just days before 1.7.2.4, where every new tent after the Millionth tent in the database wouldn't save inventory. Only this time its EVERY tent, and even vehicle inventories. Not trying to berate you for skimming over that, just, this is a completely different issue, and trying to find out if it is isolated to just my server, HFB servers or a problem with the database affecting everyone. If I can get close to nailing that down I'll go jot it down in the bug reports.

Any chance you can tell me who your provider is? Ours is HFB, and there may be a chance that the first deployment of the patch earlier today might have borked something.(Nothing against HFB <3 them, but just trying to narrow down any issues at all.)

Well this was for the website afaik. And this problem has been persisting since before the site went down. I do see it says "playing the game," but even now it is still persisting. I'll test the waters though just in case, but I'd still like to find out if this specific problem isn't just an isolated incident.

Look at it like this. Why are those weapons HACKED in? Why are they not in the Day Z in the first place? Why did Rocket not include them? Why would it be any different from a normal player using a hacked in weapon, compared to a hacker using the hacked in weapon? Sure the hacker did the dirty deed of bringing it into the game, but why is it okay to continue that deed, just because you killed that guy? Weren't the weapons hacked in for a reason? What if a hacker spawned the gun in for his non-hacking friend to use? What makes that much different than the "spoil of war"? Don't be arrogant about it. They may not be hacking themselves but knowingly using hacked in weapons is just as low as the hacker themselves. I'll give that some people won't know, and that there is exactly why Rocket doesn't want people banned for it. I mean, whose to say you didn't kill a hacker, pick it up off them and kill other hackers with it? However in a constant uphill battle against hackers, people spamming in AS50 TWS, its hard not to take some form of action. I mean look at the TWS. Its basically OP compared to every other weapon available in Day Z, what makes the guy who constantly uses it in the same manner the hacker planned, much better? This weapon has to be the most common and sought after hacked in choice. Don't get me wrong, I don't want people getting banned left and right for using hacked weapons. Just trying to throw an view point in there, show how admins and other legit players might feel. because I mean...why should another player get to tote around a hacked weapon, just because they killed the hacker?

This thread really brightened up my morning. Needed a good chuckle. :lol:

This whole "warning" seems suspicious. You just happened to be browsing this cheat site? Not to mention further investigation I found the thread and the 2nd line you posted isn't even there. Oh also, coming fromt eh thread, the program linked isn't even the same size as the tool. Plus, if you Google Day Z Radar, there is a hack tool by the same time that is different from the tool linked ont he forums. The tool is just a script parser. In fact the tool would probably be allowed if much of the features were removed, such as the map, tent, and vehicle placement. Its ability to show players using hacked weapons is quite interesting. Either way, its far to easy to abuse with the features I stated, but hopefully someone can come up with a program that parse through the file just as easily and take from it only the non-abusable bits. But as I said, after a lot of looking into this supposed threat, it seems more like a scare tactic. That deleted thread contained a COMPLETELY different set of files form the tool that was posted days ago. So better to warn people that go out fo their way to get it, even more so since its abusable and disapproved.