Devblog 171

Everyone was bitching about how awful recoil was, so I switched it over to use aimcones. Then everyone bitched about how awful aimcones were, so I've started implementing a learnable recoil system (similar to what you might find in games like CS:GO). Ours is different because it's not the aimcone that is changing but the actual view. Like how Rust recoil used to be, except predictable. This is early in development. What I've done is roll it out to the LR300 and MP5, because these guns are not as accessible and thus less commonly used in vanilla, so if something is terribly wrong it won't have that big of an impact on the core game. Please be aware there are some issues with smoothing and how long it takes to lerp the recoil away etc. The core functonality is there, though. I want people to try these out and let me know how you feel about it. If it turns out that the controlled recoil is actually better and more fun and generally well received, I will improve it and implement it on the rest of the guns. For those who aren't aware, you should know that for these weapons the aimcone has been reduced by 80%+ and instead what happens is your view will bump around with sustained fire. The thing is, the pattern that the view (and thus your aim) changes is deterministic for the weapon. This means if you learn how to control it (left,right,left,left) you can, with skill, get more shots on target. This removes the RNG aspect of shooting and increases the skill ceiling. You bitched and you got it, congratulations. Let's just hope it's actually worth it and improves the game as a whole. Here are a couple of videos of me showing the spread being nearly identical without compensation, and then me trying my best to compensate for it. Just a note: the recoil patterns I have added are pretty rudimentary, and they WILL DEFINITELY CHANGE. Please don't bitch at me if you get MLG Pro at the existing recoil patterns and they totally change in a week or two. You have been warned!

I wasted half the week trying to improve the positioning of the hotspots on ore nodes through various techniques, using hemispheres and cylindrical placement functions. It all ended up being a bunch of bullshit and a total waste of time. Shit happens. In the end, the placement should be a lot better. The hotspots will no longer jump to the other side of the node when the shape changes, and they'll always appear within about a foot of the last one.

I've added a feature for analyzing survey craters, so you know exactly what you're getting into. After you've uncovered one, you can walk up to it and hold "E". After a few seconds, you are given a note that contains the minable elements, as well as the rate they are extracted per minute from this area. This feature is a bit of a leftover from a minigame I'm working on with survey charges. Basically, I wanted people to always see a crater and have it show the distance from the deposit, so you'd have to play a hot/cold game to reach it. And when you did reach it lots of resources would explode out. This would make it less RNG and a bit more fun, but it would also provide an alternative method of mining for resources if you didn't necessarily want to build a quarry: you could just run around searching for deposits and blowing the contents out. However, there were way too many issues to reconcile from a technical standpoint with how quarries currently work so I was unable to complete it. At least you get this, though.

I've changed the yields for quarrys quite a bit. This only impacts quarries and their yields, NOT general ore spawns. You'll find that the static quarry found at warehouses produces 5x as much stone per minute as it used to. I'm excited to see how this plays out and if people gamble with their low grade fuel to score a decent amount of stone. Every placed quarry will yield stone like before, but additional resources are subject to the biome the crater is located.

• You'll only get Metal Ore from the Temperate Biome.
• You'll only get Sulfur Ore from Arid Biome.
• You'll only get HQM from Arctic Biome.

You'll also only ever get one resource in addition to the stone. No more best-of-all quarries, at least for now. In general you'll find quarries produce more resources per cycle than they used to, most notably with sulfur and stone.

One thing we talked about a while back was a task list to introduce players to the game. When you start playing Rust, you don't know what to do. You're overwhelmed by choices. The task list should provide a fun way to learn the ropes.

Official Servers Only

We do a check in the code and only show the task list if you're on an official server. Our intention here isn't to force people to play on our servers, it just means we know how they're going to experience the game. It's a waste of time having a linear task list if they spawn the server gives them an AK and 1000 wood.

Achievements

The task list items are controlled using real Steam Achievements, so when you unlock an item on the task list you unlock a real Steam Achievment.

Tutorial

The intention of the tasks is to encourage and teach. Not to set arbitrary "collect 50,000 stone to unlock achivement" goals.

Work In Progress

This is a work in progress. I've made it and handed it off to Helk to populate over time. There's only two task lists right now, but the intention is to scale this all the way from building a campfire and hunting and surviving, to building a secure base.

There was a limit of 500 players connected to a server. We'd done a bunch of hunting and couldn't find anything in our code. So I emailed Valve and it turned out there was a backend limit. They whitelisted Rust, so now you can have over 500 players on your server. Or maybe more likely, over 400 players queuing to join your 100 player server.

I went through a fixed a bunch of problems with playing older demos. I might not have got them all, but I got the most common ones.

In this wipe cycle Damian and I worked on filling the Cobalt Space Center office building with props and furniture. We created a series of assets in style of 60s and 70s which gives this environment a retro look. Although these objects can be found only in the Cobalt offices, the goal is to use them to fill other interiors in the future. With this done we will now move to smalluments. "Smalluments", as you guys like to call them, are small monuments that will be found along roads. They're fairly quick to produce for us compared to what we just finished. By going down this route, players starting out will have many more areas to loot and explore beside the harbours, lighthouse and warehouses. With this in mind, we scavenged through the concept limbo and decided that some of the smalluments you will see over the coming weeks will include a gas station, super market and a small town.

