In Rust we have this system that shows you tooltips when you look at something. This has two nice effects.. first of all they know they can interact with something instead of just spamming E at everything hoping.. and secondly you can tell them exactly what it's going to do. This is now built into the IPressable interface, so anything that implements it can also provide context sensitive help describing what it is going to do.
I don't think this was ever in Half-Life or Half-Life 2 because Valve comes at it from more of a "show don't tell" point of view, where if something looks like it can be interacted with, it will be interactable. We don't have that ability, really, because interacting with things can do unexpected stuff.. so this feels like a pragmatic choice.
Much like Garry's Mod, we want a bunch of options for our wheels, thrusters and chair entities for Sandbox mode.
Thankfully, we already have a lot of options that work well in our asset library, so you should start to see more options when building your mad contraptions in the coming days
Ponder the days of yore for a moment. You might recall that if you were sitting in a chair or chair-like object in Garry's Mod, and going very fast for whatever reason, the arms of your character model might raise skyward, so as to convey something resembling unbridled glee. This is back, and tied to a new parameter called thrill. It is also usable outside sitting — which will probably useful to you if you're making a cops & robbers thing. You could even combine it with the wish values that govern leaning to get a rather zombie-like result...
Additionally, humans now blink naturally, and a new entry to the face_override list was added to let programmers forcefully close a character's eyes at any time.
We improved our audio performance by optimizing the occlusion system, binaural spatialization, and memory management. In our audio benchmark scenes, this resulted in a solid 20–30% reduction in frame time.
We also shipped several improvements to our VOIP component. Now, lipsync and audio processing are disabled for players who aren't speaking. This change should drastically improve VOIP performance on servers with large populations.
We've moved our renderer from Forward+ Tiled Culling to Clustered Culling. Light calculation during shading will only affect what it's actually intersecting on geometry instead of any intersection with the frustum. This is a more modern way to deal with GPU culling of Lights, Envmaps, Decals and other GPU-driven objects, for the average user it's nothing to worry about.
This simplifies a lot our pipeline and improves framerate in some edge conditions, our Tiled Rendering implementation was made targeting D3D11 and was hard to maintain, this also helps us iterating on it as time goes on.
Our envmaps are awesome to generate quickly for very fast iteration on the editor but they're an annoyance to the user that they are also generated every time they join a game.
We added the ability to be able to bake and cache Envmaps to disk instead of generating them at load time.
Since these use BC6H, VRAM cost for these are 8x smaller than dynamic cubemaps.
Garry made the API for saving a dynamic texture really awesome with just Texture.SaveToVtex():
public async Task Bake()
{
RenderCubemap( CubeTexture, CubemapRendering.GGXFilterType.Quality );
var sceneFolder = Scene.Editor.GetSceneFolder();
string filename = $"/envmap/bake_{Id}.vtex_c";
var vtexBytes = await CubeTexture.SaveToVtexAsync();
var path = sceneFolder.WriteFile( filename, vtexBytes );
BakedTexture = await Texture.LoadAsync( path );
// Make envmap baked
Mode = EnvmapProbeMode.Baked;
}
Backend of this stuff will be used to store the results of other things we want baked like Indirect Light Volumes.
We've been trying to figure out how to make Scene files function like real maps for a while. We've thought about the compile process, saving lightmaps, navmesh, envmaps etc.
Since Source 1 maps have been compiled to a VPK file, which is basically like a zip file with a bunch of loose files in. We have decided to skip that and just have a folder.
So now you can call Scene.Editor.GetSceneFolder() to get a class to interact with this folder in the editor. You can generate and save resources in there, which your scene will reference and use. For example, when we bake cubemap textures we save them in this folder.
This unlocks a lot of capabilities for us in terms of mapping.
Enums in the inspector were always a dropdown control. This works, but fuck me it's a click to see the list of options, then a click to select the option. Now if your enum has less than 4 options it's turned into an EnumButtonGroup, which shows the options as a group of buttons.
This seems like a stupid thing to care about, but it makes the UX so much better when you can see everything and single click between the options.
You can force enums to use a GroupButtonControlWidget by adding the [EnumButtonGroup] attribute to the property.
We have this new property on the Application static class. This allows access to the editor tools from the game.
It doesn't have much available right now, just access to the currently editing scene and a Foreach that provides a progress bar while iterating. It's something that I can imagine will be expanded over time, as we want more editor functionality in the game code.
You can define editor menus in the game code now. I can't imagine there are a ton of use-cases for this - but it has proven to be useful for me. If you can get away with it, it's always going to be much nicer than having editor code somewhere else.
You can now store data as binary when JSON no longer fits your needs.
The system is fully transparent and integrates seamlessly with existing JSON serialization. Any type that inherits from BlobData will automatically be serialized as embedded binary data alongside JSON.
public class MyBigData : BlobData
{
public List<float> Data { get; set; } = [];
public void override Serialize( ref Writerwriter )
{
writer.Stream.Write( Data.Count ); // Int
foreach ( var instance in Data ) // float * Data.Count
{
writer.Stream.Write( instance );
}
}
public void override Deserialize( ref Reader )
{
var instanceCount = reader.Stream.Read<int>();
for( int i = 0; i < instanceCount; i++ )
{
Data.Add( reader.Stream.Read<float>() );
}
}
}
You can now select GameObject and Components right from the control widget! This makes it quick and easy to select something without losing your place in the hierarchy, or having to miss another drag & drop.
We’ve added the ability to select the individual gizmo handles from a list, as well as categories. This stuff is all based on the attributes on a component, you don’t have to do anything extra, it’ll just work.
We've added full SCSS-style @mixin and @include support to the UI stylesheet system.
Mixins let you define reusable style templates that can be included anywhere in your stylesheets. They accept parameters, support nested selectors, and can even use @content blocks for wrapping patterns, dramatically reducing repetition and making your UI code easier to maintain.
i like the way for expansions buil-in already features like player animations/hands/models/guns/open source project wants to see it more This is a good entry point for beginners and for quickly creating a variety of games from scratch, not just clickers i think More features like this, more game variations, more audience.
For "Envmaps Baking" IMO you should support .NET Streams for both the SaveToVtex and WriteFile (WriteStream?) APIs if you're not already. Byte arrays will work fine for small amounts of data but someone somewhere is going to try to stuck a gigabyte texture in one and then you've got problems. Supporting Streams allows you to internally use a small buffer to transfer any amount of data. Maybe this isn't possible (I don't know what SaveToVtex needs to do internally), but even if not, you still get support for being able to integrate with existing Stream types like NetworkStream and so forth.
i like the way for expansions buil-in already features like player animations/hands/models/guns/open source project wants to see it more
This is a good entry point for beginners and for quickly creating a variety of games from scratch, not just clickers i think
More features like this, more game variations, more audience.