Devblog 177

The new chair mechanic is almost in, and boy is it a whopper! People have been complaining about progression for a long time, so I figured I'd address it ASAP in the most logical way possible. For every three hours you sit in a chair in game you will receive a -1s bonus to crafting. In all seriousness, I spent a few hours this week and did a little bit of work that needed to be done and will help us make vehicles in the future, and help modders right now. Basically I did the beginnings of a mounting system. Right now you can sit in a chair and that's about the extent of it, but hopefully this will help the guys at The Horde and Intoxicated with their drivable vehicles and parachutes! P.S. This feature is currently disabled in case of any exploits.

I added some tooltips to the information panels that should help describe exactly what each stat means. I also fixed a weird bug where tooltips would sometimes get stuck.

If you got within the range of an autoturret, it would be able to track and target you for range + 25%. This presented itself as a bug rather than a feature, so I've removed it. The turret's range is its range and nothing beyond that any more, so it won't keep targeting you beyond its max targeting range.

I continued with my work this week to add information panels to all the items that require it. I managed to complete the medical and the consumable portions this week. In addition to this, I went through and rebalanced how burnt/raw food works. All raw food will now poison you, but still has a caloric value so it can be used for fishing and/or so animals will be baited by it. Burnt food is no longer poisonous, but instead will yield 1/4 the effects of properly cooked food. Next week I should be complete with this and can keep on keeping on with the roadmap. I think after I'm comfortable enough with this and the recoil we should make progression a priority

Vending machines have had their health increased by 25%, but the big news is that when they are destroyed they will no longer drop any of their contents. We'd like to see them a little bit more widely used so by removing any reward from their destruction, hopefully they will be targeted less.

Whoops. The Thompson never had its aimcone reduced to account for the new recoil patterns. This has since been fixed. Sorry about that!

Following the release of the supermarket and the gas station, we've put monument work on hold until we figure out how to make them more interesting for gameplay. As they are now, monuments serve little purpose beyond looting barrels and crates, and that's something that we would like to improve going forwards. The procedural map and biomes were long overdue an overhaul, and I've decided to focus on improving them in the meantime. My goal is to make a series of natural monuments that would be randomly spawned during the map generation process. These will be handcrafted scenes that will be blended with current randomly generetated terrain, giving a nice mixture of random and bespoke areas. They should serve as landmarks, helping people find their way around the map, give a greater degree of visual variety and provide players with unique areas to build on. Most of these natural monuments will be biome specific, so you can expect that each biome will have a distinct look and feel and that building in certain areas will come with some pros and cons. The first monument is a frozen lake and it will only spawn in the ice biome. It will have a few variants, to ensure that the same lake doesn't repeat itself. Going forward, you will see floating icesheets that will expand the playable area into the ocean, as well as new icebergs that will have multiple access points. While the plans for other biomes are still up in the air, some of the areas you might see will include canyons, sand dunes and plateaus in the arid climate, as well as marshes and more natural rock formations in the temperate biome.

Everybody got really frustrated at the "Downloading Skins" step of the loading screen. Since the last round of skin loading optimizations that moved the entire workload to a separate thread made this pretty obsolete, I changed the default behaviour so you immediately join the game and let the skins download in the background. If this is causing problems for you, try limiting the download rate in Steam. You can also switch back to the old behaviour by changing the "skinwarmup" convar to 1.

The last time we tried to upgrade to the new EAC API we had to revert the change as there were some authentication problems when thousands of players tried to connect simultaneously. I've debugged the problem this week and discussed fixes with the team over at EAC. They implemented the necessary SDK improvements and are confident that that the problem is fixed. As a reminder, the API upgrade eliminates the "EAC Disconnected" issue and comes with a number of other improvements. If you run into any problems after the update please contact us immediately to let us know.

I've spent some time looking into hit detection bug reports. Here's an example of a common report we've received: What happened here was that the player got wounded in the line I marked red. Both the "projectile fired" and "projectile hit" messages then reached the server after he got downed, which caused the projectile to be invalidated. If the "projectile fired" message reached the server before the player was wounded the hit would have been valid - but at close range this doesn't really happen as hitscan hit detection is used, which means the projectile hits the target in the exact same frame it was fired, which in this case was after the player had already been wounded. This gives players with good internet connections an advantage - which is to be expected and intended. For the downed player it can seem unfair, but most would agree that's better than giving people with bad internet connections an advantage. To make things worse, it's not really intuitive to see when the player got wounded as the only indicator in the combat log is the fact that the health actually went up to 5 with that particular hit, which is exactly what happens when you are being wounded. To make this better and help you understand what exactly happened in an armed encounter I added "killed" and "wounded" events to the combat log to clearly mark the hit that killed or wounded someone or something. If you have any combat logs from situations you feel treated you unfairly or incorrectly please send them our way so we can investigate.

