jwiechers

Dwarden has posted a fixed scripts.txt on the IRC -- interestingly, that scripts.txt does not change the line changed here but nevertheless supposedly fixes the issue.

I currently have 64 GB of RAM in this machine and while my usage case is relatively special -- I use 32GB as a RAMDisk -- I have no trouble filling the other 32 GB and currently have only 3 GB of "free" RAM. Obviously, if all you do is play games, badly optimized games at that, then you won't really use more than 8-12 GB of RAM at the moment, but you might in future.

This is actually something rocket mentioned as a possible solution, but it is a bit of a bother to do it. Plus, the graphics issues are very erratic: a lot of people, myself included, have only very sporadic issues right now, some have absolutely no issues and yet others absolutely can't play. So I think they're looking into what could be causing this for some people and not others, rather than simply removing the models -- which would solve the issue, but not prevent it from resurfacing with yet other models in the future.

We do not currently support third-party modifications and it is frowned upon. That said, the team has so far not blacklisted servers from the main hive for also hosting DayZ instances using those alternate or local hives.

I just had a quick chat with Dwarden from Bohemia Interactive. In theory, while the server can no longer ask the client for a beta exceeding the server's own patch level, it remains possible to specify the server-side patchlevel as the requiredbuild. That means that, in theory, a server could be configured to require 95885 from the clients, assuming that is the server's beta-patchlevel. Server and Client patchlevel are not always in step, so this may happen in rare cases where the admins have not properly read the instructions. Or, as Dwarden puts it: <@Dwarden> PEBKAC is unfixable

Please note that 95883 is the latest client-side beta. It will allow you to join servers with the latest beta.

Simply put, because we haven't told them to. ;-) Strictly speaking, the team is not enforcing one particular beta, but we have been sending out advisories that told hosters to upgrade at irregular intervals when this was necessary. The latest officially sanctioned beta, that is, the latest beta suggested for deployment by the DayZ team, has been 95417. There were a few improvements in the recent betas but also quite a few problems, especially with regard to stability. 95883 looks fairly good, though, so there may be an advisory telling people to update sooner or later.

Yeah, I've been looking through the log-files regularly and the ban-list has been growing steadily whenever someone was caught. :-)

This is based on the difficulty setting of the server in question. As far as I remember, you will not see other players on your GPS, but you will see them on the map if this is activated. Please refer to the table found at http://relay.pp.fi/G...Difficulty.html

That has been a coincidence. I am the only admin -- and leaving aside the restarts today, I don't usually restart the server manually -- the only restarts that happen are the automatic restarts at 0600, 1200, 1800 and 2400 UTC and restarts when updates are applied/released. Sadly, the recent betas have tended to sometimes crash the servers, too, after which the server auto-restarts and sometimes loses the vehicles until it is synched again at 2400 UTC. :-/

Hello everyone, I just added IPs, so people can join manually/add the servers to their favourites, since GameSpy seems not to want to list the servers anymore. :-(

That is an entirely unrelated issue. You are not shutting down the server properly and the new database connection is established without the old database connection terminating first. This results in the vehicles not being streamed. Please make sure that your server is properly terminated every time you restart the server; ensure that it is graceful, not forced. Lastly, do *not* use the engine-command #restart. As for vehicles: The vehicle-seeding process is semi-automatic and typically happens shortly after instance creation. It may however, worst case, take up to seven days before vehicles spawn on a specific instance ID after its creation.

You know, the thing is: without the author of the mod, who specifically said that he does not want private hives to happen at the moment -- even if this is changing in the near future -- you *WOULD NOT HAVE A GAME*. That is the salient point. I really don't understand where you people get your entitlement attitude from.

No. The helicopter crash sites are fairly random, so it is difficult to be precise. A good road to go along is the route that leads you from Berezino to Gorka to Polana to Orlovetz and back to Berezino, lots of open fields, lots of places where helicopters might spawn.

The reason for this model, in the case of ARMA, was that its entire design was geared towards large-scale cooperative play, not competitive play. In this model, it made sense to trust the client a lot for both performance as well as other reasons. Most games have some server sanity checking, but this only works if you have relatively small resources. The reason BattleField 3 employs substantial client-side detection (and was subsequently cheated at in a big way) was that even for a studio like DICE, with all its clout and resources, server-side hit detection at that degree of complexity and scale was not possible [that is, feasible]. They experimented with this during early development stages and the result was an unplayable game. If BF3 was only Metro, or the new CQC maps, server-side hit detection wouldn't be a problem, but if you have maps like Wake Island or Caspian, the servers would have to be ungodly powerful to handle geometry and sanity checking for 64 players employing highly variable weapons with their own ballistics, penetration factors, etc in an acceptable time frame -- and this would only compound the ping issues. Another game that has the same problem is Tribes Ascend. OnLive eliminates client-side processing. This eliminates most attack vectors. That is what I said. I didn't say ARMA handled things partciularly well or that other games didn't do it better, what I wanted to point out were the real world reasons for this.

I don't think that's the question here. What you say may or may not be the case for everyone here -- and I certainly won't make any statement to that effect -- but that does not have any bearing on the legality of the actions you describe, nor on the hosting of private hives.

Correct, you don't agree to anything, so per default, the laws of the specific jurisdiction apply, additionally, IPL, EU Law and other conventions and agreements will likely apply. See, you don't have to be told that you are not allowed to share something like an MP3 or a graphics file, or use it to produce a derivative work. The laws of most countries in the world already state that. The added contract stuff you agree to on iTunes, Amazon or wherever is simply a restatement and a clarification on additional clauses you agree to. That doesn't change that there is, per default, a restriction on your use. Additionally, you do agree to stuff when downloading the mod and particularly the server files -- and just because this isn't called "EULA" does not mean it doesn't have the same force in a strictly legal sense. All this doesn't mean these things are, in practice, enforceable, but you -- and many others on the Internet -- have a very naive view of law, domestic and international. That depends on the definition of reverse engineering of the specific jurisdiction we're talking about. The interpretations have classically been very wide, especially in the US.

That depends on the *terms* of the mod and on how your specific jurisdiction has interpreted the clauses of the revised Berne Convention and auxiliary copyright conventions. It also depends on the regulations set forth by the producers of the original game. Per default, if the mod or parts thereof can be qualified as artistic, literary or in another sense, protection-worthy, works, you would have to be granted the right to edit and modify it and would be in breach of copyright if you do so without the authors permission, express or, in some cases, implied (fair use clauses -- and: no, they do not apply here).

You guys must live in happy places. Strictly speaking, setting up private hives is likely to be software piracy (copyright infringement) and, depending on jurisdiction, computer sabotage, because you misappropriate software under a specific license and with specified terms of use. It may also be classified as illegal reverse engineering, but that is heavily dependant on whether that in particular is illegal in your jurisdiction. In any case, whether these charges are actually enforceable, under whatever jurisdiction, is another question entirely.

Speaking in absolutes is always bad, but in this case, it's downright funny. For a start, most developers realize that you have to trust the client, however grudgingly, because otherwise you'll have issues that make playing over the internet difficult to impossible. There is a very good reason why most games use client-side hit detection methods instead of server side methods, however insecure that is, there are also good reasons for doing a lot of the other work on client instead of on server -- the server is substantially limited in how much computing resources it can dedicate, the client typically has power to spare. The way ARMA2 handles Client-Server interaction is too trusting for something like DayZ and not optimized for PvP, but your absolute "every developer knows" is just silly given real world constraints and simple empirical data on how most games do it. We know it's not nice that we have to trust the client and in an ideal world, you'd use something like OnLive to eliminate everything but pixel-based aimbots (which were, by the way, the first aimbots), but we're not in an ideal world.

Not really. It is almost certain, that the standalone version will use the ARMA3 Engine which, to a substantial degree, should be compatible to the ARMA2 Engine, especially when it comes to things done through scripting. As such, a lot of what the DayZ Standalone will do can already be done in ARMA2. What the added code access to the engine does is give the team the ability to fix certain weaknesses that became apparent in the Engine from the new spin DayZ took on it.

You are getting the benefit of hosting a server for a mod. Exactly what it says when you sign up. You decide to pay for that privilege, knowing full well the restrictions imposed. It is not anyone's problem if you feel entitled to more. Hosting of DayZ servers currently costs my company around $700 a month -- and I haven't played the game in weeks, I don't have any vehicles on any of my twelve servers, all I have on one of them is a small camp with some stuff that is probably long gone -- and I don't really care. Why am I doing this? Because I *like* this game, because I want to *support* this game and its development and that's worth that money to me. At the moment, this game does not offer features like "clan only servers", "passworded" servers or in any other way private servers. That may change in the future, but right now that's the way things are. It is completely okay to state your views on the matter, to say that you'd like to see private hives, but the thing is, you're not doing that. You and a lot of other people are aggressively calling for that, some people are insulting, claiming they are entitled when they're clearly not; other people use private hives that violate the express wishes of the mod's creator and the terms of use of the mod.

It depends a bit, if you have a slotted server, it is likely complicated. If you have a dedicated server and are just switching hosters, there is no problem. Please just open a ticket at support.dayzmod.com and we'll get this done. :-)

Not at the moment, but thank you; just need to find some time to rewrite something about the servers. :-) It never displayed as well as I would've liked, that is, the way it is shown here, but the recent ARMA 2 OA update has changed some font properties and now it really looks messy. I haven't found the time to redo it again, though.

The scripts.txt linked above is very optimized. If your server has not encountered any suspicious script executions, it may not have logged anything.