Jump to content

HiveExt vs Arma2NET vs extDB


Guest

Recommended Posts

Unfortunately not, the issue isn't with extDB's input, it's the OUTPUT. I suppose I could always write custom functions in SQF to strip out the offending quotes from the extDB output before running call compile on it, but it'd be even better if it was configurable from within extDB :)

 

I have a nasty feeling I'm also going to run into an issue with DateTime, although I just read over on the BIStudio forums that Torndeco is planning on adding support for it :D

 

Here's where I'm up to currently:

 

22:54:10 "[extDB] Version: 20"
22:54:10 "[extDB] Connected to Database"
22:54:10 "[extDB] Building Object Count: 5674"
22:54:11 "[extDB] objectsArray: [2,"1749605807"]"
22:54:11 "[extDB] returnMessage Key: 1749605807"
22:54:18 "[extDB] Building Object Array: [[274,"SUV_Camo",2788,[51,[5268.4,11043.6,0.01]],[[["Sa58V_RCO_EP1","MG36","M4A3_CCO_EP1"],[1,1,1]],[["HandGrenade_East","PartEngine","PartVRotor","PartWheel","PartGlass","HandGrenade_West","FoodbeefRaw","PartGeneric","ItemBloodbag","ItemMorphine","ItemPainkiller","FoodrabbitCooked","ItemBandage","30Rnd_556x45_StanagSD"],[1,1,1,3,4,1,6,1,6,3,3,1,2,1]],[[],[]]],[["wheel_1_1_steering",0.004],["wheel_1_2_steering",0.004],["wheel_2_1_steering",0.004],["wheel_2_2_steering",0.004],["palivo",0.004],["motor",0.161],["glass1",0.013],["glass2",0.014],["glass3",0.011],["glass4",0.029],["karoserie",0.177]],0.96886,0.009],[363,"MTVR_DES_EP1",11301,[286,[9115.27,9249.87,-0.001]],[[[],[]],[["ItemWaterbottleUnfilled"],[1]],[[],[]]],[["wheel_1_1_steering",1],["wheel_1_2_steering",1],["wheel_1_3_steering",1],["wheel_2_1_steering",1],["wheel_2_2_steering",1],["wheel_2_3_steering",1],["palivo",0.035],["motor",1],["glass1",1],["glass2",1],["glass3",1]],0.80391,1],[721,"WoodFloor_DZ",59,["
22:54:23 [5674,[[274,"SUV_Camo",2788,[51,[5268.4,11043.6,0.01]],[[["Sa58V_RCO_EP1","MG36","M4A3_CCO_EP1"],[1,1,1]],[["HandGrenade_East","PartEngine","PartVRotor","PartWheel","PartGlass","HandGrenade_West","FoodbeefRaw","PartGeneric","ItemBloodbag","ItemMorphine","ItemPainkiller","FoodrabbitCooked","ItemBandage","30Rnd_556x45_StanagSD"],[1,1,1,3,4,1,6,1,6,3,3,1,2,1]],[[],[]]],[["wheel_1_1_steering",0.004],["wheel_1_2_steering",0.004],["wheel_2_1_steering",0.004],["wheel_2_2_steering",0.004],["palivo",0.004],["motor",0.161],["glass1",0.013],["glass2",0.014],["glass3",0.011],["glass4",0.029],["karoserie",0.177]],0.96886,0.009],[363,"MTVR_DES_EP1",11301,[286,[9115.27,9249.87,-0.001]],[[[],[]],[["ItemWaterbottleUnfilled"],[1]],[[],[]]],[["wheel_1_1_steering",1],["wheel_1_2_steering",1],["wheel_1_3_steering",1],["wheel_2_1_steering",1],["wheel_2_2_steering",1],["wheel_2_3_steering",1],["palivo",0.035],["motor",1],["glass1",1],["glass2",1],["glass3",1]],0.80391,1],[721,"WoodFloor_DZ",59,["181.366928","[3491.243164,
22:54:55 "[extDB] getPlayer Data:[["[FP]Michael",0]]"
22:54:55 ["[FP]Michael",0]
22:54:55 "[extDB] Player setup correctly!"
22:54:55 "[extDB] Player setup finished!"
22:54:55 "[extDB] Character Info:[]"
22:54:55 "[extDB] Character Not Found"
22:54:55 "[extDB] Creating character succeeded!"
22:54:55 "[extDB] Character setup finished!"
22:54:55 "[extDB] Primary Reads As: [17,"76561198042520374",[],[],0,0,0,"Survivor2_DZ",0]"
22:55:19 "[extDB] Full character data:[17,"76561198042520374",0,11,[["glock17_EP1","ItemMap","ItemMatchbox","ItemCompass","ItemKnife","ItemHatchet_DZE","ItemToolbox","Binocular","ItemRadio"],["ItemBandage","ItemBandage","17Rnd_9x19_glock17","17Rnd_9x19_glock17","17Rnd_9x19_glock17","17Rnd_9x19_glock17","ItemMorphine","ItemPainkiller","ItemWaterbottleBoiled","FoodSteakCooked","ItemWaterbottleBoiled","FoodSteakCooked"]],["DZ_TerminalPack_EP1",[],[]],"[]","[false,false,false,false,false,false,false,12000,[],[0,0],0]",1,2,0,0,0,0,[],0,"Survivor2_DZ",0,2500,0]"
22:55:19 "[extDB] Successfully loaded character with ID: 17"
22:55:19 "_cashMoney = 0"
22:55:19 "_lastInstance = 11"
22:55:19 "_worldspace = []"
22:55:19 "_medical = [false,false,false,false,false,false,false,12000,[],[0,0],0]"
22:55:19 "_stats = [0,0,0,0]"
22:55:19 "_state = []"
22:55:19 "_humanity = 2500"
22:55:22 "[extDB] Recorded Login"
 
So far, it can:
  • Load all objects and vehicles from the database and spawn them
  • Check for player in DB
  • If not found, create new player
  • If name is incorrect, update
  • Load character data
  • Create new character if none found, and import humanity etc from dead character if one is found.

Only glitch at the moment seems to be that InstanceID on characters changes to -1 shortly after, although I have a feeling that's a result of one of the still in-place HiveExt calls, possibly 201?

Link to comment
Share on other sites

 Just in case anyone is still interested in this, a few quick updates from tonight's experiments.

 

Now got CHILD:201 calls converted along with 101/102, including support for single currency. I've also discovered something interesting about DayZ's backend.

 

You know those "LastAte" and "LastDrank" columns in the database?

 

They do nothing. Absolutely fuck all.

 

They'll ALWAYS be equal to Datestamp (the time your character was created), because they're only set once - at character creation, specifically with an Insert Into command. Which means that EVERY time you log in, it calculates "time since you last ate/drank" using a TIMESTAMPDIFF; as shown below:

 

[getCharacter]
SQL1_1 = SELECT CharacterID, PlayerUID, Inventory, Backpack,
SQL1_2 = TIMESTAMPDIFF(MINUTE,Datestamp,LastLogin) as SurvivalTime,
SQL1_3 = TIMESTAMPDIFF(MINUTE,LastAte,NOW()) as MinsLastAte,
SQL1_4 = TIMESTAMPDIFF(MINUTE,LastDrank,NOW()) as MinsLastDrank,
SQL1_5 = Model, Infected FROM character_data WHERE PlayerUID = '$INPUT_1' AND Alive = 1 ORDER BY CharacterID DESC LIMIT 1;
Number of Inputs = 1

There's code to update this in 201 calls, but DayZ ALWAYS sends [false,false] for those values; it's hard-coded to do so. I have NO idea why.

 

Instead, food/drink levels are stored as part of the medical array as numerical values; "time" isn't involved anymore. I assume this is to prevent you from logging in after a week of not playing and discovering that your character is dead lol. However, this should've been removed from HiveExt and the Epoch codebase a LONG time ago. There are various other bits and bobs like this; at the moment I'm working on a straight conversion and just getting everything working, but once that's complete I'll look into optimization.

Link to comment
Share on other sites

 

 Just in case anyone is still interested in this, a few quick updates from tonight's experiments.

 

Now got CHILD:201 calls converted along with 101/102, including support for single currency. I've also discovered something interesting about DayZ's backend.

 

You know those "LastAte" and "LastDrank" columns in the database?

 

They do nothing. Absolutely fuck all.

 

They'll ALWAYS be equal to Datestamp (the time your character was created), because they're only set once - at character creation, specifically with an Insert Into command. Which means that EVERY time you log in, it calculates "time since you last ate/drank" using a TIMESTAMPDIFF; as shown below:

 

[getCharacter]
SQL1_1 = SELECT CharacterID, PlayerUID, Inventory, Backpack,
SQL1_2 = TIMESTAMPDIFF(MINUTE,Datestamp,LastLogin) as SurvivalTime,
SQL1_3 = TIMESTAMPDIFF(MINUTE,LastAte,NOW()) as MinsLastAte,
SQL1_4 = TIMESTAMPDIFF(MINUTE,LastDrank,NOW()) as MinsLastDrank,
SQL1_5 = Model, Infected FROM character_data WHERE PlayerUID = '$INPUT_1' AND Alive = 1 ORDER BY CharacterID DESC LIMIT 1;
Number of Inputs = 1

There's code to update this in 201 calls, but DayZ ALWAYS sends [false,false] for those values; it's hard-coded to do so. I have NO idea why.

 

Instead, food/drink levels are stored as part of the medical array as numerical values; "time" isn't involved anymore. I assume this is to prevent you from logging in after a week of not playing and discovering that your character is dead lol. However, this should've been removed from HiveExt and the Epoch codebase a LONG time ago. There are various other bits and bobs like this; at the moment I'm working on a straight conversion and just getting everything working, but once that's complete I'll look into optimization.

 

 

Not surprised.  The last ate / drank mechanics should be more like the vehicle fuel remaining.  Full = 1, take away bits for different activities (inc running / building etc) and save it.  0 = empty.  Very easy to convert to affect the GUI in different ways.

 

Update:

 

Ok, looking throught hte HiveExt code, it works out the minutes between last ate / drank and saves those (as you have shown in the code you posted above ) :) .

 

The code is availble in the Hiveext to sync the last ate / drank times (hive 201 call) but that part of the 201 call is never used in the EPoch code.  In server_playersync it ignores the ate & drank variables passed to it and hard codes false for them.

 

Would be easy to 'activate' though.

 

Looking through the change history, it has always been like that which indicates it was an addition that just never got finished.

 

 

Ehm welcome to the world of DayZ (and Epoch) code which atleast contains 10% of code that is deprecated. Imho the devs did a really poor job on keeping code organised, clean and well-structured.

 

Only 10% ?. :)

 

On a slightly different note.  AFAIK there is no problems running multiple extentions at the same time so you could leave the HiveExt as it is and use extDB to add new calls for new features / tables etc.

Link to comment
Share on other sites

Only 10% ?. :)

 

On a slightly different note.  AFAIK there is no problems running multiple extentions at the same time so you could leave the HiveExt as it is and use extDB to add new calls for new features / tables etc.

 

I was being polite :P

 

To be honest, only if extDB proves to be a noticable better performer I'll consider switching. Right now I'm quite happy with the custom Hiveext that we use (changing it to suit your needs is not rocket science).

Link to comment
Share on other sites

I was being polite :P

 

To be honest, only if extDB proves to be a noticable better performer I'll consider switching. Right now I'm quite happy with the custom Hiveext that we use (changing it to suit your needs is not rocket science).

 

Well if you are not used to programming in C++ and dont have a background in object orientated languages and no experience of creating a build environment and working with various IDEs (Visual Studio) then it has a pretty steep learning curve. 

 

I personally don't think the process of 'patching' the hiveext is the best way to go.  If I want to add a new table or query for a new mod then I dont want to have to reprogram the extension, recompile it and then distribute it to anyone who wants to use the mod.  Having multiple versions of the hive extension also creates confusion as to which version have what features enabled for what mods.  Having something that is open but then can be locked down by the server owners seems a better to control and administer system.

 

Porting the A2 Epoch calls to extDB will be interesting but Epoch really needs a rewrite to make much better use of the extDB calls you can create.  That would, of course, be a massive task though.

Link to comment
Share on other sites

Just something extra i wanna throw in the discussion

 

http://forums.bistudio.com/showthread.php?150293-iniDB-Save-and-Load-data-to-the-server-or-your-local-computer-without-databases!

 

iniDB, 4th alternative ^^ But this doesnt use a real database :)

 

