eugenharton

Dear Survivors, during the last couple of days we have experienced an unexpected downtime of the Legacy servers. The fix would require to assign developers back to it and invest extra time to make it work. Instead, and because of our focus on 0.63, we have decided to cut the Legacy branch prematurely to make sure we can spend all of our time in this year on what really counts: The release of 1.0 (which was intended to be the original closing date of the Legacy branch). So we will pull the plug on the running Legacy servers (overall peak of only 8 players per server during their up-time) and branch holding the client/server data. I'll fondly remember the experiences I had with that version of the game, and while it was broken in so many ways, it's probably been the version that a lot of you experienced as their first entry to DayZ. Our goal to package the Arma 2 mod into a standalone version of the game outgrew itself with the creation of the engine and playing the long game will bear its fruit. So I'd like to say goodbye to what DayZ was and welcome what DayZ will become. - Eugen

Hello guys, with the last Status Report, we've done a list of the most pressing issues - and it's time for another go. Make sure to check out the Status Report for the update on the previous list as well. SERVER CRASHES Server crashes are rampant these days, and out of the top crashes happening, we have been able to reproduce two that are slated for a fix. However, the one of the most common ones is elusive. Having said that, we have committed some changes that might stop the server from crashing in most cases, lowering its impact. Whatever steps are required right now to cause it, the outcome of that specific combination of factors should just end with that situation not causing a crash. VEHICLE ISSUES We are aware of issues with the first iteration of new vehicles. There has been a large refactor of vehicle physics recently that has already improved the gameplay a lot and is included in the next update coming out. We are also working on the balancing of required fluids, damage and more that should make the extensive time invested into making a vehicle functional worth it. PLAY BUTTON We are aware of the issue with the play button and the fix is planned after the next update. PERSISTENCE ISSUES After extensive investigation, we have been able to confirm that some items were being deleted after specific crashes. We have implemented a system to make sure that this does not happen in the future with other crashes. Besides that, we also recommend all server owners to update the economy files after the next Stable update, as there are changes to specific items that had issues in the past. GUN SOUNDS MISSING We are aware of the issue where gun sounds don't play for the player using them. However, internally, this has only happened a couple times during our daily tests. Most of the reports coming are related to the use of the shotgun, but it seems to be affecting all weapons. More information is required for a fix, but after the next update and necessary stability improvements, we will be looking into these next. SOUNDS STUCK IN A LOOP We are aware of sounds being stuck in a loop. As is the case with gunshot sounds, more investigation is required and a fix is slated after the next update. However, it's very likely that this issue will be less frequented now, as partial improvements are in place. M3S TRUCK STATUS Before the refactor of vehicles, we wanted to focus on making sure the first one works before we introduce a second variable to the mix. Both of the vehicles are different beasts and if things settle down with the new changes in vehicle physics, we will look into getting the V3S in. BASEBUILDING ISSUES We know and track a number of base building issues, from balancing to functionality missing, to plain bugfixing. It's certainly high on our priority and in the next update, you should see many things getting fixed. There is more to be done in terms of ghosting, protection and general usability. I'm still amazed at the creations you guys have made so far! SHOTGUN DAMAGE We are aware of the issue of shotgun damage - specifically with slug damage values being too low. We'll be looking into it. If you experience any inconsistencies in the experience with using pellets, please report them using the Feedback Tracker, ideally with information about the server you played on, and any other relevant details to make sure we can track it down properly. NIGHT SETUP As mentioned in the update on lighting issues, we know that night gameplay is only partially implemented and there is still a balancing pass to be done on light sources, luminosity and general setup to make sure lighting works properly. We agree and understand it's not a good experience right now. HIT REACTIONS AND STUN-LOCK Hit reactions and stun-lock issues are on our radar. We know its not properly configured and are working on smoothing it out. VOIP ISSUES VOIP for multichannel setups with 5.1 and 7.1 sound are fixed in the next update and we are looking into improving it even more with making sure that volume is less affected by distance. There is more work to be done here as we understand that VOIP is crucial to the DayZ experience. THINGS AFFECTED BY BALANCE PASS (GUN-PLAY, DAMAGE, DISEASES, ECONOMY AND MORE) Many of the reported issues can be improved by value adjustments on our end. I want to emphasise how important this balance pass is for DayZ and its functionality. While all sorts of interesting features are in, they require us to review their current state. We need to get dirty to properly configure them. Gun-play, damage values, diseases, economy, persistence, and so on - bugfixing definitely comes first with high priority issues, but a balance pass is what makes the game fun in the first place. We will announce as things get rolled out over the following updates before we reach 1.0. The first thing you should be seeing is recoil and its behaviour tweaks.

