Devblog 170

I've finished the first version of the ore gathering minigame I mentioned a few weeks ago. I plan to iterate on this until we have something really fun, but it's better than what we used to have that's for sure. Here's how it works: Nearby ores will display a shimmering hotspot. If you hit this hotspot you will gather resources at 150%. Each successive hotspot you hit will increase your gather rate to a maximum of 300%. If you miss, this bonus is reset to zero. It should be noted that you will not actually earn more resources, but by using skill and good aim you can harvest the ore faster than just AFK spamming a node infront of you. The visuals for the hotspots are a little buggy: sometimes they're white instead of orange/white, and they will draw on top of viewmodels and grass. A more feature complete flare system for headlights and spotlights etc. will be implemented in the coming weeks, and then we can switch the visuals over to use that. The nodes are affected by the sunlight, and are thus invisible at nighttime, unless you have a miner hat or candle hat equipped. Moving forward, I plan to spawn hotspots off of ores, and perhaps on cave walls instead of the nodes you see in there. I'd also like to make it so when an ore stage changes it reveals multiple hotspots, and perhaps take the accuracy into account when awarding the finishing bonus. We shall see. Enjoy!

I did a bit of an experiment which is proving to be promising. Basically I'm making a type of loot entity that will visually show what is inside it and allow you to pick things up directly from it. Once complete we can start replacing all the barrels in radtowns with shelves, desks, lockers, pallets etc. This should feel more natural and immersive compared to being forced to use the inventory screen to loot everything.

We've had some weak gameplay patches recently so I took a break from the tank to work on some more immediately obvious game mechanics, such as mining. Hopefully I'll have it in for the forced wipe.

I've started working on game tips. A while back we talked about what we needed to do to leave early access, and one of the things on the list was to make the game more accessible. The example that always comes up is letting people know how to open the inventory menu. It can be painful watching people play and not knowing how to do something so simple. I'm hoping that the game tips will be kind of intelligent. When I made a similar system for Garry's Mod, it had a tooltip explaining how to open the spawn menu. I saw that tip pop up about 200 times a day for 5 years, so I'm trying to make the system try to work out what information you could do with, based on your previous behaviours. If you've opened the inventory menu 31 times, it probably doesn't need to show you a tip describing how to open the inventory menu. This is still totally a work in progress, and only has 2 tips right now. We want to expand it to be more aware and use it for other things (like "this door is locked" notifications, etc.).

A couple of quick changes on the main menu. The exit button asks for confirmation before qutting again. I was giving you all too much credit, and it has become apparent that it is totally impossible to not click the exit button and you need a way for your brain to approve what your hand does. So here you go. It also seems like finding out how to actually play the game might be a bit confusing, since we're counting on people finding and pressing this button. This seems like something we should improve in the future, but for now I've added this button.

We have a script in Unity that goes through all the prefabs, scriptable objects, and static fields in classes looking for translatable phrases. It collates them and uploads them to crowdin, then it downloads all the language files. In a few places in our scripts we've accidentally re-used the same "phrase tag". An example of this was the sleeping bag and bed sharing the same description. I made the builder script spit out warnings if it found phrase tag collisions, because they're usually user errors. I then fixed a few of those collisions. The descriptions and names aren't perfect, and it's something we want to improve. Please, if you see any wrong or misleading descriptions, press F7 in game or use the feedback page.

This week has mostly been about improving on the systems I've already put in there, and it's a continous process that will take time. The scientists are becoming better at using cover information to learn about their environment and how to best survive in it, and often if they just stand around being silly it's because the cover system wasn't able to generate good cover points. This will be easier to control in radtowns, where we can hand-craft and tune cover points, but right now we generate them automatically when they are needed, and there's still quite a few improvements before the scientists can read any environment well. If you're an admin, the scientist can now be spawned ('spawn scientist' in console), but be warned that they still need a lot of work. The navmesh grid that I've been working on has not seen much love this week, but I did convar it to nav_grid, so that admins can toggle between that and the regular navmesh that we have right now. Animals can only move within their navmesh patch and player proximity controls whether NPCs are active or dormant. Needless to say, it's still work in progress.

