cen

classname needs to be ItemHatchet_DZE

I'll add some money to the pot for this

I have an apache server on my dedi with symlinks to the files
 

Sounds like none of have trust in your admins to be honest.
 
All my admins have access to all tools on every server. They are players first/admins second.
 
If they help a player out they state it in chat that they are enabling god mode and teleporting to the player unless they are engaged in combat.
 
My admin logs are publicly available for all to see to so if they have any doubt they can see any action the admin takes with the menu.

Getting the same thing here.

That's what backup are for :D

MaxMsgSend=192; MaxSizeGuaranteed=512; MaxSizeNonguaranteed=192; MinErrorToSendNear=0.047000002; MinErrorToSend=0.0040000002; MaxCustomFileSize=0; Windowed=0; adapter=-1; 3D_Performance=1; Resolution_W=800; Resolution_H=600; Resolution_Bpp=32;

Hey guys,
 
I've been thinking recently, "Wouldn't it be great to have a Git Service dedicated to DayZ?". 
 
Why you ask?
Well, yeah we have github and bitbucket and all your other gits. But really, if we had a dedicated DayZ Git for all our modifications and projects then we could advance our community's online collaboration. 
 
What can we use it for?
Use it to share code snippets, normal git stuff, help each other with projects and learn from some of the best!
 
But everything else works fine why not just use that?
Because everything is in one place, and as I previously said, 'Collaboration'.
 
OK so you convinced me how should we do it?
I was thinking of using GitLab. Going to host it with a Digital Ocean server.
 
This is just an idea, but I think it could potentially benefit the community. 
 
Vote here: http://goo.gl/BbZ63K
Have something to say? Post below.
 
 
 
FAQ

 

Most projects are generally universal. Just "DayZ" in general I guess.



All the individual projects are managed by their creators. Along with who ever they assign to managing their repo.

Not worth it since 1.0.5 won't use that patch anyways.

Rolled back to 103718. Server wasn't cleaning up anything due to the deleteVehicle issues.
 
Mucho better now.

Rolled back to 103718. Server wasn't cleaning up anything due to the deleteVehicle issues.
 
Mucho better now.

1.0.4.2 works fine on 112555, just throws a few RPT errors.
 
I diff'd the files for 1.0.5 and didn't see any changes in them, so the RPT errors will be present in 1.0.5 it looks like.

That's because the new dayz mod on steam is for dayz mod 1.8.1, not dayz epoch...

This is from maca's safezone script.
SafezoneVehicleSpeedLimit = [] spawn { _maxspeed = 25; while {true} do { waitUntil {vehicle player != player and !((vehicle player) isKindOf 'Air')}; _vehicle = vehicle player; _curspeed = speed _vehicle; if (_curspeed > _maxspeed) then { _vel = velocity _vehicle; _dir = direction _vehicle; _speed = _curspeed - _maxspeed; _vehicle setVelocity [(_vel select 0)-((sin _dir)*_speed),(_vel select 1)- ((cos _dir)*_speed),(_vel select 2)]; }; sleep 0.1; }; };

1.0.4.2 works fine on 112555, just throws a few RPT errors.
 
I diff'd the files for 1.0.5 and didn't see any changes in them, so the RPT errors will be present in 1.0.5 it looks like.

Great work, players are loving how natural it looks in the city!

My server gets to 40 players and nearly fucks itself up. Annoying but hey Overwatch itself is lag heaven epoch is worse. We just combined them.. Ummm yeah? 
 
~mochan 

He's not hiding anything. He will be the first to tell you they are his UID's. He does testing on live servers some times with players. He's been on my server plenty of times and doesn't do anything to disrupt gameplay.
 
If you don't like it, just remove them. Chances are he will never join your server anyway unless you have actually talked with him other than over email.

Sounds great Az. I for one appreciate extensive testing before releasing it!

Ok so an update!
 
Live tests were semi successful.
 
A few notes
 
No more than 1 headless client can run on the server. After a clarification from Bastion over at Battleye (Thanks for the quick reply!), only one instance of the BEClient.dll can run on the machine at a time, resulting in "Corrupt Data #5" kicks when you try and run more than one HC on the server. This can be resolved by using VM's or external clients, but is still a setback indeed. BE filters are not as standard as I was hoping to make them. You will have issues with these, especially if you have customizations. I will put up FULL instructions on how to correctly do your filters and the common issues encountered but overall it does detract from the simplicity of the framework I was hoping for. After all was said and done, there were some random crashes (caused by a script error I promptly fixed), and some massive network congestion (Might be related to the script error). Either way, it will be a few more days of live testing before I will be willing to release anything - I don't like releasing broken software.
 
The JIP functionality is also not functioning. After some more tests I will fix that.
 
Signing off! 
 
Az

I like that you guys copied my supply crate, even down to the text. Much props :D

I was unbanned immediately by Bastion, issue was unrelated to the HC.
 
I will update the git so its actually clean and not a mess of code as it is now :P
 
 
 
Starting the next round of live testing now!
 
Currently server side scripts are working excellently, but client side specific scripts are having strange issues. I plan to release the alpha after this round of live testing (and subsequently the git) and then work on implementing client side (Zeds, etc) back into the HC after the fact. I think I need to rethink my strategy with regards to communication frameworks. 
 
 
That was the easy part! Two chunks of code, one running on clients with an interface, one without. Simply checks whether a real client (Not the HC) is not CIV and if so, kicks using a PV. DSCHA's solution also works - but it was only a few minutes of testing that an actual player clued on and changed his name to "HeadlessClient" and slotted in. The framework works on a "strict" code ethos. This means that no code can execute outside of its frame of reference (players loading as HC, HC loading as player etc). 

And the best part of all....
 
I will be releasing BE filters to accompany my release. 

Not sure if anyone posted this, but if you are tired of searching for spawned vehicle every time you spawn one, then here's a quick fix:
 
In all of your deploy SQF script files
 
Find:
sleep 6; _object = "MMT_Civ" createVehicle (position player); _object setVariable ["ObjectID", "1", true]; _object setVariable ["ObjectUID", "1", true]; player reveal _object; Replace with:
sleep 6; _Offset = [0,5,0]; //change how far from player this vehicle will spawn X Y Z in meters, in this case 5 meters in front of player _worldPos = player modelToWorld _Offset; // spawn in front of player _object = "MMT_Civ" createVehicle (_worldPos); _object setVariable ["ObjectID", "1", true]; _object setVariable ["ObjectUID", "1", true]; _degrees = getDir player; //find out which direction player is looking at _object setDir _degrees; //rotate vehicle to match player's direction player reveal _object; Enjoy your bikes!

Nah they've given up on A2.

Grab remove.sqf from client files, move it mission side, overwrite it in compiles.sqf then change the code:
 
Default remove.sqf code block:
if(_finished) then { _counter = _counter + 1; // 10% chance to break a required tool each pass if((_isDestructable or _isRemovable) and !_isOwnerOfObj) then { if((random 10) <= 1) then { _brokenTool = true; }; }; }; if(_brokenTool) exitWith { _isOk = false; _proceed = false; }; My modified code block:
if(_finished) then { _counter = _counter + 1; // 10% chance to break a required tool each pass if((_isDestructable or _isRemovable) and !_isOwnerOfObj) then { if((random 40) <= 1) then { _brokenTool = true; }; }; }; if(_brokenTool) exitWith { _isOk = false; _proceed = false; }; Basically I lowered the chance of tools breaking by changing the random 10 to random 40. You can use any number you wish.