Hello Survivors! There are some hot topics regarding the recent 0.63 update that are currently resonating in the community, and I wanted to touch upon some of those in more detail. These are some of the most common issues that were currently seeing reported, and our answers to them: Item renaming Those of you playing on the Stress Test branch have probably noticed that we have renamed a large number of items in-game. All of the changes were done after a meticulous consultation with our legal department, and the sole reason why we did this was to avoid any liability in the future. I know some of you have delved into details of it, and I can't answer every single question or doubt you have about specific item names now, but one thing is certain: we need to stay within the law, and while there certainly is space for more creativity in some item names, we need to push forward the changes because of the game localization. We might look into item names again once post 1.0, but nothing can change now. Hit registration This issue has multiple causes and patterns to it and it's not a single problem. A bullet can deal no damage in certain situations while still actually be considered a hit at the same time due to how armor and damage interact. The server may then think that there are no bullets to be shot because the state of the weapon (or even state of a magazine, fire mode and more) has been desynced. Often, when we get feedback reports, we are lacking the detail needed to identify what exactly has caused the hit registration problem. Sometimes, people just miss. Other times, we just don't know the events that lead to the registration problem. Having said that, we have been able to reproduce a number of these issues, and the Experimental build has those fixes applied. We are still tracking at least two more ways to encounter the issue. One has a cause in networking and is more apparent on community servers with increased player numbers (over 60 players). While we want to support higher player counts, this will require further optimizations. The other hit registration issue we're tracking is related to the shotgun, and only happening with that weapon specifically. Changing key binds in the settings screen One of the most important modules in any multiplayer game besides the player controller is the input module of our engine. For the better part of this year, we've worked on delivering a new, reworked input module. We needed something that's easily moddable, scriptable and most importantly, something that opens up more possibilities than the old system. This transition had us cut the UI for key-binds because the new UI wasn't compatible with the old input module, and now, when we actually do use the new input module already, we're waiting for the UI to be fully connected to it. While regrettable, it was a decision that had to be made, and we simply had to push the changes even without full UI support, as the input module is a necessary component for other changes in the game. That said, our goal is to deliver the UI for key-binds as soon as possible - right now, this is blocked by the work on the server browser, and as soon as we've got that part of UI sorted, we'll move right onto key-binds. In the meantime, and I'm not saying its something I'm particularly happy about, you can use the configuration file where the key-binds are stored - we'll try to help you explain how to work with that on the forums. Bloom post process effect tweaking This is certainly one of the hot topics. While we agree that the game has some lighting issues, these are not caused by bloom, but by the simulation of exposure in the human eye and effects associated with it. In fact, we are using very little bloom and it has been significantly decreased over the course of development. The issue we believe is described by many of you is on our radar, and once we have a good solution we will definitely do something about it. FPS drops It has been some time since the new renderer has been implemented. It seems we are encountering some FPS issues again and I just want to reassure you these have always been our top priority. If you are affected by these, I recommend you to reach out to us through the Feedback Tracker with details of your PC build, drivers version, and operating system to make sure things work as intended.

