Devblog 95

I spent more time writing music this week. I’ve got the piece above fleshed out most of the way and got a really good start on a second piece (which I’m saving for next week’s blog because I am a little in love with each post having theme music).

Those are now implemented and working. We know that the fence and prison wall display an ‘Open/Close’ option right now. This bug will be ironed out soon. Shout out to Rustafied for the header's lighting inspiration.

I started to work on the floor frames and a couple of floor blocks. You can see the grill floor block in the prison cell video above. The block that will probably get the most attention is what I called the ladder-hatch: Works like a door and can take a lock. Due to the current nature of our lock placement, you can access the lock from underneath the hatch easily and less so from above it. The hatch is a three part mechanism consisting of a few hinges and sliding pieces. I can see a lot of great benefits coming from it when incorporated into your base design. The new floor blocks still need more testing and will stay on pre-release for another week before release.

I took some time to look at crashes again this week. I hooked up a crash reporter and analyzer. So now we've got a system that not only retrieves all the crashes sent by clients, but also processes them using the correct symbols and groups them together as best it can. Which means we can organize them and prioritize them. Like here - where we've got the top 50 stack traces organised by how often they're happening. The top report is in "nvwgf2umx", which is some Nvidia driver dll I guess? We can't do shit about that. It's either an nvidia problem, an out-of-memory problem, or a Unity problem. I've opened a support ticket with Unity in the hopes that they can find out what's causing that one. The second one down is in "steam_api". This is something we can fix! Steam_api.dll is used by the 32bit version of Rust on Windows. Now judging by the frequency of this crash and the stack trace, I'm guessing we've been shipping the wrong version of this dll, so I've updated all of our Steam dlls to be the same versions and I'm hoping to see a big decrease in these reports over the next week. The rest seem mostly renderer and sound based, and are most likely Unity's domain. Well, the ones that aren't out -of-memory crashes anyway. I've reported a few of these to Unity already, and I'll work down the list as we knock them off the top.

Since I was on attachments last week this seemed like a natural thing to move to, and it’s something that has been requested since the beginning. The model is temporary until Tom finishes the real deal, but it works as you’d expect. It takes the same slot as the holosight and gives you a roughly 4x zoom as well as some recoil reduction. This is probably going to be a game changer and is probably going to be overpowered so I’ll be watching over the next few weeks and listening to feedback and adjusting as we go. It’s a little rough around the edges so expect it to get better in the coming weeks. Enjoy!

There were a few issues with the attachments we added last week. One flub was the lasersight gave its bonuses even when it was turned off - haha! Fixed. This fix also allows us to do things like add penalties/bonuses when scopes are zoomed in/out. I also fixed the exploit which allowed people to swap weapons in such a way that they would see their laser/flashlight but have it be invisible to everyone else. Lastly, I removed the holosight projection code which always put it overtop of where the bullets would land, this was responsible for a good amount of the red dot jittering that you saw. It’s not perfect, but it should be much better. I ran out of time this week, but I’d like to bring the holosight closer to the camera so you get a wider field-of-view, and I'll take a look at standardizing the zoom levels for all weapons without sights.

After last week’s patch I did an optimization pass on our current dungeons greybox models. Now it’s not common to make LODs for such models because they are temporary, but we’re an early access title and our rules become somewhat different: it will be a few more months before all of the greybox is replaced, so it makes sense to give players better framerates ASAP. I then had a look at our rocks LOD distances, which I had kept close to the previous generation of rocks. The fact that the new ones produce less popping allowed me to drastically reduce the LOD switching distances without too much of a visual impact, and save a couple hundreds thousand triangles per frame on procmap. Let us know if you see better performance overall after this patch.

I’ve started working on sounds for all the new building blocks. This mostly means open and close sounds for the new doors and hatches, but I’ve been working on impact sounds for the chain link fences and some glass windows that are in the concept stage too. These aren’t quite finished yet, but they’ll be in game next week.

I've been going through some more clothing adjustments this week. I've taken the opportunity to rework a lot of the skinning on most of the clothing. The shoulder area in particular was deforming in some strange ways on most of the pieces. It's a tricky area, and it'll never be perfect, but you can see how the stretched artifacting has been reduced. So as well as the clothes fitting nicely, you should notice much smoother deformations too. I think the bulk of it is done, and I should be able to finish the rest at some point next week.