i even believe that the maker offered helping on single currency once, but we were already busssy on a custom hive back then. ( NVM that was torndeco from extDB)

 

And if u read his explanation in there it's quite easy to use ^^ i don't know about performance tho

Link to comment
Share on other sites

Yeah had seen that one too. 

 

Most likely will be tied to the HDD speed where are DB servers will tend to be cached, tables can be indexed etc. 

 

May be good for holding server configs and items that just need loading every now and then.  Could put the variables in an ini and load it with that extension rather than in a variables.sqf.  Create the variable name dynamically based on the name from the .ini and then populate its default value (server side).  Could even do that on the server and then push client relelvent variable defaults to the clients in a JIP compatible way so they are not hard coded in the sqf files at all.  May add a bit more security and allows the client variable config to be controlled / changed server side without any client file modifications. 

 

We are doing the same sort of thing with our A3 mod for various items and controls the client requres rather than hard coding it in the client PBO files.

Link to comment
Share on other sites

Innidb is single threaded & you need to update each value one @ a time which needs to be sync'ed to harddisk etc..
So unless you are using it rarely or just on server startup, it will prob hurt your server performance alot imo.
Its is nice + simply to use & ok for lightweight stuff...

 

But for performance its either a

Standard Hive

Custom Hive,

extDB

 

