BAGS TO RICHES
Backpacks have been one of Rust’s most highly requested additions for several years, and what is a survival game without backpacks? This month, we’re excited to bring you the small and large backpack, allowing players to carry more loot.
Inventory space has become more scarce as more items have been added to Rust over the years.
The small handmade backpack provides 12 slots & can be crafted for 50 cloth and five sewing kits at a T1 workbench. It is a default blueprint and will take 30 seconds to craft.
The military-grade backpack carries a whopping 28 storage slots and is uncraftable, found in military loot.
Both are worn in the backpack slot and drop off your character on death. They can be looted on the ground (be careful if dropping one in a safe zone!) or from inside your own inventory. They take 3 seconds to pickup off the ground and despawn slower when filled with valuable items (up to 2 hours).
Currently, there are no negative effects from using a backpack.
To help differentiate regular player remains from the new backpack models weāve given the player remains a visual refresh. This new model has a new open and closed visual state so you can tell at a glance if a bag has been opened by anyone. There is also some visual debris around an opened bag if the bag has more than 3 items in it.
The new metal detector allows you to find metal objects hidden beneath the ground.
Use the green lights to find the general area of an object, then when the green lights are all fully lit, hold the right mouse button to start sweeping the ground more closely and illuminate the yellow lights.
When all the yellow lights are also lit up, a flag will be placed. Dig this flag up with any melee tool and grab your treasure!
Different areas of the world will yield different types of loot, for example, what you may find on the beach will be different than what you find at the roadside or fields.
I’ve modified the animations for the SAP/SAR and they should feel a bit less floaty and more snappy when reloading and aiming. I’ve also reduced the additional recoil added while moving when using the SAP. Over the coming months I plan to take a look at each and every weapon and do another pass at balancing them. This means timings, handling, recoil, and aimcone. I’m not saying the changes will be drastic but I’m aware there are elements that need changing. Stay tuned.
Players can now only have one shelter placed at any one time
When attempting to log out in a safe zone a warning now appears
Death marker now appears on the compass UI
Some deployables such as the autoturret were unintentionally expensive to repair, this is now fixed.
Doors, hatches and embrasures can now be rotated while being deployed using R
Increased all plants ripe stage duration from 4h to 14h
A recurring community comment is the on-screen hurt, cold, warm and radioactive post-processing is hash, it impacts the screen too much. To address the comments we have made the post-processing more mild.
Above are a few examples, you can find more here[commits.facepunch.com].
As mentioned in our start of the year blog post[rust.facepunch.com], memory usage is a key area of concern this year. One aspect Iāve been looking at lately is entity counts. Anything that gets networked in a Rust server is an entity, so every tree, building block, player, vehicle, etc. What might seem counterintuitive is that many Items in your inventory are also entities, specifically an entity we call a Planner. This is the blue sheet your player visually equips when they are deploying something (eg. a sleeping bag). Any Item that can be deployed in your inventory will have a corresponding Planner entity. This entity is created when the item is created, and will exist on the server (typically in the players hands or at the world origin if they are in a container) until that item is used or destroyed. We need this entity as it handles all the logistics of spawning the deployed version of the item.
To illustrate how many entities this creates we looked a list of entities on Facepunch EU2 towards the end of the November wipe last year. Out of 362,299 entities, 32,455 of them were Planners and are the largest count of entity (the next largest was Walls at 26,015). Since Planners are technically only needed when the player has the item equipped on their belt, this is a big waste of memory and processing time as well as needlessly bloating server save files.
This month weāve rolled out a change that will only spawn a Planner for these Items once the Item is in a players inventory, then delete the entity when it is moved back into an inventory. This should dramatically cut down on the number of entities taking up memory for no real reason.
We also applied this change to Syringes and Bandages, specifically because these item types also donāt need an Entity if they arenāt in the players inventory and are often stored in large quantities (5,769 and 1,206 respectively in the above EU2 sample). Syringes in particular have been a performance bottleneck for the Industrial system due to the need to create and destroy an Entity every time the item is moved, so this change should have flow on server performance improvements there as well.
We think this change should reduce entity counts on the server by roughly 6-9% but weāll be monitoring the results over time.
We received reports from several servers this month with Industrial performance issues. After investigating we found some extremely complex conveyor systems moving large amounts of Syringes as the culprit. The above changes to Entity counts will largely solve the issue, but Iāve also added a new convar (Server.industrialTransferStrictTimeLimits) to better handle time budgeting in these situations. While the Industrial system is time budgeted per frame (eg. Only process three conveyors per frame) it struggled if one conveyor took an excessive amount of time (eg. One conveyor takes 15x the allocated budget).
This new convar will allow the conveyor system to stop half way through a transfer if it is taking too long. Crucially it will then resume the transfer from where it left off on the next tick, so the final results should be the same, they may just take longer in real time. From the players perspective, this may result in conveyors splitting things in unintuitive ways (eg. a conveyor splitting into three boxes might do 2 on the first tick, then the last one on the last tick) but it should eventually produce the same result. Therefore weād recommend turning this on selectively if a server is experiencing Industrial performance issues.
As well as this new convar some general performance optimisations were made, so things should be a little faster across the board in the Industrial system.
Despite having some guards in place, asset memory can easily run ouf of control. We keep adding awesome new content and, unfortunately, it keeps increasing our memory footprint. In order to be able to sustain this rate of content expansion, memory usage has to be low and stable, regardless of world complexity. Until we can implement more aggressive and effective streaming, every once in a while we have to sit down and look at what we missed and make the necessary corrections.
On this update we nuked almost 3 GB of memory usage in shader assets, plus a few hundred MB on textures and meshes. This is a bit of a soft start, in regards to textures and meshes, but we expect to reduce memory usge by a few more gigabytes in the coming months.
We do care about memory and performance, and we’re actively working on it. This is just the first stage of many that will target not only improve memory usage but also frame rate.
Modern games universally depend on asset compression to maximize the efficient utilization of available system memory. To justify the efforts invested in compression, developers often turn to lossy techniques, which, particularly in the realm of textures, frequently lead to a compromise in image quality. Rust was long overdue for a texture quality review. Below is a before and after.
The improvement in detail and color fidelity can be striking in some cases (right). This is an ugly texture but it’s a good example of how compression can ruin a high frequency image. Regions of pixels get merged together and color shifts slightly (left).
Texture compression was being used quite aggressively and, after tweaking some settings, we were able to significantly improve image quality without sacrificing memory. In the end, because a lot of textures had untapped potential for savings, we actually ended up saving runtime memory, at the cost of disk space, while still improving overall image quality.
These were quite mis-aligned while wearing NV Goggles, especially near the screen edges, where they would sometimes float above seemingly nothing. This has now been fixed.
Doors and Gates have been cancelling their open/close animation when hitting a vehicle since Modular Cars were introduced, however that would sometimes lead to cases where the animation cancelling would crush vehicles if they hit the Door/Gate from the opposite side. This has been improved this month and colliding with an animated Door/Gate in the direction that it is moving will no longer cause the animation to cancel. This should lead to less cars getting crushed.
