Devblog 113

I'm still working on this. It's not live with this patch, but it's playable on the pre-release branch on Steam. On there I’ve gone through and rebalanced the tech tree and I'm happy-ish with it from a gameplay perspective thus far. I’ve also written some code that calculates the cost of items based on the level they unlock at as well as how many other items are unlocked at that level. Basically, I’ve made it so when things become eligible for unlocking, you’ll be able to afford 66% of the items in that level. This will give players some choice. Do you unlock something that will help at that moment, or bank that XP so you can afford to unlock something better later on? Next week, I’m going to work on making the system a little more intuitive and adding proper “gamefeel”, so you know when you’re leveling up and whats available. I’m also going to add several new ways to earn XP (when players use tools you crafted, when players use resources you gathered, when crafting items, etc.) and tone down or eliminate the XP you get from simply hitting trees and rocks. There’s going to be some obvious oversights, and I’m patching the tech tree several times a day and adjusting as we go. Response on prerelease has been great so far and I’m constantly requesting feedback on the server, so please give it a try and let me know your suggestions. The sooner we get this balanced the sooner we can push it out to main!

Thanks to a bunch of attachment bugs being fixed we’re pleased to launch the two new muzzle modifications for weapons. As stated in the previous devblog, the muzzle brake allows you to stay on target a lot easier at the expense of some errant shots (think more CoD style spread), while the muzzle booster increases the fire rate of your weapon. I know for a fact this will need rebalancing next week so I will be listening. Thanks for the screen, Rustafied.

I’ve gone ahead and lowered the cost of weapon attachments by about half (apart from the Scope). They really weren’t being used enough, and when they were it was only by people with so much HQM to spare that they may as well waste it on them. This should lower bar for entry to poorer players as well as increase their usage in general.

Wow this is embarrassing. For the longest time the modifier effects for attachments were active even if they weren’t set to enabled. This means the Scope was doing things like lowering bullet velocity by 30%, and the Silencer was increasing fire rate. Haha. Now we get to see how unbalanced (or balanced?) the game will be now that everything is working properly. Rage on.

This time I had the chance to finish a couple of interesting structures. There's the pigeon nest, a structure you can find in canyon and water treatment plant. Remember bird poop? There’s plenty of it on that tower, and it will lead you up the tower, marking places that you can jump on. I did make the climbing of the tower easier to achieve by tweaking a few of the jumps, and it’s now more predictable where you gotta jump from and land now. I worked on the sewage tanks that you can traverse in the water treatment plant, pretty much only cosmetic changes for those. There’s a few things that might still be a bit rough around them but we’ll get that sorted over time. Also since this week’s patch is a wipe you benefit from all the previous dungeons artwork for this month.

We couldn’t figure out why the Muzzle Booster wasn’t working properly. It seemed like it wasn’t always providing the boost it should, after many hours we discovered there was a bug with the server side weapon firing rate calculation that could lead to inconsistencies for weapons with high rates of fire, especially when weapon attachments were added to the mix. Most of you probably never noticed this, but it made firing rate balancing for those weapons difficult and their damage output inconsistent. This is now fixed and you should notice smoother automatic fire.

I fixed another weapon attachment leak that could negatively affect networking and client performance. I also sped up entity linking which helps with server startup times and network group streaming performance.

With the last set of dungeon updates people with low object quality settings started noticing that a number of meshes were using geometry that was far too simplified at close range, especially in the dungeon interiors. I limited the object quality reduction to LOD1, which eliminates any gameplay advantages or disadvantages from the object quality graphics setting.

A couple of weeks ago people started noticing that they could stack boxes by placing them partially inside walls. This is now fixed and you once again have to use shelves to do this.

I worked on a number of improvements for server admins this week. In anti-hack news, admins no longer receive violations when toggling the admin fly mode while moving very fast. A new fly and jump hack protection has been implemented that can be enabled by setting the flyhack_protection convar to 2 and the projectile LOS verification I introduced last week is now stricter when testing player to player damage. I also fixed a no-clipping exploit and an exploit to access the client side layer rendering tools. The stats command was changed to display suicides in a separate column from the death count to help server owners identify suspicious behaviour more easily. I also added a number of layer console commands that can be bound to a key in order to easily show or hide certain parts of the world without having to go through the F1 menu. The restart console command now takes the number of seconds before the restart as an argument, with the default restart timer having been increased to 5 minutes. You can also call restart -1 to cancel the restart mid-countdown. Furthermore I improved server side performance by moving more processing from being done for every client tick to only being done once for every chunk of ticks, which also opens up a number of additional server side safety features. Lastly, I resolved some situations that could cause sign painting update issues for clients with slow or unreliable connections.

Building block entities now store a building identifier that’s identical for all building blocks that belong to the same building. This is used to enforce a distance of two world units between building blocks that don’t belong to the same building. We know that this won’t fix wall stacking base designs given that various combinations of triangle foundations can be used to achieve the same thing within a single building, but it’s an important step for future improvements. I wanted to get the baseline done with this wipe in case I decide to continue working on it later this month.

Overall it’s a pretty minor update to the world generation since I only had a couple of hours to spare this week, but it contains some important tweaks and fixes. First of all, mountains no longer have random holes of death in them. I also tweaked the distribution of mountains, land and water to allow for a higher monument and road density. In addition to that there are now a lot more caves on the map and the minimum distance between two caves has been reduced. Lastly, the road materials now correctly interact with shore wetness which helps blend in flooded roads more naturally.

I've finished up the decayed body sculpt that I showed off last week.

Following on from last week, I'm now going through the other throwable weapons to make them work with the new aiming system. Due to the code changes involved, this system won’t be on main until all weapons have been updated. This week I set up the rock, bone club & bone knife:

I added the first working version of this effect. This technique isn’t widely documented so we’re doing our own version. There are a few important optimizations and bug fixes to be done. The effect is disabled by default and can be activated using “graphics.lso 1” via console. Please note that it’s in an experimental stage and the performance impact might still be high on mid-to-low end hardware. I noticed recently that the effect is exacerbating some inconsistencies we currently have on our tone mapping it’s certainly something to be improved as well. Expect improvements over the next couple of weeks as this will be an ongoing development in parallel with other priority tasks.

I tentatively started work on the heavy armour that Paul concepted a few weeks ago. It's still in a very early stage, and the design space for this one is very delicate. It should definitely feel like a niche choice based on circumstance and not be objectively better than other armour choices. I'll probably take my crappy blockout and stick it in game next week to make sure the armour set is suitably vulnerable to a flanking attack, especially if the wearer has poor mobility. If we can nail that niche feeling it would be pretty cool to have flexible roles in a raiding party like having a dedicated tank to breach doors in an online raid, or fearlessly leading the charge with a pump - but then maybe I've been playing too much Overwatch.

I redid several deploy and reload animations for some of the weapons. They now resemble the viewmodel animations in terms of timing and action. Now it should be easier to tell if another player is actually finished reloading his weapon.

I’ve finished off ration box art! Rations include beans, chicken dinner and mashed potato, water, and fuel. The essentials for surviving Rust, especially the mashed potato (all will be available individually). Have spin with the preview above and below is a pic of how it'll look when added to the game.

I’ve had a bunch of people asking when the music I’ve been writing is actually going to end up in game the past few weeks. That’s what I’ve been working on this week, which means no new music previews this time since this is all backend dev work & chopping the songs we’ve got already in to little pieces. When I last worked on the music arrangement system, I set it up so that it just picked clips of music based on the intensity level (which gets turned up when bullets fly by you and what not) and played them back to back to create a song. This worked alright and sounded nice and smooth, but wasn’t not as immediately reactive as I want the music to be. I’ve been experimenting with the arrangement system this week, and now we’ve got layers that can be brought in and out depending on the intensity level, which makes immediate changes a lot easier to do. If a bullet flies by you we can immediately turn the drums on right on the next downbeat. Everything is broken up into different sections which are what contain the layers, which makes it easy for me to vary the intensity levels that a layer will play at between different sections and to add breakdowns/bridges or melodies that will always play at a specific point in a song. The basic implementation of this is all laid down and working now, but there’s a few other things I need to add, like the ability to specify if a clip should only play once, or if a clip should always be followed by another specific clip (in case we’ve got a long buildup that will sound like crap if it loops or w/e). I’d also really like to spend some time working on a nicer interface for arranging all these clips because the default Unity inspector is not at all friendly for this right now. Having our music broken up into layers also opens the door for randomization of smaller pieces of the arrangement, which I definitely am going to spend some time on next week as well. Randomization is cool because it helps reduce repetition by making songs a bit different every play through. I want to be able to specify that a given section should pick either melody A, B or C, and carry that melody on through the whole section. No timeline on this yet. I know a lot of you are excited for this and I really am too but I want to really nail it before we push it out.