I’ve overhauled the armor UI, making it much easier to figure out exactly what is going on.
Hovering over a segment of the player preview shown on the left will display the amount of protection for that body part: Head/Chest/Legs.
I’ve also changed how the display works, so it shows everything as a percentage of damage reduction.
You’ll also note that selecting a piece of armor displays the protection in an easy to read manner, as well as information about which areas that piece of armor protects. Perhaps most importantly, you can now see what protection a piece of armor provides before you craft it!
A few other notes. You can now wear the bandana with the riot helmet, wood helmet, and bucket helmet. I also reduced its kind of insane projectile protection from 10% to 5%, but have increased its cold and radiation protection.
P.P.S. I fixed a bug where the bone armor wasn’t protecting the legs… oops.
P.P.P.S. There was also this weird thing going on where the arrow protection was different than the bullet protection for some pieces of armor. I’ve rectified this and unified them to be the same value.
After listening to feedback last week, I’ve made some changes to the tree minigame to improve how it feels. You’ll notice that the first X appears relative to the first impact position, and not at a random position on the tree, allowing you to get started easier. The subsequent markings also appear closer together than they used to, and will always go in the same direction i.e. if it started out going left, they’ll continue to go left.
Personally I feel this makes the game feel way better, and you can really get into a nice groove where each swing is a hit. I think this will bring it more in line with what people have come to like about the ore minigame. Let me know if this is an improvement.
I fixed some bugs with explosives, namely with the bean can and satchel charges. If you throw a satchel at another satchel, it will ignore it and instead attach to the object the first satchel is on instead of just bouncing off as it used to.
I also fixed some issues with satchel charges acting like thrusters in Garry’s Mod when they become duds and are attached to vehicles. This could cause the vehicle to behave strangely or float away. I also added a feature where dud explosives detach from the object they are attached to if that object moves. This is to say if you throw a satchel at the Bradley and it doesn’t go off, it will fall onto the ground where it failed and you can retrieve it. I’ve also made it so in this instance picking the satchel up will not ignite its fuse, as that would be an extremely frustrating waste of resources.
I got wind of a few performance issues and sorted them out. One of them had to deal with the ‘quick craft’ UI populating with new items as they became craftable, taking a very long time as it tried to find the appropriate skin icon. This exhibited itself when your inventory was filling up with new items i.e. looting someone in PvP could lock things up for several seconds at a time. I’ve since made it so the quick craft items always show as the default icon, and this lag is now gone.
There was an issue where the map would be constantly updating as the player was running, even if it was closed. This could eat up a significant amount of CPU on some computers. This is now fixed.
Lastly, the X’s on trees were being networked to every client, every time it happened, which could lead to decreased server performance if a lot of people were chopping trees all at once. This has since been resolved.
I’ve been working on a new place to explore in the Rust universe. That’s right, the rustiest place you could imagine for our game: a junkyard!
Here’s some pictures of the current progress, and if everything goes well it should land during our next wiping update.
Now we just need to add tetanus…
This week I pretty much completed the new building system. I started by allowing foundations to snap to each other at a vertical offset of half a wall. Then I added half height walls that can be used to even out that offset on the higher floors. With half height walls and a floor you can of course also construct your own half height block – if you’re still nostalgic for this long removed building block type.
I also addressed a performance problem that might be known to those of you who like to build massive bases. The way the building plan worked it always had to create socket colliders for all building blocks around it, which could cause significant frame rate drops for some people when taking out the building plan or trying to place a deployable. I removed the need for those colliders altogether, which translates to less gabage collection and less frame rate spikes!
Roofs have often been abused for honeycombing by adding an internal wall layer behind the outermost walls of a building. This will no longer be possible with the new building system as roofs will occupy the wall socket at their bottom end and you will therefore have to choose between a roof or a wall. We’re doing this so we can explore the possibility of increasing the health of the roof building block to encourage using it as an actual roof.
Once all of that was done I went through all the old components and pieces of code that are no longer needed with the new system. The easiest code to maintain is no code at all. Now the only thing left to do is the implementation of the new building ukpeep system, for which I will hand over my branch to Helk.
Since Diogo updated our dynamic occlusion culling system to no longer require a separate occluder pass I eliminated all the occluder meshes from the building blocks. This reduces memory usage and eases the pressure on our mesh batching systems.
Due to limitations we had in the past our occlusion culling system was limited to players and NPCs. The improvements we’ve made over the past few weeks, however, have now made it possible for us to expand this capability to any renderable object.
This week I started working on making most of our objects, including deployables, rocks, monuments or even constructions, occlusion aware in order to help with reducing draw calls and overall visible triangle count which, at the moment, can easily rise up to a couple million per frame.
Did some support code to help Matt deploy hair colouring. Once he rolls out the colour variations, head and facial hair will be randomly tinted according to your steamid. Please note that randomization for hair pieces also changed so you may find yourself with a different hairdo this week.
When the time comes, the system we put together should allow us to implement some degree of player customization or aging, like custom dyes, hair growth, and haircut.
I’ve been making a lot of tweaks and improvements to the hair this week. Different skin tones now have specific hair and facial hair groups that they use, and also specific material values to make the hair blend a bit better to them. This should fix things like pubic hair and eyebrow hair having weird specular highlights that is especially visible on darker skin.
I’ve fixed holes and floating bits of geometry, like eyebrows not sitting correctly, and also tried to make some elements look a bit more natural, like reducing the size of the female pubic hair and widow’s peak on some hairstyles.
There’s now a hairstyle 3, which will add a bit more variety to the game. Implementing it threw up a few lighting issues which we’ve been working to resolve, but there’s more hair and facial hair styles that will be coming very soon.
I finished up the design of new tree sounds this week. Tree falls sound more full, impacts are a bit crunchier, all that good stuff. I did a few fun things with the implementation side of this too.
When a tree is getting close to breaking you’ll start hearing cracking sounds over the last few hits. Those add a nice touch of anticipation before the big crash of the tree falling.
There’s a bit of extra leaf rustle in the actual impact falling sound, but the lead up to it is a loop that gets louder depending on the speed the tree is falling. This should give a nice amount of movement (particularly when a tree falls perpendicular to you), since the sound is parented near the top of the tree. It also adds a little more variety to each tree fall, because the start position of the loop is randomized.
Most sounds in Rust are mono and play back from a single point in world space, but Unity gives us the ability to spread a stereo sound around the point it’s played from at varied amounts. This came in super handy for making the tree falls feel bigger. If you’re pretty close to them, they’ll sound like they’re enveloping you a bit more instead of playing from the exact point the tree lands. I kept the meatier parts of the sound like the trunk hitting the ground narrow and centered in the stereo field so you’ll mostly notice the spread on the leaves and lighter twigs.
When you’re circling a tree and playing the minigame, you tend to side step a tiny bit as the tree falls since you get in to a rhythm, which means the tree usually ends up off to the side a little when it breaks. It felt really strange to hear the tree you’ve been hitting break mostly on one side of your head, so I set something up to make the tree break sounds play partially in first person when you’re really close to them.
There was lots of little details involved in this, but it’s nice to have considering how much wood you need to survive.
I made some smaller general upgrades to the sound system and fixed a rare and obnoxious bug this week.
When I started working on Rust, there were some aspects of an AudioSource (the thing that plays sound in Unity) that could only be changed in the editor and weren’t accessible via code. The curves that define how a sound’s volume falls off with distance, and how things like first/third person blend and stereo spread change over distance were the main unscriptable things that I really wanted access to. That changed somewhat recently, so I set something up to allow us to override those default curves on a sound by sound basis. This came in really handy for some of the work I did on tree sounds this week.
I also fixed a bug where, if a sound was already in the process of fading out and it was told to fade out again, the volume would jump back up before fading again. This mostly manifested itself when we had a looping sound fading out and then the object it was attached to was destroyed, which triggers another fadeout for looping sounds. It took me a bit to track the cause of the volume jumps down but it was a quick fix once I found it.
Work continues on the admire animations, now including melee weapons.