Hicks_206 (DayZ)

Well, explosions themselves are tied to the damage system and not the engine. That said, the gameplay programming team does have plans to improve explosions with the new damage system.

Wow, thanks man. Didn't expect to see this - I'll pass the kind words off to the team. <3

Not a departure at all. As I've said before - and in the Status Report, a massive amount of work has been done over the Early Access period that is dependant upon these new systems. While there is of course risk and expected bugs, issues, etc that come with plugging these in fully and implementing them in multiplayer. That said, what you're not going to see here is forecasting milestone goals several builds in advance. Our process is established, and we speak about the current milestone goals, and the next milestone goals. However, what I said is the current plan. 0.62 is planned to be a visual overhaul of Chernarus that a small splinter team is focusing on while ... Beta is our next milestone goal that the primary bulk of the DayZ team is focused on past 0.61. It is important to understand that the Beta milestone does not equal the departure from Early Access. However, once that milestone is reached - we do plan on seeing the majority of our resources switch from feature development to bug fixing, optimization, and so on.

Parking the car in the tent has no impact on its count against server limits. Vehicle limits are finite, just like in DayZ Mod. To elaborate on this a bit: There will always be a finite amount of vehicles on the server, just like there will be a finite amount of loot. Technical reasons aside, the core pillars of DayZ *require* there to be a limited amount of supplies, ammo, etc - both to hold up the survival element of the game, and cause users to have to weigh serious decisions. Risk, expending supplies when making a decision, and so on. That said, more vehicles is a must - exactly how much more vs player count and so on remains to be seen vs optimization in beta.

Maybe DayZ isn't the experience you are looking for. Perhaps a Wasteland mod for Arma, or another game in the genre that takes a different approach? There is nothing wrong with that, but for informative purposes let me give you a bit of detail in what the base DayZ experience is intended to be. - You should struggle to survive, meaning there should in many situations not be enough supplies to go around through just traditional looting, - Methods such as horticulture, foraging for berries and apples, fishing, hunting, trapping are all vital areas to the survival puzzle - Encountering another player or engaging an infected with a firearm should not simply be a matter of "Can I kill this target", the availability of supplies should cause you to have to seriously consider if a lethal engagement is worth the amount of ammo you will expend. Its pretty late night, and there is a chance I have rambled - if so, I apologize. Keep in mind, from day one we have recognized that it might not be the game for everyone - as so many people came from less stressful or difficult varations of DayZ Mod (Epoch, Overwatch, Origins, etc), and soft modding, server files, and steam workshop modding will allow users to create that type of experience on their community servers should they choose.

For some reason I keep having to say this - in Status Reports, Tweets, and forum posts. Loot in player storage and player inventories do not count against the server totals.

I'm not quite sure what you're asking here. We don't do dates, and have not for some time - you know this.

I spoke with Fido (Lead Enfusion Programmer) this morning about this - the current video memory usage limit is defined by the 32 bit client. In the future, we fully intend to support (and is required for the offline play mode) a 64 bit client, and thus an increase in configurable video memory usage. As far as textures go, don't worry about that - as Fido says "Texture resolution in DayZ is high enough that all the visible textures would never fit into vram all together, and thus we stream the best mip-maps of textures on demand".

The subject of improving the melee fighting system is one that has come up internally a lot lately as internal engine development pushes forward on the new anim system and related areas. While we don't talk "when" past the current and next builds - We all understand how the current functionality of it can come up short. Next week I'll try and put together some thoughts from Peter and I (and potentially Viktor) if things are ready to be talked about.

Apologies Azeh - Eugen has been pretty busy, but I'll keep pestering him!

Shoot an email to [email protected] and hopefully Smoss can get you going again!

The debug monitor reports your current position in raw coordinate data, which is massively more valuable than GPS (which is only grid coordinates)

Hey Cyrus - that is by design unfortunately. After some changes to how the central economy works for that version - we noticed that we no longer had control over quantity in dynamic event spawns (past the points, obv) so we temporarily moved the weapons that spawned there to regular military structures. This is temporary, until the Central Economy offers us that control.

You're welcome to express your opinion here Just. There is nothing with your post that would get it sent to the graveyard .. with the exception of implying the developers are "lazy as fuck" - keep your criticism constructive and yourself open to discussion and you'll have no problem. Couple things though - We're not a AAA title, nor is Bohemia a AAA studio. (Although I appreciate the implication from both :) ). Additionally, as someone below mentioned - build numbers do not equal the amount of builds required to get to 1.0. It is merely a numerical byproduct of the build process that allows us to keep track of, and organize builds. To give you an example, I believe we hit Steam with .. 0.28?

Fair question Azeh - and before I head to bed I'll try and give some perspective. At the point we're at with development, we're effectively nearing merge time for the major engine modules that have been worked on. You saw it with the new renderer, and will be seeing it to a much smaller degree with the audio technology (0.61) moved over from the awesome dudes working on Arma - and currently the engine team are all cracking away on things such as physics, and the new animation system (which represents a blocker for a very large amount of content and overall changes to how the base game plays). Getting closer to (and the time approaching where we are now) these Enfusion changes being merged into DayZ's main trunk means that implementing changes in legacy SQF (which will die a horrible death with the merge to Enforce Script), or on the old animation system, hierarchy, and so on is a waste of development time - and will only serve to slow the project down even more. We (and I) completely understand how it can seem like nothing is happening while this stuff is being done - and completely understand how frustrating that is. Personally, I apologize for the frustration - but there is nothing that can be done about it, aside from us on the development team putting heads down and moving full steam ahead. To give you a little perspective on the other side of the fence, it can be frustrating for a designer (for example) to be presented with spending a good amount of time investigating a non game breaking issue in SQF, when that designer knows that absolutely all of that script/system will (and is being) be rewritten in the new scripting language. It could also be incredibly frustrating for that designer if Eugen or I were to go to Peter (our Design Lead) and push him to implement a new system (lets say.. soft skills) in the old language and hierarchy in *addition* to the new language, and get it to a stable enough point on SQF that it is functional for the users on Steam. Essentially, any further work that is put into new features or support on old technology (animation, scripting, etc) is work that while enjoyable for those testing on Steam - is ultimately work that gets us no closer to (and slows us down on the path towards) the final product. As far as why some smaller things don't get pushed sooner, like the server browser - Sometimes it is a matter of dependencies, like I mentioned earlier. Other times its as simple as not overcomplicating the build and testing pipeline. You can only branch so many times before you make your pipeline over complicated, and cumbersome to deal with. (Not to mention tracking down any issues within said pipeline). I hope my late night ramblings answer some of your questions - if not, I'll be back on the forums in the morning to try and make sense of it. Infact - I will try and pester Eugen tomorrow to jump in on this thread, as the pipeline and update scheduling is a large portion of his job.

There really is no compelling reason, besides trying to ensure you are joining an *empty* server to show the player count. We're not looking to allow folks to meta game player count in order to ensure a reduced, or even single player experience. We *will* support an offline type mode, which we have detailed before - but the base game of DayZ should be one of risk at all times. That said, allowing users to see the population density is a happy medium - and one a lot of larger MMO style titles use. After discussing with Peter earlier this week, we both agree that we should at the very least allow people to see the maximum server population as we support varied player numbers. In the end, keep in mind it is not final - and we keep an eye on feedback over on the forums. :)

True - we're not fully over onto said bullet library at the current state. Some areas of the game still use legacy physics. Trust me, I understand how frustrating it can be dealing with the issues caused by this, but it really is just a bump on the road towards a much more enjoyable experience at 1.0. :)

It is entirely possible given fluxuating server conditions on the game server you happened to be on at the time, on 0.60. Part of the issues we are trying to address in 0.61 is directly related to problems such as this, by way of server performance. Don't get *too excited* - as while we're all focused on improving server performance - we won't likely hit our targeted server perf goal until we're into beta, as spending too much time on optimization prior to that would be a waste of time.

It looks like you're hunting for something you can hold on to as a time estimate or projection - which we do not do. That said, the primary blockers from experimental are the issues I mention in the Status Report as our current focus. Player to player synchronization, and server side performance. It is critical you keep in mind the fact that experimentals primary purpose is not for "goodies" and "gameplay" - it is there as an absolute critical testing phase before hitting Stable branch. This is why it is often down, this is why it has frequent character and storage wipes - and when we have the issues we currently are working on resolving (Player 2 Player sync, Server perf) the gain we might get from pushing an unready build to that branch is significantly outweighed by the potential issues with significant noise to signal ratio from bugs being filed against systems not broken themselves, but dependant upon those two areas, and maintaining two different game and servlet versions within the same branch. I know it sucks, but patience is what is called for here. We're all working our asses off and are excited to get .61 onto experimental and stable so we can starting talking about and focusing on .62,

You're definitely correct - and if I didnt mention previously that the server browser we will see in .61 is not the finished version, that is my bad! The separation of Official from Community servers into their own tabs for example, is not there yet. There are a few filter options that will need to be added, and some cosmetic changes to the UI and UX that Peter and I have mentioned. However, at a base level you can see the direction we are going. Things like making player count not precise and instead talking population density, not giving specific time of day values and instead opting for Day/Night/etc. Initially the server browser was not going to be a .61 thing, but Eugen made the decision mid way through work on .61 to push its arrival up in order to combat issues with client side FPS and responsiveness in the old server browser - and while I wasn't thrilled with our work going out early, it makes perfect sense and is the right call in the end.

We are functionally done, yes - no new work is being added to .61, at this time we are locked into bug bashing. Player position hitching when navigating collision means the players position within a given structure is stuttering when encountering new collision geometry in a structure (props like tables, chairs, etc) - This is not alltogether unexpected - as the changes to player synchronization can and do have a large impact on how a lot of the network communication between client and server operate. This likely is just how this first major change to player network sync handles collision, regardless - it absolutely has to be improved. No one wants to deal with a sudden stutter or pinball effect when trying to run quickly around inside a building during high stress moments. The good news is we have made a lot of big improvements on this issue over the last two weeks - we're not to the level in which it is ready for stable, but definitely big improvements for sure.

Woah there guys, lets keep it civil.

Well, to be honest it is because when the server and hive dll package for DayZ mod got out there - it began the slow march towards the death of the original DayZ experience. I remember it well, hell - I even was part of the team that put out one of those mods. While the mod I worked with only sought to expand the gameplay options of DayZ mod without changing the gameplay mechanics - plenty of other mods came after it that completely erased the hardcore survival side of DayZ. Easily found automatic weapons everywhere, selectable player spawns, protected player storage, combat free safezones, and so much more became the norm and what a lot of people define as "DayZ" - and for those of us that loved DayZ Mod for what it originally was, it meant the slow death of that vanilla population. I've always compared it to what happened to Ultima Online once Everquest hit the market.

While I understand this fear - I hope you understand that modding is a core pillar of what DayZ is, and we cannot deny it. While we have stated that we will use Steam Workshop, and thus can curate what mods are on the marketplace - the PC is an open platform, and even without Steam Workshop people will find a way to mod what they want. Trying to force people into one set way to play the title just isn't who Bohemia is. Trust me - I completely share your love for a hardcore, punishing survival experience (and it is that type of experience that gets my brain racing with ideas) - it might not be what everyone wants. DayZ is a lot of things, to a lot of people - because of the fact that we are careful to not define one "right way" to play the game. So, at the very least - rest assured knowing that our vision for the title is one of a hardcore survival experience, and we as developers will do the best to make sure that is supported and the first experience someone has with DayZ well past 1.0.

UI Elements do not safely add to the difficulty in the game. You should never fight against understanding the UI or getting critical data from it. The difficulty should come from the environment, and the struggles within it. Never from trying to understand or navigate the data you are provided.