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.

I am seeing higher than normal server CPU load, R4Z0R49 - do you mind sharing the following recommended arma2.cfg for public hive (if you are aware of optimized parameters): MaxMsgSend=;MaxSizeGuaranteed=;MaxSizeNonguaranteed=;MinErrorToSendNear=;MinErrorToSend=; Any help greatly appreciated. As for the client-side patch. The new inventory look is nice, once you get used to it. Zombies are no longer dancing in circles - yay! Loot spawning is much better. Thanks!

Sad to see another public hive server go, but the general hive population has diminished greatly recently. The hive connection problem dropped the average number of players even lower. Thanks for providing the service.

Good day all, I have several objects in my server instance that are in the debug area: Does the public hive not automatically move out of bounds objects to the edge of the map? I looked at dayz_server.pbo under \compile\fa_hiveMaintenance.hpp: Both of those values are not defined, and editing them causes the server to never initialize the hive connection on startup. Any assistance greatly appreciated. I don't want players saving vehicles outside the map or having for inactive/bugged ones to respawn after the inactivity timer (whatever it is). Thanks for your time in advance.

The connection seems consistent now on restarts, thank you for finally addressing this. Like a few others, I was ready to give up on the public hive - but I am happy to keep the pure vanilla instance going.

Still happening on random restarts, same timeout error for me (US 1257)

The ratio for me now is about 1 out of 6-7 restarts. Someone must still have access to the host SQL host, because things like these do not happen out of the blue. Some configuration got changed.

This is madness. I can not babysit my auto-restarts all the time. It takes about 6 manual restarts to get a properly working connection.

More timeouts than usual today, quite sad.

Get rid of this line (remove). It is doing no good and just causing data packet fragmentation for your clients.

Send me a private message with your in-game nickname and your GUID. You can find your GUID# by joining any server and typing #beclient guid in the chat box.