Safes are still losing contents

[justchil]

I've applied all the fixes posted by ebay (forEach replacements). For almost a week I didn't get complaints but once again the problem is back. The last time I investigated it I came up with the same details.

9:22pm Player1 puts items into safe:

[[["M32_EP1"],[1]],[["ItemBriefcase100oz","6Rnd_HE_M203","ItemObsidian","ItemSodaRbull","ItemRuby","ItemBriefcase90oz","ItemBriefcaseEmpty","ItemBriefcaseS80oz"],[44,3,3,1,1,1,2,1]],[[],[]]]

I confirmed that he put all of these items into the safe with addmagazinecargo.log. I didn't confirm if he put the weapon in there but it remains there now. I also confirmed with my database backups.

At 9:59pm Player1 unlocks safe and finds all items missing and submits a ticket for help.

I have backups at 9:50 and 10:05 (15min) and I can confirm that the items are indeed missing during this period.

[[["M32_EP1"],[1]],[[],[]],[[],[]]]

There was a restart at 9:30pm EST which is 8 minutes after Player1 placed items in the safe and they were there afterwards. I don't know what other information I can provide. There are other server ops with the same problem but I guess most just replace gear and move on.

I have just turned hive.log back down to 'notice' after almost a week of no problems. If trace logs would help any I can turn it back up to that level and wait for it to happen again.

From what I can tell it happened when he unlocked the safe.

[justchil]

I changed a few more counts back to forEach. I don't have a full understanding of c/c++ etc but we'll see what happens. I'm also running trace hive logs.

[Uro1]

I've had players having the same situation except with StorageShed_DZ which has a huge magazine count compared to safes.

They have a lot of different items in the shed in question, and stowed gear (guns/mags) in it ~10 mins prior to restart. After restart the storage shed was back to the way it was prior to them putting items in it (weapons/mags/backpacks).

Im thinking along the same lines as justchil, that it's not counting the items correctly.

That or, StorageShed_DZ may suffer from the same string length issues that were effecting safes a while back. StorageShed_DZ has a magazine limit of 400. 400 different items would be a collosal string length :D

[justchil]

