Posted on February 2nd, 2023 02:27 PM EST
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.
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
- Electric Furnace
- Drop box
- Vending Machine
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.
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.
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)
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.
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.
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).
The majority of players (73%) using 1080p... yet only 2.5% of players using 4k?!
- GTX 1650 = 6%
- GTX 1060 = 2.5%
- GTX 2060 = 5.5%
- RTX 3060 = 7%
- RTX 3090 = 0.6%
- RTX 4090 = 0.2%
Yet even stranger are the people still on Windows 8... laptops perhaps?
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.
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.