Jump to content
Sign in to follow this  
Dillwhop

Public Shard/Hive?

Recommended Posts

Is it possible to make a public shard server with the server files on my own hardware? or only private?.

I couldn't seem to find how to do it if you can.

Share this post


Link to post
Share on other sites
41 minutes ago, Gibson.D said:

Is it possible to make a public shard server with the server files on my own hardware? or only private?.

I couldn't seem to find how to do it if you can.

Seems unlikely - if you had your server on the public hive, you could create all kinds of non-standard stuff (instant gear spawns, backpacks full of ammo, whatever) on your home server, and folk could gear up with that and move to another public server. Can't see how that could happen. If you mod the game in any way (and who's to say you won't) you can link up with other private shard servers running the same mod. Don't see that would be a problem ?

Share this post


Link to post
Share on other sites

it uses SQLite, which is practically impossible to share between two applications, let alone across a network. SQLite uses fopen(), which locks a file while in use. So even if you could get the 2nd server to read the database, it wouldn't be able to write to it.

The only solution around this that I can think of is some form of sqlite reader/converter to mysql, but it still would not be an easy or even viable solution. Unless somehow a mock sqlite file is made that the server hooks into that is really hooking to a mysql server, but that is just a mental theory (not even sure if it even possible).

Share this post


Link to post
Share on other sites
2 hours ago, Aussie Cleetus said:

it uses SQLite, which is practically impossible to share between two applications, let alone across a network. SQLite uses fopen(), which locks a file while in use. So even if you could get the 2nd server to read the database, it wouldn't be able to write to it.

The only solution around this that I can think of is some form of sqlite reader/converter to mysql, but it still would not be an easy or even viable solution. Unless somehow a mock sqlite file is made that the server hooks into that is really hooking to a mysql server, but that is just a mental theory (not even sure if it even possible).

The DayZ instance on a server doesn't have to share with other DayZ servers - they just have to use the same Hive. 
We know this works because we can right now play the same DayZ version on many servers all using the Official Hive. Any group (shard) of DayZ servers only has one Hive, they use it to store/retrieve the player state,  so the player can 'move' between DayZ servers. The player is only ever on one server.
The game instance servers don't communicate with each other.

Edited by pilgrim*

Share this post


Link to post
Share on other sites
4 hours ago, pilgrim* said:

The DayZ instance on a server doesn't have to share with other DayZ servers - they just have to use the same Hive. 
We know this works because we can right now play the same DayZ version on many servers all using the Official Hive. Any group (shard) of DayZ servers only has one Hive, they use it to store/retrieve the player state,  so the player can 'move' between DayZ servers. The player is only ever on one server.
The game instance servers don't communicate with each other.

I looked further into it, and my theory for a "fake" sqlite file that is really just pulling/sending data from/to a mysql server is not really plausible.

The issue is that a "hive" is just another name for a database server that houses the character table. The current system uses sqlite which is a single file local-only database, which cannot be access by an application while it is already in use by another. 

