March 2022

You probably noticed the frequency of posts here have become a bit random. I started feeling for a while that we were working for the blog, instead of having the blog work for us. I could feel that members of the team felt like shit because they had nothing to post in them, so I want to de-emphasise their importance. 

The dev blogs should be a window into the development process. I think overall they do more good than harm. If people feel like shit at the end of the month when they have nothing to show, maybe that's part of the development process. So going forward I'm going to make an effort to put them back on schedule.

We've been working on source 2 for over a year now.  We've made some missteps and wasted some time, which is inherent with the jazz like way we work, no deadlines, unlimited money and a non standard end goal.

Binding Qt to c# and making all the tools moddable is something we should have done within the first couple of months. If we'd have done that I think we'd be 6 months ahead right now. 

I spent a long time trying to get our in game UI in a position where we could feasibly make the editor tools in it, and there was really no need. The upside is that the UI system we have now is about 5 times better than it needs to be.

People have started noticing engine updates on the DOTA branch and asking whether we're going to be pulling those updates into s&box. We did ask Valve about it and they don't seem that enthusiastic about it.. which is fine - they've already given us so much, we don't want to push it.

As nice as it is to spend 20 minutes copy and pasting code between codebases, it might not be the best thing for us in the long run. Where possible we should be looking at new tool features and figuring out ways to make them ourselves or allow community addons implement them. We should be finding ways to be more self sustainable.

We've spent a few months rearranging the furniture. Implementing features badly, full of bugs, then reimplementing them again, but with fewer bugs.

The last month or so has been pretty exciting. Getting cloud models spawning and working on actual game code has put our goals back in focus. UGC and real games.

The last time I did game stuff on the engine was a few months back, and the last time the DM98 code was touched was even further back.. So now we have a ton more functionality and there's a lot of easier ways to accomplish things.

My metric for whether I'm doing the right thing has always been if I go to bed and excitedly think about my next day coding. There have been a lot of those nights over the last couple of months. 😍

Your legs individually react to the water, a tiny dam would stop the flow of waves, bullets react and their waves bounce from edges.

Water shading code has been entirely refactored, this includes streamlining the water settings on the material and giving you more options to customize it how you want, this includes such options as Two Tone Fog

The dedicated server is uploaded to its own repo. There's a write up here on how to download and host your own server. It's windows only for now.

Something of note with this stuff is that we're using Steam's SDR stuff, which means your real IP is never exposed because all the traffic is passed through their backbone.

What this means in practical terms is that you can probably host a dedicated server on your home network without getting DDOS'd, and you don't have to fight with your firewall to get it to work.

I have added a map cleanup system. It works very similarly to how it does in Garry's Mod, with the exception that in S&box you can preserve specific entity instances rather than working solely with internal entity class names.

Sandbox gamemode has an example usage of this system via the respawn_entities console command.

I've reworked ambient occlusion to have support for dynamic objects without looking wonky, no need to change any setting, it just works as long as you have AO Proxies in your meshes.

It looks specially nice in the small touches of Citizen's clothes.

Being calculated in world space means you can see things that would affect it even if they are occluded (ha) from your screen like the underside of a car.

Still using analytical ambient occlusion, so it's very cheap and yet closely matches to ground truth.

I introduced a resolution rescaler to allow people with lower-end systems to achieve more desirable framerates on the game. For upscaling the resolution back to the native resolution, we're using AMDs Fidelity FX Super Resolution. This yields a sharper image for rescaled resolutions.

Some additions and changes have been made to hammers real-time lighting previews. We've added support for textures to be visible within the lighting preview now. An additional lighting preview mode was introduced which also allowed viewing the lighting preview using full-resolution textures too! No more blobby-looking bricks!

Gradient fog has been moved to C# & completely customizable within your worlds! In addition to being able to add/remove fog from your maps, you can additionally add fog to scene panels so you can have your fancy character customization panels

A single 8k texture was taking up to 4-8 seconds to compile which was completely unacceptable. I reworked DXT & BC7 texture compilation. It now can take as little as 300ms to compile the textures which is a huge improvement!

When you select a model in the asset browser now, you get an option to publish it as an addon.

A gamemode can query the list of all uploaded models, filter them by tags and stuff, and even download and spawn models using them. This gets the sandbox gamemode into the wonderful world of UGC.

Something of note here is that if your model depends on something, like a particle system or sounds, they're uploaded too.

This is something I wanted to get possible as soon as possible, because it opens the door for a lot of things.. like what if you could list the models in Hammer and place them in your map just like any other model.

We can store metadata in the model upload. We can verify/update/add this metadata using VRF on our backend. This should allow us to tag and sort assets retroactively without too much fuss.

There's work to do here with categorization and discovery but I'm really happy with how it works. Spawning a model is incredibly fast and works on dedicated servers etc.

The future of this feature on the sandbox gamemode hasn't really been decided yet. I would imagine we'll have an approved list of models that anyone can spawn, but the admin can spawn whatever model they want. Something like that.

We started work on our own asset browser. 

My aim here was to make it work more like Unity. I feel like it's second nature to organise files into folders, so now you can explore your assets by folder. If you don't like that there's an option to flatten the filesystem so you see everything in that folder and its subfolders.

You can right click on a folder to get options, like this..

This feels like a more natural way to create assets for me. I find it a bit jarring to open the editor, go to save, then try to find the folder to save into.

The overall aim of this is to make something dockable in the main editor that feels comfortable to quickly create/select/find/create assets.

I have been working on a selection of props. Street furniture making up the bulk of it. The road and street name kits should be particularly useful for peoples maps. There are sign shapes ranging from small arrows, all the way up to full size motorway signs. I have included skins for a lot of the most common UK road sign designs. Creating new skins for your own signs is also easy to do by duplicating an existing skin and adding your own custom design in the colour texture slot.

Started on the detailing pass to make the map less sterile but trying to avoid to clutter it. 

Second pass on the floors (a ladder was also added in case people needed one to test stuffs).

Decals were created to try to ground everything together, and started to add text and graphic design elements.

Dressing on the road blocked area, 'justifying' why the access is blocked.

On the less visible side, lots of smaller things, props placement, prefabs and breakable setup, texture and material tweak and variation. 

The background was move to the skybox, first optimization pass and vis setup were made. A bunch of materials that were coloured in the editor were converted as their own colour variation materials.

First Blog post for me and very excited to talk about all the clothing we've added!

I've been working on a selection of clothes for Terry to beef up the amount of outfit combinations. As well as this, I've been working on new hairstyles and eyelashes; we're starting to see a mixed bag outfit combinations. My hope is to have a full range of awesome clothing for you all to mix and match with! 

Another focus is making sure we can have a full range of different looks for Terry. That's definitely been a big focus for me since starting work on Terry's wardrobe. And there's a lot more to come!

More to come soon!

Citizen.vmdl is now broken up into prefabs, one for each section, and several for animations. You can think of them as the equivalent of Source 1 .qci files.

Every node has been moved into one of these. It means that if you want to "fork" the model to add things to it (like new animations), you won't have to keep up with our changes manually, because the prefabs take care of that. You can create a copy of the VMDL file as-is, and put your changes right under them.

Some animation groups (like the ones specific to our gamemodes) are also in their own prefabs, so you can choose to include/exclude based on your needs.

If you've been watching our commit log, you'll have seen that Michael is working on developing a similar solution for animgraphs, and we hope to have more to share on that side soon.

I ported the Block tool to a C# addon, these use the new PolygonMesh API.

You can create your own primitives or modify the existing ones, your changes are instantly hotloaded into Hammer.

Whenever you edit your game entities code it is reflected instantly in Hammer.

Sharp shadows like in CS:GO but not moveable, far shadows are still baked and don't dissapear, good if you want this aesthetic on the map or want to do a quick compile. 

Other light types are now named Baked and Moveable for streamlining their meaning.

Previously shadows used multiple systems, each that spanned from a different project for other Source 2 games, this made maintaining it pretty annoying as adding a feature to one system meant having to do something different for the other system, or having to support multiple paths on shaders or it breaks when the maps uses another one.

I've unified all shadowing system outside of tools, so all changes will apply everywhere, making it much simpler to maintain, and also renders faster.

Previously baked lights only supported it supported only a single dynamic shadow at the time, that looked awful if your map had multiple players and is indoors,.

It needed a major reengineering to support multiple ones, now it supports as many as we want.

They're only active when an object is in it's bounds, this is also becomes a good optimization step as mappers can use it more often rather than using fully dynamic lights that render all the time for key areas that need dynamic shadowing.

We have viewmodel shadows on the new system, with everything being unified, it means that indoor llghts also cast shadows on them.

A while back I made it so all of a game addon's settings were edited in game. I threw all that work in the bin this month. It's no longer needed, it's no longer makes any sense.

Now we have it all in the addon editor!

This works great because it's all offline. So you can change settings without actually publishing anything.. and any changes you make don't affect anyone else until you do publish.

It's also versioned, as part of your .addon file.. so if you mess something up it's much easier to see what you did wrong and revert to that previous version.

If you're here because it's 2023 and I linked to this post from another post where I explained that this is terrible and it's been replaced again, please, forgive me.

I added motion data for supported controllers (PS4/5, Switch, Steam Deck).

It's simple to use and accessible server-side too, you have access to absolute rotation, positional acceleration and angular velocity.

Actual servers are now shown on the server list. I've got some work to do on the presentation here, but this is a dedicated server.

Thanks to Fletcher at Valve for all the backend work making this possible, bringing the server list system up to date and making it work for us. Please tweet him a picture of a duck in thanks.

The basic difference between this and something like GMod are this. In GMod your game would ask for the server list and it'd send a bunch of server ips, then your game would message each server and ask how many players and stuff.

The new way it works is that we don't ask the server, because Steam already knows how many users there are and what they're all doing. So we just get all that information straight from Steam instead.

The hope with this is that we won't end up with all the fake player counts and fake pings and fake redirect servers that have plagued us in Rust/GMod. And server owners no longer have to have the A2S query port open.