Devblog 173

I tried so hard and got so far, but in the end, the bradley didn't make it this week. A metric shit tonne of progress was made with the bradley but not enough to put it into a shippable state. I expect 1-2 weeks before you see it live, but definately on staging next week. I've set up a connection of nodes and paths on the launch site for the bradley to follow and it no longer blindly goes around in circles. I've added interest points that it will randomly patrol between to search for targets. Once a target has been found it will engage it and if that target becomes invisible it will find the best palce to move to to engage it. There are now tread and engine sounds and the coaxial gun on the main turret is functional. I also sorted out a bunch of movement bugs, but more remain. Moving forward, I have to finish the path at the launch site and increase its resolution so sneaky players can't find exploitable positions. And in the event a player DOES find an unreachable position, the bradley needs to know to flee. There are a bunch of edge cases that need to be sorted out like speed limits in tight areas and I still have to implement targeting more than one player at a time with the many weapons the bradley has. Also missiles. Check out some media from my work this week :

Some armors weren't being used as much as they should be so I've gone ahead and tried to make them a little more accessable. Bone armor requires cloth instead of rope, as does its accompanying helmet. I've also removed the sewing kit cost from the riot helmet as about 5 are crafted on an entire server per month.

Man, no one uses the heavy armor. I get it, the nerfs were a little much. Now the heavy armor helmet blocks 90% of bullet and arrow damage, and the chest/legs block 75% of bullet damage Given the vision obstruction and half movement speed you're going to take more shots anyway so perhaps these values aren't too crazy. I'll keep an eye out for feedback

Seems like most of the feedback since the most recent LR300 changes has been super positive. Because of this I decided I may as well start expanding it to other weapons. You'll now notice that the AK47, M92, and P250(SAP) All have learnable recoil patterns and have had their aimcone reduced bt 80%. I think we're in a good place now but you'll all have to let me know how the recoil feels for these weapons. I've also disabled recoil compensation on any weapons that use learnable recoil as it is kind of buggy and really intended for consoles only. The normal disclaimer applies - Don't get too butthurt if we end up changing the recoil patterns as time goes on, they aren't set in stone. That being said, I think they're pretty close to what we'll want eventually.

I made a good jump from the greyboxed Gas Station of last week over the last few days. It's now at a stage where most surfaces are textured, however there's still quite a bit of work ahead. I still have to make a damage pass on geometry, and wear pass over the materials. Once the structure is rock solid I will move to the smaller props that make this place, like the pumps.

This week I polished up the pitch tracking and engine cycle start/end detection enough that it worked well across the entire long recording, but sadly, during playback some slight variations in tone from the different acceleration ramps in the recording ended up standing out a lot more when splicing cycles together. Thankfully, the extra work to nail tracking down over the long file still benefits the results we're getting from the shorter file with a single acceleration ramp, and it's been succesfully able to track a few other engine recordings I've never tested it on before, so it wasn't wasted time. This does mean that we need another strategy to handle repetition reduction at static RPMs though. My first alternate approach will be grabbing engine cycles from nearby RPMs and pitch shifting them slightly. I've found having 6-7 cycles at a given RPM sounds natural enough. All of our groups of cycles have at least 2-3 so I shouldn't have to pitch shift anything by more than about 5%, which is small enough that there shouldn't be weird artifacts. If that doesn't work out I should be able to use the spectral data that we've already got from the pitch analysis to synthesize additional variations. I wired the current best system up to the Tank in game this week for the first time and it actually sounds pretty great already since the throttle control that's driving the engine is reacting to the physics simulation which keeps it from staying at static RPMs much at all. I'd almost be happy release it this way, but I'd like to fix the static RPM jankiness still if I can :) I've also started working on faking the RPM revs and dropouts that come with gear changes, and on support for using a separate recording for deceleration which sounds a lot more natural.

More work on the supermarket this week. I have polished the main building which is now mostly finished. There's still some damage I want to add, such as broken floor and wall tiles and collapsed ceiling panels, but that will come later. I have since started to work on the props and have finished the supermarket shelves. Next, I will work on the store counters, cash register and newspaper stands.