This week's update includes a new iteration of the procedural world generation. I spent a lot of time on a new road algorithm to generate more circular road networks with intelligently placed T and Y intersections that should eventually lead to continuous road network through monuments, but unfortunately it's not ready for prime time yet. Here's what I did manage to finish up in time.

Mountain Splat Transfer

I finally implemented some terrain splat map improvements that allow us to transfer the more realistically simulated texturing from the mountains on our Hapis Island map. It looks nice, but it also decreases the time needed to generate the map and was required to prepare us for some future terrain features like biome-specific mountain designs.

Icebergs

Icebergs are back. Due to the ladder raiding changes they should no longer be overpowered locations to build your base on, and they look pretty neat in the distance. They're the same old icebergs you know and love for now, but as you might know we're planning to completely revamp the northern icesheet landscape in the near to medium future.

Junkpile Spawns

The junkpile respawn rate could be too low to guarantee sufficient junkpile counts around roads on busy servers. I increased the spawn attempts per respawn wave to resolve this.

We're once again bottlenecked by the garbage collection performance. This seems to be the number one reason for performance issues during PVP and has undeniably gotten a lot worse over time. Since we've optimized most of the other causes for frame rate drops (like workshop skins) we've decided that it's time to tackle this next. As a first step I eliminated some GC caused by the new ore hotspot mechanic, but we still have a long way to go. The metric we're most interested in is the amount of managed memory that's allocated. We're in the process of identifying situations where this number jumps up so we can profile the specific situations and eliminate the underlying issues one by one. If you understand what I just said and want to help us out, file an ingame report describing what was going on when you saw the managed memory jump up. We're aware that this is a major problem, particularly during PVP, and we're gonna make sure to address this as quickly as possible.

In Rust all quality presets except for the lowest two were using the maxmimum texture resolution. This would drastically increase the RAM usage when the graphics card couldn't keep all textures in VRAM, which affected a fair amount of people who were playing on medium settings. The texture resolution is now more of a curve and only the highest two quality presets use the maximum texture resolution. Let us know if this helps you out. I also changed the behaviour of the itemskins convar so skin textures are no longer loaded into memory when playing with itemskins 0. This may help reduce RAM and VRAM usage for some people, but since skins are fairly optimized and compressed they only account for a pretty small part of the used texture memory. Lastly we're now no longer loading all monuments when joining a server but instead only the monuments that actually exist on the current map. This reduces the amount of textures that are loaded into memory and speeds up the asset warmup step in the loading screen.

This week I have mainly been working on the navmesh. I set up links between patches of navmesh so that NPCs can cross between them, but work remains to make the transitioning between two navmesh patches look good. I added support for Andre’s custom terrain mesh, which removes some major overhead we were seeing with navmesh and Unity terrain. Finally, I got started on detection of which navmesh patches touch monuments and player buildings, where we will want to do some special handling. I also experimented with combining hand-crafted navmesh and generated navmesh, but ultimately I couldn’t get the quality I was after.

Last week, while doing texture optimization work, I noticed that our terrain specular values were looking off. I took care of it this week with help from Petur. You should expect proper shine, as well as deeper contrast, based on what the artist originally intended: This of course only made one of our long standing problems, lack of reflection shadowing - e.g. a reflection from the sun that is shadowed by a mountain - a bit worse. I was lucky enough to come up with a decent solution without any tradeoffs to fake it. It's not a solution for all cases, but it makes a huge improvement where it matters the most. While doing all this, I also stumbled upon a zero cost solution to fix distant seams on the terrain caused by repeating our custom terrain atlas textures:

Progress is going well with the makeshift backpack. I decided to regress a little bit for artistic purposes. As I said in the last devblog, the concept is a little old and that I'd be making some changes if I think it's warrented. I felt that the arm straps were a little bland, being mere rope on either side. So to mix it up a bit I've used jumper cables instead on the one side. Also, it was odd looking at the bag: it felt floaty and too empty as it was, so I've made it look like there's something inside of it to give it some visual weight and interest.

The granular engine sound stuff is coming along well. I've move on from working with the smaller piece of test audio to a longer, full recording and hit a few snags tracking the length of the engine cycles we're chopping out in certain parts of the longer file. I spent some time this week changing up the way we're tracking that and it's working quite a bit better through the longer file now. There's a few little bits to smooth out, but I've got a solution in mind for that and it should be straight forward to implement, so we're on the home stretch with this now. This shows a spectrogram of the engine recording, the teal line is the part of the sound we're tracking now, and the blue line is the part of the sound that correspongs to a single cycle of the engine (which we're calculating based on the teal line). My next step is to track more of those white lines around the teal line so we can be more accurate in spots where the current teal line drops out or wavers a bit more than it should.