The way coding works for sqlite is you open the file during practically the entire session that the server is running, for speed of access to the data within (it's actually a feature they boast). Therefore, the only way to make a "Hive" is to modify the entire database interactions to work with a new database system that actually allows multiple connections.

The sqlite file holds ALL information about the world, not just the players. The data is not separated. So even if you manage to get 2 servers reading and writing the same sqlite database (technically impossible by their docs), both worlds would contain the same items on the floor, door settings, etc.

This was quite deliberately done, they do not want us making hives yet. But that doesn't mean there aren't people capable of doing it. I know it's outside of my abilities, but it's somewhat still possible.

Share this post


Link to post
Share on other sites
1 hour ago, Aussie Cleetus said:

I looked further into it, and my theory for a "fake" sqlite file that is really just pulling/sending data from/to a mysql server is not really plausible.

The issue is that a "hive" is just another name for a database server that houses the character table. The current system uses sqlite which is a single file local-only database, which cannot be access by an application while it is already in use by another. 

The way coding works for sqlite is you open the file during practically the entire session that the server is running, for speed of access to the data within (it's actually a feature they boast). Therefore, the only way to make a "Hive" is to modify the entire database interactions to work with a new database system that actually allows multiple connections.

The sqlite file holds ALL information about the world, not just the players. The data is not separated. So even if you manage to get 2 servers reading and writing the same sqlite database (technically impossible by their docs), both worlds would contain the same items on the floor, door settings, etc.

This was quite deliberately done, they do not want us making hives yet. But that doesn't mean there aren't people capable of doing it. I know it's outside of my abilities, but it's somewhat still possible.

Hang on a mo..

The Hive stores player info.. the GAME software updates the Hive regularly on the player state = location and carried gear & player condition (health etc) - thats ALL. the Game updates the Hive regularly (often), AND immediately when the player is killed AND when the player logs out. This is why, if you are suddenly dropped from the server, when you log back in you are a few seconds behind your previous location and state, because the server has requested your player-state from the Hive when you log in and got the last stored player state. BUT you'll find the car you were driving a way down the road.. it's position is stored by the Game instance, not by the Hive.

It does not matter WHICH game instance does the updating - the Hive does NOT even need to know which server the player is on.  So with 100 GAME instances connected to a Hive, only ONE Game will ever query or get info on a player state at ONE TIME... because the player-state is IN USE by that single Game and not any other.

The GAME instance has it's OWN database (which is NOT the Hive) so it knows where everything is, inside that one game, but it does NOT need to tell the Hive about it. eg The Hive does NOT know where all the cars are on any server at all. (why would it need to know?) Each Game instance knows where it's OWN stuff is. The Game also knows where the player is in that one Game, and what kit he has etc etc (and tells the Hive frequently) .. because only the player and the kit he carries can LEAVE that instance and log in to another.. cars and zombies cant. The Hive has NO IDEA where THEY are on each server - why should it? .. that info is stored in the Single Game instance, in it's own database (which is part of the installed GAME Software)  - that's why when you log back in, the zombie that was standing next to is NOT there anymore.. the HIVE doesn't give a damn where the zomb is, it has no idea. And the Hive has no idea where you left your car or your tent either. The local Game instance Database knows that. 

So you have a Game (one instance) and you have a Hive.  These are two separate things, even if they are both on the same server.  A player with server space running a private hive has a Game instance and a Hive both on the same server. Other game instances on other servers can share that Hive if they agree to (if they point their Game at it).

So when any GAME instance is talking to a Hive - it is only talking about a player-status (player health, location, and all his carried kit). At any time, only ONE game instance ever talks to ONE Hive about that ONE player - because you CANT have one player with one player-state playing on TWO GAMES at the same time - that would be a NON-sense.

And you CANT have two GAMES "linked" as you suggest - or if a player drove a car a mile in THIS game instance, then the car in the OTHER game would drive a mile for no reason. This is also a NON-Sense.

You are mixing up the Game instance's own database ( what you call "single file local-only database") with the Hive database. They are separate software entities. The distance between these two DISTINCT software entities does not matter - they can be on one server or half the internet apart.

Right now, if you HIRE a private DayZ server, you get a private Hive (a "shard") with it.- costs you more -  Several DayZ Games can - right now - run using that same Private Hive - if they decide to. Then their player-states can be moved to (requested by/and then modified by) any ONE of the instances using that Hive. Only one DayZ instance ever uses a player-state at ONE time, so there is no "locked file" problem.

The Hive has nothing to do with the "local-only" database,  the Hive is a =Different= database. One software CAN send info backwards and forwards between two different databases at "the same time".. right?   Zero problem.

 

Edited by pilgrim*

Share this post


Link to post
Share on other sites

You're basically saying the same things I am about hive, but obviously misunderstanding that we are.


As the server is currently coded, the server cannot pull player info from a "hive", because that code was either removed or deactivated and is directly locked to the sqlite file.

Someone would need to make it from scratch, or pull data from somewhere else (not sure what other bohemia games use the hive system). Then they would need to code it to update the local database with the vital player information on the sqlite, as well as push it's updates in the manner you said.

 

It's not rocket science, but it's also not exactly a 3 minute hack

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×