Jump to content

999 Hive


DeanReid

Recommended Posts

Since this project simply uses diag_log lines to cause the arma server binary to spit out hive "calls" that writer.pl listens for, you could conceivably add any call you wanted. This doesn't use any dll's that need to be modified, you can see all of the calls in the server dayz_server.pbo by unpacking and running the following command from your unpacked dayz_server directory:

grep -IR "CHILD:" ./

As an example, look at the calls for 201 (player sync).

diag_log format["CHILD:201: ... 

This can be seen in writer.pl in the list of calls, like so:

201 => \&h_player_update,

You would then find the appropriate section that handles that call in writer.pl, which in this instance is the subroutine starting with:

sub h_player_update { ...

One you understand how this works, you should be able to add any call you want. The hardest part is writing the handler subroutine. I considered attempting this very thing, but I'm having to jump ship and go to a Windows server sadly. I hope I've helped in some way by explaining this.

 

Link to comment
Share on other sites

  • 3 weeks later...

I've asked him longer ago for such a function. Not supported was the statement.

I wanted to be able to change the code of a safe which is already build. Therefore he created hive 31 for me (should be in writer.pl).

I think you need to create a function depending on a use-case which is not difficult if you just copy e.g. hive31 from writer.pl and change it a bit.

 

To create a more general (or dynmic) function (as I understood what hive999 is) will be more difficult as you need to check number of input parameters and build a corresponding statement from these. Maybe you can build a statement string in your server files and just pass this through to writer.pl and just execute exact that statement (the text send from the server to writer.pl). Never thought about security issues doing it like this. Is it possible to execute server commands from the mission? Then this would not be a good idea.

Link to comment
Share on other sites

This is possible and probably even trivial. First approach that comes to mind is to pass SQL statements with placeholders separately from their parameters, so that the writer script can properly escape the values and reject hacking attempts. The second approach would be with SQL-side stored procedures, which can greatly simplify the game-side development. In fact, passing data from the database to the server is more of a problem than vice versa: this is done through intermediary files because there isn't a good way for the server engine to accept it directly and syncronously. I have asked the BIS developers if they intend to backport the Linux-capable dynamic library facility from Arma 3, but haven't heard any answer so far.

Link to comment
Share on other sites

Problem with the files is unfortunately that you can only load the same file name once in a mission. That's a real problem ;)

So even if you change the content the cached file (loaded the first time) is executed. That's the reason for devd to go the way via the different player directories 1,2,3,4,5 inside the cache directories.

 

I wrote a hive 307 function to be able to use real events from Epoch (if someone needs it accurate per minute....I guess nobody needs that).

So every minute I write a new file into the cache directory from the sql DB directly and load that from the server files when spawnEvent.sqf is called. For my 4 hours restart server that are 4*60 files sys_time1.sfq, sys_time2.sqf,... ;)

It works but this is not the way for executing any statement as you already said above. So therefore I think a function to execute any sql statement is useless here.

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
  • Discord

×
×
  • Create New...