Devblog 130

I’ve doubled the XP earn rate on main! Enjoy it while it lasts. This should also help everyone to get used to having everything unlocked. Giddy up!

Did someone exclaim 'giddy up'? That seems like the perfect place for me to talk about this week's update.

Some people were exploiting the Autoturret's storage capabilities and hiding weapons and whatnot inside them. Its storage space is restricted to 5.56 ammo now.

I’ve added a recycler item to pre-release. It’s a public works item so you can find it in most radtowns. Basically it will destroy an item and give you a fraction of its components. This will play a large part in the upcoming component system and allow us to spawn very specific items such as propane tanks or tarps, which are only used in a handful of recipes, but allow you to break them down into things like metal or cloth. A video does a better job at explaining the process so check it out: Please note the art was cobbled together by me and is completely placeholder. Check out Paul Bradley's section to see how the real thing will look.

I've been working on a machine that players can use to break items down into raw components. Right away I thought that about the machine that eats anything would be fitting (with a little suspension of disbelief): this thing would basically break down any item fed in from the top and crunch it down into fragments and parts that would collect in a small storage box underneath.

I’ve added a bunch of uncraftable components to pre-release and will be adjusting crafting recipes and drop tables starting tomorrow. I’m planning to work from the low tech tier up and will make sure the progression feels right. This is partly why I introduced the recycler first, so we wouldn’t have to redo it all again later. Please excuse the terrible programmer art icons!

I wrapped up some more optimizations this week. Most of them are related to the player model, collision and name tag instantiation and updating, which means you should see less frame rate drops and performance issues when there are many players around you or entering your networking range.

Ever since visibility culling was added there have been issues with animations having to catch up when a player becomes visible. This was because in Unity animators lose their state when they’re disabled, which is an integral part of this optimization. I added a warmup mechanism to the player model handler that snaps their animation to the current state whenever the animator is switched from disabled to enabled, which takes care of this.

There have been some new hacks trying to slip through the fly hack and jump hack detection by being very careful and only providing small jump boosts when in use. I made those parts of the detection stricter after Alistair tested it on a couple of servers this week, so those hacks should no longer be possible without getting kicked.

Starting with one of the last Unity updates we noticed a physics performance regression on the server whenever batched colliders reached a certain size. The issue only seemed to be a problem on some servers, so I added a new collider_capacity convar that allows server owners to limit the maximum vertex count of pooled mesh colliders. The default value is set to half of what it used to be before we exposed the convar, which should take care of the problem while we’re gathering more info for a bug report to Unity.

There are various things in Rust that rely on using secondary cameras to embed information in render textures. Be it the inventory player preview, large scale occlusion or grass displacement, all of those systems have been affected by significant overhead from those secondary cameras in the past. I tracked down the exact cause for this when I rebooted the grass displacement system and reported the issue to Unity. I’m still discussing the details with them, but I’m hoping we’ll see a fix for this in the nearish future. Getting this fixed would be a huge gain for us.

I made some adjustments to the way the procedural map generation scales down to smaller maps in the 3000 range. Those now also include some of the more interesting inland geographic features of the bigger maps.

There was a regression in the terrain carving triggers that could lead to rubber banding around the outer edges of certain monument tunnel and sewer systems. This is now fixed.

I took care of some water-related low-hanging fruit, most notably the water getting brighter than it should, at a distance. It was causing ocean, river and lake surfaces to stand out from the fog where they should be blending seamlessly. This unwanted visual glitch might have been inadvertently introduced during previous optimizations.

For the last few weeks I've been investing in a few extra graphics cards for maintenance and performance testing. Rust has been running well on NVIDIA GTX 960 onwards but it was time for AMD owners to get some love. This week isn't strong on optimizations, but I did fix a few DX9-related problems that affected AMD R9 and possibly other models (including from other vendors): fixed broken motion blur, broken water reflections and that half-screen darken/brighten issue. If you're looking to run Rust on a AMD card, please don't pick any below a AMD Radeon HD 7970 or AMD Radeon R9 280. Also, please note that my optimization efforts will be focused mostly on AMD R9 380 and above.

