Rust — PIVOT OR DIE

PROGRESSION CHANGES

Continuing from last month’s controversial Meta Shift changes and our push to make meaningful experimental changes to Rust’s progression, this month we’re taking things a step further.

By making progression easier! Wait, what? Bear with me.

One of the main issues with Rust progression is that the majority of servers don’t Blueprint wipe, including our Facepunch servers. When you join a freshly map-wiped server but already have everything unlocked, you’re effectively skipping the entire early and mid-game. You craft late-tier items immediately, bypassing all the gear and choices before it, which completely breaks the sense of progression on a wipe. Given the current state of the game, we may as well unlock or remove BPs, which seems crazy.

Today, we’re wiping all Blueprints, wiping all servers, and drastically reducing tech tree and research costs:

• Common: 15 (down from 20)

• Uncommon: 30 (down from 75)

• Rare: 60 (down from 125)

• Very Rare: 120 (down from 500)

We’ve also removed scrap crafting costs from Workbenches, while Blueprint Fragment requirements remain unchanged.

By drastically reducing unlock costs and removing scrap from workbench crafting, the progression curve will feel smoother without removing that sense of effort or reward. Rather than skipping straight to the end, players will be encouraged to actually use early-tier items first and naturally progress upward.

Blueprint wipes bring back that sense of discovery, structure, and early-game pacing that Rust was built on. Combined with the cheaper unlocks and the removal of scrap from workbench crafting, the system should feel faster and less punishing, not a grind, while still maintaining that satisfying sense of progression and reward each wipe.

The current loop of the game is that you must find components and Blueprint fragments. Through that loop, you’ll naturally collect scrap as you go, and now with Blueprint wipes, there’s a meaningful way to spend it again.

Does this mean we’ll be force-wiping Blueprints every month? Maybe. We’re not committing to anything yet. We’re going to play, watch, and listen before making any long-term decisions based on the past two months of changes.

BOX SORTING

Got a Storage Adaptor attached to a box? You’ll now find it has a power input and some new box sorting settings available when you open it. You can sort items alphabetically (and change what language you use), condition, count, category (matching the conveyor filter) as well as a custom snapshot mode.

The custom snaphsot mode allows you to set a container up with the item layout that you want, take a snapshot of it and then the sorter will attempt to recreate that snapshot as best it can. Sorting is applied automatically 1s after an item is added or removed from the container.

Box sorting is enabled on the Large and Small Wooden Boxes, the Coffin and all DLC storage items (barrels and box skins).

MINI FRIDGE

Keep your food fresh and neatly stored with the new Mini Fridge deployable.

Designed for compact bases and early-game, the Mini Fridge offers a compact way to preserve perishables without needing a full-sized refrigerator.

• Requires: 3 power

• Storage: 18 slots

• Placement: Fits comfortably under half-height floor builds

• **Unlock: **Early unlock from the Engineers workbench

Perfect for solo players or tight base designs, the Mini Fridge bridges the gap between early-game food storage and late-game luxury, giving you a simple, power-efficient way to keep your meals from spoiling.

MONUMENT PUZZLE RESET CHANGES

Last month’s Meta Shift update caused quite a lot of activity around monuments due to the new blueprint fragment system. While these fragments are designed to be scarce, we observed some undesired behaviour due to how monuments would reset to refresh their loot that was contributing to the fragments not spawning as quickly as intended.

Due to the value of these fragments, camping around monuments to ambush players became a popular playstyle. While that’s a classic strategy in Rust and not something we would want to disallow, we noticed that some players were camping so close to monument puzzles and loot rooms that they were inadvertently preventing the loot from respawning. This would lead to fragments becoming even more rare, which would encourage more players to camp the monuments, which would make the problem even worse. It would also lead to long periods of pointless camping, as no new fragments were being generated.

This is how monument puzzles used to work:

• Start a timer for 30 minutes

• If a player is within range of the monument pause the timer until they leave

• Refresh the loot once the timer finishes

To resolve this we’ve made several changes to how most keycard monuments reset and refresh their loot:

• Monument refresh timers will now only start once a player loots a container in the puzzle rooms, rather than constantly refreshing every 30 minutes even if no players have visited.

• Monument refresh timers will now tick down even if players are in range.

• Monuments will now start generating radiation around their loot rooms and relevant puzzle elements (switches, fuse boxes, etc) 10 minutes before they are due to refresh. This radiation is severe and unsurvivable, although it has a small radius around it of milder radiation to communicate that you should stay clear.

• Once radiation is active, the puzzle can only reset once it has been clear of players for a total of 5 minutes.

• We’ve adjusted and shrunk the areas that we check for player presence across most monuments in order to make them as forgiving as possible and still allow general movement and looting around the monument while this refresh is taking place.

These changes should hopefully preserve the importance of monument PvP combat while making sure that the presence of combat doesn’t make blueprint fragments artificially harder to get.

MEDICAL SYRINGES AND HORSES

Medical syringes can now be used on horses by right clicking on the horse with a medical syringe equipped, in the same way you can heal other players. Horse healing can be performed whilst mounted as well as unmounted. Upon healing, horses additionally receive a temporary boost to their max gallop speed (+12.6km/h for 4s) and a small amount of stamina recovery.

This should help prevent tragedies of your noble steed succumbing to the various dangers of the island, with the speed boost also giving a better chance of escaping dangerous situations. Horse jockeys may also find this interesting in achieving the maximum possible speed with horses (please gallop responsibly).

NOTABLE CHANGES

**Water Well Vendor **Semi Automatic Pistol Sell Order Removed

**M4 Shotgun **M4 Shotgun Now Spawns Inside Hackable Loot Crate Again

**Hackable L96 **L96 Spawn Chance Lowered Inside Hackable Crate

**Boat Vendor DPV **DPV Can Now Be Purchased At Fishing Village

**DPV **Removed HQM Crafting Cost From DPV

**Computer Station **Can Now Add More Cameras To The Computer Station

**Diving Tank **Diving Tank Can Now Be Repaired For Free Like The Jack Hammer

**Blue Keycard Vendor **Removed Keycard Purchase from Vendor

VENDING MACHINE - DRONE ACCESSIBILITY

No longer will you have to travel to outpost just to find that the Vending Machine you wanted to buy from doesn't support drones.

All Vending Machines will now show if they are drone accessible or not via the Vendor UI in the main game map.

WINDTURBINE OPTIMIZATIONS

On servers with large bases there are often a decent amount of wind turbines. Each of these turbines were skinned to allow it to be animated. This meant that each wind turbine had its own animator and animation system to allow it to spin. This is fine for lower numbers, but at higher amounts it can affect game performance. To combat this we have removed the skin from wind turbines. Instead having them animated in code.

You shouldn't see a difference here in game, but we should get some better performance, especially with more turbines in the same area.

This also gave me a chance to review our LODs for the turbines themselves and make them a bit better at distance as well, the 'pop in' should be noticeably improved.

ELEVATOR IMPROVEMENTS

We’ve given the player placed elevator a bit of love this month. One recurring annoyance was having to replug the elevator power every time you add a floor, which was difficult since you often couldn’t easily reach the top. Now there is a power input plug on each floor (separate to the call button) and if any floor has power the whole elevator will be considered powered.

We’ve also increased the speed significantly (3m/s to 5m/s) and reduced the delay between when the elevator can be used again after it comes to a stop.

HELICOPTER BALANCE PASS

There's no question that attack helicopters are at the apex of offensive vehicles, but with that strength there still has to be counter-play and ways for defenders (cough victims) to fight them off. With this balance pass we took a look at one of the core-problems, that the attack helicopters are too hard to take down with the homing missile launcher, which was intended to be the primary counter-play solution.

The first change is that we have completely removed the ability for thrown flares to interact with homing missiles. Passenger's shouldn't be able to avoid the 30s cooldown of the helicopter flare launcher by manually throwing a flare. Now when the flare launcher is used and is reloading, subsequent homing missiles pose a legitimate risk to the helicopter and the pilot needs to choose whether to fight or flee.

To couple with this change, we have also removed the ability to repair helicopters that are in-flight. If you are taking heavy damage you will have to find a safe place to land to be able to repair your vehicle. This further reduces the ability for attack-heli passengers to mitigate all incoming damage.

And finally, pilots should be taking a risk when flying the helicopter, and to keep a steady grip on the controls they will need both hands. Currently healing items like the bandage and syringe aren't usable, but other items that act more like food still function (i.e. large medkit, and healing teas), meaning a quick-fingered pilot can heal from their inventory menu while flying. With this update we are bringing this more in-line with the other consumables, disabling the ability to use healing foods while piloting a vehicle. This applies to all vehicles, not just helicopters.

With these systematic changes, we don't want to hit the other player-driven helicopters too hard. So to compensate, the minicopter and scrap transport helicopter have been retro-fitted with their own flare launchers. When purchasing one of these helicopters from a vendor they will start with flares already loaded in the flare compartment accessible from the fuel tank(s).

For hot air balloons (HABs), you will be able to dodge homing missiles by turning off the engine for 4 seconds. But just to be clear, homing missiles by default do not target the HAB, this is only _if _the server ConVar has been toggled that enables the HAB to be targeted.

NEW CCTV CAMERAS

