Storage Adaptor

• When attached to a furnace the Input will insert items into the Fuel/Inputs item slots while the output will remove items from the output slots
  
• When attached to a locker the storage adaptor will only access one partition, to access all partitions you'll need to place three storage adaptors
  

• Tool Cupboard
  
• Large Wooden Box
  
• Small Wooden Box
  
• Small Furnace
  
• Large Furnace
  
• Refinery
  
• Electric Furnace
  
• Locker
  
• Fridge
  
• Drop box
  
• Vending Machine
  

Industrial Conveyor

Pipe Tool

Industrial Splitter/Combiner

Industrial Crafter

Electric Furnace

Limitations and Server options

• server.conveyorMoveFrequency - How often conveyors attempt a move (default 5s)
  
• server.industrialCrafterFrequency - How often crafters attempt to craft something (default 5s)
  
• server.maxItemStacksMovedPerTickIndustrial - How many whole stacks a conveyor can move in a single tick (default 12)
  

CODELOCK DEFAULT OPTIONS

first placed = "change code" (to quickly set your code)

unauthorized on codelock & auth on TC = "enter code"

authorized on codelock & unlocked door = "lock door" (to prevent leaving doors unlocked)

This should allow you to see at a glance what you still need to enter a code on & open the codelock UI much easier.

TRAIN WAGON LOOT

Train wagons containing crates now have different variants of varying qualities. Overall should be seeing wagons with much higher-quality loot from crates.

CLIENT PERFORMANCE METRICS

Performance is always a hot topic but it is difficult to address without having an accurate image of the problem. This month I setup logging of client performance and displayed them in various graphs.

This has already proven to be useful. We noticed that exclusive fullscreen had lower FPS than borderless. Rather than guessing, we were able to query the database and confirm it.



See below for various graphs to get an idea of the insights we are seeing & some interesting data.

Overall FPS

First up is median FPS across all hardware. It doesn't give a full picture: players with 60hz monitors are included beside 144hz gamers.



A better metric may be comparing average fps to monitor refresh rate to see how many players are getting lower FPS than their monitor supports... something we will look at in the future.

Best Performing Hardware

These charts clearly shows how Rust is CPU bottlenecked (no surprise). What is interesting is how much the extra cache does: a 5800x3D is on average 50% faster than a 5950x!

Please don't use this as an excuse to go buy a better CPU as performance is subject to change... but do use this info so you avoid buying a new GPU for Rust then being surprised when it yields no performance improvement (at this time).

Hardware Capacity

~75% of the playerbase is running 16GB or less of RAM.... perhaps we should really prioritize why Unity is hogging all the RAM.



The majority of players (73%) using 1080p... yet only 2.5% of players using 4k?!

Popular Hardware

Looking at most popular CPU & GPU we find that it is similar to steam's hardware survey but differs slightly as for Rust. Here are some GPUs as % of total:

Our Metrics:

• GTX 1650 = 6%
  
• GTX 1060 = 2.5%
  
• GTX 2060 = 5.5%
  
• RTX 3060 = 7%
  
• RTX 3090 = 0.6%
  
• RTX 4090 = 0.2%
  

Graphics settings

30% of people using motion blur 👀 only 5% of players using SMAA, 20% of players using primarily windowed mode (not borderless)... all interesting. I thought more players would have turned shadows off.

Operating System

Our Mac playerbase is very small, only 0.3% of players.



Yet even stranger are the people still on Windows 8... laptops perhaps?

Future

Next steps are to expand to gameplay metrics. Technically.... we already have some gameplay stats but they are very limited: "total wood gathered", "total kills", etc.

Better gameplay metrics will give us the ability to drill down to specific information such as:

• most popular weapon each day of a wipe
  
• win ratio of different weapon match-ups
  
• deaths per size of team
  
• hourly loot per monuments
  
• least used items
  

WATER IO SERVER IMPROVEMENTS

We've been aware of some server performance degradation with large scale farms and Water Catcher networks for a while and we've made some improvements this month to hopefully improve the situation.

The primary performance issue at play here is the amount of processing required when an entity in an IO chain switches on or off. Under normal circumstances this doesn't happen that often but water containers are considered On when they have water and Off when they are empty. When a chain of Water Catchers are connected and sending water down a chain each container will turn on when it receives the water and then turn off as it passes the water to its next container. Water transferring is quite quick and responsive, this results in rapid sequences of entities turning on and off repeatedly which sends a lot of network updates to any clients in range and involves a lot of (largely useless) IO processing as the network changes state so rapidly.

