Devblog 114

Since the line-of-sight and distance verification for projectiles has gotten quite solid I decided to add a similar system for melee weapons this week. It uses the same lag compensation as the one for projectiles, so it should be just as reliable and resistant to false positives. The line of sight verification is especially important since it prevents exploits that allow people to deal damage to sleepers, storage containers and cupboards through walls.

There’s been a long-standing issue where the server was spamming messages about missing projectile IDs and even though we addressed a number of situations that could cause this we never completely eliminated it. Turns out the one remaining issue was the server side weapon firing rate not compensating for client to server delay and effects from weapon attachments. This could lead to fairly wonky weapon firing rates, especially for people with unreliable connections and inconsistent server pings.

I got back on decay this week in order to continue our efforts for better client and server performance, especially deep into the wipe cycle. I added decay to many more deployables, like wooden boxes, in order to fight escalating entity counts. As a counterweight I made it such that opening a storage containers resets the decay timer on them, which should help smooth over the transitional period. Doors of course still reset decay on both building blocks and deployables, but I’m now using the building ID I added last week to only reset decay on building blocks that belong to the same building as the door.

Over the course of the week we tested the advanced fly and jump hack protection mode on some high population official and community servers. After fixing the initial chunk of issues it now finally seems to be ready for prime time. In our tests it didn’t affect server performance in any way, but if you’re a server owner and notice performance issues with this patch, try reverting to flyhack_protection 1 and let me know if that fixes the issue.

We had some difficulty getting everything from main merged into prerelease but finally got everything up and running, sorry for the outages throughout the week and thanks for continuing to play and provide feedback. Due to these changes we can now maintain parity between main and prerelease much more seamlessly. This brings us to the D3D11 crashes which are now are highest priority. Based on our research so far, these crashes seem to be related to Unity’s multithreaded D3D11 implementation and can be avoided by using the -force-gfx-direct command-line parameter in the game’s launch options. Unfortunately, this option forces single-threading and may affect performance considerably so please consider using D3D9 until we get this problem sorted out. We also had the chance to nail down some new XP earners in prerelease. After much internal discussion and debate we decided on adding fractional ownership for items. Let me explain how this works: first of all, ownership of items is going to dictate how much XP is earned when the tool is used. So if I craft an item and give it to you, I’ll earn a percentage of XP when that item is used somehow. Now with fractional ownership it basically means that each item will store what % of the item is owned by whom. This means if you harvest the resources and craft a hatchet, you’ll be 100% owner. But if you were given the resources by someone else and craft it, you and the provider will both be 50% owners. This comes into play if you decide to give that hatchet to a third party and they begin to harvest resources with it: the harvested resources ownership are then split 33% by the crafter, the harvester, and the provider. Ultimately the goal here is so there is a big incentive to helping other players. While you don’t need to do this, being a provider for new players can lead to you having many XP streams and advancing faster than a recluse. This is something we need in Rust. It’s very hard to make people cooperate and very easy to make everyone want to kill each other. I think this will be a good first step. After this is added I want to phase out earning XP from harvesting rocks and trees and instead have that XP distributed when those resources are actually used to craft something. These changes should be live in the next couple of day,s barring any insane roadblocks. I’ll make a post on reddit asking people to try it

Some good stuff done this week, one big prop or structure rather: the trainyard crane. This was the last of the bigger structures for the industrial set of buildings I have been working on. I have given it a small room at the top, which will provide you with a tiny shelter in case you found the cranes to be a bit too over exposed. I moved on to the smaller things. We needed garage doors and a set of doors so I’m tackling this at the moment. Doors in dungeons will work exactly like players doors, with an action to open/close. You cannot pick them up, and I think only a minority of them you will be able to destroy. Generally doors there should stay unbreakable for the sake of keeping the experience balanced for everyone. Now the question I can read on everybody’s lips, ‘Will we be able to place those doors in our bases since they use the same technique?’ Answer is yeah, probably but later.

Progress on the heavy armour this week, you can have a spin around an untextured WIP of it here:

Helk wanted me to address a dubious tactic: some players would fill up their quick slot inventory with several Pipe Shotguns, allowing them to fire a shot, switch to another loaded Pipe, and fire another shot. The delay when deploying the shotgun was too short so I adjusted the deploy animation to take a little longer. Now the delay between switching shotguns and firing them looks like this.

I noticed several of the player clothes exhibit an unnatural, Gumby-like bending at the joints, as illustrated in this video. I modified the skinning so the joints don’t lose their volume so drastically. It now looks like this.

Several of the LODs for the animals and third-person weapon models had excessive vertex counts due to the model’s normals not being unified (ie. some of the vertices had more than one normal, which resulted in Unity creating extra vertices when the model was imported). This is what it should look like on LOD3: absolute minimal smoothing groups or only one with one line per vertex. But this is what our LOD3 looked like. Super crazy. You can see the difference in vertex count in the before and after picture, when all the vertices have been unified. We realized that this issue was a side effect of Maya’s LOD plugin, so I went through all of the offending LODs and fixed them. They now use far fewer vertices in Unity, which should result in a slight performance/memory boost.

Still waiting for Paul’s shotgun concept, but in the meantime I’ve nearly finished up on an old concept of his: the mortar!

Taking the Double Barreled design towards final now. I'm having a lot of fun with this: I took it into 3D and started designing with the first-person in mind, giving it a cool, chunky shape that looks like it would do some brutal damage up close. I like having lots of bolts/screws and springs visible in a style I'm starting to call ‘DIY Punk’, so you get a feel somewhat for how this thing fires and operates.

I’ve been plowing through music implementation stuff this week. I made a bunch of tweaks to the playback system so we can smoothly and immediately bring new clips in in the middle of a section and everything stays nicely in sync. I’ve started linking music intensity changes up to in-game events. It’s really easy for us to tie intensity changes to pretty much anything. Intensity will be bumped up slightly if you’ve got a weapon equipped, or there’s a helicopter flying around. It’ll get a bigger bump if a bullet flies by your head, and an even bigger bump if you take damage. If nothing has happened during a given section of music, the intensity will drop a bit at the end of each section, so we get a nice natural sounding migration back to zero intensity. I spent some time working on a UI to set up and arrange our songs and did a few other little things to make this nicer to work with in Unity. Each of these little blocks is a clip of music. The sliders in the boxes define the intensity range that a clip can play at in a certain section of the song. The green/blue colored boxes are clips that will play at the current intensity level, and the column with the green boxes is the currently playing section. Previously this data was all in a huge list of nested dropdowns and was a total pain in the ass to manage, and the visual indication of what’s playing back has helped quite a lot already too. All that’s left to do on this now is:

• Set up a system to decide which songs to play and when. This will work similarly to the ambience system, we’ll change songs depending on what part of the map you’re in, the time of day, the weather, etc. I’d eventually like all the monuments to have their own theme song as well.
• Finish tying intensity changes to in game events
• Chop up the songs we’ve got now and set them up
• Write more music!

I’m aiming to get this stuff included in next week’s update, but it’ll be disabled by default with a convar for the first week or two so I can test it in a live gameplay environment and spend a little bit of time fine tuning everything before we launch it for realsies.

More progress this week on adding the new aiming system to throwable weapons: