Dear Survivors, we have some good news to share. The Content Update has hit the Experimental Branch today, and that means we're also making it available to community server owners currently hosting with one of our Game Server Providers (GSPs). Please expect slight delays as GSPs will cope with the number of switch requests, but I'm happy to see things finally move along to the Experimental phase after most of the critical issues were fixed in our Stress Tests. We have implemented a large number of optimizations in our network code while trying to identify an issue that in the end was caused by specific server hardware problems.
Now I have something that many of you probably don’t expect yet, but we want to see things move along at a faster pace there so we can get feedback: We've decided to release the DayZ 0.63 Server Files before BETA, and currently, we'd like to make them available to all DayZ players within the next week. Everyone will be able to download the Server Files for free on Steam under the tools section, and from that moment, everyone will be able to host a DayZ server on their own. I think that with the release of Server Files, we will see a much broader variety of server setups and community made game modes and while the full modding tool-set won’t be available before BETA, I think you guys have already figured a lot of the stuff out.
Last but not least, our goal with the next Content Update (that we might already call an Experimental BETA patch since we will be stabilizing the internal version of the game on the Stress Test machines) is to have a release in as soon as the next couple of weeks. This update will, again,introduce a variety of new things, with vehicles getting in a bit later after the initial release of this next Content Update. We will announce the new features and content as soon as we release the first Stress Test build. Just to pick one example, the new restraining system that Adam talks about is definitely one of my favourite ones.
The Xbox version of the game will see major game updates getting in soon after they hit the PC Experimental branch. While we won't be Stress Testing as of now on the Xbox platform, we will keep churning out updates with bug fixes and stability fixes to this version as they manifest themselves. Even today, we have pushed a game update with lots of fixes for bugs that we have seen in the PC version, and most importantly, we're fixing some of the specific inventory issues and controller related bugs that will make DayZ a better, more enjoyable experience on Xbox.
- Eugen Harton / Lead Producer
Hello survivors. For the last couple of weeks we were releasing new Stress Test builds almost every day with the goal to improve server performance and to finally solve the BattlEye mass kicking. And we solved it! I'd like to describe here what we were doing and why Stress Tests are so important for us.
Probably the best way how to explain what we were doing in our last Stress Tests is to answer some questions directly from the community. Let's go through the questions that TheMagicTorch asked on Reddit, as they will nicely demonstrate our thought process.
Q: Are you working with BattlEye developers to try and resolve the issues?
A: We do have a direct communication open with BattlEye developers, and the first thing we've made was that we asked them for some input on what could be wrong. In any case, the kicking issue was there even when we disabled BattlEye, so logically, we started looking for an issue on our end.
Q: What do you think is causing the kicking? In technical terms.
A: So we knew that the issue is on our side, we were sure it must be somewhere in the low level part of our networking - we were thinking that the issue must have something to do with packet ordering or re-sending of lost packets, or even with serial numbers of packets. Now we know it was caused by packet fragmentation - in some rare cases, some packets were dropped and it broke down the entire server.
Q: Why are you finding it particularly difficult to resolve kicks and lag? Are the kicks and lag a result of lots of bugs that you're slowly working through, or are you still trying to identify where problems are?
A: The source of the kicks was just one mistake in the code, but it was hard to find it, since we weren't able to reproduce it internally. The 0.63 branch was created almost 2 years ago and a lot of changes have been made during this time period. Two weeks ago, we started to revert these changes, because it was probably the fastest way (but not the easiest one) how to find the source of the issue. We have reverted one or two improvements every day, made a build and released it on the Stress Test servers, so basically we went back in time every day (the curiosity here is that this bug has been in the build since May 2016). When we've identified the source of the issue, we started putting the reverted and working stuff back into the branch, and released it in Stress Test #46.
Lags are closely connected to the server performance, so different parts of the code may cause them. We were profiling the servers every day to find out the source of performance drops, or what exactly takes most of the CPU time. Every day, we've made some improvements, which were merged into the Stress Test branch for play-testing. It's important to test these optimizations because optimizations can often break things that were previously working fine. One optimization helped us to find out that there is an issue with the firearm damage sanity check, which caused bad hit registration. This bug was there the whole time, but after the optimization, it happened more often.
Q: Why does performance seem to vary between region?
A: The deployment team along with Eugen has tracked this issue down to be a problem with a hardware configuration of the servers, and we're now seeing consistently decent server performance across regions.
- Miroslav Maněna/ Lead Programmer
Hey everyone, it's been a while since I wrote something, but boy, have I got goodies today or what?
For the last two weeks, I have been working on looking through optics, surrender and restrained states.
The current implementation of looking through a detached optic in the latest public build had a lot of problems with it... The accuracy of mouse-to-screen is sub-par at best, and you can't accurately follow a target without moving your mouse a couple of meters. We discussed various ways to implement a solution, but I was mainly worried about the character not accurately displaying where someone is looking. If we were to ignore the player animation accuracy and just set the camera to be 1:1 with the mouse, other players could think that they haven't been discovered all while the player who's looking through his binoculars could be tracking them.
I solved this by not allowing you to move while looking through binoculars or scopes, and by doing this, I eliminated any external factors that could mess with the accuracy of the animation; because really, what kind of crazy person would be moving while looking through a pair of binoculars? One wrong step and you could lose your target entirely! Here's the animation I cooked up:
As you can see, it's quite damn responsive. Here's how it looks while looking through it:
It's in a really good state so far and accurately displays in and out of the optics exactly where that person would be looking.
Surrender and Restrained
Surrender is a highly sought after feature that we have been working on to deliver in the highest possible quality. At first glance, it would look like it's just another gesture; but under the hood it holds a bunch of complexities. You can't access your inventory when you're in surrendering - not something common for gestures. You also have new stance rules where you can only walk while standing and only turn in standing and crouched - also not something gestures can control. Lastly, but not least, it also has a bunch of surrender-specific stance changing animations - also something that gestures cannot control. With these things in mind, we had to approach the surrender mechanic with a bit more caution, as a half-assed approach would probably come back to bite us later down the line.
We have solved it by essentially handling it like a gesture state on the script side, but on the animation side, it would be considered an "item" of sorts. The reason behind this solution is that when a player puts an item in his hands, his character will switch to the corresponding animation set (picking up a rifle will start playing the rifle animations, pistols for pistols, and so on) with all of their specific animations for turning, changing stances, etc. By putting this "ghost item" into the character's hands, the surrender animation set is enabled, and the specific movement rules that that animation set has attached to it. In addition, we have opened up avenues for ourselves where we can have a bunch of surrender-specific animations; such as deaths, gestures, actions, etc, etc. Gestures-in-gestures? Oh boy.
All of those same rules also apply to the restrained state, but this also means we can accurately show what item is currently restraining you; such as in this case with some locked handcuffs:
Maybe down the line, you'd be able to drink face-first from ponds even while restrained to keep yourself hydrated while running from your captors. Who knows!
Until next time.
- Adam Oresten / Technical Animator