Freeborne (DayZ)

Well I can't speak for every server, but the DayZ Dev's update ours, and make config changes from time to time (without us knowing about though). They've undone all our FireDaemon Pro setup, and replaced it with DayZ Server Monitor about 12 hours ago. It now restarts our servers and Hive apps every 6 hours, regardless of if they only restarted (after crashing) 10 minutes ago, or if it's all running perfectly. Players of course are not notified because it's automatic. The belief was that a game server will run really bad after 6 hours, so a restart fixes that. As you can tell, that theory has it's own flaws too. If we (cm or myself) are doing manual restarts to fix something, we always sent a global SAY via RCON, giving ppl 3 minutes to save their cars, gear, etc. But, we're different. We believe in common curteousy :( Now with this new app though, we can't do manual restarts unless we close the whole DayZ Server Monitor app down, which means closing down our other server running off the same box. But it's okay. It's an alpha...

AusArmA was hoping to have another 2x servers up this weekend, but there was a delay in the server provisioning. It should be up Tuesday or Wednesday.

Suggest changing the naming format of the "users" folder to the region name of the server. Eg: US1 EU4 ANZ3 When BattlEye message pop up, it uses that name. So IMHO it looks silly when it says something like: "cfgday2: Bob was kicked. Ping too high, etc...."

Well Antipop edited his post in that thread on the 14th, so I never read the thread again since it was edited. Our servers were setup before that date, with no instructions, no how-to's, or advice on what to do, and what not to do. I guess server admins are expected to read the same threads over and over again, incase they're updated? I still stand by my statement, which was not in direct response to passwording servers either. Just overall lack of info given to server hosts. There was nothing saying you have to have a dedicated IP for example, or that you must run at least X number of slots. Nothing about what configs and difficulty settings to run, etc. We ended up fine-tuning our server quite a bit, and several times DayZ mods have RDP'ed in, and undone it all, often making really noob mistakes in the process, such as wiping out difficulty settings, renaming the server, or just using generic passwords. There's obviously little structure within the Dev team, and it shows. We don't even know when an update is out, without checking the forums frequently, or looking at other server names. If you're a server admin, and want to just talk with other server admins, you can't do it. Make a post anywhere here and it gets flooded with bunch of kids who have NFI what they're talking about, but just love to fill up every thread with their spamming opinions.

Against the rules? I'd give them the benefit of the doubt, in that maybe they don't know about this non-existent set of rules, which consists of multiple forums posts all over the place, rumours, and contradictory statements by various DayZ staff and 'unofficial' DayZ staff. Where is the big long list of rules saying what server admins can and can't do? Why should server admins have to browse these forums, with 90% spam, just to find out what they aren't allowed to do? When they find out what they can do, DayZ staff come and wipe it all out and make changes to undo all their hard work anyway.

Google > "arma2 dedicated server ports" > http://community.bistudio.com/wiki/ArmA:_Dedicated_Server The short-cut to launch your 2nd server would look a little like this: "arma2oaserver.exe -mod=EXPANSION;ca;@dayz;@CBA;@JayArma2Lib -name=server2 -config=server2\server.cfg -cfg=server2\arma2.cfg -profiles=server2 -world=Chernarus -cpuCount=2 -exThreads=7 -port=2402 -nosound"

If a server is using the wrong mission instance ID, then no vehicles will spawn. If someone else uses the same instance as another server, it will cause problems and vehicles will appear and disappear on both servers depending when one of them gets restarted. If a mission starts and 50 players flood in, click Continue, and all load the mission at once, the server will probably experience dsync and everyone will see red chain for a minute. That usually causes the vehicle/tent initialisation scripts to time out, so they don't spawn. After the red chain goes away, everything else is okay with zombies and loot later spawning, but vehicles won't appear until a server reset. We lock our servers sometimes and let the server load with less than 10 people in, then unlock it after we've allowed enough time for tents/vehicles to spawn.

Jump on a few DayZ servers. Quit. Check your ARMA2 folder for the MPMissions. In there will be a separate mission file for each server you joined. Some of the new ones I think are hard coded to 50 slots, but some are still setup for 100 slots. Go on Dev-Heaven and search for dePBO. Unpack the mission file, and there's 3 files you can easily edit with a text editor. It's pretty easy to see what you need to change there. Then don't forget to change the max player setting in your dedicated server config settings.

