Gand (DayZ)

It is a bummer situation, I have to agree. While 1257 was never as popular as 3480, I really enjoyed providing another place for the community to play and do my best at keeping script-kiddies at bay. Personally I feel like there aren't enough players left in the vanilla sphere to warrant running another private hive (for me). Anyway just wanted to say thanks for providing a good server and helping out with some advice. I guess the mod has had a fairly decent run and all the branched out modifications are more appealing to whatever player population still exists.

Agreed. The only thing I personally do not like is the side-chat, but it is just a personal preference. US 3480 has a stable population.

Bump, still no hive connection. Does anyone have any idea about what is going on or know whom we should be contacting? Edit: Similar symptoms as before, takes multiple mission restarts to connect properly to the hive.

Just noticed mine died on restart as well. Nooooooooooooooooo. I hope someone bothers to monitor these boxes even a little.

You can not disable it on the client. This is part of the mission file, which is download/executed when you join the server.

The Arma2 Server is single threaded for the most part and will only fully utilize 1 core. This means that if you are running a traditional 4 core (quad) CPU like an i5 without hyperthreading your overall system CPU usage will be 25-30%. There is some overhead with log files/hive IO. Pure number of MHz on a single core is really all the server cares about when you are talking about server-side FPS.

I think he means in-game admin/server messages, which are red by default. I am pretty sure that color you can not change.

They need to update their BattleEye filters. If you are not the admin, there is nothing you can do but wait until they do so.

Thanks, I was trying to add it to line 0 and it wasn't working. Line 1 did the trick.

Bump. 1.8.0.3. Getting kicked for PublicVariable Restriction #1 with latest filters. Happens within a couple of seconds of logging/spawning in. 14.10.2013 11:05:10: Dangbackwards (x.x.x.x) - #1 "PVDZ_getTickTime" = <NULL-object>

They are frames per second - for the server. This is not directly related to frames per second each client (how quickly their machines can render what is happening on their screen). Simulation frames are not graphical frames, they are "complete" calculations for everything the server has to process like player movement, bullet physics, etc.

Server side FPS determines how quickly the "simulation" runs on the server side. As facoptere described, all the things the server does like dead body cleanup, etc. If your server FPS drops below 10, things become inconsistent and people will notice strange things happening when they are around zombies/objects and while they are trying to do things like manage inventory.

I understand the RPT file no longer reports "possible" combat logs. This was the case in 1.7.x.x anyway. I am not sure if its back in 1.8.

This sounds like a server side lag problem. The loot spawns are much more consistent now, but this also means the server is keeping track of way more objects when its running its logic loop = more CPU usage on the server. I suspect a lot of servers are not handling the greater amount of loot very well and hence the lag. My only suggestion would probably be to try a server that has a consistent 4-6 hour restart schedule.

I understand, but the parameters do make a difference in CPU usage. The server side FPS determines how smoothly the simulation runs to the clients, and the default MaxMsgSend and MaxSizeGuaranteed are not necessarily optimal. I was just asking for some semi-official recommendations, since there is a lot of possibilities and no "official" input on the matter.