To solve these issues water will now take 10 seconds to start draining once it's inserted into a container. This means that when water travels through multiple containers each container in the sequence will build up a buffer (usually 50-100 water) in each container. This allows the same water flow as before but mostly prevents the containers rapidly turning on/off. The result is that a small sequence of 3 full barrels connected to each other powering a sprinkler used to be sending 10-20 network updates every few seconds will no longer send any updates at all while the system is active, only a few updates when the system runs out of water. This should improve performance primarily on the server but receiving less network traffic will help client performance as well.

We've also modified the behaviour of Water Catchers, when a Water Catcher is going to generate some water, it will now deposit its water as far down the chain as possible. This means that if you have 3 Water Catchers connected to a Water Barrel, the catchers will actually never receive water at all, instead the water will be deposited directly into the barrel.

In a benchmark of 1000 water catchers connected to each other, we found that the server's IO would become unresponsive after several minutes of gameplay as the system became overloaded with water transfer processing. With the above changes server IO performance remains instantaneous even if we artificially limit the servers frame rate.

There is also a new optional server convar "server.waterContainersLeaveWaterBehind" that modifies the draining behaviour to leave one unit of water behind in a liquid container that drains into another container. This keeps the container in its "On" state permanently and further helps performance. Since this is a change in functionality it is disabled by default, if your server is still experiencing IO performance issues due to water entities turning this on may improve performance.

HAPIS RETIREMENT

Today we're permanently retiring Hapis Island map. Hapis Island was first introduced in April 2015 by Petur, inspired by the original Rust legacy map. Over the years, Hapis has gone through countless revisions to where it is at today.

Why Retire Hapis?

We're a small development team with no dedicated staff focusing on map design and creation, our mapping attention is focused on procedural maps. Hapis has continuously been developed on the sidelines as a lower-priority project with any free time Petur has. Free time is harder to find nowadays as we focus more on larger, longer-term features with a higher level of polish. Hapis Island needs a lot of attention requiring hundreds of work hours to be polished and kept fresh, which we can't currently give it.

Hapis Island is missing many key features we've added over the past couple of years, zip lines, subways, new monuments and above-ground rail systems, to name a few. When Hapis can support newer features it often takes an extra month, or few for the features to be introduced to Hapis, leaving players waiting and disappointed, some features, such as the rail systems Hapis can't currently support due to a lack of internal tools.

This isn't the end for static maps on Facepunch servers, we'll be working with the custom map community to fill this void over the coming weeks and months.

UNITY 2021.3 UPGRADE

We have upgraded the client engine to Unity version 2021.3 earlier this month. Initially there have been a number of issues from the upgrade, but we've gone through and addressed all the major ones with several small patches.

This new version of Unity should open up new possibilities for both performance and visual improvements that we're hoping to introduce over the coming months. A big one is Unity's Burst compiler that will help us transition existing code in the Jobs system to a higher performance version of it.

Unfortunately the upgrade also introduced a bug in fullscreen exclusive mode that caused a significant performance degradation compared to borderless fullscreen mode. Due to this we had to retire fullscreen exclusive mode. If you're encountering issues that seem related to this, please contact our support team to figure out a workaround for your specific setup.

The server build of the game will remain on 2019.3 for this month while we continue testing the new engine version to make sure the server build is stable enough for a wide release. More on that hopefully next month.

MULTITHREADED NETWORK TESTING

We've been working on a major networking performance improvement called multithreaded networking. This will apply to both the client and the server, but naturally it will have a significantly higher impact on the server. Due to the nature of the change we wanted to make sure it's working as intended before enabling it by default, so we're first going to start testing it on select official servers this month before hopefully enabling it by default on all servers next month. If you want to start testing it before then, simply add the startup parameter -networkthread to your server or client. Please note that this is a highly experimental feature that may cause significant problems when enabled.

SERVER QUERY PORT SHARING RETIREMENT

As announced in the November and December devblogs, we are working on a number of networking improvements that require us to retire server query port sharing. Because of this, we have requested that all server owners that are still using this feature update their server startup parameters to use a query port that is separate from the game port.

We have decided to pull the trigger and finally retire query port sharing this month. If you're a server owner who still hasn't updated their server startup parameters, please make sure to do so immediately.