July 4, 2026·RustProfit Team

What's New in Rust's "Devblog 36" Update

November 2014's Devblog 36 was the unglamorous one: a 25% average framerate improvement, a long list of Helk gameplay fixes including the large storage box and lock behaviour, and Garry questioning whether the devblogs were distracting from the game.

What's New in Rust's "Devblog 36" Update

Devblog 36 arrived at the end of November 2014 and was deliberately unsexy: performance and gameplay, no new toys. The client got measurably faster, Helk worked through a long list of gameplay irritations, and server optimization work began in earnest. It also came with a bit of soul-searching about what the devblogs were actually for.

Client optimizations

The optimization work paid off in numbers. Across the two days since the update went out, the average framerate was 42 fps - up 12 fps on the average from a few weeks earlier, roughly a 25% improvement. More was still on the table, with the F3 menu flagged for being made clearer and more useful the following week.

Gameplay fixes

Helk went through a broad pass of gameplay problems:

  • Adjusted melee ranges, and fixed melee not always registering
  • Melee traces now properly use spherecasts
  • Campfires hurt less
  • Added audio to the furnace
  • Destroying a crate now makes it spew its contents
  • Fixed the lantern material
  • Fixed terrain footsteps when indoors, and made footsteps louder
  • You now receive more than one bullet per craft
  • Spear attack nerfed, and stone spear cost increased
  • Bandages now cost 3 cloth
  • Right click to smash skulls into bone fragments
  • Added the large storage box at 24 slots; the small storage box dropped from 12 slots to 8
  • Code locks now save and restore their whitelist properly, and a code lock automatically locks after the first code is entered
  • Locks automatically lock after a key is created

Server optimizations

Server-side work started too, with an ambitious stated target: servers able to stay online and wipe-free for at least six months. Garry acknowledged how far off that was, but framed the week's work as steps toward it.

A major server stability problem from the previous week had been solved, though at a cost - the building stability system became a bit less predictable as a result, with a fix planned for the following week.

A separate timeout bug was still live. It appeared on servers that had been up a long time with more than 70 players online, dropping every player at regular intervals. Garry had a fix in mind, but it was tangled up in the ongoing weapon refactor, so it would arrive with that - hopefully testing on the dev branch the week after.

The devblog question

The summary was a candid one. Garry felt the team had been guilty of working for the devblogs rather than for the game, which is exactly how something like optimization ends up neglected - game development isn't always sexy. That prompted a rethink about whether the blogs contributed anything to the game itself, and whether concept art, ideas and model renders should be posted at all, or only things that are actually in the game. The conclusion: the development cycle should feed the game, not the devblog audience.