Devblog 148

Safe trading in Rust has arrived! The Metal Shop Front provides the kind of feature that has been in MMOs for decades: the ability to safely trade items with another player. Each player, one on each side of the shop front, opens its inventory. They both put their desired trade items in and press accept. When both parties have accepted, the items will be deposited in the other player's inventory. If you hit the cancel button, or if the inventory is modified in any way after you’ve pressed accept, the trade will not complete. I’ve tried hard to make it exploit-proof, so let me know ASAP if someone figures out a way to steal items! A few other things to note: the glass is bulletproof, and if you press Tab or Escape to get out of the trade window quickly, all your items will automatically be re-deposited in your own inventory. I hope this leads to more cooperation and trading now that you don’t have to risk your life and all your items trusting some random person who wants to “trade”.

I fixed a bunch of bugs with the Vending Machines. For starters, you can no longer use Alt Look to look around and gain access to the other side of the machine, sneaky! Q no longer closes the menu (making it impossible to type High Quality Metal), I’ve added a little ‘Vending’ busy panel, and the purchase sound is now serverside so everyone can hear it. Vending Machine icons now show the skin of the item being sold. This feature slipped through the cracks last week. My apologies. But now you should be able to craft skinned items and sell them at a premium. Vending Machine purchases now reset decay, just like a door opening and closing. I’ve also made some changes to how vending machine administration works. For starters, you can no longer lock them; administration works for anyone if you’re behind the machine. This may change in the future, but I’d like to see how this plays out and how it influences design of trading posts. Lastly, you can rotate a Vending Machine if it is empty! This should be welcome news for anyone who placed one the wrong way by accident.

I’ve brought the Vending Machine screens to life this week. I was going to do a bunch of text and stuff, but thanks to this post on reddit I opted to mainly use icons. I still want to add some options for customization--like a message or two that will display on screen intermittently--but for now here’s how they look: They’ll only be visible when you’re within 15 meters, to save resources, otherwise they’ll fall back to the old full screen image. They cycle through all the sell orders in the machine that currently have stock and display the price up top. If no sell orders are available, it’ll display a big X so you don’t have to waste time. There's lots we can do with these moving forward, but for now they’re a nice little extra to have.

Not too much here, but I did add a small movement penalty to recoil when moving, and the pistol's aim cone has been slightly increased to make it more ineffective at long range (you don’t notice this up close).

The Python Revolver has had its damage increased by 18% and now benefits from a slightly higher re-fire rate. It’s also much cheaper to craft. I’ve also increased the Semi-Auto Rifle damage by about 15%, which should make it more viable in combat.

This isn't coming to the game any time soon, and when it does it has nothing to do with people needing an object that closes their doors for them because they are forgetful. It will be for trading areas and include an exit push-bar on the inside. Relax.

You can pick up triggered Bear Traps and replace them somewhere else if you have building privilege. You can also repair them. No idea why I didn’t add this sooner.

Zombies are on the pre-release branch. Don't get excited: they're a convenient AI for testing, since all they do is follow players. This video shows how AI can now navigate around properly without walking through rocks. It won't walk up or down super steep hills, or through walls.

I looked at ways to improve our animal animations. There's problems in the current animations with feet slipping, where the animation playback speed doesn't match the entity movement speed, so it looks like it's running on ice. I fixed that here. The playback speed of walk animations is now controlled precisely by the ground speed. As well as looking way better, this reduces the complexity of the animation controller and the amount of animations needed. I've also made the back-end lag behind the front-end, to give a more natural look. This was previously simulated using two extra "lean left, lean right" animations, but there's no reason we couldn't make this procedural.

When explosives destroyed a wall they could deal damage to objects behind that wall since the wall was no longer there when the line-of-sight test on those other objects was performed. I changed this so when an explosive explodes it first does all its line-of-sight checks and then deals damage to the objects. This means you no longer accidentally destroy Tool Cupboards or storage boxes when raiding a base.

I finished the base implementation of the new foliage rendering system this week. It sadly turned out to be too slow to go live with this update, but the good news is I spent the rest of the week moving all the heavy work to a thread to speed things up. It completely eliminated all frame rate drops from generating the optimized foliage batches. The only things left to do now are some art and shader tasks so I’m hoping to start testing this on the dev branch early next week.

