Devblog 93

Click play for atmosphere. I’ve spent some time testing/tuning the dynamic music arrangement system and started work on another piece of music which has more of a lazy, melancholy vibe than the other music we’ve shown so far. I think this one’s a good candidate for a home theme (which would play when you’ve got building privilege) or a daytime, rainy weather theme. The project files for this are set up to make it easy to pull pieces for our dynamic arrangement system and easily test how transitions from one intensity level/section to another sound, but it’s not really designed to be played back as a linear song right now. I’ve thrown a few of the pieces together back to back quickly for this preview though since I figured you guys would rather hear a tossed together arrangement than nothing at all :)

Lots of new bugs to talk about. Lots of crashing and freezing. I'm told that Unity updated FMod (the sound engine) and it's caused all kinds of hell. We haven't got a patch for this yet. Misaligned loot panels. Unity's UI is erroring out at weird times. I've got a bug submitted with Unity. As usual it looks like they're not going to do anything until we deliver a minimal reproducible project, so we haven't got a patch for this yet. UI font corruption. A bug in Unity's UI system is causing the UI to sometimes become corrupt until it's re-layed out. I've given Unity some Rust keys and shown them how to re-create it (by scrolling the server list). We haven't got a patch for this yet. Screen resolution UI stretching. A bug in Unity's UI system. They released a patch that is meant to fix it today - but we haven't had time to test it so didn't want to update yet. Will test over the next week. Updating Unity is like running through a minefield full of puppies. We'll probably get into a situation where we don't change the Unity version on the staging branch as often as on the production branch - just so we can be sure that anything like this gets fixed before we ship.

There was a problem with the skin colour system: there were hardly any white people. I tweaked the player skin colours so that instead of the different shades of brown, people are generally black or white. There are still mid-shades but they're a lot rarer than they were. This means you might have changed colour in-game.

We saw our huge player numbers last week. The highest player numbers since February 2014, so I threw a bunch more official servers up. Most locations now host 3 servers - a 4k procedural, 2k procedural, and Hapis Island. We also started hosting Intoxicated's Battle Royale servers officially, which I would encourage you to check out if you haven't already. Our intention is to better support modding, and we're hoping that working more closely with bawNg will be a good way to facilitate that.

I did some stuff for a different game we’re working on. Before you lose your shit about how I’m not using every waking minute on Rust, I did all of this on my own time over the weekend/Christmas holidays, and everything I worked on will benefit Rust as well, which is why I’m writing about it here. To throw out a few buzzwords, the biggest improvements will be directional occlusion for our aerial perspective image effect, better altitude based fog density and improved cloud shading. I’m hoping to get them to the staging branch early next week.

The female character is nearing completion now. The face is finished and you can see the final result below. Here's a comparison to the old one. She's in-game too, skinned to the male rig, although the implementation is a little rough still. After a little clean-up I'll go back to adapting the clothing sets to the reworked models.

There's a few magic keys in Rust that admins and developers use. If you press Right Shift and P you get a debug camera and can fly around. If you press Right Shift and L you go into no-clip mode and can fly around. Until now these have been hard-coded to these keys, which is kind of stupid now we have a binding system, so I've moved them to console commands. This doesn't mean you need to go into the console every time you want to use them. You can bind them to keys. So just open the console and type in "bind p debugcamera", and "bind l noclip" and you're back to the old config without having to press Right Shift. You can set it to whichever key you want. Don't forget to type "writecfg" if you want your changes saved so you don't have to bind every time.

I’m adding train tracks and road art in this update. It’s a first iteration, and textures and meshes might need polish here and there over time, but at the current stage in dungeons progress it will do the job just fine.

Steam has a built-in protocol so you can click a link on a webpage and it opens the game and connects to the server. Up until now we haven't been set up to use it. I implemented it this week, so you should be able to connect to the Battle Royale server by clicking this link.

