Some tents are in "read only"

duluc

Member
I saw in database some tents not updating...
Ingame it's ok (in the inventory viewed by the player) until the server restart, then respawn the content before.
New content added not saving.

Not all the camping ingame, but some of them...

If needed, i'll try to catch a bugged tent, then put a log file here.
What log can be helpful ?
 
Hoo ok I've understood why (some) tents are not updating...... I've tried with 1 bugged tent ingame...
In the HiveExt.log, I saw the mysql command to update the tent's inventory in DB

2012-12-05 14:05:59 Database.MySqlPreparedStatement: [Trace] Execute [0 ms] Statement: update `instance_deployable` SET `inventory` = ? where `unique_id` = ? VALUES("[[["Colt1911","M4A1"],[1,1]],[["ItemBandage","ItemBloodbag","PartGeneric","ItemWaterbottle","PartGlass","PartWheel","ItemJerrycan","HandRoadFlare"],[2,2,4,1,3,5,2,1]],[[],[]]]", 61819279110354)

but 61819279110354 is not the good ID ! It's trying to update a bad tent ID, not in the database :s
The good one is 61818279150354

And in arma2oaserver.RPT :

15:05:50 "Locality Event"
15:05:50 "Locality Event"
15:05:53 "WRITE: ["PASS"]"
15:05:53 "HIVE: WRITE: "CHILD:309:61819279110354:[[["Colt1911","M4A1"],[1,1]],[["ItemBandage","ItemBloodbag","PartGeneric","ItemWaterbottle","PartGlass","PartWheel","ItemJerrycan","HandRoadFlare"],[2,3,4,1,3,5,2,1]],[[],[]]]:""
15:05:53 "WRITE: ["PASS"]"
15:05:59 "HIVE: WRITE: "CHILD:305:0:[354,[6181.91,2791.03,0.00270271]]:0:""
15:05:59 "WRITE: ["PASS"]"
15:05:59 "HIVE: WRITE: "CHILD:309:61819279110354:[[["Colt1911","M4A1"],[1,1]],[["ItemBandage","ItemBloodbag","PartGeneric","ItemWaterbottle","PartGlass","PartWheel","ItemJerrycan","HandRoadFlare"],[2,2,4,1,3,5,2,1]],[[],[]]]:""
15:05:59 "WRITE: ["PASS"]"
15:05:59 "HIVE: WRITE: "CHILD:306:0:[]:0:""
15:05:59 "WRITE: ["PASS"]"
15:06:05 "WRITE: ["PASS"]"
15:06:17 "WRITE: ["PASS"]"


How can it be solved ?! humm, if possible not by trying every tents ingame of course
 
Tried today with actual Bliss release, in Namalsk this time.

Always the same problem on some tents...
Some of them haven't the good id in database, and server try to update another tent id that doesn't exist.
 
Have dropped a tent under a pine tree and found I couldn't add gear to it. I read that, in the last update, that tents couldn't be put on concrete (not sure that's true) or under trees. Presumably to force them to be more visible / less buggy maybe. Could this be related, something in the dayZ code maybe ? This was on Chernarus. Have definitely 'lost' tents a couple of times on public servers grrr.
 
Not for me,
Players continue to put tents under (and inside trees=fucked), and duplicate...
I think nothing has been really fixed from a lot of months for tents,
duplicate+tree-fuck+sliding= always here.
But the fact to pitch easily than running/pitch glitch...lol
+++ my actual pb, sometimes the bad ID in database...
 
My mate thinks they deliberately made tents under trees fooked to stop it, they were fine before. Not an elegant solution but I suppose people learn to keep tents away from trees.

I wondered about the running glitch, in the early days, when tents were nigh on impossible to pitch, I ended up with 4 tents for the price of 1, think I was running, crouching, all sorts to get it to pitch. All of them worked though, had a nice little base on that server until they got found n pillaged..
 
I wonder if a solution could be found using a MySQL trigger. Kick off a stored procedure that creates the entry in instance_deployable when it is a failed tent update. That way the next time someone tries there will be an entry for them to update..
 
Looking at the bliss server update code, it gets the uid from the game. Looks like the dayZ code returning the wrong uid, probably where the tent has been duped, then the original cleaned up or vice versa. Best advice with tents is pitch the carefully :)
 
I have this problem as well.

For instance --> HiveExt.log
Code:
Line 6903: 2013-01-19 03:35:18 Database.MySqlPreparedStatement: [Trace] Execute [1 ms] Statement: update `instance_deployable` SET `inventory` = ? where `unique_id` = ? VALUES("[[["BAF_LRR_scoped_W"],[2]],[["5Rnd_86x70_L115A1","5Rnd_127x108_KSVK","10Rnd_127x99_m107"],[12,1,4]],[[],[]]]", 881042006740267)

The actual record in the database has a unique_id of 881032006740267 *NOT* 881042006740267!

When I update the unique id to the one Bliss is trying to write too, the tent is now writable and works properly from this point on. Is Ayan aware of this issue?
 
More importantly, why are there no error messages in the hive logs when it (quite clearly) fails to update the record in MySQL?
 
Back
Top