Devblog 118

There was a very, very bad bug in the code when the XP system was introduced. 100% XP earn was given to each owner regardless of their ownership fraction. This meant that even if you owned <1% of the tool you still got 100% XP. This lead to some players earning ridiculous amounts of experience points. We’re talking one level per minute. This has since been patched thanks to André. We’ve also made the following changes to the XP earner system:

• Maximum XP you can earn from any single player is limited to 6XP
• No more XP gain from the usage of resources
• Each time you craft an item for the first time you will earn 0.5XP
• XP diminishing is in effect: the more an action is done, the less XP it yields

These changes will mostly affect groups boosting each other. All your friends can go out and harvest for you all they want, but you will be met with diminishing returns and a maximum. It’s better to meet new players as the first XP a player earns from you will come quickly.

Due to the exploits, bugs and oversights, we had people reaching level 50+ in a matter of hours, fully unlocking all equipment and running around the server with C4 and AK47s. Now that we’ve patched all the exploits and nerfed some of the XP gains any ‘regular’ player--or someone just joining the server--would have to compete against that, and we don’t think that’s fair. Also, we have no way of tracking the speed at which players are legitimately earning XP and leveling up, so we can’t really make any adjustments in the future based on this XP cycle. Because of these problems, we’ve made the decision to wipe the game and start fresh. This also includes a map wipe to remove the stacks of AK47s and other items being hoarded that would provide an unfair advantage to everyone starting new. I know this sucks and I’m really sorry, but we need to get it out of the way now so we can improve the game. I want everyone to know that this is absolutely not standard practice and we never intended for XP to wipe at a frequency higher than blueprints. Please understand this was not supposed to happen for months, and as I expressed on reddit, I’d like to extend my sincere apologies to you all. These things do happen from time to time, and it’s part of the reason why we still have the Early Access tag on the game, but we will do our best in the future to mitigate any situations like this arising again. That being said, we have added a way for server owners to backup and restore their XP database, effectively giving them the option to skip an XP wipe like this one. Server owners can update their servers, and then take the following action to restore the XP database and savegame in the server folder:

• Rename “xp3.db” to “xp4.db”
• Rename “UserPersistence.db” to “user4.db”
• Rename “0.sav” in the “save/Procedural Map_3000_1234” folder to “proceduralmap.3000.1234.132.sav” and move it to the server folder such that it’s next to the “xp4.db” and “user4.db” files

Note that in this example 3000 is the world size and 1234 is the world seed. The number 132 is our current internal savegame protocol, which is the same for every server after the update.

Next week I’d like to add the ability to set an XP multiplier on players. Once this is in place we can do things like have double XP weekends from time-to-time, or add a feature that gives you an XP multiplier bonus if you’ve been offline a long time (giving casuals a bit of help against no-lifers). We can also then limit the XP earned when offline if this becomes a problem. We’ll be watching and making balance and tech tree changes, and adding new ways to earn XP. We’ve also got to start looking at something that will allow you to forfeit all your XP for a worthwhile bonus, effectively allowing you to play again (think prestige mode from Call of Duty), further limiting the need for XP wipes.

After the first release of the new airfield last week, I moved on to improving or finishing the area to a good standard. I can polish it further in the future, but it's now a lot better. That included redoing hangar models from two years ago that did not reach the quality mark I want the environment art to sit at. Here’s the new ones: After this I'll add a power sub-station ground to the Airfield, in the brick-walled section of the area that's empty as of last patch. This little substation will connect with procedurally-generated powerlines in the future and make a neat end-of-line connection for those instead of an abrupt stop.

We have a Staging server that we were doing all the testing on, and the performance was great. When we released we realised that the server performance was shitty. Really shitty. After some investigation we found that the servers were stalling when saving XP data to the database on disk. We didn't notice this on our test server because it has super fast hard-drives, but most game servers don't have them because they generally don't need them. So I made a bunch of changes, a bunch of optimizations, and got it working relatively well. To stop this from happening again we've got a bunch more staging servers running on regular hardware.

Servers were using a lot of bandwidth, so I added a bunch of diagnostic tools and unit tests and optimized it. If you have a low bandwidth connection you should find that things are a bit better now. If you're a server owner you should find your bandwidth usage is less.

The rebooted gunplay systems are now live. Gunplay has been one of the main concerns of the community for a while and we’re thinking we’re finally on the right track now. I explained most of this with a fair amount of detail in devblog 117, but here’s the gist of it:

• New hitbox system (clothing no longer affects hitboxes)
• New weapon damage model (more predictable body damage multipliers)
• New projectile weapon hit detection (best-fit hit detection for reliable results)
• New clothing and armor protection system (less random protective properties)

The aim of all those changes is to make gunplay feel more precise and predictable. While it’s certainly not perfect yet it should be a huge step in the right direction and offer us various tools we can use to improve it even further in the future.

This one has been around forever. In rare cases people could be building blocked everywhere on the map until they died and respawned. We’ve never been able to reproduce this reliably so it wasn’t easy to track down, but it should finally be fixed now - make sure to let us know if you’re still encountering it.