Or you could look @

Stats (http://www.armaholic.com/page.php?id=26985)
Should work fine for Arma2, the only things you need to check / find out is that the extension outputsize is not hardcoded.
If there is a config file that you can randomize the filename.

Link to comment
Share on other sites

I've gotta say, after converting most stuff to extDB, Torndeco has done a FANTASTIC job with it.

 

Aside from the two remaining issues (quotes wrapped/not wrapped around VARCHAR and the way that Arma requires it for some things and not others - come on dude, make it configurable for me ;)) and the DateTime support (should be as easy as recompiling using Poco 1.5.x right? 1.6 is out any day now, which is the next stable release), it's pretty much perfect.

 

Just found it it also has the ability to return server time +/- an offset, so that's even better. Can replace that part of HiveExt without using Killzone Kid's DLL now :)

Link to comment
Share on other sites

Last time i tried Poco 1.5 it had to many issues...

From unable to compile extension on Linux & crashes on Windows

I would rather wait for Poco 1.6 to be out for abit & see what sort of issues  / pull requests crop up on the github page.

There are some minor code changes required when switching from Poco 1.4 -> 1.5/1.6

They fixed Poco Detecting MySQL Datatype Text beening detected as a String Datatype.
Will break String Datatype Check behaviour for MySQL i.e not adding "quotes" to TEXT datatype

