Sandbird / Dayz.Epoch.3d.Editor.Live.Mission-with-Database

For fast debugging of scripts, without running a server. All done in the 3d editor (Alt+E), now with Database interactions.
2 stars 4 forks source link

Does this work on the newer version of dayz epoch? #1

Open Stijnkluiters opened 7 years ago

Stijnkluiters commented 7 years ago

Title descripes my question.

Sandbird commented 7 years ago

Nope, this was done for the 1.0.5.1 version of epoch...but....if you know what you're doing you could easily convert it to the new version. If you take a look at this script here: https://epochmod.com/forum/topic/10107-release-walk-amongst-the-dead-hide-from-zombies-like-the-walking-dead/ ,this script was also for the 1.05 version, and most global variables used there are also used within this script. The reason why this script wouldnt work properly is because Epoch has changed the names of some global variables and probably some functions as well which i dont know since i stopped playing arma2. ...But if you look at this updated script here: https://epochmod.com/forum/topic/43841-update-16-walk-amongst-the-dead/ , you'll see that juandayz managed to convert my zombie script for the latest epoch version. I guess if you download both versions and compare them you'll be able to find these global variables...or you could also ask juandayz on the epoch forum about them.

Nonetheless, the MYSQL dlls, and scripts for this mission file, should probably still be valid..so no need to change the whole 'core' of this script. If juandayz did a simple search/replace of some global variables you should be able to convert this in a few hours if not minutes.

In a nutshell, this mission file all that it does is run both the server files and client files inside the editor, then with a hack separate the two, (in reality the server is also a client...kinda like a headless client), and then use arma2net dlls to connect to the mysql server and handle all the spawning/creating/querying etc. It took me only a few days to write the Walk Amongst the Dead script with this mission file. Debugging is cut down to seconds, instead of minutes (starting the server and join with a client).

I'd say give it a go...i think it can easily get converted to the latest epoch.

Sandbird commented 7 years ago

ps: if you look at this thread post here (and bellow): https://epochmod.com/forum/topic/10107-release-walk-amongst-the-dead-hide-from-zombies-like-the-walking-dead/?do=findComment&comment=285684

You'll see which main global variables have been changed by epoch...try and find those first at juandayz's script and see what he replaced them with...These are the most important ones to change. The whole script is based on these...

Stijnkluiters commented 7 years ago

Alright, thanks for the comprehensive explanation, very usefull. There is one problem though, i dont really understand how that headless client thing works. The rest of the stuff you're talking is clear. Since you're capable of explaining this well, i want to ask you if you also can explain the headless client process

Sandbird commented 7 years ago

uh, not to worry about it then, but in a nutshell the headless client is the server acting as player. Usually the server spawns a soldier in the middle of nowhere (probably in the water far away), gives him god mode, so noone can kill him, and then executes some scripts via him. Imagine him as the Architect in the Matrix. He exists inside the game but not as a bot...more like a statue, and can execute scripts (usually start/end bot missions). Now why go through all this trouble ? Because Arma's memory optimization is crap....and on a monster dedicated server all that ram is going to waste since Arma uses only 3gb. So instead of the server running the bot mission scripts and handle all those soldiers walking around shooting at people, you cut down some processing time and memory by 'spawning' a client window (like i said, its like the server is also playing the game), and let that extra 3gb ram do that. It's like the server is spawning children that each can grab a few gb from the ram to do stuff...thus lowering the server FPS, making it lag free from the players.

This 3d.live mission script kiiiiiiiinda does the same thing but only using a virtual soldier (you cant see him when the script is working fine...when i was making the script i had an actual soldier spawned at my location that was handling everything). If you see the init.sqf you'll see this line here: if (isNil "oneTime") then { This is the 'hack' that i did to separate the server from the actual client inside the editor. Its a global variable that gets initialized when you preview the mission in the editor. The first time the script runs 'i assume' its the server, so i execute some stuff that i need the server to do, but whatever is inside that if will not be executed by the player when he spawns on the map. So when its time for the player to spawn, the global variable oneTime is not null anymore since it was initialized by the server, so there are tons of scripts that are skipped for the player. This way there is a 'virtual soldier' with X number of scripts running on him, that the normal player doesnt have....thus creating this illusion of a server/client relationship within the editor. This virtual soldier handles all the spawning/querying/etc and the player just does the usual things (basebuilding, kill zombies etc). In the Instructions page there is a Bugs part. You'll see that i mention there that if you chose the 1st method of spawning a player, you might see 2 soldiers spawning....Thats the reason why they are 2. One is the server. Ofc if you kill him, the 'server' will not continue executing scripts and you have to Restart the mission. Overall, you dont have to worry about all the above. The only thing you have to remember is the Related to coding part of the instructions. Some global variables provided by BIS cannot be 'emulated' inside the editor. So you have to write your code inside the editor following the instructions i gave regarding these commands. When it's time to move your script to the server, then replace these variables with the proper ones. For example:

In the editor you did: _playerUID = player getVariable ["CharacterID","0"];
When the real one is : _playerUID = getPlayerUID player;
Stijnkluiters commented 7 years ago

Thanks for the explanation @Sandbird i really appriciate the big explanation. I can create my own server now with an HC because i understand the process. I am a programmer myself so i can work this all out.

i've a question though, do you know why i can't get the humanity variable with: player getVariable["humanity","0"];

Sandbird commented 7 years ago

You are welcome. And something else to help you figure out what changed. If for some reason you have doubts about some variables, searching in the Epoch's github might give you some clues. For example searching for the word humanity there, we get this: https://github.com/EpochModTeam/DayZ-Epoch/search?utf8=%E2%9C%93&q=humanity&type=

Now as you can see they still use:_humanity = player getVariable["humanity", 0]; so that means your code is correct. Probably you have no humanity on the player, so let's set some. You could try:

_humanity = player getVariable ["humanity",0];
_humanity = _humanity + 10;
player setVariable ["humanity",_humanity,true];
//Lets see if that worked
_humanity = player getVariable ["humanity",0];
Stijnkluiters commented 7 years ago

_humanity = player getVariable["humanity",0]; // This is where my own server failed because of my anti-hack

https://epochmod.com/forum/topic/43153-released-custom-spawn-loadout-dependend-on-humanity/

Sandbird commented 7 years ago

hmm the only thing i can think of is because of the player variable. The script doesnt have access to this global variable...and it shouldnt have probably...Player details were sent to this function...its not an 'exec' script. If you are using this file: https://github.com/EpochModTeam/DayZ-Epoch/blob/master/SQF/dayz_server/compile/server_playerLogin.sqf Between lines 91-110, you'll see they use the variable _primary to describe the player variable. That's the one you need to use. (Initialized at line 84) This happens because the script was sent some variables (lines 5,6) to execute stuff based on whatever the 'caller' script used for these 2. It has no idea of 'player' or any other object for that matter...

Stijnkluiters commented 7 years ago

I fixed in a very bad way actualy... by making the humanity variable public. i should have made it that it unsets the global after it has set the loadout.

But for next time i'll use the _primary variable which comes out of the mysql database :p

Sandbird commented 7 years ago

And for all of the above i made this 3d.live mission file. Writing this script that you are doing the traditional way without access to mysql via the editor, would be a time consuming task. But with this way and a few diag_log commands...you get it done in 5min. :)