Possible to publish to new table in database?

Sand

New Member
Morning All,

I'm looking into understanding how DayZ publishes to the tables within the hive database.
There are different tables for different data however I'm failing to find the thread regarding how the script knows which database to pull from.

Example - DayZ_PlayerUID pulls the player ID from _playerUID in player_monitor.fsm
How does it know to pull that information from the Player_data table in the hive?

I'd like to add a table to the hive and be able to publish and pull data to/from the table.

Any help connecting the dots is appreciated.

Thanks,
Sand
 
was in the same situation. as far as i remember you simply cant write to and read from your own tables when using the standard HiveExt.dll. the second parameter in the call to server_hiveReadWrite determines which function of a set of functions within HiveExt.dll is called. the tables in the database to be accessed are hardcoded within this functions.

for example look at the commands in server_playerLogin.sqf
Code:
    _key = format["CHILD:101:%1:%2:%3:",_playerID,dayZ_instance,_playerName];
    _primary = _key call server_hiveReadWrite;

the second parameter 101 selects function loadPlayer in HiveExt.dll to be called, which finally ends up accesses the table Player_DATA and reads certain (hardcoded) fields from this table. there is no way to read additional field from this table. the record to be read is selected by the parameters supplied in %1:%2:%3: _playerID, dayZ_instance, _playerName

as i was in the need to save some custom info to the database, i ended up in modifying HiveExt.dll to my likings.

so to sum it up: without a custom (modified) HiveExt.dll, its impossible to access your own tables in the database, thus its impossible to write to or read from your own tables.
 