So when i switch over to Poco 1.6 will rename extension to extDB2 or something similiar, since the change will break Altis Life RPG.

 

Also will add MongoDB Support for extDB while i am it.

----------------------

 

Anyway

Support for defining OUTPUTS to have Quotes / No Change /  AutoDetect Database String Datatype will be in the next version.

Also afew new Options for INPUTS etc, so you dont lose ability to run Sanitize Data Check  on INPUT Values, if you arent adding quotes to them in the Database.

The code is already pretty much done (on dev branch, not compiled).
I just need to get around to testing it + compiling the Release Versions for Windows / Linux.

Link to comment
Share on other sites

Well, it's finished :)

 

I've implemented all of the existing Epoch database calls in extDB, and added a few new ones as well to handle base maintenance, which is now far more reliable than it was before.

 

Next step is to improve granularity of the logging (at the moment, I only have Debug on/off and some important stuff forced output) and look into some sort of modification to server_hive* calls to allow compatibility with other scripts and/or infiSTAR. Currently I'm still making a call to HIVE 302 to set up the instance so that additional calls made by other scripts don't overwrite the instanceID in the database. Not sure what the potential downsides to this are, but I'd like to avoid them if at all possible, so perhaps parsing the calls to server_hiveWrite etc and converting them in the function to extDB might be the best solution.

 

I might also see if I can have a chat with Chris (infiSTAR) and provide an option to utilize extDB features; the amount of control over the server that would be possible with extDB should appeal very nicely to him :P

Link to comment
Share on other sites

Well, it's finished :)

 

I've implemented all of the existing Epoch database calls in extDB, and added a few new ones as well to handle base maintenance, which is now far more reliable than it was before.

 

Next step is to improve granularity of the logging (at the moment, I only have Debug on/off and some important stuff forced output) and look into some sort of modification to server_hive* calls to allow compatibility with other scripts and/or infiSTAR. Currently I'm still making a call to HIVE 302 to set up the instance so that additional calls made by other scripts don't overwrite the instanceID in the database. Not sure what the potential downsides to this are, but I'd like to avoid them if at all possible, so perhaps parsing the calls to server_hiveWrite etc and converting them in the function to extDB might be the best solution.

 

I might also see if I can have a chat with Chris (infiSTAR) and provide an option to utilize extDB features; the amount of control over the server that would be possible with extDB should appeal very nicely to him :P

 

He is using Zupa's currency dll right now. I am sure he would be open to ideas :P

Link to comment
Share on other sites

He is using Zupa's currency dll right now. I am sure he would be open to ideas :P

 

Yep, I suggested it to him ;)

 

Thought it might help with 500 calls, but alas they're still a bit glitchy. If we can swap over to extDB it opens up ALL SORTS of possibilities :)

Link to comment
Share on other sites

Yep, I suggested it to him ;)

 

Thought it might help with 500 calls, but alas they're still a bit glitchy. If we can swap over to extDB it opens up ALL SORTS of possibilities :)

 

Yeah i disabled his 500 call function in AH cause i dont use zupa's dll and i dont trust Arma2Net that much to do it either :P

Link to comment
Share on other sites

I just modified the code slightly (I wrote it originally, so apologies to anyone who has suffered crashes :P) to output the OwnerID instead of querying for their name. Much easier to search the player_data table by their UID rather than have to look up the object and pull out the owner ID from object_data first.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×
×
  • Create New...