Spencer
This week I made a lot of progress towards a public deathmatch build. This involved updating the ragdoll system to use the new character mesh baking system, speeding up the transition massively. I also brought the gear equipment system (non hotbar equip) into the current century heavily simplifying how it works.
During this process I started running into one of the first big challenges of actual ItemV2 use, where each client doesn’t know about every item ahead of time. In the old architecture, items were represented by id codes + stack sizes. When an item is equipped, everyone needs to know some information about it, what meshes to attach to a player model, how to modify the players stats on the server, how to simulate the item on the owner etc. In ItemV2, items are created on the fly, meaning that at some stage clients need to be told about the definition of an item, and also notified when it changes (by adding a scope for example).
If an operation requires an item to progress, its quite easy to run into race condition scenarios where the client knows it wants to equip item 23422 but doesn’t know anything about it. To solve this problem for all future cases, I implemented a system that can lazy load items from the server. If a client needs an item before its ready, the item manager returns a dummy item, tells the consumer that the item isn’t yet complete, and then requests the full definition from the server. In a few frames when the full definition comes in, the item manager fleshes out the instance that is already held by the consumer and notifies anyone subscribed that an update has occurred. This works quite well, and will save us heaps of headaches in future.
I spent the end of the week working through all the deployment issues around our new build architecture. Everything is much more modular, allowing mods to remove default configurations for almost anything in the game and replace them with custom content. Due to the structure changes, and the fact that this branch I’ve been working in hasn’t been built properly for 5 months, this took a while to get everything working again.
Today we got the first internal test build up, not only running ItemV2, but the new Nullius map.
Its pretty barebones right now, but we will be looking to open the experimental build up to the public in the next couple of weeks.
Cow_Trix
This week I’m back into developing the map and getting ItemV2 up to scratch. I’ve fixed up and brought across things like ambient sound tracks, ambient particle effects and localized visual biome effects. You’ll be able to specify custom ambient tracks for both day and night, as well as particle effects and other effects.
The map itself – which has the working title “Nullius” – is coming along well! I’ve been playing around with the layout, and currently it’s a number of islands surrounded by water. This has meant I’ve had to jump back in to water in Hurtworld, which is a bit of a rabbit hole, but luckily there are a number of tools out there that should get us 70% of the way there. The problems that still need to be solved is allowing for multiple Levels of Detail so water doesn’t kill lower end machines, creating a underwater camera effect, and figuring out how the player should interact with the water. We’ve been thinking about doing it as a vehicle that you enter whenever you get a certain depth below the water. Hopefully what comes out of this is a general water system that you can use in all your custom levels, for whatever you want, that performs well.
To this end, I’ve been playing around with tools like AQUAS for the shading side of things, and looking into mesh generation. Water is mainly limited by fill-rate, which means we need to aggressively cull rendering of the water.
Gavku
The two packs are all baked out and textured. We now have two different sized packs. A large military/camping styled pack, and a smaller crumpler style one. Both will be paintable in some fashion. Next for me is baking out and texturing the shorts, then moving a bunch of this newer gear across to the dev branch for testing etc.
Mils
I’ve continued to explore the shapes and materials that we want to use on the Creature weapons. Now that we have a fairly good array of variation in design elements, like switches, batteries, capacitors, grilles, vents & other components, I am now going to focus on knocking our some more basic shapes for the weapons. The first 3 images follow on from the previous weeks concepts. The last two images show some simpler body shapes that would then, when modeling have these detailed elements added to them. I can speed up the concept process to get more body types designed in a shorter time period.
Below: .22 caliber machine pistol.
Below: SMG body type.
Tom
This week I was working on finishing up the 0.3.7.4 update.
Thanks to bug reports on the steam forums I was able to patch up a few more exploits. There was a bug where Goats and Kangas weren’t checking if doors were blocking a player’s entry to the vehicle allowing a pretty nasty exploit where you could position the vehicles right up against a door so when you entered the upper half of the player’s body would be through the door which would instantly trigger a crash due to the collision but the position of the body would spawn the crash vehicle on the wrong side of the door granting access to the base. I’ve fixed this so doors properly block entry to vehicles as well as adding an additional raycast check on crash vehicle spawn that can deny a crash if the crash vehicle is going to spawn in an illegal location.
Whilst working on the rock bases I also took a look at how people were using doors to push themselves inside of rocks. We run a check when the door is closing to make sure there are no players in the doorway and then reopen the door if it is blocked. I found a couple of bugs in our overlap check where you could stand in certain locations to ‘dodge’ it so I replaced it with a more defensive bounds check which should make this exploit a lot harder to pull off, if you find situations where it’s still possible please let us know!
Speaking of rock bases I also added a change where ownership stakes now check if they are inside a rock on server startup and destroy themselves if needed, hopefully some of you were able to get some revenge after the patch went live, unfortunately we couldn’t announce this ahead of time and give an opportunity the rock bases to prepare.
After the patch I spent the rest of the week merging the latest changes into our ItemV2 branch and started getting vehicles working again under our new gear simulation system.
Unfortunately today though we’ve noticed some more issues with the current build so i’ll be back to bugfixing for the start of this week so expect another update soon.