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

Devblog 39 closed out 2014 in December with three themes: lerping, performance, and skins. It's a good example of the era - two genuinely absurd bugs found and killed, a movement system finally built properly, and a long tail of fixes across building, locks, sound and UI.

Lerping fixed

The recurring question of "why do players move so spazzily" had a name: lerp. Player positions arrive from the server roughly 10 times a second, and making that look smooth without interpolation would require sending them 60 times a second - which was never going to happen. So the client interpolates linearly between the positions it receives.

The problem was that Rust's existing interpolation was, in Garry's words, a rushed ten-minute job. This week he wrote the real thing: the same kind of system any normal networked game in 2014 has. It keeps a record of server positions, orders them by time received, and moves the entity along those points at a point in the past derived from ping and the interval between updates. Every entity uses it, so players move far more smoothly and airdrop planes glide across the sky as they always should have.

Performance: two very silly bugs

Server-side, Garry spent several days working with Aaron and his community on stability. Servers had long suffered drop-outs and struggled once a lot of buildings existed. The result was 100 players on the Amsterdam server with 45,000 entities, including 120 chickens, 65 wolves, 60 stags, 58 bears and 51 boars all running around at once. Much of the work went into adding profiling points and time warnings, so future lag can actually be diagnosed.

The big culprit was building stability processing, which contained a recursion bug that could lock a server up for ten minutes under the right conditions - also making loads slow and shutdowns slow. That's fixed, though the stability system hadn't been tested at the new settings, so more instability was possible. Early reports suggested it was more stable, which Garry again called the right side of the line.

Client-side framerates had become dreadful - 20 fps in places even on Garry's own high-end machine. The cause turned out to be every weapon entity that had ever existed spawning in the sky 10,000 metres above players' heads. That alone would have been survivable, except some of them were torch models, spewing particles and light. Once resolved, the framerate improved dramatically, with plenty of favourable feedback from servers.

Melee screen swinging

Several players reported that the melee attack screen swinging made them feel sick. It had already been toned down a lot but remained a problem. The long-term plan was an option to turn it off entirely on the new options screen; short-term, the aim was to find a comfortable level and identify exactly what causes the nausea. Three effects can be in play:

• ScreenBounce - like an earthquake or gun recoil shake. Probably not the culprit, since most games do something similar.
• ScreenFOV - bounces the field of view. The most likely offender, because it's unusual and changing FOV changes a lot about the scene.
• ScreenRotate - alters pitch, roll and yaw. The most obvious effect and a strong candidate.

Feedback was requested, specifically: which weapon, and whether it's the swing, the impact, or both.

Building skins and concept art

Vince's work on the building models was going well enough that Garry advised players not to upgrade walls to stone yet, purely because stone looked bad next to the new wood. Wooden stilt foundations and real stairs both arrived. Meg and Howie also produced a run of concept art describing where the team wanted to push Rust.

Fixes and smaller changes

• Ore resources fixed - they weren't giving enough, and sometimes gave the wrong resources. Ore nodes were flagged as temporary, with the intention being for gatherable rocks and ores to spawn on existing world rocks, the same way log piles were outgrown
• Large wooden box capacity fixed
• Servers now auto-save when the quit command is called or when auto-updating
• Fixed the cupboard exploit where you'd place your guide then back out of its influence
• Rebuilt the console, after a spamming MissingMethodException was tanking framerate
• Fixed bullet effects appearing on parts of an object you weren't shooting
• Fixed sleeping bag respawn sometimes not being offered
• Server death messages now show why a player died, such as hunger; server log now shows the disconnect reason (time out, disconnecting, quitting)
• Fixed the active item staying active after being dropped or deleted
• Fixed object tooltips not updating until you looked away and back; sped up tooltip effects
• Locks can be deployed normally again, and show a ghost guide when placeable
• Fixed water refracting objects in front of it
• Fixed the server running unconnected players' network queues, and errors when a cargo plane launches
• Fixed bushes being hittable by melee and bullets
• Loading screen now shows connection progress
• Walls placed on a foundation or floor now face outwards by default
• Added server.compression, off by default as it can be a CPU hog
• Animals made more sensitive to some damage types; some melee weapons now distribute multiple damage types; fixed the torch not having a damage type
• Fixed some sound volumes and distances

Wrapping up

Garry was happy with the week - the game felt good, ran well, and mostly looked good. Radtown and blueprint work was nearly done but got shelved when performance took priority.

On the commercial side, the answer to repeated Steam Sale questions was no discount. Instead a 4-pack was added, at four for the price of three, which as Garry put it is kind of a sale except it always costs that much. With Christmas and New Year arriving he expected to keep tinkering himself, but told players not to expect anything significant from the rest of the team until January.