We've removed the DirectX 9 launch option this week since, as we explained in last week's devblog, Unity is planning to retire DirectX 9 support in the near future. If you're having issues running the game with DirectX 11, please give these a try:

• Update your graphics drivers
• Try the lowest quality setting in the launcher
• If all else fails, try adding the "-force-glcore" startup parameter in Steam

Definitely send a support ticket our way if you're having trouble with the transition. We'll do our best to help you out.

We've identified some performance bottlenecks in the skin cache implementation on lower end machines with relatively slow hard disks. These issues could cause fairly significant frame rate drops and make the game pretty unplayable for some people. I rewrote the workshop skin cache implementation in native code and eliminated all GC overhead from it. I also moved all skin cache I/O operations to a separate thread so they can no longer stall the main thread under any circumstances. This completely got rid of the spikes in our tests.

I've updated the EAC SDK to the latest version. EAC think they've found the reason for the "EAC Disconnected" error that's been plaguing some people for quite some time now. So far we're not aware of any issues, but let us know if you're having trouble with EAC after the update.

The backpack is finished! I altered the positon so the arm straps fit nicely when dropped on the floor. Now comes work on a new backpack. It's smaller and made out of rubbish materials. Badly held together, but it gets the job done. Because it's a slightly older concept, I'll make one or two adjustments where I think needs it for visual interest. One thing I discussed with Paul while I was making the initial backpack was character and personality of items, and how to get the right balance. The item should be distinct, but not too distinct; plain enough that it blends in well with everything else instead of it looking like a glaringly obvious repeatable texture on the terrain. It works well with objects like workbenches, because they aren't in your view 24/7 whilst playing the game, so to speak, but also because bags are part of the character. If it was overly recognisable and special, and everyone had one? Well it'd no longer be special. That's not the purpose of a backpack, anyway. It just needs to sit well. Progress on the highpoly is going well, too!

I've been implementing some of the variation work this week. Here's a quick video of me spamming through random player seeds so you can get an idea of the types of variations you can expect. This is just a demonstration, and it'll obviously be cleaner when released. I've got a couple more types that need implementing (in the video you'll only see white females; I'm working on the other female race variations) before setting up some hybrid sets. I'm pretty close to having enough sets to generate the kind of variety I'm happy with. I'm hoping to get this all on it's own branch this week so I can start going through and fixing any bugs and weirdness, like the neck seams, etc.

This week I've gotten sample-accurate granular audio playback working in Unity, which was the first big piece of this puzzle. Now I'm working on automatically analyzing a recording of a tank engine to determine exactly what slices of audio to play. I'm doing a bit of DSP (FFTs + harmonic product spectrum at the moment) to determine the fundamental frequency of the engine sound at any given point in the audio file. With an engine, the fundamental corresponds with a single cycle of the engine, and can also be used to determine exactly what RPM the engine is running at throughout the recording. I'm using that information to map individual engine cycles from the recording to different RPM so we can just pass the current engine RPM in to the granular playback system and have individual engine cycles accurately stitched end-to-end to create a cohesive engine sound that smoothly reacts to changes in RPM. This is working really well so far, and sounds quite smooth when changing RPMs. I'm using a fairly short snippet of a longer recording right now, so when the engine speed is static at some RPMs there's not enough engine cycles to sound natural yet. Once I'm happy with how it performs on this snippet I should be able to use the rest of the recording with no problem. I'm still working on tightening up the cycle detection a bit more because the start and end points of individual cycles aren't 100% perfect yet, and that makes the engine sound a little more loose and sputtery than it needs to. We're currently only picking start and end points by looking for zero crossings that are close to where a cycle should be, so my next steps are to start taking phase information from the FFTs in to account and maybe to do some analysis on the higher frequencies of each cycle to help line the start points up better.