Devblog 166

Greetings from Shadowfrax. Here's his look at the latest update.

As part of the resource gathering revamp I've made some changes to ores and how they work. The first thing you'll notice is ore nodes are specific to their type. This means stone nodes yield only stone, sulfur only sulfur, and metal only metal. This is the first step in improving resource gathering and making it less grindy. As it was, you were effectively a moth to a flame as soon as you left your base. Any node you saw you had to hit or you felt like you were losing out, and nothing felt like an achievement because you got a bit of everything from everything. It's very muddy. I want people to make active decisions about what they need and take the time to find areas that provide it. Another change you'll notice is the fact that ore nodes look nicer while they're being destroyed. I've added a much needed particle effect and sound to mask the visual change that happens as the node stage changes. I've also added something called a "finishing bonus" to the ore nodes. The final hit will yield a bonus of about 20% of the total, which is not only satisfying but should mitigate cherry picking and just leaving half finished nodes around the map. It should be noted that you can only receive this bonus with a proper tool. Bone clubs and stones do not trigger it. Lastly, in what is sure to be a controversial decision, I have removed HQM from ore nodes with the exception of the metal one. You will instead receive 2 HQM in the finishing bonus of a metal ore node. This means if you want to pump out guns you're going to need to build a quarry. I plan to revisit how quarries work next week, and make them not only more viable but necessary and fun to use. If you're a lone wolf you should be able to get by via recycling or trading. You shouldn't need to pump out 5 AK47s a day, so getting 2 HQM for hitting a static object in the world for 10 seconds should not be a huge issue. Look, any time I make a change that fundamentally modifies how the game is played the outrage on reddit is extreme. Unfortunately I fell victim to reading the playrust subreddit and actually took the beratings to heart and got cold feet which resulted in me making kneejerk last minute changes to my work to try and please "the community". It turns out "the community" I was listening to is likely just a few extremely loud mouthed negative people who cannot see beyond the next 5 minutes of playtime. The entire point of me introducing HQM in the first place was to split up the resource requirements for new players and for high-end players. It's the same reason why I wanted to make different types of resources available in different areas of the map. Because I listened to people bitching, I lost sight of my original vision and we've been left with a muddy mess of a resource collection game, where everything is available everywhere all the time. This may be because people just want instant gratification and be the first to have a P250 so they can ruin other peoples days. This is why we have junkpiles everywhere - because people didn't want to go to radtowns. This is why HQM was in nodes - people didn't want to do the work to get a quarry. This is why we don't have the north/south divide - people didn't like the thought of actually having to do more than step outside their base to get good items. When I sit back and reflect on these aspects it makes me very unhappy with the state of the game. So I'm going to change it. I'm asking for you guys to reserve judgement for a few weeks and really let things play through. I feel like I write this every few weeks, but understand that nothing is set in stone, and if something sucks it'll get changed. The goal here is to make the game as fun as possible, and that is what I am attempting to do. You might be accustomed to a certain Rust lifestyle and when that is changed you may feel slighted, but please try and think about the future and let us try and push it into a better direction. Another thing I'm looking at doing is making the resource gathering a little more fun with a minigame: It's not live yet, and I'm working on a few different iterations, but basically what I'm going to do is have some 'hot spots' on the node you can see in certain light conditions or with the miner hat which grants you a bonus upon finishing the node. I'll probably have them chain together, so if you do a good job at smashing them all you'll receive more in the end. I feel little things like this will go a hell of a long way in reducing the mundane nature of gathering resources in Rust (colliqualy known as grinding). That's all for now, stay tuned. Try not to act like the game is ruined and just trust us. Please?

As a first step to increasing the prevalence of mining quarries, I've made them a bit easier to construct. They now cost 5000 Wood, 1500 Metal Fragments, 6 Gears, 4 Sheet Metal. In the coming weeks I'm going to have a pass at making them much more viable and interesting to use, as the reliance upon them should increase with the ore Changes this week.

