Shared by SepticFalcon on March 30, 2016

Evening Survivors,

It’s time for that update on what’s been going on during the past two weeks. We have a bit of info on blocker issues for 0.60 as well as which subjects will be in focus for the immediate future.

Dev Update: B. Hicks

Hey everyone. While I don’t have an experimental build for you today – I do have good news and an update on what is going on with the blockers, how far we’ve got with them, and so on:

Inventory UI
User controls within the new inventory look to be at parity with the old inventory system. The last few remaining issues are a few nasty blocking bugs on the functional side, such as items missing their icons.

Reload mechanics
The QA team have worked with the design and animation teams to get a firm handle on exactly where the inconsistencies are with the new reload mechanics, and said teams are working on resolving the issue. I think we can all agree that when we push a large change to how weapons reload – they damn better all reload with the same mechanics 😉

Character Loading/Saving
Proper character loading/saving is back, and in the process some nice network optimizations in this area were made!

Renderer based blocking issues

  • We’ve cut the list of blocker flagged issues tied to the new Enfusion renderer in half since the last time we talked – and in the time since our last Status Report the Enfusion engine team has made some outstanding optimizations across Chernarus – which you can see the result of in the latest .60 Dev Log video that you see below.
  • In addition, while the Enfusion engine team was able to commit and test their latest optimizations, the automated performance benchmarking tool briefly discussed in the latest .60 Dev Log video has enabled the environment team to begin to isolate problematic issues with certain areas of the map that would not otherwise be noticed. We’re excited to see these fixes give us yet another small bump up in Enfusion’s new renderer performance.

What to expect?
As we get closer to bringing .60 to experimental branch, I lightly urge you all to temper your excitement with a few brief statements of reality about public development of a title, and its engine:

  • 0.60 is focused on UI, and Renderer – it does not feature the new animation system, player controller, or user actions
  • We still have plenty of issues ahead of us to tackle, the renderer is but one hurdle on the road to a complete DayZ
  • Network Optimizations, Server Performance Optimization (This is a big one, standing between us and more players, more infected, more animals), Animation System, Eden Update Audio Tech merge, and more are all ahead of us

So I encourage you to keep your eye on the proverbial prize here and report your bugs over on the official DayZ forums, be active in testing these new technology changes, and be a part of moving DayZ towards 1.0.

Before I wrap up my part for this Status Report, I’d like to include an excerpt from a post I made over on the official forums – that I think a lot of you might have missed:

I frequently get asked why a specific bug might not be resolved yet, or why something hasn’t been addressed yet in development that from a players perspective might seem critical.
There are a lot of things to take into consideration in development when weighing a bugfix, not to mention when you’re dealing with a title transitioning from one engine, to another one that is *in development* Lets take a quick look into a brief break down of how the thought process goes:

– First off – what is the risk of this fix at the current time?

  • What are the goals for the upcoming build? Does this potentially represent larger issues that will push the build back?
  • Is this issue tied to a technology that is going to be replaced?
  • For example – Is this an issue tied with the legacy renderer?
  • Is this issue related to ongoing investigation of a larger issue with wider sweeping impact?
  • If this issue IS tied to a system scheduled to be rewritten – what is the estimated time for:
  • Work resolving the issue itself
  • Test pass on the issue
  • Overall BVT test pass to ensure related issues are not encountered
  • Regression testing on the issue
  • A lot of issues consumers see in the way of:
  • Duplicating (Old action system)
  • Glitching into models
  • Damage / Projectile cheats
  • Balancing / etc

Are all things that are slated to be resolved, or at least mitigated with new technologies that are being worked on *right now* – so the hard decision has to be made – Do we potentially waste valuable development time and resources on something that will *not* end up in the shipped title? Honestly – we try to do that as little as possible.

We still end up going a very large amount of it to try and keep the consumer steam branches as playable as possible, but frequently the unpopular and hard decision has to be made to stay the course, and dedicated those resources towards the final product / final systems / final technology.

Dev Update: P. Nespesny

I’ll continue were I left off in my last Status Report entry and write a bit about the planned changes to the systems and functionality tied to such mechanics as attachments, crafting or the quick bar. As I said few times already I want to see DayZ’s gameplay as much physicality as possible and controls as less obstructive as possible.