Moving on with my continuous efforts to combat cheating and exploiting, I took on a number of long standing issues this week. I fixed a building design exploit that made the outer walls of a tower immune to rocket damage. Next I tracked down another exploit that allowed object placement through rocks and enabled people to build rock bases. Lastly I fixed a helicopter exploit that utilized glass windows around the new monuments to be almost entirely immune to damage from the helicopter machineguns.

I took on a few false positives from our in-house anti-hack system this week, both of which could lead to the server rejecting legitimate bullets from the clients. One of them was caused by some legacy code that should have been removed a while ago--this is the one that showed the “AntiHack!” message in chat--the other one was simply due to the projectile speed verification being too strict under certain conditions. This should all be taken care of now.

Servers can now set a “server.branch” startup parameter to force all clients that try to connect to be on a certain branch of the Rust install in Steam. We’re using this to keep new players from connecting to the official staging servers just to be unable to connect the next time we increase the network protocol or to be confused when they are restarting, breaking or wiping more often than expected.

Work continues on the bone armour rework. I've been working into the details a bit more, adding a lot of straps, ties and small bones. I'm trying to make it look really authentic in its makeshift assembly. They're small details, but I think they go a long way, and it's definitely something that makes the existing bone armour feel a little lackluster.

This week we've introduced a few new anti-aliasing options. We had only two options, either off or on. When enabled, it used our default implementation which was based on subpixel morphological antialiasing and while it's robust it can also be a tad slow. We now provide two extra options: a low-end FXAA or fast approximate anti-aliasing, as well as a mid-to-high-end solution TSSAA aka temporal supersampling anti-aliasing. Combined, these should make anti-aliasing affordable for GPUs at any price range. A higher resolution comparison for more a more detailed analysis: Please note that TSSAA is a work in progress. You may expect the results to be a bit blurry, especially in motion. It's based on Unity's implementation and certainly will improve over time. If you see a black sludge spreading through the screen until it all becomes dark, don't panic, just disable TSSAA. This is a known issue and should be mitigated over the coming weeks.

There was already some fine work done by Andre in the past few months to improve draw call batching and we now have to complement that work by looking at runtime shader, texture memory bandwidth, latency and footprint. This week I started looking at performance from top to bottom as well as actually addressing it. I've already identified a few bottlenecks besides those we already knew about. The first change we're introduced was a slight reduction in arithmetic computations in the shader lighting computations. Just is just a drop in the bucket and we need a bunch of drops to actually make a difference. I'll be aiming for a solid 60 FPS experience at 1080p on a NVIDIA GTX 960 (and comparable cards from other vendors), assuming the CPU is not the bottleneck, while keeping aesthetically pleasing visuals. We're likely ending up with a combination of optimizations and default setting tweaks. There's a ton of work ahead of us that should span across several weeks. I'll keep you posted on developments.

First thing I worked on this week didn't come off, so after that I looked at fixing some issues on the crossbow we've had for ages. These included:

• Deploy anim not being triggering properly
• Shearing of the wrist due to too much twist during the reload anim
• Anim length not matching the reload time, causing clipping if using ironsight
• Idle loop bumps
• Shaking of model & bow near end of reload
• 'fire' anim not feeling satisfying

I finished up the LODs and textures on this. I wanted some visual difference to the default grip i.e lighter colour to the wood and with some saturated colours to tie it in with the rest of the gun. I am planning to make more variations of our weapons so you can have some fun customising your stuff when they are implemented (check the bicycle stock below).

A new Unity update came out that’s sorted the crash issues we were having with the build server, so music stuff is ready to go out now (much love to Andre and Garry for the time they spent helping me try to track that down before the update). We’ll be playing it safe and waiting until next week to push it out though since we cocked the game up last week already. I did a few little tweaks to how music plays back in the main menu, fixed up a few things that got overwritten in the bullshit crash chasing we did last week, and added a console command “music.info” that will print information about the current song, section, and intensity level to the console. Once we push this out I’d love it if you guys use music.info to tell me about anything that feels off or feels awesome next week!

I noticed that some of the player animations were holding the weapons in such a way that they weren’t pointing in the direction the player was looking. I believe the bug was caused by a recent update to Unity, so I went through all of the offending animations and corrected them. I also tweaked some of the gun fire animations so they look more violent and abrupt. I went over the hunting bow animations and improved them a bit by tweaking the position of the hand that held the arrow as well as fixing up the head rotation so he actually looks like he’s aiming the bow. I also added pre-throw animations for the rock and spears so people will know when a player is about to throw them.

After finishing up on the stock variation for the Double-Barreled Shotgun, I thought it would be a good idea to make more variations for the SMG, which will hopefully be useable on other weapons such as the AK47. Now obviously the programmers are focusing on more important stuff at the moment, but my hope is that we will have a good amount of variation when these (and more) can be implemented. The idea with the bicycle seat stock is to reduce the recoil with the springs. If there are any ideas you guys and gals think are cool and practical, let us know!