I finally finished up this client-side rendering optimization, which involved a few more changes than I initially anticipated. Batching is the process of combining multiple smaller objects into a single big object in order to make it faster to render. Unity comes with two ways of doing this by default - static batching and dynamic batching - but neither really works for us since we have fairly high poly meshes, like buildings that are placed dynamically at runtime. We used to do custom batching for a select few of our lowest poly LODs and shadow casting geometry, but it was awkward to set up and only worked for fairly specific cases. This new and improved version is very generic, works for nearly any object and is easy to set up without sacrificing performance. Okay so now why should you care about this. It’s difficult to benchmark this sort of thing reliably since if you create some abstract test scene it won’t really be representative for what’s happening on a server and tends to overestimate the impact of an optimization. It also hugely depends on your hardware. That being said, I have tested a couple of areas from actual server save games and seen improvements of multiple milliseconds per frame near the bigger player-made structures on my machine. We’ll add this new system to more and more objects over the coming weeks as part of a bigger effort to improve performance, particularly around the loot areas.

We had skin running in the deferred path before. However, it didn't have any subsurface scattering or any skin-specific feature. I was able to cram more information in deferred mode in order to support these features properly. Performance should be slightly improved now around areas with many lights. The following shot shows our progress from basic shader in deferred mode (left), basic skin with subsurface scattering in forward mode (middle) and second stage skin in deferred mode (right). Last one features curvature scaling for transmission and softer subsurface normal: I also fixed an ambient lighting issue that was causing skin to look darker than it should.

We added the semi-auto rifle today! It's a mid-tier weapon with good accuracy and damage, and should fill the gap between the jump to AK/bolt. It's a little more common, and it takes metal fragments instead of high quality metal to craft. I'm sure we will need to do a balance patch on it, so let us know how much it sucks/rocks

Something we hear over and over again is that admins are spawning stuff on their servers and making the game unfair. Sometimes admins have a good reason to spawn something, but most of the time they're just abusing their power on the server to make the game easier for themselves. So now when an admin spawns an item for themselves (or another player) it will be announced to the entire server in the chat box. I know this isn't going to go down well with server owners. They'll claim they need to be able to spawn 100 C4 for their regular admin duties. Well that's okay. If it's legit you have nothing to hide from your server's users.

Paul and I have been mulling over which weapon I should tackle next. I really liked the idea of the new bow, but we don’t have any finalised concept art for that just yet. So instead I started tackling the flamethrower. Concept art can be seen here. Modelling the various elements of the concept I realised that the fuel handle wasn’t based off anything real. We looked at some real-world examples of fuel pump grips and decided to swap it for this. I think the concept is pretty bad-ass and I can’t wait to finish it and get it in game. Here’s the progress on the high-poly so far. It’s essentially finished, with one or two small things to adjust, but I’m already doing the low-poly of it. Hopefully going to bang out the unwrap and start the materials by next week!

Here’s the thing: The damage weapons do in Rust feels far too random and unpredictable. You should know that when you hit someone with an AK 4 times he’s dead. You also shouldn’t get 10 hit indicators on your enemy just to see the him continue to run around like it’s the best day of his life. We reconsidered the way things are working right now and started to make some major changes. The body part damage multipliers are now more uniform such that when you hit someone X amount of times with a certain weapon you’re guaranteed to have killed him rather than piling up hits that barely did any damage. Contributing to this we disabled projectile penetration on player body parts since more often than not these were triggered by random animations anyhow, which again made things feel like a slot machine. Hits on players will now always stop a bullet, but your bullets can of course still penetrate through wooden barricades and stuff.

Our amazing testers found a bug that could mess things up pretty badly when disconnecting from a server during the loading screen. This could potentially be used as an exploit, and it most definitely caused some weird behaviour for some people when they inadvertently ran into it. A bunch of errors in our remote error reporting tool also seem to have been caused by this bug, so having it out of the way will finally get rid of a few error reports that up to this point didn’t make a lot of sense to us.

I haven't been very happy with the SSAO options available on the Asset Store so, as an fun side project, I decided to give a stab at a new implementation on my free time. It's based on industry-standard SSAO techniques. I started this project a few weeks ago and it eventually evolved into a full blown, solid implementation. It fixes a lot of issues we were having have with, pretty much, all of our other options. From artefacts to radius limitations and performance. Before, we had to choose between quality and performance and this technique scales well to higher resolutions and larger sampling radius, so finally we can get both. These are before (left), and after (right), shots of a third person perspective. In these close up shots I increased radius and intensity a bit, in comparison to before without artefacts: One of the most serious issues we were having with the previous implementation was a darkening artefact caused by precision issues. That's gone. We now can increase radius quite a bit too.