Devblog 163

Here's Shadowfrax!

I played a bunch of CombatTag on the weekend and found some pretty weak stats on some guns. I mainly noticed it on the AK47 and Semi Auto Rifle. I couldn't hit anything no matter how hard I tried. It was super annoying to have the iron-sight directly on someone, sustained, and have all misses. It was hard for me to come to this conclusion prior to patching last week as I was testing against reactive targets. Since then I have programmed a very rudimentary CPU controlled "Bot" which just runs around randomly. This gives me a nice moving target that can wear any armor and really helps me with the balance. To that end, I've added a weighting system to the aimcones for full auto weapons (as well as the SAR). This means that some of the shots are more likely to land in the center rather than a completely arbitary position anywhere in the maximum aimcone during full auto fire. This seems to bring it more in line with other first person shooters, and I hope this is a welcome change. It may need balancing, so please test it out and let me know how you guys feel. I also fixed a bug where aimcones were being calculated as a sphere under some circumstances instead of a circle (meaning some information was lost and aimcones were slightly more random than they should have been) In addition to this modification, I've made some balance changes to weapons. Most importantly, the AK47 has had its maximum aimcone reduced, but its horizontal recoil increased (meeting halfway with old style recoil).

Notice anything different? Probably not. But you sure will when you actually go to use shotguns. Before, each shotgun pellet would randomly roll between 0 and the Maximum aimcone to offset its trajectory. This kinda really didn't work, as you can see from the above image. There were random groupings and gaps. You were completely at the mercy of RNG and could be close to point blank and still miss! I fixed this by implementing two distinct features. First, each pellet adds itself at a random point on a concentric circle from the aim point. This leads to a better overall distribution with fewer gaps. Secondly, I've added a weight to the pellets so that the first 20% of pellets are more likely to hit where you are aiming (notice the groupings near the X's in the after shot vs the before shot). Thirdly, I've lowered the maximum effective range of shotguns to about 40m for buckshot and 25m for handmade shells. All this plays nicely together to make shotguns far more viable weapons that actually pack some real punch in their intended rage. You'll be able to aim at and hit people at a decent distance without it being overpowered at long ranges, which is so much better than just having a large aimcone. Give it a try and let me know what you guys think. There is also a slew of other changes made to shotguns and ammo in general (such as half price slugs!) so check out the changelog for everything else.

A few changes were made to the dropbox. I fixed its emission values so it will glow at night. Neither the mailbox nor the dropbox will auto submit items upon closing now. You have to press the submit button. Items will now stack in the dropbox even if submitted seperately. And lastly, items will no longer toss into the world if you submit against a full inventory for drop/mailbox. They will remain in the submit box.

We've been struggling with a number of packet vulnerabilities over the weekend that could bring down a server when exploited. We pushed out several smaller server updates to address those, and the last and hopefully final round of fixes will roll out with today's patch. While investigating these issues we also noticed that the bow would continuously spam the server with packets when aiming it with no arrows in the inventory, which is now fixed as well.

This one has annoyed me for ages. You know how our weapon viewmodels were freaking out when you aimed down sights right after pulling them out? This is now fixed and things are looking pretty smooth, though some weapons will still need some tweaking. While I was at it I also handled some edge cases that could cause weird viewmodel flickering issues when repeatedly hammering the right mouse button.

We started forcing the anisotropic filtering setting as a global minimum for all textures some time ago, but this caused some issues and could even significantly reduce performance when using high anisotropic filtering settings like 8 or 16. I changed it to only use the setting as an upper bound and let the textures decide their individual filtering as needed, which greatly improves performance if you've been playing the game with high anisotropic filtering settings. While I was at it I also optimized the filtering settings on workshop skins to reduce their performance impact.

Unity has added some nice new ways to utilize instancing in 5.6 so I figured I'd check it out. The problem with instancing in Unity is that if you simply let the engine handle it it comes with significant CPU overhead as meshes and materials that can be combined into a single draw call are being retrieved and sorted every single frame. This makes it nearly useless for scenes like ours where we have an enormous amount of meshes and materials present at any given time. The new APIs allow us to keep track of meshes and materials in our own code and hand them over to Unity in a manner where they're already packed together and can go straight to the GPU. I figured a good way to test this out are the deferred decals we're using for bullet impacts, melee hitmarks and footprints. Turns out this new system makes rendering the decals nearly free with only some very slight CPU overhead left to create the command buffer before handing it off to the engine. All the sorting of draw calls by mesh and material is now only done when adding or removing a decal rather than every frame and is therefore extremely efficient.

While implementing instancing for the deferred decals I noticed that quite a few of our structs that are used as keys in dictionaries can cause dynamic memory allocations whenever an element is added or retrieved from the dictionary. To fix this the structs need to explicitly implement the IEquatable interface (simply overriding Equals() will now suffice), which they now do. This eliminates a decent chunk of garbage collections, particularly on the client.

This one has been causing some headaches on both sides of the fence over the past few days. Last week we fixed a bug that was allowing bloom to be disabled via console. This, however, was never intended, as you may notice that the high-quality bloom graphics option simply alternates between low quality and high quality bloom. Gameplay was our initial argument for forcing it on players; we wanted to avoid situations where some players would be blinded by facing the sun while others wouldn't, thus providing some kind of advantage. Bloom is not just about aesthetics in Rust. However, there were quite a few bloom-induced bugs that surfaced last week and were fixed for this update. Please be assured that we'll keep listening and tweaking in order to improve the experience. We might also consider gameplay options to help mitigate the glare caused by the sun.

As part of the revamped shader set we're building, I was able to finish the new hair shader this week. Now I'm now working with artists to try and get the most out of it. It will be used for any type of player hair, including facial and body. Actual art assets will need to be produced and integrated into our current player rendering. This process might take a while. As usual, we'll share the progress as we go.

I spent this week optimizing the buildings and other models I created over the last month. So on that side of things there's no new visuals really. Other than that I have created a checkpoint to create proper points of entry into our monuments. It's something that was visually needed for a while, so there it is. End of this week I will be starting the beautification pass I mentioned last time. We're getting close to where we want to be on this monument now.

For the past few days I've been working on getting the rocket factory to a finished level. I have reworked the scaffolding around the rocket and added rail tracks that beneath its wheels. I tweaked the elevator shafts and added some ladders that will enable you to access some hidden areas. All exterior and interior walls have also been vertex painted to reduce texture repetition, and all minor bugs have been squashed. All in all, the work on the rocket factory is now mostly complete, and all that is left are LOD models, collisions and optimization.

In addition I finished fuel silos that are scattered around the area. The silos have ladder access that will allow you to get to the top and add a bit of vertical gameplay to the area.

Alex and I have been discussing how clothing could be incorporated onto the viewmodels, so I ran a couple of tests to see how it might look by reusing existing models (and, by extension, their skins). I've had to increase the geometry around the wrist so it's appropriate for how close it will be to the camera. There's still a lot to consider, but as far as tests go I think it's looking like we might be able to get an acceptable quality with a bit of work, while still supporting skins.

I finished up a polish pass over all the metallic melee weapon impacts. They're quite a bit cleaner and a little more restrained now (particularly the metal tools), which makes them layer more nicely with the material impacts. I'm pretty happy with how the soft material impacts turned out on most of these. I might re-record a few of the soft hit layers next week to try to soften the initial transient up and let the metal ring a little more though. I've also started recording some material to use to for a pass over the non-metal melee weapons. I continued working on music this week too, and the updates to this are pretty much ready to go out now. I still need to test it on staging in a live server environment, and didn't have a chance to get to do that in time to make the update, but hopefully next week :) There was some construction outside my house the last week or two and I took being woken up early by that as an opportunity to record quite a bit of material, so I've been going through those recordings and pulling out and cleaning up the good bits. These won't end up in game immediately, but they fill some gaps in my sound library and will be useful in the future! I've also made a handful of random sound and mix tweaks, and fixed a bug that caused NPCs to spawn tons of footstep effects if they were moved a long distance in a short period of time.