DayZ is a MOD, for a game.. called..ARMA2 ;-) So jump on Google, and read up on how to setup ARMA2 servers. There's a guide by Kelly's Heroes which is quite good (it has a few mistakes, but nothing you can't fix by reading up the latest on the BIS wiki). You need to change the port for each game instance you run, and you should also have different folder for each game instance with separate copies of the server.cfg, beserver.cfg, arma2.cfg, etc. All of these are defined in the startup line when you run the file. So you'd have say 3 batch files to run 3 servers, and each one would have different parameter options to specify the game port, what config files to load, etc.

C'mon man. Use Google. Take you less than 30 seconds to find what you're after. http://forums.bistudio.com/showthread.php?131759-New-BattlEye-features-for-server-admins

http://en.wikipedia.org/wiki/Hawaii :-p

We ping 160ms to Hive over TCP, so a DB closer to home would offer better performance, with a local distributed model, offering nanosecond response instead of millisecond, yes? Is that 5000 simultaneous remote connections, from all around the world with roundtrips of 300+ ms? From our end, it seems to cope rather well, but something is causing Hive and HiveAuth to lock up sometimes. It looks okay, but it won't process new data. It's not a game server issue in these instances because we run 2 or 3 game servers off the one box, so unlikely all 3 would fail at once, right? More meaningful output on Hive and HiveAuth console would also help admins troubleshoot, or just have a clearer idea of what's going on the background. I mean what do 201 and 202 mean, etc and why not display the player's name when they authenticate.

Yes, probably. If you play on those servers, look for an in-game admin, or go on their TeamSpeak and see if you can find one. If several players have same problem, it's probably something they can fix by restarting server or Hive apps. There's also players who install 1.5.6 over 1.5.7 and then join a server. They get the msg "you need to update your files", so they then copy 1.5.7 back again, overwriting 1.5.6. Then they rejoin and get straight back in the servers. I believe the reason in those cases is the players have some corrupt data in their gear (I see it often in the Hive logs), so going back to 1.5.6 sort of clears out that corrupted data, so that when they upgrade again to 1.5.7 they have a nice clean inventory of gear and the server processes that quickly.

I don't know for certain. What I have noticed though was over the past 24-48 hours, there was frequent errors in Hive and HiveAuth, and sometimes these apps could not communicate with the remote SQL server either. I suspect the server was getting hit too hard and refusing some of the connections and data we were sending it. My other assumption, is that Hive and HiveAuth are not programmed to be forgiving when the central Hive server is unreachable, so the program will still run, and ARMA2 server will keep running, but the actual SQL connection and data will not go through, causing issues like "Waiting for Server Response". So some server admins are restarting their game server automatically when it crashes, but they need to manually restart HIVE too, even though the app hasn't crashed, it needs to re-authenticate with Hive again. I played on a few servers, and they had the same problem with Waiting for Server Response. The game server would crash and restart automatically, but the problem persisted. On our servers, we kept manually restarting the Hive apps and it fixed our problems, but they would return after a while (again, because I believe central Hive was overloaded)

http://en.wikipedia.org/wiki/Oceania Can you confirm the physical location of the server. I think you may be thinking Oceania refers to the Americas?

So call it "Expert". Everything's off in Expert, including 3rd person, by default. My advice is still to ask for less upfront cost. I'm just giving my opinion as an outside observer. I read the link you posted, and all I got was basically this: - We have run A2 servers before, but we won't tell you which ones, just trust us that we know what we're doing. - Everyone else can only manage about 50 slot servers, but we're going to do better, coz we can, trust us! - We want 4 months upfront now. We want your cash before you get a chance to see we can meet our claims of high slots and a stable server. - We also have no forums, and no TeamSpeak server, but trust us, we'll get one, and it will be super awesome. Sorry, I'm often a pessimist, but all I get out of that is some 16yo expecting a bunch of players to donate to a cause with no credibility. As an example, we paid for the first month for our server at our our own pockets (cm and myself). We THEN started taking donations after the server went up. Donations flooded in after that, as everyone was to happy to play on our servers. In less than 2 weeks we raised another for another 2 months, with the promise of refunding all PayPal donations if we don't raise enough for the next month.

Yeah you cant loop the MOTD. I don't think it would be that practical though, as you probably only want to repeat one or two lines, not the entire series of messages including the "Welcome to my server" bit. You should instead using BattlEye RCON and the "Say" command. You can create a batch script that logins via BE, and says something like "Say -1 Please remember to donate to keep this server running" and then put in a pause of 60 seconds in the next line, and then repeat it, etc.

Why is it hard to understand? I don't know what their limits are, but let's just say its 200GB of data transfers per month, but unlimited data transfer within NZ. If they allow Australians in their server, they'll get flooded with us (as there's more of us looking for a server, than there is Kiwis), and that 200GB will get used up in 2-3 days. Here's an example of a typical plan/pricing for NZ dedicated server: http://www.webslice.co.nz/dedicated-servers/ They might not have access to IP filtering to block our Australian IP ranges, so they have to use a really low IP ping limit. Last I read they had it at 60ms.

What kind of server hardware do you have, to run over 50 slots? With the latest DayZ patch, running 50 slots means having about 1000 zombies spawned. As Mojo said it's more a limitation of ArmA as to how many players "any" server can comfortably support. You won't get 100 players for example without it crashing frequently, and having such low fps that half the scripts don't work properly, loot won't spawn, zombies will spawn with long delays, etc. If you don't know how to dePBO a mission file, I doubt you know how to optimize your ArmA configs to squeeze more performance out of it then the ArmA admins who have been running servers for years? I'm not ArmA server guru, but we use an E3 1240, which is only 300MHz slower than the 1270 from memory. You cannot use more than 2 cores in the server engine. We managed 75 slots with 1.5.6 quite comfortably on 2 cores. After 1.5.7 we had to drop it to 45-50 slots, with all the extra zombies. We still get about 4 fps though. 1 month in DayZ universe is a LONG time. I'd suggest raising enough money for a month's server hosting, and see what you can do in that time, instead of trying to raise so much start-up cash, without proving to your customers you can achieve your goals. Run a DayZ server for a month, and see if you can make it more reliable than everyone else, and squeeze more performance out of a server that's less powerful than what other's are using. See how stable you can get DayZ, without touching any of Rocket's coding or custom apps, and only working with the few small areas of your server you are allowed to modify ;-)

NZ1 is hosted by ON3. They have unlimited national traffic, but limited international traffic. Traffic to Australia is still counted as international traffic. So they can run the server fine if only NZ players join. If Aussies join, they'll use up their limited international traffic allowance. My ping to the server is 47ms and I'm in QLD, Australia. So if they're going to sustain the server, they'll need to have a super low ping limit. Basically, if you don't live in New Zealand, DON'T play on their server ;-)

You can repeat the MOTD warnings several times, change the MOTD Interval to change the frequency of messages, and use blank lines to space them apart further. Use special characters and spaces to make the warnings more visible between the flood of global chat spam. It seems you're being proactively lazy about educating your users. Do you really think making a topic here will get read by the hundreds of noobs joining your server? Also, Join-In-Progress (JIP) has always caused spikes in bandwidth consumption with A2 servers. Alter your min/max bandwidth settings if it's a concern, it will also result in dsync but conserve your bandwidth usage. I do not disagree that continually joining causes issues for the server, but asking players to just 'keep waiting' won't solve anything except have players filling up your slots for 20+ minutes and ruin their gaming experience.

http://community.bistudio.com/wiki/server.cfg

Yes, also getting it on our servers. Had it pop up a few times yesterday too. I say it can't handle this many simultaneous connections from the internet.

Sorry Mojo, I disagree with your advice. Both the "Loading character data" and "waiting for server response" refer to issues with Hive. Hive can be down for everyone, or experiencing high load which will cause intermittent problems world wide. This however, is not that common. What is more common, is the local server to have issues of it's own, commonly caused by Hive and HiveAuth locking up, or trying to process corrupt data. In those cases (i.e the majority) it's wise to find another server. More recently, some servers didn't make it on the IP whitelist, which also caused issues just for those servers. So, in most cases, moving to another server is usually a better idea, then continually spamming the same server. Most users are new, so admins should be putting a MOTD that explains the long wait periods. We do that on our servers, stating it can take 3-5min, otherwise to try to rejoin. These 10+ minute wait times are nothing but superstition. It does NOT take that long to load your data, and if it does, there's something wrong with the server 9/10's and not Hive.

190 slots running at the moment. It's only 12 noon on a Thursday, and most of the servers are full. Last I checked 15 minutes ago, there was only 11 slots free between 6 servers. Those 190 slots will be completely full I'm sure by 3 or 4PM. Waiting on ON3, to see how many slots they'll put up, but AFAIK they'll only be servicing NZ players. (There's about 8 times as many AUS players compared to NZ, on average) AusArmA is getting another server in next day or two, and should be able to provide up to 90 more slots, which we'll put up on an as-needed-basis to ensure decent numbers in all servers (rather than just a few in each during off-peak times). I think that should cover the demand for ANZ region for now and eliminate the waiting periods.