There was a problem with the looking at code I added in last week: when you're looking right at something you usually want to use that object, not the one off to the side but slightly closer. This was really obvious when you had a bunch of crates close together and you'd have to fight and position yourself to open the right one. So now it prioritises that correctly. If you're looking right at an interactive object that will always be the one that you interact with. The radius thing still happens, but only if you're not looking directly at something.

We had a problem with pumpkin plants: on one of our servers we had 400k entities, and over 100k of them were pumpkin plants. The problem is that they just don't die. They keep giving seeds, but they don't die off. The long term goal to solve this is that you're going to have to water them and shit to keep them alive. For now I've hard-coded their mortality so they live for up to seven seasons or three harvests, whichever comes first.

I’ve made some big progress with the flamethrower. Helk has spotted a few things that I need to fix, but you can have play around with the model below! If your internet is rubbish here's some screenshots:

Because we’ve got the attachments in game now, we’re making more attachments... duh! So here’s a scope model you can play around with. And some screenshots.

You know how player movement in Rust often felt sluggish, delayed or indirect? Turns out this wasn’t as much the player movement itself but the post-physics camera position smoothing which incorrectly applied to horizontal player movement. This is now fixed and to me 60 FPS finally feels like 60 FPS again, which is great news for those who play at 60 FPS - congratulations to the two of you.

I finally sat down this week and thought about the problems with our building conditional model system and ways to improve it. If you wonder what the hell conditional models even are - they’re things like wall corner pieces or roof sides that have to appear or disappear depending on the building blocks that surround them. Here’s a list of things the new system should be able to do:

• Run on the server to be able to change colliders (like roof sides)
• Free of physics queries (performance)
• Fast enough to run on all building blocks (view distance)
• Remove pieces of building meshes that cannot be seen (like inside foundations)
• Tie in nicely with batching (without forcing batch refreshes all the time)
• Be reliable (no more incorrect wall corner pieces)

The primary reason to do this now is because it will help us improve the performance of huge player-made structures, but it will also allow us to do more complex conditional model checks in the future. I’m not completely done with it just yet, but things are looking very promising so far.

I’m not quite sure what happened, but our project animal footstep folder was a complete mess and animals were missing footstep sounds on most surface types or using incorrect sounds on those surfaces that were set up. This is now fixed, so you can once again hear bears coming shortly before they maul you to death.

I've been working on the levelling and XP system on and off. I've made some quite good progress. It's still about a month away from being ready to be tested, as we want to really get it together, working and polished before throwing it out to the public. The systems of gaining XP are mostly done. We just need to sprinkle gain points around the code. The way this works is that every item has a limited amount of XP with diminishing returns. So, for example, the first time you chop wood with a rock you're going to be getting a lot of XP, but that's going to fade down and get harder and harder to get XP that way. But by then you'll have earned enough XP to be able to gain it from chopping wood with a hatchet. Obviously gathering resources is only one way we're going to give XP. Pretty much every survival action will gain XP, every time you do something new. The only thing we won't be rewarding (or punishing) is killing other players, because that's rewarded enough already. The next step is revamping the blueprint system. At the moment blueprints are found or researched. This has its pros and cons: it’s fun to go looting and not knowing what you’re going to find; it’s fun to collect them and give them to friends. But it’s also terribly unpredictable, inconsistent and grindy. It’s really not a friendly way to do it. The plan right now is to make blueprints become available when you level up. You will spend your earned XP to unlock them. The blueprints will be organised in a tech tree, so, for example, you won’t be able to unlock a stone spear blueprint without first unlocking a wooden blueprint. I've spent a day or two working on an editor for this. Quality of life tools like this is one of the places we're really weak on in our development right now. It means that instead of going through items one by one setting the levels and then trying to remember which level they're at in relation to the others, we can see all the important data and edit it together. This is going to make a huge difference to Rust, and we know people are worried about it. Our feeling is that once you get used to it, it's going to make the game more enjoyable and easier to understand for everyone.

Been thinking about this idea for a while and working on it off and on, finally got it done! This would be another great place to spawn high quality loot and reaching it would be especially hard because of the equipment required get there.