One of the problems we are facing is a quite non readable agenda or to say it better, limits of the game that we set – what can be done or achieved and how all these various mechanics work, coupled with a rather chaotic approach to the usage of these systems, it leads in most cases to force players to visit community wikis and find out there. Of course in the past with the dawn of the original DayZ mod it was really refreshing and stunning to find out all the obfuscated in-game mechanics by yourself or learn them directly in-game from other survivors and at the end it contributed to creating one of the most beautiful game communities out of these shared experiences. It was one of the key points of mod success without any doubt, even when it was a virtue of necessity in the light how it all began and was made. However do we still need to keep the same approach after such time, where most of the orthodox players already known everything and new players came to the game mainly for all sort of experiences and stories they seen or heard about? If this is what we are offering to the players – experiences and stories – then we should not stay in their way.

We decided to unveil how things work with addition of meaningful assistance especially in the inventory side. You will find ghosts/silhouette placeholders for all possible attachments that can be attached to systems like player character, weapons, vehicles, constructions, fireplaces, etc. Of course it can ignite pursuit for “filling those spots” notably for completionist style players. On the other hand it will help to orientate what is possible and what isn’t as in reality you know that you can definitely can put a second rifle around your neck but you can’t in game, so instead of trying by yourself it’s better to be told straight that these are the cards to play with instead of trying all the possible combinations to find proper one like in old school point and click adventures (which I love, to be clear).

With the possibility to add and remove all attachments within the inventory screen and with the need of securing some of them with tools in mind comes a secured/unsecured icon – think of vehicle wheels which you can attach to the hub but you need to fasten them with lug wrench for proper functionality or they will simply fall off during the drive or nail down the planks to make a fence from simple frame. With this locking of attachments via user actions it comes hand in hand need of the unreachable functionality for attachments, again think of how visually unpleasant it will be to teleport wheels to front hubs of bus standing at very different side or by its back, this will get you to the right spot if you want it to drag and drop it from inventory instead using direct in-game attach user action. To quickly mention some other aids for convenient usage, we plan to introduce lighting bolt icon for electricity system to clearly overview if object it’s plugged in/under current or needed amount of some specific item to be able to turn it into desired state like number of planks to barricade the doors.

Crafting is another important part of the game and it is critical to bring it out to the light from the darkness of the inventory screen. Intended plans for field crafting changes is that it always needs to be initiated from the hands with the one of the two required ingredients for said recipe. Combining wooden sticks with rags is a good example. Crafting can be initiated in different ways, solely in inventory by putting let’s say rags to hands and drag and drop wooden sticks on them from vicinity or cargo, second possible approach is a bit of a shortcut when you have let’s say wooden sticks already in hands and rags set in some quick slot and pressing this quick slot number to invoke the crafting recipe, or the last way is with direct interaction with the item in the world by pointing rags in hands onto sticks gathered from bush.

All of these options of crafting initialization let you to choose how you want to craft directly in the world instead of the inventory, in that case a torch, splint or fireplace and by holding the right mouse button craft it the same as you would use a canteen to continuously drink from. Some of the positives of this approach is that it eliminates automatic removal of previous item in hands so you don’t suddenly loose your precious double carried item, adding tangibility and actual feel to execution of crafting actions or the possibility to walk during some crafting actions like opening cans or feeding magazines with cartridges. Additionally feeding a magazine will be a continuous action, the same as feeding the internal magazine of a gun which takes some time, one by one cartridge loading as long as you perform that feeding action which leads to a much more believable tension with planning ahead and tactical approach instead of that game where the fastest fingers win the crucial situations. At the end of the day the advantage of magazines lays in how many rounds you can fire with the current set without manipulating too much with the weapon or magazine instead of making nearly endless stream of fire with juggling with just two mags and ammo piles. (Keep in mind, we aren’t going for 1:1 realism – obviously in a video game, round by round loading will be a bit faster than in real life).

As in the good tradition of DayZ all new changes will have visual feedback to players like attaching something to gun, picking item from ground, dropping it, feeding the magazine or crafting something. Everything should be readable by other survivors to make it clear what’s going on and to be able to react on your performed actions which can offer time windows to take advantage of. All these changes will shift how DayZ is played a bit but I truly believe these they are introduced for a good reason and help to form a higher principle.

Nothing should stand between you and your stories… see you in Chernarus folks!

Dev Update: V. Kostik

We are now focused on adding missing animations for vehicles. For the new animation system we have been adding some offset poses to allow player to look around inside the vehicle and also changing slightly how steering wheel looks to allow animating shift gear in the future.

Obviously never ending work on guns is still in progress. That means we are adding chambering animations for more guns and polishing existing reloading anims. The player graph now containes some new actions like animation for emptying bottle. Some more wounded moves have been created. The bow and pistols now have the same set as rifle – standing walk and run.

I am also planning next mocap session to capture some animations for operating the vehicles like engine repairing or attaching doors and wheels. More wounded anims are also on mocap list so we can continue on this feature.

DayZ Trello:
Report Exploit/Bug Here: