Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
COW_TRIX
This week I’ve been testing and writing documentation for the new modding framework, and the creating of Construction Packs. I’ve also been preparing for the next patch – more info below! All hosted on the official wiki, you can now read how to Create a Construction Pack, Install a Construction Pack, how the Construction Attachment Editor works, and more! I also brought all the other modding documentation up to date, as a few things have changed. There’s still a bit to do, as testing the modding framework has led to a few changes over the past week. Whereas before I had thought of the architecture as Levels, Construction Packs, and then whatever we added in the future, after some discussion I realised that it’s really Levels and then an overarching additive Mod category, as we want mods to be able to incorporate multiple levels of custom content. For instance, a mod should be able to package up all into one custom vehicles, construction pieces, dynamic objects, and all of that, in any combination.
In between writing documentation, I put in a bit of visualization for construction attachment rotations. Now, you’ll be able to clearly see when an attachment point in the construction system has multiple rotations, what those rotations are, and what rotation you are currently on. This should make multiple attachment rotations a bit more intuitive.
I also have been working on getting basic networked entities into the SDK. At this point, you’ll be able to spawn dynamic objects into the world, but they won’t be able to do much. As of the next patch, we’ll probably support dynamic networked rigidbodies, which will sync their positions. Which, I reckon, you’ll be able to do some very, very cool stuff with, when combined with Oxide! This will be a huge boon for those mods, which will now be able to use custom assets as well as in-built ones.
We’ll be aiming to get this patch out by this Friday, the 24th of June. This patch is notbackwards compatible, so all servers will wipe when upgrading. This is always unfortunate, especially for community servers that prefer to never wipe. However, I know most of the official infin-wipe servers are aching for a wipe. This also means that the 14-day servers will actually be 7-day servers for this cycle.
GAVKU
So I have finished up the MP5 and it looks to be a good test case for weapon attachment/modifiers. I may end up tweaking a couple of the maps slightly once we have it on the player and can accurately view it in first person etc, but I think in general its fine especially for a stock standard smg.
Having the multiple scopes will be fun as we currently dont have any in game atm. Next up for me is to jump back on to character gear
MILS
I have been testing performance with our new grid culling system which I covered in the Devblog a couple of weeks ago. I did some tests using different sized grids with different culling distances as below;
Baseline test – No Culling
Culling 100×100 metre 50% cull distance
Culling 50×50 metre 25% cull distance
Culling 200×200 metre 50% cull distance
We didn’t get great performance out of these and realised that the culling result was being applied based on the bounding box of the tallest object and how much of the vertical screen-space it was taking up. What is preferable and simpler for us is to set distance culling per grid square. This would be calculated from the center of each grid space to the POV of the player.
So Tom is busy fixing the culling tool (amongst other things) and in the meantime I am pushing on to the suburbs and industrial areas around the city.
The suburbs are going to be achieved by standalone one unit structures, spaced out around the road network.
Above shows the same building just rotated 180 degrees. Where possible I will try to create buildings that have a dual frontage design. This will allow us to flesh out the suburbs quickly.
Swapping textures will also help use the same meshes whilst having a bit of visual difference. That said I would like to get a few different designs into the house zone.
Below are more versions of the same house simply with swapped textures. Makes quite a believable neighbourhood with the added fences.
TOM
This week I’ve been hunting down bugs in our vehicle system, a big thanks to all who contributed to the feedback discussion thread and helped with pinning some of this stuff down.
First up are the infamous vehicle launching bugs. This one was a tricky one as there were actually two separate issues that both caused the same behaviour. The vehicle launching bug occurs when the vehicle and an object that isn’t being simulated by the physics engine overlap. This causes a force to be applied to the vehicle to push it away from the overlapping object. Unity gives us a way to set a limit on this force but a bug causes this limit to get reset every time the vehicle is disabled and re-enabled. Now we are reapplying this limit every reset so objects like loot crates and resource nodes can no longer create huge forces on vehicles launching them into the air.
The other big launching bug comes from players, more specifically their character controller which is a special capsule shape collider that provides a nice controllable way to move a character around and collide with the physics engine. Remember that force limit I was talking about before? Unfortunately a bug means it is totally ignored when physics objects overlap with character colliders allowing vehicles to be launched into the air by players standing in them. This was very easy to achieve using a spear to lift a vehicle and crawling under the opening.
This has been fixed by listening for player collisions in the physics update and if any are detected that are generating a large force then the vehicle velocity is reset to whatever it was before the physics step. Here you can see a before/after gif of the behaviour.
Speaking of flipping vehicles with the spear, I noticed this was very inconsistent and tracked down another bug in the way the collision check was being applied. You can now aim the spear with the crosshair to flip vehicles rather than looking at the ground. The vertical offset that was being applied to the collision before has now been moved to the flipping force so you should find this behaviour a lot more consistent and easier to use once these changes go live.
I’ve also been looking into how the vehicles and landmines play together and tracked down another bug with how explosive forces were being applied. Previously we were applying the force for each collider in the vehicle when it should have only been applied once for each vehicle. Because a vehicle can have a different number of colliders based on its configuration and vehicle type this was leading to some pretty inconsistent behaviour.
Here you can see a before/after gif of a roach running over a landcrab mine.
I’m also looking into reapplying explosive damage to the driver in these situations as a temporary fix but ultimately we need to make the vehicles destructible and it should be the exploding vehicle that kills you rather than the exploding mine.
Several people on the vehicle feedback thread brought up the need to be able to crash the motorbike. I agree with this both from a realism and a gameplay perspective so I’ve started working on a crash system. Generally in a crash system you want to ragdoll the player and let the physics system sort it out. Unfortunately in a networked game you either use a lot of bandwidth syncing up all of the player skeleton accurately or you run into desync issues because most physics engines aren’t deterministic meaning given the same inputs there is no guarantee of the same output. This is why we run all our vehicle physics server side.
So far I’ve been experimenting with running the torso of the player server side and then running physics on the limbs on the client. This keeps the player position in sync even if the exact ragdoll pose isn’t which gives us relatively consistent behaviour without a huge overhead on the network.
Whilst the motorbike and vehicle overhaul are still a ways off we should be able to push the bug fixes with vehicle launching into the next patch so look out for that.
SPENCER
Last week I’ve been working on upgrading the ballistics system to bring it inline with ItemV2. The first area of focus has been moving projectiles from being what we call first class entities into a system that is managed in a central point. As none of our bullets are hitscan (no travel time), we have to deal with the extra challenge of client side predicting real world objects that are constantly being created and destroyed. If we didn’t, and just waited for the server to spawn the bullet before you see it, there would be a very noticeable delay when firing a gun, especially on higher ping servers.
To prevent the problem of your client needing to predict an entity that doesn’t yet exist, we cheated slightly by spawning the bullet projectiles for the gun ahead of time. The server sends your client a message when you equip the gun saying “The next bullets you fire will be entity: 125,128 then 141…”. When you fire your weapon, your client looks for the next bullet in the list and fires it predicatively, knowing that the server will be firing the same entity once it gets the message that you fired.
This method has heaps of overhead, as with an automatic rifle, the server is constantly instantiating fully networked entities and sending queue messages to the client upto 20 times per second. Sometimes one of these packets can get lost, causing the client to predict the fire of a different bullet than the server. This is pretty easy to detect, but requires the entire bullet buffer be thrown away, re spawned and re queued. I’m sure most of you have experienced this when your gun won’t shoot for a couple of seconds for no reason, quite often resulting in you getting killed.
The solution I’ve been working on this week, is downgrading bullets from first class entities to virtual objects managed by the ballistics system. The ballistics system is a single networked entity that is responsible for all bullet projection, hit detection and visualization across the entire game. Now when a bullet is fired, the ballistics system is notified with all the relevant properties of the weapon, it can first create a local predicted bullet on your client and create a hash of the event that created it. By using the exact time tick when it was fired and playerid that fired it we can infer a unique enough identifier for the bullet that the server can also automatically determine at fire time. Meaning no pre-sharing of bullet sequence is required. The second benefit to this is bullets will use a fraction of the CPU time and eliminate all garbage generated as we can properly pool the local virtual entities without upgrading them to the network system.
Part of this will allow us to bring into line, what the person who fires sees and what everyone else sees. An example of this is when someone other than you fires an arrow at a Shigi; it dies, but on your screen there was no blood splat or hit sound, just a dust puff. By tweaking the responsibility of how the effect is generated, this should come back into line.
My second focus last week was improving the melee swing mechanics. Previously all melee weapons were a directly straight raycast from the center of the screen over a couple of frames. To more accurately represent the movement of the weapon I have introduced a fully configurable projection setup. Each weapon can model their swing arc using either a sphere cast or capsule cast. Like everything else I’ve been doing lately, this fully supports modding.
This week I will be nutting out the long awaited recoil system.
Release Date
Folks wondering when this stuff will make it into the game, we are still a couple of months out yet for all ItemV2 stuff. The main reason for the delays are the change of architecture requires a lot of re-implementing how items are built. Whenever I come across something that needs improvement, it pains me to port over sub par system and is much quicker in the long run to bring them upto scratch while I’m working on them.
This week I’ve been testing and writing documentation for the new modding framework, and the creating of Construction Packs. I’ve also been preparing for the next patch – more info below! All hosted on the official wiki, you can now read how to Create a Construction Pack, Install a Construction Pack, how the Construction Attachment Editor works, and more! I also brought all the other modding documentation up to date, as a few things have changed. There’s still a bit to do, as testing the modding framework has led to a few changes over the past week. Whereas before I had thought of the architecture as Levels, Construction Packs, and then whatever we added in the future, after some discussion I realised that it’s really Levels and then an overarching additive Mod category, as we want mods to be able to incorporate multiple levels of custom content. For instance, a mod should be able to package up all into one custom vehicles, construction pieces, dynamic objects, and all of that, in any combination.
In between writing documentation, I put in a bit of visualization for construction attachment rotations. Now, you’ll be able to clearly see when an attachment point in the construction system has multiple rotations, what those rotations are, and what rotation you are currently on. This should make multiple attachment rotations a bit more intuitive.
I also have been working on getting basic networked entities into the SDK. At this point, you’ll be able to spawn dynamic objects into the world, but they won’t be able to do much. As of the next patch, we’ll probably support dynamic networked rigidbodies, which will sync their positions. Which, I reckon, you’ll be able to do some very, very cool stuff with, when combined with Oxide! This will be a huge boon for those mods, which will now be able to use custom assets as well as in-built ones.
We’ll be aiming to get this patch out by this Friday, the 24th of June. This patch is notbackwards compatible, so all servers will wipe when upgrading. This is always unfortunate, especially for community servers that prefer to never wipe. However, I know most of the official infin-wipe servers are aching for a wipe. This also means that the 14-day servers will actually be 7-day servers for this cycle.
GAVKU
So I have finished up the MP5 and it looks to be a good test case for weapon attachment/modifiers. I may end up tweaking a couple of the maps slightly once we have it on the player and can accurately view it in first person etc, but I think in general its fine especially for a stock standard smg.
Having the multiple scopes will be fun as we currently dont have any in game atm. Next up for me is to jump back on to character gear
MILS
I have been testing performance with our new grid culling system which I covered in the Devblog a couple of weeks ago. I did some tests using different sized grids with different culling distances as below;
Baseline test – No Culling
Culling 100×100 metre 50% cull distance
Culling 50×50 metre 25% cull distance
Culling 200×200 metre 50% cull distance
We didn’t get great performance out of these and realised that the culling result was being applied based on the bounding box of the tallest object and how much of the vertical screen-space it was taking up. What is preferable and simpler for us is to set distance culling per grid square. This would be calculated from the center of each grid space to the POV of the player.
So Tom is busy fixing the culling tool (amongst other things) and in the meantime I am pushing on to the suburbs and industrial areas around the city.
The suburbs are going to be achieved by standalone one unit structures, spaced out around the road network.
Above shows the same building just rotated 180 degrees. Where possible I will try to create buildings that have a dual frontage design. This will allow us to flesh out the suburbs quickly.
Swapping textures will also help use the same meshes whilst having a bit of visual difference. That said I would like to get a few different designs into the house zone.
Below are more versions of the same house simply with swapped textures. Makes quite a believable neighbourhood with the added fences.
TOM
This week I’ve been hunting down bugs in our vehicle system, a big thanks to all who contributed to the feedback discussion thread and helped with pinning some of this stuff down.
First up are the infamous vehicle launching bugs. This one was a tricky one as there were actually two separate issues that both caused the same behaviour. The vehicle launching bug occurs when the vehicle and an object that isn’t being simulated by the physics engine overlap. This causes a force to be applied to the vehicle to push it away from the overlapping object. Unity gives us a way to set a limit on this force but a bug causes this limit to get reset every time the vehicle is disabled and re-enabled. Now we are reapplying this limit every reset so objects like loot crates and resource nodes can no longer create huge forces on vehicles launching them into the air.
The other big launching bug comes from players, more specifically their character controller which is a special capsule shape collider that provides a nice controllable way to move a character around and collide with the physics engine. Remember that force limit I was talking about before? Unfortunately a bug means it is totally ignored when physics objects overlap with character colliders allowing vehicles to be launched into the air by players standing in them. This was very easy to achieve using a spear to lift a vehicle and crawling under the opening.
This has been fixed by listening for player collisions in the physics update and if any are detected that are generating a large force then the vehicle velocity is reset to whatever it was before the physics step. Here you can see a before/after gif of the behaviour.
Speaking of flipping vehicles with the spear, I noticed this was very inconsistent and tracked down another bug in the way the collision check was being applied. You can now aim the spear with the crosshair to flip vehicles rather than looking at the ground. The vertical offset that was being applied to the collision before has now been moved to the flipping force so you should find this behaviour a lot more consistent and easier to use once these changes go live.
I’ve also been looking into how the vehicles and landmines play together and tracked down another bug with how explosive forces were being applied. Previously we were applying the force for each collider in the vehicle when it should have only been applied once for each vehicle. Because a vehicle can have a different number of colliders based on its configuration and vehicle type this was leading to some pretty inconsistent behaviour.
Here you can see a before/after gif of a roach running over a landcrab mine.
I’m also looking into reapplying explosive damage to the driver in these situations as a temporary fix but ultimately we need to make the vehicles destructible and it should be the exploding vehicle that kills you rather than the exploding mine.
Several people on the vehicle feedback thread brought up the need to be able to crash the motorbike. I agree with this both from a realism and a gameplay perspective so I’ve started working on a crash system. Generally in a crash system you want to ragdoll the player and let the physics system sort it out. Unfortunately in a networked game you either use a lot of bandwidth syncing up all of the player skeleton accurately or you run into desync issues because most physics engines aren’t deterministic meaning given the same inputs there is no guarantee of the same output. This is why we run all our vehicle physics server side.
So far I’ve been experimenting with running the torso of the player server side and then running physics on the limbs on the client. This keeps the player position in sync even if the exact ragdoll pose isn’t which gives us relatively consistent behaviour without a huge overhead on the network.
Whilst the motorbike and vehicle overhaul are still a ways off we should be able to push the bug fixes with vehicle launching into the next patch so look out for that.
SPENCER
Last week I’ve been working on upgrading the ballistics system to bring it inline with ItemV2. The first area of focus has been moving projectiles from being what we call first class entities into a system that is managed in a central point. As none of our bullets are hitscan (no travel time), we have to deal with the extra challenge of client side predicting real world objects that are constantly being created and destroyed. If we didn’t, and just waited for the server to spawn the bullet before you see it, there would be a very noticeable delay when firing a gun, especially on higher ping servers.
To prevent the problem of your client needing to predict an entity that doesn’t yet exist, we cheated slightly by spawning the bullet projectiles for the gun ahead of time. The server sends your client a message when you equip the gun saying “The next bullets you fire will be entity: 125,128 then 141…”. When you fire your weapon, your client looks for the next bullet in the list and fires it predicatively, knowing that the server will be firing the same entity once it gets the message that you fired.
This method has heaps of overhead, as with an automatic rifle, the server is constantly instantiating fully networked entities and sending queue messages to the client upto 20 times per second. Sometimes one of these packets can get lost, causing the client to predict the fire of a different bullet than the server. This is pretty easy to detect, but requires the entire bullet buffer be thrown away, re spawned and re queued. I’m sure most of you have experienced this when your gun won’t shoot for a couple of seconds for no reason, quite often resulting in you getting killed.
The solution I’ve been working on this week, is downgrading bullets from first class entities to virtual objects managed by the ballistics system. The ballistics system is a single networked entity that is responsible for all bullet projection, hit detection and visualization across the entire game. Now when a bullet is fired, the ballistics system is notified with all the relevant properties of the weapon, it can first create a local predicted bullet on your client and create a hash of the event that created it. By using the exact time tick when it was fired and playerid that fired it we can infer a unique enough identifier for the bullet that the server can also automatically determine at fire time. Meaning no pre-sharing of bullet sequence is required. The second benefit to this is bullets will use a fraction of the CPU time and eliminate all garbage generated as we can properly pool the local virtual entities without upgrading them to the network system.
Part of this will allow us to bring into line, what the person who fires sees and what everyone else sees. An example of this is when someone other than you fires an arrow at a Shigi; it dies, but on your screen there was no blood splat or hit sound, just a dust puff. By tweaking the responsibility of how the effect is generated, this should come back into line.
My second focus last week was improving the melee swing mechanics. Previously all melee weapons were a directly straight raycast from the center of the screen over a couple of frames. To more accurately represent the movement of the weapon I have introduced a fully configurable projection setup. Each weapon can model their swing arc using either a sphere cast or capsule cast. Like everything else I’ve been doing lately, this fully supports modding.
This week I will be nutting out the long awaited recoil system.
Release Date
Folks wondering when this stuff will make it into the game, we are still a couple of months out yet for all ItemV2 stuff. The main reason for the delays are the change of architecture requires a lot of re-implementing how items are built. Whenever I come across something that needs improvement, it pains me to port over sub par system and is much quicker in the long run to bring them upto scratch while I’m working on them.