at the time i have read about the 999 thing, i did not realize which version of dayz is using this hive! also, from looking at the threads i read, i was not able to understand how to use it. as i had this hive not at hand it was hard to figure this out without any testing. i suppose reality (if it's reality) is still using this feature. but as said before i'm not using it, thus don't know.

anyway, i'm talking about the hive coming with plain vanilla dayz (version f0.9.6.14_p0.8.0.4). as i'm using plain vanilla dayz i preferred to also use the hive version coming bundled with it. so the only solution to solve this for me, was to modify it.

don't not know which version of dayz the starter of this thread is using. but as there is nothing mentioned in his posting i assume its plain vanilla dayz.
 
I was starting to worry this was over everyone's head - I know it is mine.
I'm using DayZ Epoch currently - Any idea if the 999 is applicable?

I'd be interested in talking about this a little more indepth and perhaps some help following the bread crumbs a little further. If you don't mind discussing, please let me know.

Thanks,
Sand
 
I found someone trying to use 999 method to update some tables which didn't work for them since it was on bliss. But maybe you can use their syntax to understand how to use method 999 which is a custom SQL query with params, which would basically let you do anything you wanted surely?
Like Panadur said though, unless Epoch is actively using that custom hive on the current Epoch version you would have to compile it yourself or get someone else to compile it.
I might be able to but not until I am at home later tonight.

_key = format["CHILD:999:UPDATE `object_data` SET `characterid` = '%1' WHERE `objectUID` = %2 LIMIT 1:[]:",_survivorID,_objectUID];
diag_log format["HIVE: WRITE: CO Query: %1",_key];
_result = _key call server_hiveReadWrite;

diag_log format["HIVE: WRITE: CO result: %1",_result];
 
I'd love to test this - however I'm still overlooking something. I still have no clue where to look to determine what the name of the table should be for the 998 & 999 custom calls.

Viewing the files in Hex doesn't seem to do me any good. I feel as though there's something obvious I'm not catching on to...
 
I'd love to test this - however I'm still overlooking something. I still have no clue where to look to determine what the name of the table should be for the 998 & 999 custom calls.

table name is supplied in the sql statement. this calls allow you to access any table in your database.

from looking at the example supplied by kaotix

_key = format["CHILD:999:UPDATE `object_data` SET `characterid` = '%1' WHERE `objectUID` = %2 LIMIT 1:[]:",_survivorID,_objectUID];

_result = _key call server_hiveReadWrite;

its very obvious what all this means:

the red part of code represents the sql statement, which of course can be replaced for any other valid sql statement. the table accessed here is `object_data`. the fields of interest are `characterid` and `objectUID`.

the two variables following in blue represent parameters to the sql statement and will replace the two placeholders %1 and %2, where %1 will be replaced by _survivorID and %2 will be replaced by_objectUID. everything else remains unchanged: the leading "CHILD:999:" and also the trailing ":[]:".

the variable _result which in almost all situations will be an arrray, will receive the result of the sql statement. in the example above it will just tell if the statement was successful or not.

so i would expect the example will simply set a new "owner" for an object in the database.

don't know the layout of tables used on epoch. from looking at the layout of the plain vanilla hive i would expect the following example will return the ingame name of your player:

_key = format["CHILD:999:SELECT `playerUID`,`playerName`FROM `player_data` WHERE `playerUID` = %1 LIMIT 1:[]:",_playerUID];

_result = _key call server_hiveReadWrite;

when _playerUID is set to your playerUID (i use 123456 as an example), _result will receive the array [123456, "your player name"]. playerUID might be returned as a string as well. dont want to dive too deep into the code. you will figure out ...

this was a rather simple example using the sql select statement. but you can imagine, by using sql, you can easily write, read, or modify your database ...

there are lots of explanations out there describing sql. a simpple one might be found here:

http://www.tizag.com/sqlTutorial/index.php

assuming the source code found on github is valid for your epoch server, this statement should do no harm to your database. anyway, i would recommend to make a backup of your database before starting to play around with this stuff ...
 
Nicely put. I was looking for something within the dll compile which pointed to a specific database, hadn't realized the answer was right in the sql. I'll give this a try tonight and see what I can get going. Always practice on my test box before publishing to production.

Thanks again for the help. I'll let you know how it turns out.

Sand
 
ok guys, compiled this hive for you. but as said before, i don't run epoch, thus have not checked if it works at all.

from looking at the source code, both (998 and 999) custom calls are included!

if you wan't you can try:

http://www.file-upload.net/download-8218230/DayZhiveEpoch-master.rar.html

if anybody is willing to give it a try, report back if it works ...

Hi,

first of all thank you very much for compiling the hive for us!

I tested much things the last 2-3 days with the new CHILD 999 function and can say that its a bit bugged.

Maybe some people know the issue that ObjectUIDs aren't send from database to the arma server client - they are recalculated based on the Worldspace from the database.

This is often an issue cause the ObjectUID can slightly change and then if you need to delete via CHILD 304 aka server_deleteObj.sqf with ObjectUID and don't have the ObjectID (cause the database create the ObjectID and it isn't available till next server restart and a new streaming from database of all items via CHILD 302 aka servermonitor.sqf) you have to use the ObjectUID to delete it.

We had the plan to recreate the streaming in the server_monitor that it also sends the ObjectUID from database instead of recalculating it.

Here comes the bug, it seems they messed up with datatypes somewhere. Cause the UID values are quite high like for example 403731167350475 in the database and the return is always same.

What the CHILD 999 returns all the time for every UID is 2147483647. Seems that the CHILD is trying to put the UID into a too small data type? I'm not very firm with C++ so I can't fix it myself and can't say if my assumption is right, but if anybody would do this, would be really awesome.

Thanks!

For other smaller values it seems to work for most things.

Regards kikyou2
 
sorry to hear that!

i just pulled the source code and compiled it. as said before, i don't use this hive version so have not looked into it. i stick to the standard hive which is used on vanilla dayz, though slightly modified ...

no idea whats wrong with this version.
 
sorry to hear that!

i just pulled the source code and compiled it. as said before, i don't use this hive version so have not looked into it. i stick to the standard hive which is used on vanilla dayz, though slightly modified ...

no idea whats wrong with this version.


Yeah I didn't wanted to blame you, just saying for others who read this and maybe can spare to spend as much time as me to code functions like mentioned above and don't waste the time like I did :D

Thank you very much for compiling it, I already opened an issue in the github of the Hive from DayZEpoch team.
 
If you fancy writing in a different language you could use Arma2Net and write/read to any table you like in whatever way you like :D
 
I don't know C++...

2147483647 - highest value of a signed int. Double that for normal int datatype.
Largest value for ObjectUID in MY object_data table (and thats at just 35 vehicles) is...
1191761192120169
That's a definite problem.

Has anything been able to fix this yet?
Maybe using a BigInt Class?
Unsigned Long Long?

Even if it means compiling a special hive for 64bit only (if that's even a possibility?)

I dunno, I'm talking out of my rear, but just thought I'd throw that out there...
 
kikyou2,

digged into the hive again as i was in the need of a modification for my server. would like to be able to spawn vehicles to the running server which are published to the database and also correctly updated and streamed after restart.

remember i'm talking about plain vanilla dayz here!

anyway, here my findings:

from what i could see, ObjectUID is not used at all! there is just one situation where ObjectUID is created and written to the database. its in server_publishObject.sqf

ObjectUID is never read from the database, at least i did not find a single place where its read!

in all situations ObjectID is first used to reference objects in the database. only if ObjectID is not available for any reason, ObjectUID will be used!

as ObjectID is read from the database during streaming of objects at server start - as you already know, we run into a problem when objects are published to the database during server runtime.

i solved this for me by modifying the 308 function to return ObjectID when a new object is published to the database and set the variable ObjectID on the newly published object.

besides using my modified HiveExt.dll:

http://www.megafileupload.com/en/file/471565/HiveExt-zip.html

you also have to change server_publishObject.sqf (thats how it looks like on vanilla dayz, might be different for epoch!):

search for
Code:
_key call server_hiveWrite;

and replace with
Code:
//_key call server_hiveWrite;
 
private ["_result", "_objectID"];
 
_result = _key call server_hiveReadWrite;
 
if ((_result select 0) == "PASS") then {
  _objectID = _result select 1;
  _object setVariable ["ObjectID", _objectID, true];
} else {
  diag_log ("server_publishObject: HIVE: READWRITE: read ObjectID for Object " + str(_uid) + " failed");
};


if you use your own script to publish objects to the database keep in mind:

_key is used as before no changes here:

_key = format["CHILD:308:%1:%2:%3:%4:%5:%6:%7:%8:%9:", dayZ_instance, _class, 0 , _charID, _worldspace, [], [], 0,_uid];


the important part is "_result =" which receives the ObjectID from the database and to use server_hiveReadWrite instead of server_hiveWrite:

_result = _key call server_hiveReadWrite;

_result is an array, where element 0 holds the string "PASS" and element 1 holds the ObjectID which is returned as a string.

as long as u don't use ObjectUID anywhere in your code you are fine. as said before ObjectUID is not used in plain vanilla dayz at all and from what i have seen its the same in epoch when using the standard functions.

when using the 999 function its up to you to decide whether to use ObjectID or ObjectUID. as ObjectID is at your hand now, there is no reason to use ObjectUID anywhere ...
 
Yeah thanks fgw,

I know there is a similiar possibility as it is used for vehicles in DayZ Epoch if you buy them, but it often crashes when the server is on heavy load. I will try your version, thanks!

Problem is that if you use it for every object and the server is on heavy load it will often crash, as if you use many read from database while Server is running this often fails (you will see it in the rpt as it will retry often and sometimes just stuck and the script will exit).

At the moment I rewritten everything what can be build or set up at my server (we have a large own basebuilding system) and changed it so you can delete most of the things after the next restart cause the ObjectID is then streamed from the database so the delete function can use it.

I know that the normal function doesn't stream the UID as said in my post before, thats the problem why I ended and trying to use the CHILD:999 function to stream it at the beginning additionally to the rest of the data.
If you would stream after restart the UID it can't change, cause the first time it is send to the database its firstly calculated and so it is the same ingame. After the next restart it can fail so if it would be picked up out of the database the UIDs would be fine again to use. At the moment they are really useless.

My main reason to get here a reliable system is that I need a reliable system to delete and update things as its otherwise often not deleted in database and the user gets a refund for something which is spawning next restart again. Duping easily basebuilding materials is the product out of this, which is really horrible for our server as we have a real balanced prices and economy.

However, thanks very much for your input ;)
 
Back
Top