This week has been what I hope to be the last navmesh grid optimization week. Navmesh generation is now performing without any spikes on my development branch. I've also worked to get all NPCs to spawn with a valid position on the navmesh, such that they all can walk about and not stand frozen in place anywhere. I also have scientist populations that spawn at monuments now, but this is still only in testing as well. Slowly getting there! Finally I provided a little bit of A* pathfinding assistance to Bradley.

I've been working with the EAC team to transition Rust to their new anti cheat API. This brings a number of advantages over the old system, the most notable one being that all traffic goes through our server with no direct connection between the client and EAC. This means the error "EAC Disconnected" can no longer happen - as long as you can connect to a game server EAC will automatically also work. It also comes with improved detection and prevention mechanisms that will roll out over the coming weeks.

I've continued my efforts to eliminate as much garbage collections as possible. As a reminder, garbage collections cause frame rate drops and are one of the biggest performance concerns in Rust right now, so eliminating them is of the highest priority in order to achieve a smoother experience at a more stable frame rate. This week I primarily optimized prefab instantiates, effects and sounds. First I eliminated a number of memory allocations whenever an effect was spawned or a sound was played, which happens pretty much all the time. Once that was done I did another detailed profiling pass and noticed that one of the biggest remaining causes of garbage collections were strings from prefab names, rig bone names, effect paths and surface type queries. To address this I implemented a number of caching and lookup mechanisms so those strings are kept in memory exactly once instead of being repeatedly allocated and freed. I'll do another profiling pass tonight on a busy server to see where we're at, but I believe things are slowly moving in the right direction.

Player spawn areas sucked. You pretty much always spawned in the same 2-3 areas of the map, which naturally got particularly chaotic on wipe day. I improved the spawn area selection in order to qualify more areas around the map for player spawning. This seems to have worked on the map seeds I've tested, but let's see how things are on a highly populated server.

I've addressed a number of outstanding issues in the system that determines where to spawn trees and other resources around the map. Most of this may not be immediately obvious, but resources should now be distributed a lot better around the map. I've also cut back the amount of wooden logs by about 30% since they could get pretty annoying.

To keep it short and to the point: less blue tint all over the map at clear weather conditions.

The makeshift backpack is complete and ready for implementation, here's a picture. And now comes work for the Geiger Counter. I've finished the high poly model and now i'm halfway through making the low poly, game ready, model. Because we don't really need to concept a model like this I'll just be modelling it from reference, like this. Here's the high poly.

I'm working through some fixes on the new player models, and I'm still aiming for it to be in for the next wipe. As well as new heads I've done a general pass over the player model, I've added some geometry in areas that were lacking as well as tweaking some of the skinning. I've fixed up some things that had broken somewhere down the line, particularly the eye movement and blinking. Here's a look at me cycling through a couple of different variations. Speaking of variations, I've been working with Matt to get some hair prefabs setup. Hopefully these will get merged into main along with the skin updates and although functional hair is a way off it should give us an idea of what's left to be done.

One of last week's rendering tweaks to the terrain texturing caused an unforeseen side-effect when playing with anisotropic filtering set to 1. You'd notice that slopes, and anywhere where the terrain showed low/blurred texture resolution, were showing an artifact in motion which we call aliasing or shimmering. This week I tweaked the textures again to ameliorate the issue. It should display fine now in all anisotropic levels.

Got back to material/texture packing work this week to fix a few issues, add a few more tools and start packing materials again. Packing quality has been improved, packed maps now take less space in the project and generation time has been reduced. Now that we're now back on track, I've packed 26 materials this week, spread across various usage types (buildings, animals, props, items, etc..). I'm adding them at a low pace, to ensure that the tools are working properly and there are no longer dependencies on the unpacked maps. If all goes well, packing should save us around 1 GB of system and video ram, adding to the other benefits I discussed in earlier blogs.