I started to pump out more cave layouts this week, adding the occasional missing block to the cave set. So far the plan is:

• Three small caves from easy to difficult Small caves will all have a single entrance/exit. The complexity of the network is memorable. Puzzles are easy and non-deadly (unless you’re really pushing for it). One to two build rooms.
• Three medium caves from easy to difficult Medium caves will have on average two points of entry, some three. Network complexity is harder to memorise. The more difficult layout includes one deadly trap. Puzzles are a notch more difficult. Two to four build rooms.
• Three large caves from average to difficult Large caves will have as many as five points of entry or exit. Some of them will be natural caves, some will be old mining tunnels. Network complexity is a step above all the other caves, a lot of players might live in those caves and not meet all that often. Puzzles are deadlier and longer. Up to eight build rooms.

I decided against creating a large and easy cave because it would likely end up being boring to go through. I can also design the difficult caves to deploy an easy branch early on in the network to balance it out. We’ll be looking into adding drops of basic resources inside all of them, such as wood and ores.

We're considering removing Legacy from Steam. I know, we're dicks, but let me explain the logic here: we have to pay license fees to a couple of middleware companies to keep Legacy available. This amounts to a few thousand dollars a year, which haven't minded paying that for the last few years because we assumed a lot of people were still enjoying it. To be totally blunt, we don't really like these middleware companies, so we would rather not keep paying them. I ran some stats earlier this week to verify that. It turns out that at peak time, once you filter out all the bots and fake players, there's around 200 people playing legacy at one time. That obviously is a very small amount when you consider at peak time Rust gets 20,000 people playing. So I'm posting this to get the feeling from the community. Do you care if we do this? Shall we keep it available for another year, see how people feel then?

We have a lot of Steam specific code in Rust. One of my long term goals is to move that into its own dll. There's two major motivations for this. Firstly, a nice to use library that we can easily use in other projects is cool. Secondly, it makes it platform agnostic, so that when we look at porting to consoles (after we're out of early access) it's just a case of stubbing the dll and replacing the appropriate functions. It's something I've been messing with on and off for a while and the source is all here for anyone that is looking for something similar. I've managed to get this live on the pre-release branch this week, and I'm anticipating problems with it that I'll mop up as they come up. My hope is that by the time pre-release is merged into main the library will be advanced enough that we can start adding new skins from the workshop.

After a period of testing and fixing a few issues, the new Lighthouse will be finally coming out with this month’s wipe. All the interiors and loot are now fully accessible, and I’m looking forward to seeing the inevitable carnage that will happen in this place. Also, thanks to Andre’s help, the Lighthouse will no longer spawn in awkward places, such as on beaches or too close to the cliffs.

Apart from that I continued working on the industrial props from last week. The Substance Designer texturing workflow had proven to be useful and I was able to finish a couple of previously greyboxed props very quickly. You will find now fewer unfinished assets in the game.

I rigged up and started working on the MP5 animations. They’re about 90% done. I just need to clean up some minor issues, such as clipping, and tweak the screen shaking. Here’s what it look like so far.

I thought it would be nice to give the guitar some love. Updates include:

• Viewmodel and anims
• Deploy sound (made with my own fair hands but I'm sure AlexR can do much better)
• World model & LODS (so you don't just get a burlap sack when dropping)

I’ve been polishing off and optimizing the sound occlusion stuff this week. It’s feature complete and running pretty well right now. I still need to finish deciding which sounds we want to enable occlusion on, and to go through and tune each sound’s occlusion settings. I think this should be ready to go in next patch, but I’m going to play it safe and disable it behind a convar so I can test it in the wild a bit before it’s turned on by default. I’ve also been shuffling a few things in the sound system around so that anything that doesn’t need to update every single frame (distance crossfades, sounds fading in/out, etc) runs in a coroutine that’s limited to a certain number of ms per frame. Previously most this stuff was just set up to tick at a slower rate. Most of it runs pretty quickly as is, but keeping it all under a single ms-per-frame budget gives me more room to experiment and should smooth perf out a tiny bit.

I also started working on item placement sounds this week, so placing campfires and doors and all that won’t be silent any more.