While redoing the particle effects on the rock, I had a chance to look at our explosion effects and Oh My Goodness... I can't believe they were that crappy for that long! I bought an asset pack with some awesome explosions and replaced the ones we had. They're far from perfect, and need a bit of work (longer lasting smoke, more grey instead of black, vertex lighting etc), but at the very least they are way, way better than what we currently had and it wasn't a huge amount of work. I'll probably get Gooseman to improve them over the next little while when we get some spare time. Enjoy! I've also added an awesome screen shake effect to explosions. Based on the explosive the severity and the falloff is different. It really helps to make explosions feel powerful.

Not any closer to going in game, but I'd like to let you guys know whats going on with it. I need to sort out some performance issues with gathering paths, as well as some logic issues (some weird decisions are made). I also have to ensure that they play nice together and balance their loot. All that is straight forward and will just take time, however the one major issue is the fidelity of the NavMesh. I optimized it to generate about 4x as fast a few months ago, after we introduced the new animals, because of servers hanging for several minutes on startup. The downside of this is that in and around radtowns there are lots of navmesh bugs and bad accuracy in general. I'll see about contacting Unity to see if we can change how the navmesh is generated internally, so it stops hanging servers and so we can use a higher resolution navmesh. Until then the AI is going to be kind of shitty around radtowns, which means I'll have to anchor them to more open areas or just spawn them on terrain away from radtowns. I'll keep you guys posted.

Some fairly important changes to decay coming this week. Deployables now only decay when they're outside (i.e. don't have anything above them that would shelter them from rain, if we had rain). This means abandoned bases will no longer have their boxes decay and should once again be worthwhile targets for a raid. Furthermore, storage containers no longer reset their decay timer when interacted with so storage boxes that are placed into the wild properly decay even when random players continuously interact with them. Hidden stashes are not affected by this change.

A lot has changed with dropped items. First of all, debris and ragdolls no longer prevent you from picking up items that are behind them. That means you can finally pick up your loot after destroying a barrel. Next, dropped items despawn a lot slower than before, particularly the rare ones, as despawn times have been increased to between 5 and 60 minutes. This means an AK will remain in the world for a full hour before it disappears while hemp seeds will already despawn after 5 minutes. The aim is to give people more time to retrieve dropped items and to keep players from despawning their loot during a raid. With dropped items staying around much longer than before we decided that it would be a good idea to change corpses and storage boxes as well. They now drop a backpack or pouch with all their items in it when destroyed, instead of spewing dozens of items all over the place. This reduces the performance impact since the backpack is much cheaper to render than a ragdoll, and both the backpack and the pouch are only a single physics object to simulate. This allows us to keep them around much longer. In fact, the despawn time on the backpack and pouch is as long as the despawn time of the most valuable item they hold. Another annoying thing about dropped items was that they were really hard to find in grass and had a tendency to slide off into the distance when falling on a slope. Both of these are now fixed since dropped items, like the backpack and pouch, displace grass around them and use much higher friction than before.

We've been having some problems with a server crash that was caused by physics items having an invalid NaN position. It seems like this could happen when boxes were destroyed or decayed and dropped all of their items. This hit the official servers particularly hard since they are using relatively long wipe cycles and therefore have a lot of abandoned bases that decay. Since boxes now drop a single item pouch instead of dozens of individual items, the crash bug appears to have been fixed as well in our testing. We'll keep an eye on the live servers to confirm this.

Grenades felt horrible. They still do, but a bit less so. I increased their friction so they don't slide around on the floor like an ice cube, and I reduced their bounciness to make their landing look less like you're throwing a tennis ball. Once that was done I increased their weight and reduced the throw velocity a tiny bit. While they're still far from perfect, I do at least tend to hit my targets now.

Praise the lord, you no longer have to press a hotkey twice to consume an item that's in your hotbar. I know this is a tiny change, probably too small for its own devblog section, but if you're like me you'll love to hear that this is finally fixed.

With the addition of the new skin shader introduced a few weeks ago, I'm taking a pass over our existing skin textures. The new shader makes use of a couple of features which currently don't have the proper art to support it - so I'm touching up the textures and creating a couple of new maps such as the scatter amount. While I'm at it, I'm hoping to add a bunch of variations in heads as the current selection is a little lackluster. The biggest time-sink with creating variations currently is that each variation requires its own hand sculpted high poly mesh. A long time ago I did some explorations into using the low poly geometry as much as possible to define larger shapes, and to use textures to mostly define skin texture and small details, so it seems like a good time to return to that now. Here are three heads that share the same material, but with some variations in the low poly mesh. This is quite a tame example, but I'm hoping to push it even more; combining meshes, materials and skin tints to create a much broader variety of faces.

I finished the beautification pass that remained to be done on my section of the site. The goal now is to release the level in the most stable state possible. This week I also worked with Andre on implementing the new (from January) grass I have made. I expect a lot of work/debug the coming week as the merging of the launchsite and updated airfield to main represent a sizeable update.

The work on the rocket factory is nearing the end. This week I have focused on creating all the necessary LOD and colision models for assets surrounding the factory, as well as the building itself. On the graphical side all major tasks are now completed, so all that's left is additional polish, playtesting, bugfixing and optimization. My goal is to have all the LOD and colisions models completed by the end of this week and then spend the next week taking care of all the loose ends before the next forced wipe.

I finished most of the texture packing work this week and ran some analysis on the type of memory savings we can get, as well as runtime performance deltas. Visual results are very decent. There should be no discernible difference in relation to the unpacked version in most cases, unless you're doing a direct comparison like the sphere below (you'll need to zoom to notice differences): They look very similar, even though packed version can take up to 35% less memory, in its current state. In some cases it might even end up looking better due to the fact that we can now use custom, more accurate rescaling filters. Packing textures in bulk will allow us to have final-pass optimization control over the regular textures. In the example above, the most important packed map, which contains albedo, has a max anisotropic value of 16 while the second packed map (normal) is capped at 4. In the vast majority of cases you won't be able to tell the difference and boost can be quite significant at a very small visual cost. A quick analysis showed we can save up to 20%, on both system and video memory, by packing our standard materials. Other material types may yield more or less than that. Performance-wise, we're looking at a decent reduction in texture bandwidth requirements, that ultimately benefit low-end GPUs. At the lowest anisotropic value (1), the improvement on those materials, can go up to 10% depending on how many pixels fill the screen. This number inflates to 66% when anisotropic is set to highest (16). Results were measured on a GTX 960. More impressively, by packing we can nearly halve the total number of textures used, on supported materials. This means the CPU will be doing a lot less work when binding materials during rendering. Right now the process is manual and, since it's in early testing stages, still requires some oversight. I'll be rolling out a couple of packed materials for testing during next week, and should be able roll out dozens more the week after, if all goes as planned. These changes will arrive incrementally and, hopefully, seamlessly.

This week I worked on fixing the occasional sync issues I mentioned last week, and made some pretty good progress. Unity only provides one way to play precisely timed audio (AudioSource.PlayScheduled). This works great when you want to play something at an exact point in the future, but if you pass it a time that's in the past it'll just start playing immediately instead of adjusting the start position of the sound to time it as though it was started in the past. That sucks if you're doing something like making a music system where you want clips to fade in mid-clip sometimes. There is a way for us to set the playback position of a clip once we start it, which we've been doing, but it's not super accurate and occasionally stuff doesn't change at exactly the right time because these time changes need to get fed over to the audio thread. This week I discovered that the problem is way worse for clips that stream from disk instead of being loaded in memory, and previously all of our music was set to stream. Now obviously we don't want to load all the music clips in memory at once. Thankfully loading/unloading audio already happens on a separate thread, so I've set up a little system to load and unload music clips as they're needed. Right now it just loads a whole song at once but I'm going to tighten it up so it just loads the current and upcoming sections of a song. There's still occasional sync issues with the in memory clips because of the way Unity propogates playback position changes to the audio thread, although I think it might be tight enough to not really be noticable now. If this doesn't end up holding up well enough during real play testing I do have a couple other avenues to explore that will absolutely give us sample-accurate playback, but that will take a bit more work to implement and might have performance issues unless we're really careful. I've done some smaller cleanup and optimization work on the music system this week, and made a few more tweaks to playback settings for some songs too.

I was mostly focused on the music stuff this week, but I did create some sounds for the new ore stage change effects, did another batch of polish and mix tweaks, and got a few more raw recordings cleaned up and library ready.

The Hapis update is still on schedule for next week's wipe. New trees mayyybe as well.