Ever since we upgraded from Unity 5.6 to 2017 we've been struggling with an issue that's completely out of our control. Non-exclusive mode (default) upscaling from game resolution (e.g. 1920x1080) to a higher desktop resolution (e.g. 2560x1440) results in aliasing artifacts. It causes smaller text to become unreadable and polygon edges to appear choppy. The following image shows what we're getting in Unity 2017 (on the left) and what we need, a simple bilinear filter, on the right: This is obviously a bug and we, along with other developers, have already reported the issue. We're now just waiting for a patch release that solves the problem before upgrading.

After spending most of the week tracking down and fixing bugs, I finally had some time to review lighting and shadowing. One of the reasons why our lighting looked inferior to previous months seemed to be that direct lighting was too strong and shadows too dark. In this update, I addressed both by bringing down the sun light and compensated with more exposure, pushing up ambient lighting. Also halved ambient lighting saturation to make surfaces less blue when in shadow. Generally, it looks softer and less saturated, as seen in the image below: Unfortunately the new skin changes didn't go in this week. However, in preparation for its release next week, I decided to give a stab at fixing the floating shadow problem, which is also the root cause for light leaking across surfaces fully in shadow (e.g. eye lids). This is a problem that affects player rendering in a big way. Please note that this is unrelated to Contact Shadows, although it's one of the problems it attempts to address but doesn't always succeed. I was able to find a workaround that mitigated both of these issues by modifying Unity's built-in shadows. The results look very promising. Players no longer look like they're floating based on their shadow:

Those of you who play on the staging branch might have noticed you were playing as a different character for a couple of hours today. I merged the player model changes in this week, but encountered a couple of issues that I wasn't able to get to the bottom of in time. That's on me, I should have handled the merge sooner to have more time for potential issues. My bad. I'll be doing the merge first thing on Monday, so I'll have more time to spend on the problems before the patch next week.

Last week's solution to connect Navmeshes together caused a crash in Unity, so this week was largely spent finding a way around the problem. Helk came up with a brilliantly obvious solution, to only generate links where we need them, when we need them. Now the crash seems to be circumvented and Navmesh grid connection for NPCs have become a reality. Navmesh grids will give us a lot more flexibility in how our trusty and savage NPCs roam the land. We can more accurately simulate the size of different types of NPCs, allowing smaller NPCs to fit where larger NPCs can't. We can also more efficiently adapt the navigation data to player constructions, and increase or decrease the detail of information in the navigation data based on location and the needs of the NPC at hand. There are still improvements we can make to this system, and it still needs to undergo rigorous testing, but the ground work has been laid and the focus can finally lean more toward NPC behaviour. I also tweaked NPC movement a bit, so that it's affected by how sharply its current direction of movement is compared to where it's trying to go next. This will need a more thorough steering solution to be fully fixed, but it's a start. I also tweaked the behaviour of fleeing.

Woohoo! I finished up the first pass over the sounds for the tank this week and got everything in game. I'm pretty happy with how this all turned out. I think the the main cannon flybys and all the explosions really came together well. I mixed some loud tearing fighter jet sounds with the main cannon flybys, which gave them this really nice roaring bite. I might swap the engine sound out for something with a bit more weight and do one more pass over the tread clacks still. We had been working with a recording of a Bradley that we found because Helk wanted this to really sound like an actual Bradley, but the recording isn't that awesome fidelity-wise. I think we can make it better and still keep it feeling realistic if we build something new from better source material. I'm going to have a go at beefing up the recording we're using now some more, and then look in to making something new if I can't get that sounding right.

I thought I'd sorted a performance related bug around bases with lots of auto turrets last week. I wasn't able to reproduce it so I wasn't totally sure, but it turns out I only alleviated the symptoms a little bit. I managed to reproduce the issue this week and fixed it properly, so bases with massive amouts of autoturrets shouldn't impact performance as much anymore.

This week I've been working on improving some of the special fx for the various weapons (muzzle flashes/shell ejections). I also got around to adding some dirt/smoke effects that get created when the APC drives over terrain. I've also been continuing to do minor tweaks to various player animations that looked a bit rough around the edges.