Hicks_206 (DayZ)

DayZTV is a fansite - and one that tends to datamine. We're not ready to talk details about electricity - when we are, we will - through official channels.

Not cool - it is there because of a bug. Soon as the bug is resolved, they will be 8 days as they should.

Lifetime counts as long as the server is offline. Most items are 30 minutes. Barrels are 8 days Tents currently 45 Backpacks are 4 hours last I checked.

8 days for barrels 45 for tents (as they don't currently refresh their lifetime unless you pack/pitch)

Hey guys - I know a lot of folks were giving me guff about using imgur and jpg Steam default for the 4K images I shared a few days ago - so I took some new ones. PNG Lossless - and Uploaded to Flickr. https://www.flickr.com/gp/143594186@N03/aUg659

Heads up everyone - I just want to get ahead of the E3 hype train and derail it straight away. Just so everyone that participates in the development of DayZ is aware - Our presence at E3 will be limited, but what presence there is - will *not* be new information for those active folks. E3 is primarily a media/retail show, and the small presence we will have there will be discussing what most of you already know - that we're getting ready to move 0.60 from Experimental to Stable (as soon as the blocking issues are resolved) and exactly what 0.60 is (Direct X 11 Enfusion Renderer, Economy Updates, Reload Mechanics changes). We're aiming to hit those who might have taken a break and not checked back with the information regarding 0.60, and hoping they'll take another look so we can see any other potential issues caused by the new tech changes. No console news either - Console platforms will come - when the primary platform for DayZ (PC) is stabilized, and those platforms are ready. That said - I know the Arma team will also be at the PC Gaming conference with us - I can't wait to see what they have up their sleeves :) That said, I hope you're all as excited as we are for 0.60 Stable!

Hey guys, Pretty often we get a lot of inquiries as to why Experimental/Unstable branch servers are not online, or requests to revert to the last playable build so people can play on the Experimental/Unstable branch servers while they're offline. I thought I'd take a brief moment to try and explain exactly why when they are offline to the public they can't just be turned back online. As you all probably know, especially if you keep up to date with our Status Reports (Biweekly - found at devhub.dayz.com) the team has been working hard on resolving the current primary major blocker for testing 0.60 build on Experimental/Unstable branch - servers unable to accept client connections past 10(ish) players at a time. This is just one example of the many different type of type of issues that can and will come up during the development, testing, iteration, and regression of a new build in DayZ's development cycle. "Just reverting" is far more of set back than just simply renaming a few files and pasting in the last known good build to the gameserver root folder. - Each iteration on an Experimental/Unstable build entails more than just the executable and data folder for the game server - Database structure, Servlet functionality (Central Hive), and Central Loot Economy are all also often iterated within this update process and are not often backwards compatible with older versions of the DayZServer software (In simple terms, the language changes a little bit each update and DayZServer.exe versions don't often talk properly to newer versions of the database, servlet, and CLE) - Internal testing for Experimental/Unstable updates occurs *on the Experimental/Unstable database/servlet* and if we revert, then we shut down the internal testing process on the next update - Even if the public Experimental/Unstable branch servers are offline, we are often running internal tests on unlisted servers on the Experimental/Unstable environment in an effort to resolve any blocking issues and get the next update to Experimental/Unstable branch out there for public testing I know I might have gone off on a bit of a tangent there, as I am often doing in these type of posts - but I thought some of you might like to know a little more why its not as easy as just rolling back a build when we're working on getting Experimental > Stable.

Greetings Survivors, As those of you participating in testing on the Experimental/Unstable branch on Steam are aware, we have been working hard on iterating 0.60 towards a stable branch candidate. We've received outstanding support from the community, through both extensive bug reports on our Official Forums, and large amounts of server crash and performance data on the Experimental Branch servers themselves. The team has been working hard on isolating several specific server crashes from the experimental branch servers that we are unfortunately unable to reproduce internally. To that end, as frustrating as it may be, your consistent testing on the builds that have these issues has generated a large amount of crash dumps and logging for the team to analyze. We'll be using this data on Monday, but in the mean time we will be switching the Experimental Branch servers to the last known good 0.60 build for the weekend. No ETA as of this moment on experimental server downtime, but we will let you know just as soon as they come back online and the client update is ready. Thank you again for your continued support!

Servers are now back online, the experimental branch client update 0.60.132940 should be live momentarily. If you do not see the update, make sure to close and restart Steam. Thank you!

Recently I've noticed some discussion and confusion centered around our Communication Process. Now, I'd spoken on this in previous Status Reports - but it looks like it might be in everyone's best interest for me to go over this again. We made some changes to said process a few months back, starting with handing over responsibility for our Status Reports to Dhawkz, our new Brand Manager. I'm pleased to say that has been very fruitful for us, and we've had the Status Reports out on schedule without issue for quite some time now. That specifically is not what I was intending to think out loud about today, so let me get back on topic. We have two people full time on community and external communication, and part time each of the leads contribute to it as well. - SMoss (Community Manager) - Dhawkz (Brand Manager) Past the staffing responsibility we have 3 main methods of sharing external development information. - Status Reports (Biweekly - Tuesdays (Anytime on Tuesday) - Trello (No schedule, as assets are available to show) - DayZDevTeam Youtube (No schedule, we show things that are ready to be shown (Dev Logs), and we are trying out developer Q&A videos - Design coming soon!) In general you can see a theme above. As development is fluid, it can be hard to predict with certain accuracy exactly when a specific system, tech, or feature will be playable or even showable. We can give our goals, or even our estimates - but we'll always end up upsetting at least one side of the crowd. Not to mention the fact that showing things while in development that aren't *on the docket* for the very next stable release only tends to end up causing confusion - and in some rare cases, frustration. Often you can end up with a render, preview animation, or prototype system that is dependant upon significantly more moving parts to be playable or even testable - and that tends not to trickle out through all human/organic communication channels of mouth to mouth. So moving forward we've been following a principle of only showing things in our YouTube channel that are coming up in the next stable build. We've allowed for more loose communication style with the Status Reports - as they can tend to be very text heavy and dry, the developers can take some liberty to talk about more long term goals and tasks. In addition, our recent change in how we communicate "deadlines, goals, and targets" will bring milestone review briefs to the Status Reports - starting with .61 development. Our Trello is very irregular, and I'd like to improve that - I just need to figure out how to combat people misunderstanding a model preview for something that is ready to be in game, or even will be soon. ;) When it comes to "dates" - well, as I've said a few times before - We're just not doing that with our communication any more. Things come up, dates end up getting pushed, and we end up with both developers and early access users frustrated. So, we're taking a different approach - one that gives a bit more transparency into what systems / changes are targeted for a given stable update, what the progress is towards said build, and what got pushed and why. We have our firm date for Status Reports, and the guideline of "when its ready" for showing things on our YouTube channel - paired with the above mentioned milestone reviews in Status Reports - I think for those that are interested in following DayZ development towards its 1.0 release, there is a lot of information to be had. I'm sure this rambling post will upset some, maybe please some others - but I thought it needed to be said, and if I didn't care - I wouldn't be here writing it :) See you all out there in Chernarus!

Because you're playing a title in development. The queue system, like many other features and tech changes are upcoming.

This morning after having a coffee and catching up on e-mail I started going over tweets people had sent to myself, and the official DayZ Dev Team twitter account and I noticed some statements, albeit from a albeit small portion of the community, but ones I thought needed addressing none the less. First off however, let me take a moment to thank the overwhelming support the DayZ community has given us thus far in our efforts to iterate on 0.60 experimental branch. You guys have helped us isolate a large amount of issues that didn't come up under the first stage of testing with our internal QA teams and that is outstanding. Hats off, applause all around. You guys *rock*. Now, while going through the tweets this morning I did notice a good deal of frustration from this vocal minority in the community surrounding a lot of issues (Requests to push the current 0.60 build to stable right away, Frustration that experimental servers were not online at all times, Anger over experimental branch servers not being increased to ensure all those interested could log in, Misunderstanding over allowing content creators to show 0.60 to their audiences, Requests to take stable branch official servers offline and switch them to experimental, etc) - but the core of the issues all pointed back to one shared root: Availability of player slots on Experimental Branch. While I sympathize with those who are frustrated that they cannot get on to an experimental server due to demand, as it is regrettable that the nature of experimental branch does not allow all of you to be guaranteed access I think it is important we revisit this stickied forum post from 2014: "This branch is by its own definition "Unstable". In simplest terms, the purpose of experimental branch is for the development team to experiment with builds in a larger userbase than our internal QA. Sometimes that results in us finding issues we cannot catch internally, sometimes that means we can verify fixes on issues with very low repro rates. Sometimes the builds are very unstable. (As mentioned prior) The branch exists for load/volume/stress testing. Those who go through the process of manually opting into this branch (its not super visible - by design) and dealing with whatever issues the current build on it may have, get to sometimes see content and systems not quite ready for prime time. However, that does not mean that is the purpose of the branch. As the nature of the experimental branch is for the above mentioned testing methods, neither uptime, character data, nor stability is guaranteed." Experimental Branch usage is (like the rest of development) an iterative process. We (the DayZ Dev Team - and specifically Production, QA, and Build Management) start small and scale up as we identify critical issues and gain more confidence in the build's performance in stress scenarios. You might have seen this visible in the next day update to experimental branch, and the increase of player slots per instance to 60 players. To those who don't follow experimental testing closely this might not be super obvious, but this has provided us with *VERY* valuable data. I'm going to try and answer/explain a few of the topics tweeted at us over the span of last night below: Why won't you just push 0.60 to stable now? / It has to be better than 0.59: Well, simply put we just can't do that. There are quite a few issues that would flat out prevent a large amount of the userbase from playing DayZ at all. From the ever present "Application Error" to black screens on launch, server crashes, and many more - The build *has* to stay on experimental so we can get it to a state that allows the vast majority of the DayZ playerbase to play and test it on stable branch. Lets not forget that all branches of DayZ Early Access are testing branches! The testing base and goals scale up from our Internal QA, to Experimental Branch, and finally to the Stable branch as the default build you play when you install DayZ on Steam. I know it is not the popular thing to say, and the less fun part of my job involves having to take the brunt of passing on bad news - but your patience, participation, and feedback is and will help us get this build to stable as soon as possible. Why are the experimental servers down in my region? / Why aren't the devs saying anything about the server being down in my area?: Keep in mind the DayZ Dev Team operates out of Central Europe, and depending on where you are in the world there is a high chance the developers are in bed / haven't had time yet to analyze the issues causing the outage. Time Zone differences can be confusing, trust us we know! Pair that with the fact that server availability, distance from the Prague offices, and latency can fluctuate greatly depending where you are in the world - and it can and will lead to server downtimes in your region. A good example of this is the Oceanic and Asia regions - of which we've been fighting server issues and connection speeds throughout experimental branch usage. So please, be patient with us - we haven't forgotten anyone and will get the servers up as soon as time, and process allows. As well, sending tweets out every time a server crashes or goes offline due to a bug or server hardware issue isn't practical given how frequent this can happen on the experimental/unstable branch. Why aren't there more player slots? / Lots of people want to play, let us all play: The experimental branch testing phase is *not* set up to ensure availability and accessibility to all. Besides it not being practical on an infrastructure point, the nature of how we use experimental branch means we need to be able to create false stress situations for the game server instances, the central hive, and in some cases even the server hardware. Now, as experimental branch testing moves forward on any given build we slowly increase the player slots for that branch whenever possible. Be it actual game server instances slots, or allocating additional hardware when possible. Simply put, especially at the initial stages of a build being on experimental branch, we *need* to see how the build operates under extreme demand, we need to see it fail, and we need to analyze that data and make changes where necessary. That said, we are looking into increasing the branch player capacity within reason. Don't expect several thousands more player count capacity, as that is what stable branch is for - but we recognize the demand and are doing everything we can to help alleviate the issue. Why are streamers given special treatment? / I should be able to play there too: Early on after the first build of 0.60 was pushed to experimental I realized we just didn't have the infrastructure or hardware available to let everyone who wanted to see 0.60 on experimental branch that wanted to, and we wouldn't be able to flex up to accept all of the demand. Realizing this, at the end of the work day a development box that I use to capture footage for our Youtube Channel, and bug bash internal development builds was taken offline and converted to point to the experimental branch in the hopes that we could at least through allowing content creators to showcase the build let those who couldn't get onto an experimental branch server *see* how 0.60 was operating, performing, and moving along. The hardware used was not powerful enough to actually operate an actual experimental branch server, and would for certain buckle under the demand, but through reallocating this one small instance we could at least provide 30 or so content creators from across the globe, and across multiple languages give thousands more people a look at how things were looking on the march towards 0.60 stable branch. Creators of all audience sizes, and regions across the globe were given access to the box and asked to use said access to help alleviate the stressed demand on experimental branch by sharing their experiences on their distribution methods (Youtube, Twitch, Twitter). Through this method we were able to allow thousands of additional people to see and experience 0.60 experimental branch that we would not have been able to otherwise. Some people seem to think that experimental server resources were diverted to allow content creators access to 0.60, or player slots that could have been used for general experimental branch usage were given to these users. Simply put that is not the case, as mentioned before the server utilized was my personal work box and would not be able to handle such a demand. This was easily demonstrated earlier this morning when some enterprising folks acquired and distributed the IP address to this PC and the game server rapidly failed and stopped operating for several hours. No one was being denied playable server slots on experimental, and while we did ask content creators to be discrete so as to not compound the issue with experimental branch being at capacity that plan upset a small portion of the community, and for that I am sorry. It was never my intention to make anyone feel less important than anyone else in the community, the intent was explicitly to allow as many people as possible to at least *see* 0.60 experimental. Why don't you just take stable servers offline and convert them? / No one is using stable servers, switch them over: While it may seem that way to some users, DayZ has an active player base of several hundred thousand that cycle in and out (call it turnstile if you will) and it is important that we not just switch off game servers that users call home. We already fight issues with this in the case of some stable branch official servers, you may have seen it visible in forum posts asking where a specific official branch server that went offline was, and how users could get their camps, vehicles, etc back. As we move forward with development and push changes such as the final redesign of our server browser out, increasing visibility and thus reliability in these stable branch servers becomes even more paramount. For a game that is effectively a service in some definitions, like DayZ can be, we need to provide a certain amount of stability and reliability with the official DayZ servers. Switching them off and converting them to experimental branch due to a short term increase in demand is - in short, as I like to call it - "A bandaid on a broken leg". We all recognize that as we continue to move forward with major engine updates to Enfusion/DayZ demand will likely increase on this branch, and while we still have to keep the experimental branch within a certain limited capacity compared to stable branch, we *are* working on being able to increase (flex) experimental branch player slots to try and alleviate the demand as best we can with resources that do not compromise the integrity of stable branch official servers. I hope the answers above help you understand why/how things are done the way they are. I know some of the answers might not be what some of you want to hear at the time, but I felt it was important to address the questions and concerns raised via twitter over last night. Thank you all for being so awesome, and joining us in this incredible and sometimes stressful journey that is the development of what I think is one of the best gaming experiences of all time.

Hey guys, We'll have a small presence at PAX East this year - taking the opportunity to show the latest build of .60, meet and greet some Chernarussian survivors, and answer questions about the upcoming ,60 experimental release. We'll be working again with Astro Gaming, MrBlack0ut, and Anthony Kongphan. Our schedule for the weekend looks like such: Friday: 2:00 to 3:00 - Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut Saturday: 2:00 to 3:00 Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut Saturday 2:30 to 5:30 Live Stream w/ rotating guests on latest 0.60 build - Gameplay, Discussion, and Questions (Creative Director Brian Hicks, MrBlack0ut, Brand Manager Dustin Hucks) Sunday: 2:00 to 3:00 - Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut We're obviously all excited to get .60 on to experimental branch and in the hands of the Early Access users, so we're keeping it light this year - but rest assured we'll be showing live gameplay, handing out sweet DayZ swag, and doing our best to answer your questions during the weekend event. Live Stream: http://www.twitch.tv/astrogaming Tweet your questions to: @dayzdevteam (Hashtag #PAXEast) (All times are US EST) PAX East: east.paxsite.com

So, one of the topics that is frequently on my mind is difficulty. Where we fall on the spectrum, and if you'll forgive the expression - "What we can get away with". Peter (Lead Designer) and I frequently spend a lot of time thinking about this, talking about this, hell even arguing about this. There will be times where I swing from one side to the other, the game developer side of me wants to make things as hard as they can be, the side of me that spent thousands upon thousands of hours playing and streaming DayZ Mod on twitch.tv is very aware of the border of playability. Fortunately we have a Lead Designer that is willing to do whatever he needs to do to survive when in DayZ, so he is *in tune* with struggling to survive. :) DayZ suffers (at times) from a small amount of double personality. We've been known for a long time for being a punishing survival experience. Obviously that shifts from build to build during development, but the titles identity as a whole has always had that associated with it. That said, because of the uniqueness of the DayZ experience - be it from the stories you experience and pass on to others, or the tension that comes from the uncertainty of potentially losing it all over the smallest of choices, DayZ has carried a very large identity in the consumer market outside of the typical personality type that might enjoy something punishing in his/her survival. You can see it in the countless hours of Youtube videos, twitch streams, and reddit posts. DayZ has become (and potentially always was) something different to many different types of people. So where does that leave us, the developers, with the base game experience? It can be daunting combing over user feedback and trying to take that into consideration when paired with the intended game design of DayZ. Let us not forget that happy consumers rarely feel compelled to get up and let their feelings be known (for the most part, there is always the exception to the rule) they are too busy playing the game, and experiencing their own stories. The vocal userbase is more often than not those that are unhappy, and with DayZ (aside from the time it takes to develop the title) you can frequently see the vocal masses pipe up when the title gets too difficult (see: 0.55). This is where our strong commitment to game modification (modding) comes into play. The decision to "hand the keys to the kingdom" over to the DayZ community once the base game and engine are at a point of stability allows us to do our best to stay firm to what DayZ is, and do our best to keep it difficult without having to make those types of users feel ignored and neglected. A good portion of the userbase has expressed concern about this - citing the fractured userbase of DayZ Mod once the binaries (or hell even the old Hive.dll) made it out into the public ecosystem. Mods such as Lingor, Namalsk, Taviana, Epoch and many others certainly did split the userbase up. There is no denying that - but there is also something to be aware of, a lesson I'm sure many of my favorite game developers when I was younger had to learn (see titles such as Ultima Online, Shadowbane, Asheron's Call, etc). You can't force people to play the way you want them to. You can design the path to go the direction you want, and iterate upon it, and refine it time and time again - but given enough time, people (life, heh heh) WILL find a way (around it). Not to mention the fact that the industry, and the ecosystem in this genre is already large, and only growing larger. If you don't give people the option or the tools to play how they want to - they WILL find another experience that does. In the end, you have to get ahead of the bull - so to speak. So that leaves us with a few key points. - Keep the experience as punishing as you can while maintaining the core gameplay loop. - Do your absolute best to ensure that the users are combating the environment, the antagonists, the struggle for survival - and NEVER the gatekeepers to those areas. (UI, Usability, etc) - Provide the community with the tools they need to take the work we the developers have done, and craft it to their own style of experiences. - Continue to iterate upon the base game past 1.0 - keep it fresh and compelling, like watering a beautiful house plant you do your best to keep the base game community thriving and interested. I apologize if I've rambled - I like to sit down and type out my thoughts at times to let you all see a bit behind the curtain.

Hey guys, I wanted to sit down this evening and go over a few thoughts I was having in regards to publicly viewed roadmaps, developer stated goals, and things along these lines (anything projected release based). Obviously - everyone involved, be it developer or consumer goes through the experience of gnashing of teeth when things come up that change, or in general push these back. We've tried annual roadmaps, quarterly goal roadmaps, we've tried heavily disclaimered target goals for a build - but in the end, it always ends up with one of us - the community around DayZ's development frustrated. One of the great opportunities of allowing folks access to the development via Early Access is that we can experiment, see how things work, and change them up. Usually this is restricted to gameplay, and infrastructure - but it can also extend to how we interact with the community and discuss/release information. Most folks might not know that as we move from one version to another (the two digit value before a build number . eg - 0.59.######) the leads from Prague and Bratislava spend a day and a half meeting, planning, and discussing what are target features and changes are for the next version. What we're going to do moving forward is take that information, and bring you guys - the players - into our "milestone goals" for the version that happens to be being worked on at the time. So we're looking at the following: Compile a master list of our intended major feature set for 1.0 At the first Status Report after the Leads Meeting include a list of our milestone goals for the next version Each subsequent Status Report include a break down of our progress towards completing the milestone Per Major Feature Any major bugs we are tackling at the time Once said version (milestone) is moved to Stable branch include a break down of what milestone goals we hit AND what goals were pushed (and why) We're hoping this will increase visibility into what our immediate goals are, and remove some of the speculation - as well as let you guys understand a bit more about what is going on "under the hood" at DayZ.

No - it is not in "early funding" - Bohemia Interactive did not go to Early Access to fund DayZ's development. Our budget is not reflected based upon sales, and the company did not need sales to fund it. Early Access was, is, and will remain an opportunity for people to get access to the title while it is being developed - at a discounted price that slowly increases as we move towards the release game, and release price. That is it. Steam sales, and DayZ's budget are not married in any way.

Not sure which thread to reply to buuuuuuuuuut - select fire modes are coming, in time.

And don't let me catch you putting the work ethic of the developers in question again, Tigermonk.

Let me stop you there. DayZ is not a crowd funded title, and it never has been. You're thinking of kickstarter titles. DayZ is not dependent on sales from Early Access to fund itself, and it never has been.

Then you've never listened to me. Lets keep the topic about DayZ, and not trying to "read between the lines" on the tone of my voice. Its just plain silly.

Not sure if this in jest or not - might be an interesting idea to try out for a mod - but Fast Travel will *never* be in the base game of DayZ, ever.

And thats just it - really. The stats show a general list of things your character has done, and while *you* might not like that playstyle - some do, and it is just as valid as living in the woods.

I saw a few tweets and comments being a bit confused about some of the dependencies - so: New Animation System < New Player Controller < All those things I listed waiting on it

That should be resolved by launch - and is obviously just a low priority bug right now ;)

Nah - its just a 3 month old test. Rerun it now.