[previewyoutube][/previewyoutube]
Bring new levels of efficiency and unlock new avenues for automation with this month's set of Industrial entities. With these new tools you can move items around your base as well as craft items automatically without you needing to lift a finger.
[h3]Storage Adaptor[/h3]
The Storage Adaptor is the starting point for most of your Industrial plans - simply attach an adaptor to an existing storage entity to make that entity compatible with your Industrial systems. The adaptor does not require power.
Some entities have more than one slot that a storage adaptor can be attached to for ease of placement. Typically the storage adaptor can use all inventory slots on it's attached storage for input/output, although there are some exceptions:
- 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
The storage adaptor is compatible with:
- Tool Cupboard
- Large Wooden Box
- Small Wooden Box
- Small Furnace
- Large Furnace
- Refinery
- Electric Furnace
- Locker
- Fridge
- Drop box
- Vending Machine
[h3]Industrial Conveyor[/h3]
The Conveyor is responsible for moving items from one entity to another, generally via Storage Adaptors. Once powered and turned on the conveyor will look for items in containers connected to its inputs and then divide those items amongst its outputs.
By default a Conveyor will move any item it can find, but you can also assign a filter to have more precise control over exactly what items you're moving. Each Conveyor's filter can have up to 12 items or categories (
resources/components/clothing/etc). When a filter is assigned the Conveyor will only transfer items that pass those conditions. You can also assign values to each item in a filter to control quantities, by setting the Maximum amount (
don't send resources if the target container has over X of that resource already) and Minimum amount (
only send resources in a minimum batch of X size).
You'll also find a Filter Pass and Filter Fail electrical passthrough, these will activate based on the current state of the conveyor allowing you to control other parts of the Industrial network based on what items are being moved around.
[h3]Pipe Tool[/h3]
The Pipe Tool is how you connect industrial entities - if you've used the Wire or Hose tool before you'll be right at home. Pipes come in 4 colours to help identify what's going where. Same distance rules apply here except that the anchor points need to be a small distance apart from one another and that pipes cannot go through building blocks or Vending Machines. They can go through deployables like doors.
[h3]Industrial Splitter/Combiner[/h3]
These work as you'd expect, allowing you to funnel or split the flow of items. In the case of a splitter connected to the output of a Conveyor, the Conveyor will spread its resources across all of its connections (
eg. a Conveyor connected to a splitter which connects to three boxes that wants to send 600 wood will send 200 wood to each box).
[h3]Industrial Crafter[/h3]
Once attached to a workbench (any tier) the Industrial Crafter allows you to automatically craft items once provided with a blueprint and the required materials. Simply insert the blueprint of your choice in the blueprint slot, insert the required materials, connect some power and turn it on to start producing items.
The Industrial Crafter has built in Industrial slots (so no need for an adaptor) so that you can use Conveyors to insert materials and then extract the finished result. There is also a Blueprint In/Out Industrial slot allowing you to swap out the blueprint being crafted. The Crafter can only craft items that are appropriate for the workbench it's attached to and will take the same amount of time to craft an item as a player would.
[h3]Electric Furnace[/h3]
To complement the Industrial items we're also releasing the new Electric Furnace. It works similarly to other furnaces with a slightly accelerated smelting rate except that it requires power instead of a fuel item. This also means that it doesn't produce charcoal.
[h3]Limitations and Server options[/h3]
To maintain server performance there are several limitations to prevent Industrial networks from becoming too out of control. There is a hardcoded 16 container input/output limit for each conveyor. This means that as well as the max depth limitation of regular IO, a conveyor will only be able to see the first 16 containers it encounters in the input/output network.
There is also a hardcoded limit on how many items in a stack a Conveyor can move in a single tick - 32. If a stack has a count higher than this it will be moved gradually over several ticks.
There are also several convars to control the speed and efficiency of industrial systems:
- 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)
Previously doors would show "Open" as the default option whether you had the code or not, requiring you to randomly stumble upon doors you couldn't open, beeping in your face then requiring you to holding E to bring up radial menu and select unlock.
The new default options are as follows:
- 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 wagons containing crates now have different variants of varying qualities. Overall should be seeing wagons with much higher-quality loot from crates.
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.
[h3]Overall FPS[/h3]
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.
[h3]Best Performing Hardware[/h3]
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).
[h3]Hardware Capacity[/h3]
~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?!
[h3]Popular Hardware[/h3]
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%
[h3]Graphics settings[/h3]
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.
[h3]Operating System[/h3]
Our Mac playerbase is very small, only 0.3% of players.
Yet even stranger are the people still on Windows 8... laptops perhaps?
[h3]Future[/h3]
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
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.
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.
[h3]Why Retire Hapis? [/h3]
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.
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.
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.
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.