Yeah I don't know. I changed pretty much every count back to forEach in the server.pbo and I've only had 1 complaint since (which wasn't legit). Pretty game breaking bug with no attention but that's ok. I figure. Why they would commit something like that is beyond me. I have probably 20 fixes reverting that command back and didn't see any performance gains from it.

[icomrade]

Anecdotal evidence is great and all, but I have never experienced this "bug" on any server I've played on. Which is not to say that it doesn't happen, but there are many variable from server to server. I have, however, had my safe reset after locking it too close to restart in patches prior to 1.0.5, which is pretty much the exact situation you described in the first post. cheat protection, DB performance, server performance, and probably most importantly, the way the server is restarted.

Do you have a backup of the DB when the server restarted? Does this happen when a safe contents are changed with more time away from a restart?

For your concerns about performance, or as to why it was committed. In a scheduled environment count will run 1 frame faster than a forEach loop http://pastebin.com/AWgv27iR You won't see any performance gain in FPS from this, since the thread it's executed on is not the main thread (same reason why you can sleep in non-blocking threads). If you haven't seen any performance gains it's because you haven't tried to benchmark them.

These changes have occurred in many files, including fn_selfactions, fn_damageActions, etc. If there was an issue with count iterating through an array as a loop these files would be non-functional and break fundamental functionality of the game. I'm not convinced that there's an issue with count, but I am convinced (have seen and reproduced) an issue with locking a safe too close to restart.

[MGTDB]

I remember something a while back about open safes and loot piles and the subsequent cleanup partially wiping some of the safe contents, could this be the cause?

[justchil]

I wish more people would post because I know they're having problems too. I have looked at backups before/after is happened before/after restarts. It seems to always happen when the player unlocks the safe after some time of not being accessed. I have about 8 new cases of it happening over the past week so I will start digging into those. I can go a bit without any issues but it may just be players not playing for a few days then coming online and noticing.

[RimBlock]

Are you able to put in a few debug lines to capture any insert and removal from safes (who, what, when) ?.

You could also add an audit table and suitable UID triggers to capture any object (would suggest just safes in this case) changes at a DB level so you can see when it is happening. I did post up the triggers previously on the forums. PM me on the forums if you want the code again.

[MGTDB]

This is still happening, it's related to a self corrupting file in 125548, client crash when leaving game is the most noticeable symptom. When the client verifies their files in Steam, 1 file is corrupt and downloaded. Prior to them verifying, this corrupted file still allows the player to join the game but if they interact with locked storage in some instances all or partial storage inventory is wiped.

[ghost]

I am also having this issue. http://epochmod.com/forum/index.php?/topic/2423-safe-item-deletion-please-help/

My post on the issue -> http://epochmod.com/forum/index.php?/topic/16493-epoch-v1051-safe-deleting-contents/
@MGTDB, you do realize that you can go into Steam verify files, get that error have it downloaded and instantly verify again and you will get the same error.

I've run version 125548 stable for months now with no safes deleting contents after restart. It's only since updating to 1.0.5.1 or 1.0.5.2

Only edit I've done to the original sqf files not suggested in the install instructions is taking the copy paste code and using a second and third variable _index, _index1, _index2 in places I was getting the error
3:21:50 Error in expression < select _index1;
_itemType = _itemTypes select _index2;
_veh addMagazineCargoGlo>
13:21:50 Error position: <select _index2;
_veh addMagazineCargoGlo>
13:21:50 Error Zero divisor
13:21:50 File z\addons\dayz_server\init\server_functions.sqf, line 368

Datestamp is 6 Sept

I have since removed any error now other than minor ones related to .p3d which I believe to be model descriptions due to the error being about a face.

I am still having issues with safes.

[ghost]

Update fixed, added UK431-Soul suggested check.

[CyberJunki3]

@VladisuarusReX - Are you referencing to actually fixing this issue? I still have this issue big time. Servers been empty now.

Detailed explanation of whats going on:
Safe placement/codes/etc is working perfectly fine.
ANY amount of items (even tested by myself) placed in the safe, Weapons, Magazines, etc, will reset but only as the player OPENS the safe after a restart. Doesn't actually reset on the restart.
The entire string is still the same in the database until the moment the player opens the safe (after restart) and the forEach pull didn't fix it. Same exact issue.

I am 100% sure this isn't just players trying to get free items due to the fact that i've tested it even with a bandage, hatchet, other small items.

Can somebody please link me towards a fix if any or suggest where I could start looking?
I almost wonder if its in the unlock safe script area.

[justchil]

I still have the problem as well. I think players are starting getting used to it and it's going to leave a bad taste in their mouth when it comes to A3 which seems to be where the focus is now.

If it happens to a player once it seems to happen again.... I'm not sure if it's how they utilize safes / where they are located... or what. I quit investigating after players started accepting that it's pretty much happening everywhere.

I have seen safes that just don't update in the database for whatever reason.... The one I was able to reproduce was on top of the bridge on Tavi. I could place a safe (it would be in the db) and put items into it and they would never show in the db... although I put one on the ground beside the bridge and it worked fine. I have no been able to duplicate the problem of losing items of safes no matter what I do nor ever had it happen to me on the servers I play on as non-admin.

[CyberJunki3]

I haven't experienced them not updating in the database, that is certainly a weird issue of its own. (Just to add that to my comment)

Thanks for adding your input, @justchil

[nkukard]

I've not seen this on Cherno. What about setting MySQL to log all the queries? It really shouldn't be hard to debug.

The only time I've been able to reproduce loss of items is by killing the server process instead of shutting it down properly. It either rolls back (looks like caching of data going to the DB), or simply losses the last few mins of changes/data.

[ghost]

In server monitor change these lines:

_object setVariable ["WeaponCargo", (_intentory select 0)];
_object setVariable ["MagazineCargo", (_intentory select 1)];
_object setVariable ["BackpackCargo", (_intentory select 2)];

To:

_object setVariable ["WeaponCargo", (_inventory select 0),true];
_object setVariable ["MagazineCargo", (_inventory select 0),true];
_object setVariable ["BackPackCargo", (_inventory select 0),true];

I was actually seeing an error in my rpt log whenever players locked or unlocked their safes, since the db showed items in safes prior to unlocking but after unlocking showed them empty I looked my error was related to the lock unlock event.

if (count _inventory > 0) then {
if (_type in DZE_LockedStorage) then {
// Fill variables with loot
_object setVariable ["WeaponCargo", (_inventory select 0),true];
_object setVariable ["MagazineCargo", (_inventory select 1),true];
_object setVariable ["BackpackCargo", (_inventory select 2),true];
} else {

                //Add weapons
                _objWpnTypes = (_inventory select 0) select 0;
                _objWpnQty = (_inventory select 0) select 1;
                _countr = 0;                    
                {

I guess since it will error returning zero select or similar and the lock unlock event empties the db.

[RimBlock]

So the safes contents were being read as the server loaded the DB objects but not broadcast to client machines.

The added field in the setvariable command tells the machine running the command to broadcast to all machines on the network.

Unfortunately as the safe is accessed its contents will be saved (on gear menu exit IIRC) and as the client has no contents, the contents are empty in the inventory update sent to the server and written to the DB.

[justchil]

These are two separate issues. My issue in the "OP" was that they are lost not on a server reboot... just randomly or when the player opens the safe.

What's pasted above was actually the "fix" for safe contents being lost on restarts which is already in 1501 files.

I don't know short of diffing 1.4.0.2 vs 1.5.0.1 client/server files and trying things that were changed. It's really hard to fix when you can't duplicate the problem.

[redrumfk]

Has anyone found a fix for this problem. I get all the same problems with safes i know one instance i had
a few guys on server going from safe to safe and taking random stuff out of safe's but not packing them but with infistars lockunlock dll i found out who they were, but with other issues i found only the players owning the safe were accessing them.

[justchil]

We still have complaints of this happening weekly if not daily. I don't see any activity on the git anymore so I'm going to assume it's not getting resolved? If anyone has figured this out my players and admins would be really happy.

[Namindu]

Whats the CPU use on the box?

[Markokil321]

Ugh.

Have been confronted by 2 seperate people in the last couple of days that their safe has wiped all of the weapon slots after a restart. Backpacks and Item slots are still in there fine, only all Weapons (+ tools) have been wiped.

Both players claimed they made sure the safe was not over filled and was locked after they were last done using it, etc.
I was not able to find any visible errors to do with these issues yet.

Last recorded log of one of the safe contents with all the items still inside of it, in-case it may help: http://pastebin.com/ynd0J5yJ

Anyways there seem to be several different issues being reported here, several threads all to do with similar problems and a bunch of fixes unofficially out there. AFAIK someone is yet to find the one thing that will 100% fix these safe bugs??
Would really appreciate some clarification when it comes to this, or a reply from the devs...

[ReDBaroN1]

We're getting this happen as well. Sometimes just magazines emptied back to 200 free slots and sometimes weapons as well.
But, as justchil mentioned this happens intermittently but often. Sometimes weekly, sometimes daily.

Did anyone get anywhere towards fixing the issue?

[ebayShopper]

726e4e0
#1467
#1641