When I implemented threading for the foliage system I decided to design it in a way that I can reuse it for our generic renderer and collider batching systems, which are mostly used for buildings. This greatly helps with keeping the frame rate consistent when new meshes are created or old meshes are removed since all of the hard work is done in a separate thread from the main game. People who have used Unity before may appreciate the pain I had to go through to get multithreading working in tasks that interact with Unity’s mesh API. Everyone else feel free to complain about the fact that this isn’t included in this week’s update because I implemented it on the foliage system branch. It will however definitely go to the dev branch on Monday to get it properly tested for next week’s update.

After that previous push for the overgrowth in-game, it felt like the right time to include some decorative items. I was a tad ambitious with this one since it turned out it needed a little more work than a purely decorative item, but nothing is lost. The fridge will gain more purpose in the future than in this current release form. Next I'll create some more decorative items: some for camouflage, some for comfort, some for storage. Your crib should start to look a lot homier real soon.

Last week we rolled out some visual improvements to the lowest shader level with some optimizations to make it possible. However, the low performance impact wasn't enough for some players running lowest-end graphics hardware, particularly integrated GPUs. Since this change wasn't meant to balance the game, but simply raise the overall aesthetic perception of the game, we decided to bring back the potato mode, enabled only when the lowest possible shader level (100) is set:

I've skinned and LODded the Heavy Plate Armour and finished its accompanying world models. Currently they take up the entire leg slot, so you can't equip pants underneath them (the default urban pants mesh is included in the model). At the moment the pants meshes take up a significant volume, which means we're either faced with clipping, or weird hovering meshes (like the current wood armour). Hopefully this will be a temporary solution, and I'd like to work towards a more permanent fix at some point (maybe through bone scaling or something similar). It's an issue that I'm coming across a lot - and we know it sucks to lose a level of customisation. It won't be available this week, as Helk will need a bit of time to make sure it's properly balanced, but expect to be able to cosplay as a tin-can next week!

I spent the last week dressing all remaining bunker rooms and getting them to the same standard as the room shown in the last week's update. I spent the rest of the week optimizing the scene and all the new assets I made for it. When I’m done with the optimization pass I'll be adding bunker rooms to some familiar areas, such as the airfield and the canyon sewers.

This week I implemented Tom's component and resource world models. There's a few outstanding models left, but 99% are in and working now.

This task was long overdue. I took some time to fix decals that spawn when shooting glass:

I made some new bullet impact particle effects for when the player hits glass. I also tweaked the sounds a bit.

I spent most of this week working on some improvements to the sound occlusion system. Previously, all sound occlusion checks just happened from whatever point a given sound was playing from, on a sound-by-sound basis. Now, any object can be set up as a sound source, and those sound sources can opt-in to handling occlusion for any sound that’s attached to them. A sound source can have multiple points that occlusion checks run from now. The turrets, for example, have an occlusion point at their base, at the middle, and slightly above the top of the turret, which means that if the base is hidden behind a wall but you can still see 2/3rds of the turret, you’ll still be able to hear it. We’re also using the number of occluded points to decide how much we should turn the sound down by, which feels nice. This is currently only set up on objects that have looping occludable sounds (campfire, furnace, turrets, etc), and it’s disabled by default until I get a chance to test it on a populated server in the wild. You can change audio.advancedocclusion in the console if you want to turn it on now though.

Currently all of the logic that controls individual sound playback runs with a maximum milliseconds budget per frame. I pulled some other smaller bits of the sound system (the new sound sources, reverb triggers) under this budgeted update this week. You shouldn’t notice anything different on your end, but I wanted to make sure that occlusion checks from sound sources were going to be kept in check too. I also started working on Vending Machine sounds and fixed a bug this week that would cause music clips to overlap occasionally (mostly while loading a map).

I completed new third-person animations for the M249, Thompson, and Magnum Revolver. The guns also animate during the reloads as well. Currently, there’s some slight sync issues with the player animating and the weapon animating (bolt moving, parts opening, etc. ). I’m looking into ironing those out, but it’s a bit tricky since the player and the weapon are separate entities, and it’s difficult getting them to play their animations at exactly the same time. You will might see some small timing issues, such as the bolt moving before the player’s hand actually touches it.