Devblog 115

I've returned from paternity leave, but Helk will remain the project lead. I took over as lead to keep the project from completely dying while he had to take some personal time to deal with some family stuff. I'm good at getting shit done, but Helk is much better at gameplay and balancing, as I'm sure you've all seen over the past few weeks. Rust has always been Helk's project, and while I had input on certain things, he is responsible for the huge majority of it. So stop blaming me for shit on reddit.

Ever wish there was a map without grass and rocks and bushes and all that shit, so you could play at a decent quality setting with a decent frame rate? Well now there is. It's on the pre-release branch, labelled as 'Barren'. Join the pre-release branch to try it. It's a procedural map, so it's generated and seeded just like the regular map. It has monuments, loot, ores, trees. Just none of the purely visual stuff.

It's obvious that our previous anticheat strategies aren't working. Cheaters and Cheat makers have become accustomed to the routine and have learned how to coexist with it. We need to switch it up. A good number of persistent cheaters have a main account alongside a string of accounts on which they cheat and expect to be banned. We can see these accounts, we can see how they're used, how they benefit from the actions of your cheater accounts. Previously we've only banned accounts that were used for cheating; from now on if you're caught we'll ban all of your accounts.

Had a bit of a health scare (I’m fine). I didn’t get as much done this week as I’d like, but I do have some good news: we’re planning to merge the pre-release branch into main and launch XP system with the next forced wipe (July 7th). I wanted to make this public so you can all call us shitty game developers if we fail, but we’re totally not going to. This means we’re not going to be pushing any new content to main as we have all hands on deck working on pre-release. We got way too far behind and it’s time to really stick to our guns and churn this sucker out. I encourage everyone to opt in to the pre-release branch on Steam and give the XP system a try. We need as much feedback as we can get. We frequent reddit, so post your thoughts there.

Players have to send a bunch of info, like their position, in regular intervals to the server and there are certain situations and exploits that can flood the server with those types of messages. While we can and should address those on the client, I also added a second layer of protection to the server this week. Players that send too many ticks in a short period of time are now automatically kicked. Server owners can adjust that threshold with the maxflood convar, but the default value seemed to give plenty of room to account for any connection quality fluctuations.

This one has been on the back of my mind for a while now. Up until now we did all antihack tests using the last verified tick and the last received tick, essentially skipping over all intermediate values to avoid players choking up the server by sending a bunch of tiny position updates in quick succession. However, this also meant that when verifying player movement on the server any position updates that were received in the same server frame were simplified to a straight line. This worked for the most part since the server usually receives a decent amount of position updates per second from the player. Problems started to occur when servers reached extreme population counts, or when players had very unreliable internet connections that required packets to be resent multiple times. The solution to all of this is to create a curve from all ticks the server received in a frame and verify player movement along that curve. This makes it possible to set upper bounds for the step sizes and therefore the performance impact while keeping the results of the movement tests as accurate as possible. The new system can be toggled as mode 3 of the noclip_protection convar, with the two new convars noclip_stepsize and noclip_maxsteps allowing server owners to adjust the accuracy. I’m sure this will need some tweaking over the next couple of weeks, but I’m confident enough to enable it on all servers by default.

Decay has received quite a bit of backlash on reddit. I read through it all and did a balancing pass on the decay rate of deployables. The main reason this was added is performance, especially further into the wipe cycle, but server owners who wipe in different intervals than the official servers can adjust the decay.tick convar to scale it according to their needs. The default decay rate for most deployables is now a 2 day decay delay followed by a 2 day decay duration. Storage boxes and furnaces decay at a slower rate with a 2 day decay delay and 4 day decay duration to give people more time to raid abandoned bases.

This complaint partially ties in with the deployable decay we added last week but has really always been a problem after raids. Up until now most deployables could not be repaired once they’ve been placed and there wasn’t really a good reason for it other than repair cost being completely unbalanced until a few weeks ago. From now on nearly all deployables can be repaired, with notable exceptions being traps and barricades.

This one was way long overdue. Every couple of months, Helk comes to me and asks about river flow. I always tell him I have other priorities on my plate. Well, this time I just went ahead and did it. It can be useful to know which direction to follow in order to find the coast, other than relying just on the terrain slope.

After a long time deprived of radiation, it's returning to the game’s dungeons. If server owners want to enable it, they can do so starting from the next wipe cycle (it will default to off otherwise). This time it covers some areas of loot and camping. Loot inside larger buildings or on top of them, for example, is more likely to be inside an irradiated zone. Ground floors and smaller out buildings are radiation free; top floors and vantage points where camping can happen are not. It should help with the pacing and traversal of these places, and add a slight challenge to those who want to collect all the loot one town contains.

While adding river flow I took the opportunity to add foam, so we're now a bit closer to having fully seamless river to ocean surface transitions: The only problems left to fix, which have been already reported, are ocean showing below the rivers at estuaries and river underwater rendering.

Despite taking a small break this week to work on some aesthetics, performance and stability are still my number one priorities right now. Improvements this week include combining tone mapping and color grading into a single pass, as well as speeding up parts of ambient occlusion. The actual savings will depend on your graphics card and whether both grading and occlusion are enabled. Lower-end hardware will benefit the most. Next week I’m hoping to continue and, hopefully, tackle some high-yield problems to achieve more meaningful performance improvements.

I bet you didn’t see this coming. I spent more time on the music system this week! I’ve been having issues with the Unity editor crashing that we think is related to a recent OSX steam update. It’s been slowing me down a bit, but I’ve been trucking through it. It’s all hooked up to most of the in-game events we want to trigger intensity changes from now (one of my favorites is the intensity gradually increasing as you approach a supply drop). Songs are selected similarly to how ambience is selected now. We can override the current song for special events or what not (think helicopter theme song), and the override song will come in smoothly and perfectly on time just like it’s a new set of clips from the currently playing song. I’ve squashed a bunch of smaller bugs and cleaned the system up a bit too. I’ve chopped some more songs up, but this part is taking a bit longer than I had hoped. I really want the songs to stand up well if they’re playing at zero intensity the whole time, if they’re playing at full intensity the whole time, and if the intensity is fluctuating everywhere, so there’s been lots of testing and re-exporting clips with instruments moved to different layers going on, but it’s going well so far and I’m loving that a single song can play as a nice ambient track when you’re safe in your house but also play as a nerve wracking storm of drums and tense silences when your neighbors are being asses. Between the Unity issues and the song chopping being a longer process I didn’t hit my target of getting this stuff in game under a disabled-by-default convar this week but that should happen in next week’s update and I’m really hyped about it!

After finishing up on the mortar concept, I started to make some good progress on Paul awesome double-barreled shotgun concept. This is the progress so far. I added the grip of a screw driver instead of a bolt, so it has a feeling it was crafted out of random stuff. Paul dug it so we’re running with it! I should be working on the low-poly and textures by the next update!

Work continues on the long list of throwables. This week I’ve started to tackle the two-handed weapons: the pickaxe, salvaged icepick, axe, and hammer.

This week I’ve been going over all of the clothing items and fixed areas which looked particularly bad when animated (most notably around the shoulder and elbow areas). Here’s some images to illustrate some of improvements being made.