S&box is a very cloud-focused engine. When we make a model at Facepunch, we ship it by uploading to the cloud - not to the game folder.
That means that when you want to play the game, you have to download everything from the cloud. This isn't a great user experience, to sit downloading shit when you just want to try Sandbox Mode.
So now, we ship on Steam with a bunch of these files preloaded. This means that when you load the game, they're instantly available. You don't have to download anything, you skip that step. You can get straight into the game.
We'll tweak this over time based on metrics, to preload the files that make the most sense.
We're making a push with the material system, which has been left pretty much untouched since the start.
This update makes Material.Set actually do something. You should be able to now set any shader parameters using this API, and they should update.
Previously, you'd have to do this wild dance where you'd have to set something as an attribute and set the attribute on the Renderer. This should make things much more logical.
The material editor had this thing where you could click a button and write some code to make it do stuff. A few of the more nerdier community members had found this, and had started using it.
This isn't something we want to support long term. So we felt like it was probably best to get rid of it sooner rather tha later. So we did. It's gone.
We do definitely want to replace the functionality with something better, and will do at some point. I don't like removing things before a replacement is done, but in this case I feel like it's better to pull it - before people start relying on it more and more.
There was no feedback when you crashed before. Your game would just close to desktop, no dialogs or anything. Crashes were always uploaded to our Sentry backend, now when you crash we'll open a page showing your crash.You can share this link with others, see how many other people have this crash, some basic details about it.
The SpriteRenderer component now has a few Actions that it can invoke:
OnAnimationStart(string name)
OnAnimationEnd(string name)
OnBroadcastMessage(string message)
The OnBroadcastMessage action is used for custom events you want to invoke upon a certain frame of animation. This is useful for things like footsteps, or animations where a projectile should be spawned at a certain frameThere are a few different Broadcast Message types that you can choose instead if you want to do things quickly and easily without the need for any code
A continuation from our blog 2 weeks ago: we added the ability to reference components if they implement an interface type.. Now you can do the same, but with Resources.
You can now edit HashSet<T> properties directly in the inspector. They look just like lists, minus the ordering.
/// <summary>
/// What areas the agent is allowed to travel on. If empty, all areas are allowed.
/// </summary>
[Group( "Movement" )]
[Property]
public HashSet<NavMeshAreaDefinition> AllowedAreas { get; set; } = new();
We discovered (the hard way) that our current BBox.Transform() implementation is incorrect when you try to transform an asymmetric box with a non-uniform scale.
We went ahead and fixed the function and added tests to lock this down for the future.
This should cause no issues most existing games. But if you heavily make use of BBox.Transform() and maybe relied on the broken behaviour, double check your game still works as expected.
We've improved the integration between our API whitelist checks and the s&box compiler. You'll now see these errors reported just like normal compile errors, and failing to pass these checks when required will block your build - just like you'd expect.Some might remember we experimented before with ways to get these checks inside your IDE. This doesn't quite go that far, but we'll keep looking at ways to improve feedback with this system. For now, these changes should make it much clearer when you’re using APIs that aren’t allowed - and hopefully less confusing overall.
Bloom had a recent regression where everything would be too bright.
We applied BORDER hardware clamping to blank out out-of-bounds texture fetches for free during downsample for bloom but it should be done on bloom generation as well, higher mips would absolutely destroy visibility.
Glass & other shader effects that need to grab the color underneath them would be reusing a shared texture across all views, this saves a bit of memory but can cause issues with multiple views, our depth-aware filter would not be applied correctly across them and they were being offsetted incorrectly on tools.
Now it's reworked so that each view has an exclusive texture for shader framebuffer fetches, exactly like in our C# API, fixes all the problems people were having.
Depth of Field had a small line running through that looked bad and cause vignetting around objects, downsampling pass was not accounting for center of DoF, instead it was going towards bottom-right corner
That's sorted and super sexy now, on top of that DoF quality settings finally give you perfomance gain.