This month, some new static CCTV cameras were installed at the Cargo Ship and Ferry Terminal locations. Players will now be able to input the following codes into a computer station:

Cargo Ship

• CARGODECK

• CARGOBRIDGE

• CARGOSTERN

• CARGOHOLD1

• CARGOHOLD2

Ferry Terminal

• FERRYDOCK

• FERRYPARKING

• FERRYUTILITIES

• FERRYLOGISTICS

Additionally, we fixed a long standing bug limiting the number of CCTV codes per computer station lower than intended, so you should now be able to have a lot more added at once.

PAINTING COLOR WHEEL & FAVOURITE COLORS

The painting menu has gotten a long-awaited upgrade, a colour wheel! Now you can pick your colour using the same type of colour picker as in the workshop scene, including the copy/paste ability with hexcodes.

With this comes another QoL improvement so you don't lose your selections: favourite colours. Add up to 10 favourite colours that can be easily copied to the brush, or swapped out, with a single click. These favourites can also be accessed using the paint.favcolours ConVar, meaning you can bind custom swatches to different keys to hotswap your palette!

DIRECTIONAL FOLIAGE DISPLACEMENT

Foliage now will now physically and directionally push away from players and other moving objects. Things like leaves, shrubbery and branches will move out of your way (within reason). This should make off-ground foliage feel more reactive and realistic as players move around.

RPG LAUNCHER ITEM STORE DLC

This month we’re introducing the RPG Launcher, which is a unique skin for the Rocket Launcher.

The skin can be purchased in-game or from the Rust Steam permanent item store.

Whether you’re marauding on the high seas or just outside Outpost, this battle-hardened RPG Launcher will strike fear into the hearts of your enemies, and a rocket into the heart of their base. Comes with unique rocket ammunition skins.

WORKSHOP SCENE IMPROVEMENTS CONT.

Continuing on the work from last patch, we have another round of workshop scene improvements for the skinners out there. This month has been focused on adding new features to improve the creative flow and keep most of the tools in-game, so you don't have to alt-tab to the workshop page or reference tables with the maximum texture resolutions.

MORE EXPERIMENTAL SERVER OPTIMISATIONS

Couple months ago I wrote about the release of updated flow of processing players on the server that could be activated with **UsePlayerUpdateJobs 2. **It's key aspect is that it tries to leverage multithreading to speed up stagers of logic. The highlights are:

• We can run server occlusion in parallel

• We can send entity snapshots and entity destroy messages in parallel

• Only main thread serializes entity snapshots, the cached snapshots get consumed by worker threads

I've ran a bunch of tests on our servers and discovered that it's been a mixed bag of results - on fresh servers it showed good results, but on older servers it would show no benefit at all. I've investigated and discovered the following problems that have been addressed in this release.

Similar to last time, I'm hoping to validate the new mode and once confirmed that it's holding, roll it out to all official servers.

Server Occlusion - too much work

In retrospect, I've already mentioned in the old blog post how 350 players can cause 10k of various checks to be run, I just assumed that we'd be able to sift through them quick. But that's not the case:

In the above view we do a lot of small checks that usually are cheap, but we have so many pairs to check (~2.7k in above 330 player snapshot) that it becomes expensive. The way we gather pairs was inefficient - we could generate an (active player, sleeper) from-to visibility check, meaning we'd need to eventually validate if we should send data to the sleepers. We also intermixed player state checks throughout the logic, which would lead to us generating more pairs if we discovered half-way through pair filtering that we need to revalidate things. All-in-all, it was still doing too much work.

I've applied the following changes:

• I've simplified player/sleeper state checks further, as some state can be inferred, and added result caching

• When generating pairs we now always end up with (player-or-sleeper, player) from-to pairs.

• Because of above, I ripped out additional downstream checks to see if pair.to is ever not-player or should ignore

This should bring down hash lookups by ~75% & reduce pair count by ~50% (rough guess). I hope this'll bring server occlusion times down to ~2ms per frame for 330p case.

Player Processing - Lock Contention

Another obvious problem that became apparent on snapshots. Our multithreaded player update processing was slow, as slow as serial processing.

All threads, including main, got bottlenecked on 1 lock - you can see how the purple WriteThread bellow has gaps where it doesn't do anything right as above green worker thread is pushing more work:

We rely on pooling to reduce allocations. But to do that safely, our pool uses a lock per type - this allows us to be fast in single-thread cases. But it doesn't scale in a many-thread scenario. It was rather bad, to the point where total time across threads for pushing entity snapshots was 100ms.

Instead of modifying our pool implementation (as that's used in our entire codebase), we now pre-allocate all necessary state on main thread (avoiding expensive locks). I'm hoping it'll speed up the processing and bring it closer to 3ms for comparable population(330p).