DayZ Private Server Files Pack (1.8.8)

24/7 40+ people @ my server.
after updating to 1.7.4.4 the server is crashing at restart randomly --> database.dll error
i downloaded the latest hive files (not from pwnoz0r) now it restarts fine, but is crashing randomly after 1 hour
 
I can get you up and running, just can walk you through it easier by voice instead of typing. I have Steam, Teamspeak, Skype, pick your posien. I finid Teamview to be very helpful as you can share your screen allowing the other person to see what you are doing and troubleshoot your problems easier.
 
Every time the server goes completely empty after players have played (even for one minute), ArmA crashes without fail.
 
Thanks for causing me problems Pwnzor
I don't know WHERE you got this table layout, but it's wrong on a couple of different levels:
Code:
Player_DATA:
1. Missing PlayerMorality in case it's used in the future
Player_LOGIN:
1. PlayerUID can be NULL
2. CharacterID can be NULL
3. Datestamp can be NULL
Character_DATA:
1. PlayerUID 16 chars instead of 20 like in Player_DATA
3. InstanceID is a VARCHAR(4) what ?!
4. All the datetime typed fields are timestamp type for some reason, and some of them can be NULL when they shouldn't
5. Inventory and Backpack are varchar(2048) instead of longtext (IMPORTANT !!!)
6. Worldspace is TOO SHORT (at least 128) (IMPORTANT !!!)
7. Medical is TOO SHORT (at least 300) (IMPORTANT !!!)
8. CurrentState is TOO SHORT (at least 200) (IMPORTANT !!!)
9. Humanity has NULL as default and can be NULL
10. Missing keys on PlayerUID, Alive

And there are other smaller problems such as differing field types, but those don't cause problems
The BIGGEST problem are the TOO SHORT fields, which cause SQL ERRORS on UPDATE statements, and then people come and complain to me, not to mention that data is being dropped into the ether !

If you use the proper table layouts, the fix from github.com/R4Z0R49/DayZMod/issues/115 works, DO NOT USE OLD FILES like 1.7.3 dlls.
 
IMPORTANT - ALL SERVER ADMINS USING PWNZ0RS MAP PACK READ THIS

The table structure of character_data needs immediate editing

In some extreme cases, the "Medical" cell length is not enough to hold data for medical. If this happens, your logs will be spammed with errors and the server will enter an infinite loop and crash. I know this as it just happened to me.

If you do not know much about MySQL - you need to increase the length of the "Medical" column.

To do this, access hivemind from Navicat and right click"character_data" table and go to "Design Table".

From this you need to change the length of "Medical" to something greater than 128 (what it currently is). To be safe, I have changed mine to 2048 until a fix is released. This will stop any errors caused by the data not fitting into the cell. The server does not need to be taken offline to make this change.



I could not post this as a new topic. I hope one of the admins does so soon!
 
That's what i said one post above yours, after someone posted me their HiveExt.log, and said that he got the "server pack" from this thread.
Change the field lengths to the "at least" values of the lines marked with "IMPORTANT !!!"
 
I think the 2048 varchar fields are OK - Varchar can handle something silly like 65kb since MySQL 5.0.x or something. Thank you for your other fixes, I am making ammendments to my table structures right now. +1rajkosto
 
Is inventory and backpack supposed to be varchar or longtext?

By the way thanks to Pwnoz0r, Doc, rajkosto, and everyone else!!!
 
Thanks joikd. I belive both will work, varchar is probably more suitable as longtext is designed fot data entries that are millions of bytes rather than hundreds of bytes. I didn't edit my backpack/inbentory structure as I belive 2048 varchar is mote than sufficient. I would like to hear the big mans input on this. either way it *Must be increased in max value
 
You can do it either way
Code:
+------------------------+-----------------------+
| MAX(LENGTH(Inventory)) | MAX(LENGTH(Backpack)) |
+------------------------+-----------------------+
|                   1929 |                   763 |
+------------------------+-----------------------+

However, VARCHAR always uses up the specified amount of bytes on DISK/RAM, while a TEXT field would be stored separately and use up only as much as is stored in it.
 
  • Like
Reactions: Doc
Thanks rajkosto, I didn't know that. I will change the column to the lowest Text type then. +1
 
Thanks for causing me problems Pwnzor
I attempted to match the public hive layout. I will revert it back and replace the old data with the new. Sorry for causing all the problems. QQ

EDIT: I didn't change "object_data"... where did you say the errors were?
 
You used ancient antirocket-dumped SQL files when there were nice and updated ones available on my HiveExt github.
I just now updated them to even more closely match the public hive SQL layout, have a look:
github.com/rajkosto/hive/tree/master/Hive/SQL
 
Medical is still only varchar @ 256 bytes in that one. You positive that's enough?
 
Well... the only reason it would be larger than 170 is if hackers put their script code escaped in there... So maybe put it at something crazy like 2000 and then you know anyone with > 200 is a hacker
 
Back
Top