Dear Survivors, today did not go as planned. Our goal was to update the Xbox and PC Experimental servers to the same version while offering the server files to the public. This hasn't happened, and I want to let you know how we're gonna proceed and why. We have prepared the documentation for the Server Files release and the build yesterday, focusing on particular quality of life fixes for both admins working with community servers as well as those looking to host on their own. These fixes included character corruption, admin log fixes, server browser fixes and more. All but one have been confirmed to work. Sadly the server browser fixes have caused any private hive to be invisible in the server browser. As such we have decided to not release the Experimental Update as well as postpone the Server Files. While the fix has been committed, we will require at least some testing before we go ahead with both the Experimental release and Server Files going public. During this effort, we have encountered multiple issues with Steam that have made the process slower, and hopefully, we won't see this happening again. I`m deeply sorry for today, we will confirm the fix tomorrow and plan the release. More information is coming.

As we suggested in our newsletter, we're going to offer all Server Owners the option to switch to 0.63 servers. We actually provide two options - initially, you'll be able to use the standard hosting via Game Server Providers (GSPs), and later on, we'll add the option to host a server on your own with the release of DayZ Server Files. Let's go through the basics of what each option means and when they will be available. GSPs switch - what to expect The switch to 0.63 servers is happening with the release of the Experimental Content Update today (September 11, 2018). Moving to a new version of the game means you will lose compatibility with the previous persistence file from version 0.62, as well as characters associated with that shard. The switch is a fresh start in many ways, but in case you, for some reason, want to roll back to 0.62, the option will still be there. GSPs and their support teams should be able to get you back to the previous state of things on your 0.62 servers. Available functionality In general, all the commands for server management that were available to you up until now are still there: ability to use functional limitation on maxping is back whitelisting, send message and ban are all in dart and BEC are compatible just like in 0.62, with new tools to be made available later Community hive is not available for now, but... The ability to create the community hive (backend) and toolset will be released at a later date around BETA patch release. We have however structured server functionality in a way that it can scale: you can turn persistence off and on locally you can save/load characters from a local storage that means that this local storage is the most important part of the server package to backup regularly Once the community hive is released, you’ll be able to use a server configuration option to point it at a specific hive/installation and have multiple servers serving the same economy/characters on a larger scale. For those hosting with our providers, you’ll benefit from cross server persistence based on our hive. This is achieved in the same as before - by using the same ShardID on all your servers hosted. When not using hive and relying on an offline database implementation on a server install, we offer the same on server functionality as when using the hive. All information centralized in a database and stored locally, keeping it accessible. Any economy changes can be done by modifying local files. Changes to logging One of the very important topics for you when running servers has been logging. To understand what that means from our side I'll dive in on a bit more technical level. The idea is simple. The more we log, the higher the performance tax is on the server. Currently, we offer two logs: an admin log, and a server log. They can be amplified to show all the possible entries by using -dologs start parameter on a server. However, this might cause some performance drops, depending on the I/O it's creating. We tried to accommodate a lot of new entries and their detail, and a lot more things can be done. As far as reliability goes, this has increased significantly as these are tied to performance first and foremost. All calls are done from the script and I believe we can do anything together. Server Files release - what to expect We'll go through the Server Files release implications in detail in the next newsletter, but for now, it basically means two things for all Server Owners: hosting a server on your own terms with any providers, but also on your own hardware if you choose to do so ability to have custom settings, missions and even mods on community servers Especially the customization option is very exciting, and while we're not fully ready to support modding with all the necessary tools, having server files released will already open a lot of new ways how to enjoy DayZ beyond the vanilla experience. We also don’t want to stop you from figuring things out. We will offer basic documentation to server installation and its configuration, including startup parameters on the day of the Server Files release.

This week, we've reached an important internal milestone of completely deprecating our old SQF scripting language (it's been with us, in some form, ever since the first Arma got released). From now on, our internal branch of DayZ only runs modules written in the Enforce Script. Since I wanted to cover that internal milestone and explain its implications, I`m going to be more outspoken than usual, but before I get slightly more in-depth, the most important part for majority of our fans is this: From now on, internally, most of us in the DayZ team no longer need to work with a game that uses legacy modules of DayZ and functionality scripted in SQF. The legacy modules and scripts were often incompatible with the new ones written in Enforce Script, which were clashing together as we have prepared to phase them out. We don't need to worry about these anymore, and can actually start connecting all the new engine modules,technical modules and data together, and focus only on these. In a sense, that means that internally, we no longer maintain two different versions of DayZ content and gameplay. Before you get excited, this does in no way mean that we are very close to a public BETA build release: there is still a lot of work ahead of us, but this milestone is a major relief for the team. Why? This is where I want to get more in-detail: If we define gameplay as action that player can take in the game, there are two ways in general to make that gameplay "work": having things "hard-coded" (in C++ in the case of DayZ) using a scripting language (Enforce Script for DayZ, previously SQF in DayZ and other Bohemia games from the Arma branch) Most games use both scripting and hard-coded functionality. In a world where community modding matters (= our world!), you try and keep as many things as possible written in script - you want to have the ability to easily edit them later on. Scripting also makes iteration faster and helps our own designers create things on their own, while not spending additional programming time that is needed elsewhere. In our particular example, there are direct advantages in moving away from legacy SQF to the new interpretation of our gameplay using the Enforce Script. In direct comparison, we can say Enforce Script is much faster and more flexible. It is also object oriented and will be the backbone for all of DayZ modding. Even for modders themselves we want to introduce a script editor with IDE and debug functionality. Maybe you're wondering now: does all the work we did on the public branches of DayZ get scrapped all of a sudden? The answer is: some of it does (script), and some of it doesn't (data). We don't need to quickly write some rushed version of everything in DayZ using the new script now though: we've been working with both legacy script and the new script at the same time, and what exists in the public branches of DayZ now already exists written in the Enforce Script, too - all of it. As there is no direct "backwards compatibility" between the two scripts, we had to re-write the gameplay to the new script entirely, dragging all these pipelines in parallel. At the same time, content like models, textures and other binary files remains functional - we've said many times that we were trying to balance our development in a way that avoids, as often as possible, doing things twice - in order to save time and effort. And that's what we've managed to do - while expanding on their quality and additional features. We tried to test things which made sense to be tested on the public branches - things that provided you with a reasonable gameplay experience, and things that provided us with necessary data. But from this point going forward, internally, we only run version 0.63 which is BETA for us. As in a version that will have all the new engine modules and technical modules implemented, along with all the data that was created to support these modules. So again: Removing SQF means that our internal client runs only the gameplay functionality that is either hardcoded, or written in the new Enforce Script. No legacy systems. And no legacy engine modules in the end. That is the game that most of us have worked for so hard for the better part of those last three years. We are excited and wanted to share this important milestone with you. Eugen

I`m sorry guys, Brian is right on that subject, because of the complexity of the beta goals and merge of the work that has been done for the past few years for some of the modules :), I`m spending insane amount of time analyzing risks, cosnulting with team members and getting ahead of issues we might encounter. <3

To explain the numbers What you see on steam currently is number of people with running dayz.exe at that one moment. Its called concurrency aka amount at one time. Monthly unique players and Daily unique players is something most services use to determine their userbase. The number is the amount of unique players that have logged into a game in a period of time. We track the number based on login to server, so its people playing a game to be exact. So if we say 300k people played it means 300k poeple logged into a dayz server over a said period of time. Eugen Harton

Zombie AI simulation is tied to network bubble, they should have idle set of animations and roaming behaviour when they are in yours. Probably a bug. I`ll look into it.

Okay the dual core problem fixed internaly, it was a sideeffect of some changes for new renderer. Fixed. Hardest part was getting the old hardware plugged back in :-D

Gonna look into it

Can you post your DXdiag?

I`ll look into it.

Hey guys, I`m looking for specific feedback on the last experimental, since most of the data is mixed. To understand my point : Server performance (server fps) affects all sorts of things within simulation, but best way for player to determine that server performance is low is by interacting with enviroment (doors,items,crafting,action menu delay etc.) And desync can and can not be affected by it, what I mean that desync can happen even when server performance is great. Logic of the sync system is being tuned as we speak on many levels. With last experimental however the feedback was mixed and thus we suspect there is a specific trigger that makes the player experience differ. Its probably because of one bug with corpses, but more data on your plays yesterday and today is always welcome. Thanks for everything! Eugen Harton

We should be okay for now, thanks for being patient guys.