Intermittent Humanity Reset on Death

[GeryonTom]

Okay I'm in need of some advice. There has been an intermittent problem where player's humanity are being reset to 2500 typically after death or when logging back into lobby. Sometimes players spawn back in time (with respect to location).

I guess I'd like to ask: Is there a know issue? If not could this be due to low server fps when the player population is high? Where should I look?

I'm using the 1.8.2.rar schema: https://drive.google.com/file/d/0B9svef6jQxfZTk5jVTFHSEFLd1E/view

Other notes from other player comments: RomanZ: http://forums.dayzgame.com/index.php?/topic/206360-dayz-mod-182/page-16#entry2128721 Bullet_Catcher, Smurf and Medic: http://forums.dayzgame.com/index.php?/topic/206360-dayz-mod-182/?p=2127798

Sorry no direct steps to reproduce but it looks like certain players will have the reset on death and respawning in.

[GeryonTom]

Oh one other thing no AH like Infistar is being used. Plain Jane BE and Faco's BE Filters.

[R4Z0R49]

Whats strange is others are not reporting this issue. We will try to get it looked at

[GeryonTom]

Okay txs R4z0R. I did notice a few have complained about it recently from other servers on the 1.8.2 forum but agreed it is mostly from US 434. I did a double check on the hive and DB DLLs and they are the correct ones. I might do a reinstall again if it persists.

[bchawke]

After extensive testing (ie we play DayZ WAAYY too much!), my group of friends and I have noticed that the reset seems to happen if your character dies and you do not log back in until after a server restart. We've died a number of times and immediately respawned with no humanity reset. We log out and back in daily without dying and do not get humanity reset. But since we noticed the trend, every time we've died and not logged back in until after the server restarts, we get the humanity reset back to 2500. This is wreaking havoc in the game as bandits look like survivors and heroes who spent months giving medical care are losing all that work.

I'll try this out on another server to see if it's happening there and post the results here.

[R4Z0R49]

Im not too worried about this as you say in another post it's easy to cheat your way into bandit/survivor.

Replacing the hole system would be the better choice it's never been too good. But while we wait to redo a new version ill see if i can find the issue.

[NPG-Soul]

@bchawke

Does the server delete all dead player characters every restart by any chance, cause then i can see that be happening with those specific conditions you state. In fact it would be default behaviour for the current official hive.

what it does is take the humanity of the most recent dead survivor character and apply it to your new character to make it persistent, but this requires the existence of a dead character otherwhise it will default to 2500 points.

I however still run reality hive and do not suffer this problem as it is stored in a different persistent table.

IMO persistent stats should be stored in a persistent table and not be relied upon the existance of rows that might get deleted every restart, just my 2 cents!

[GeryonTom]

UK431,

The server places all dead characters from character_data into character_dead. After it deletes the dead characters from character_data table. This cleanup routine happens at the beginning of every restart.

That's what the schema package linked with the mod came with. However I see your point about the cleanup especially if it's relying on the most recent death in the character_data table to spawn in your next character.

I'm going to disable the character cleanup DML statements to see if that covers it.

[NPG-Soul]

this is the code that actualy gets previouse char information to make a new survivor entry... server_playerLogin calls for child 101 and this then checks if you are a known player, if you have a living character and handles accordingly.

//try getting previous character info
        {
            auto prevCharRes = getDB()->queryParams(
                ("SELECT `Generation`, `Humanity`, `Model`, `Infected` FROM `Character_DATA` WHERE `"+_idFieldName+"` = '%s' AND `Alive` = 0 ORDER BY `CharacterID` DESC LIMIT 1").c_str(), getDB()->escape(playerId).c_str());
            if (prevCharRes && prevCharRes->fetchRow())
            {
                generation = prevCharRes->at(0).getInt32();
                generation++; //apparently this was the correct behaviour all along

                humanity = prevCharRes->at(1).getInt32();
                try
                {
                    model = boost::get<string>(lexical_cast<Sqf::Value>(prevCharRes->at(2).getString()));
                }
                catch(...)
                {
                    model = prevCharRes->at(2).getString();
                }
                infected = prevCharRes->at(3).getInt32();

            }
        }

[GeryonTom]

Thanks UK431 that puts a lot into perspective. For now I've disabled the select insert into the character_dead table + deleting all the dead characters in the table character_data table. I doubt anyone will do a select union statement into code above so when my brain stops hurting I'll do set up a cleanup script that always leaves the latest dead character in the table character_data.

[NPG-Soul]

imo persistent stats should be stored in persistent tables not in the character data tables its a fucked up idea whoever came up with that should be punished ;)

[dayz10k]

That makes no sense.

Sent from my iPhone

On Oct 12, 2014, at 1:11 PM, UK431-Soul notifications@github.com wrote:

imo persistent stats should be stored in persistent tables not in the character data tables its a fucked up idea whoever came up with that should be punished ;)

— Reply to this email directly or view it on GitHub.

[facoptere]

For admins: could you check if you can find such lines in HiveExt.log:

2014-10-12 14:02:15 HiveExt: [Information] Method: 102 Params: 35965461: 2014-10-12 14:02:15 HiveExt: [Information] Result: ["PASS",[false,false,false,false,false,false,false,12000,[],[0,0],0,"B",true,[71.501,550.156,0]],[0,0,0,0],[["M4A1_HWS_GL_camo","amovpknlmstpsr aswrfldnon",42],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]],[320,[1475,9501.95,8.545e-04]],-44933]

--> Humanity is -44933

2014-10-13 15:28:12 HiveExt: [Information] Method: 102 Params: 35971002: 2014-10-13 15:28:12 HiveExt: [Warning] Invalid CurrentState (detail load) for CharacterID(35971002): [["LeeEnfield","aidlpknlmstpslowwrfldnon_player_idlesteady04",41],[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 2014-10-13 15:28:12 HiveExt: [Information] Result: ["PASS",[false,false,false,false,false,false,true,9031.03,[],[0.015,0],0,"B",true,[33.24,594.491,0]],[0,0,0,0],[],[42,[10411.9,2563.03,5.003]],2500]

--> due to the currenstate error, humanity is reset to 2500

Achievement array is too big to fit into currentstate column limited to 100 chars.

[GeryonTom]

I did a text search on Invalid CurrentState and couldn't fine one instance on the current hiveext.log. It's currently 250 megs so it's not super large but it's not just data from one restart either. I'll do a check another night to see if I see the text.

By the way we haven't had a humanity reset in nearly a week with the cleanup being disabled.

[R4Z0R49]

currentState varchar(1000) NOT NULL DEFAULT '[[],[]]', <<< its 1000 from 1.8.2

https://github.com/R4Z0R49/DayZMod/blob/Development/SQL/1.8.2/character_data.sql#L33

[GeryonTom]

I can confirm currentState is a varchar(1000) as well.

[R4Z0R49]

Also plz remember the private SQL wasn't really used for anything more then testing. The official didn't cleanup char_data due to a few items. So cleanup will need to be reworked/updated.

[facoptere]

So can we mark this as closed? I think it was the cleanup.

[GeryonTom]

I would agree.