Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
MILS
I have designed 5 new graphics for the fairings of the Kanga this week. They are all pretty varied and should be fun to customise. It is difficult to come up with different ideas that look significantly different and also look good on the bike at the same time. I designed 8-10 variations and they were all reasonable ideas, some just didn’t lend well to being placed on a bike. Only these 5 made the final cut. They are only skinned on the ‘Crow’ body kit currently.
I’ll proceed to enhance these a little more next week and get them onto the other body kits. After that the Kanga is ready to be passed to Tom to finish off his end of things on it too. This has come out nicely and after testing the actual ride that Tom has put together so well, this thing is going to be a favourite I think.
TOM
This week I’ve been working on getting the Kanga ready for release. We’ve now got all the kanga items up and running including all the variants and paint masks (although these still need to be applied to the Raider and Earwig variants), Diemensland has been updated with Kanga spawners and the loot tables have been updated to include the new Kanga items.
One of the hardest parts of developing the Kanga has been making the crash system safe so it never places you inside rocks or other peoples bases. After a lot of iteration we’ve settled on attaching an invisible capsule to the vehicle via a joint that can be broken by force, if broken then a crash is triggered. This allows you to bump into and drag across rocks and walls at slow speeds without crashing which is a whole lot less frustrating plus it doubles as excellent validation for the crash vehicle spawn location as we can replace the capsule with the crash vehicle. As well as watching for the joint to break we also check for any large changes in velocity over a small period of time and also test the pitch of the bike relative to the angle of the ground (if we just tested the pitch of the bike against the ‘up’ direction of the world then crashes would be thrown when riding upside down through a loop). Unfortunately early in the week I encountered a bug where If I crashed and the bike landed perfectly upside down I could then re-enter the bike which would instantly cause a crash and the crash vehicle would spawn in the rider position which would be under the ground at that instant meaning you could use this to glitch into rocks.
To fix this up I created a new type of vehicle entry that does some physics checks to make sure the rider has room to enter the vehicle, if this check fails the vehicle gets briefly put into a lift mode where it will try and turn itself upright, giving room to enter.
As well as this fix I’ve also discovered a reliable way to check if a point is inside a collider or not which I’ve added to the ownership stake validation, this should finally put an end to invulnerable rock bases even if players manage to glitch themselves into the rocks.
After reviewing the destruction changes we decided they still have a ways to go as we need to develop good ways to give feedback on the health of the vehicle and its attachments plus feedback on your actions to damage/repair them. In the interest of getting the Kanga update out sooner and not having to redo a lot of work as our whole item system gets overhauled we’ve decided to push the vehicle destruction changes back to itemv2.
I’ve put together our work in progress changelist so you can get an idea of what will be in the update
Not a tonne of pretty pictures from me this week. I’ve been putting the pieces back together after our significant project restructure, and the rabbit hole has taken me into bringing entity stats into ItemV2. The project restructure has felt a little like an open heart surgery. We’ve made the big cuts, and moved around the internal organs we needed to (note – do not do real surgery like this). Now we’re just stitching up everything and getting the heart beating again.
As I mentioned last week, I’ve been taking a look at the Biome and environmental effects system. As is the pattern, this has evolved into a refactor of a base underlying system, the entity stat system. We’ve talked about this a lot before, but as a refresher, this is the system that handles the interactions between all the different stats in the game, like health, nutrition, damage, speed, and more. It’s an incredibly complex system, that does a million different things. One of the fundamental parts of the system is the process of building an entity stats object, like for a player, which contains all stats that entity uses. We need to specify somewhere what all these data and relationships are. Previously, we did this in code, which was easy but not extensible. It wasn’t a thing that could be modded easily, or at all really. So I’ve been porting the entity stats building code over to a format that can be defined in the SDK. The challenge in this has been the huge complexity possible with entity stats, but it’s mostly been moving things around rather than having to come up with entirely new logic.
The map is also coming along. I now have the tools in place to start actually making macro builds of the map, which is a big step. Builds are on the horizon – when things aren’t so broken.
SPENCER
Continuing on from last week, I’ve been putting the structures in place so that our asset database can import and export asset manifests as needed. One requirement of this, is that we migrate all our content assets into the map SDK project so we have a clean separation of core logic and configuration. To make this possible, I had to migrate over 1000 code files stripping them of their dependencies on the core project.
Doing this manually would have taken me weeks… instead I utilized the AOT code generation framework I wrote a few weeks back and used it to dynamically rewrite almost all of our code in a form that can be used by the SDK. Long story short, this mostly involves reflectively finding all fields that Unity can serialize on an object, and emitting C# code so that the SDK can construct objects our main project can read, without all of the run time functionality included. We then mark all editor time scripts that need to be fully included and manually flag pieces of code not to be included using compile time #ifdefs.
This means we no longer need to doubly manage 2 code bases, and removes any overhead created by our expanding sdk.
As Cow_Trix described, we are now getting the heart beating again after the enormous restructure. Just to be clear, Cow_Trix and I are working in a different branch to the motorbike progress. The motorbike will be released before the work we are doing towards ItemV2.
I have designed 5 new graphics for the fairings of the Kanga this week. They are all pretty varied and should be fun to customise. It is difficult to come up with different ideas that look significantly different and also look good on the bike at the same time. I designed 8-10 variations and they were all reasonable ideas, some just didn’t lend well to being placed on a bike. Only these 5 made the final cut. They are only skinned on the ‘Crow’ body kit currently.
I’ll proceed to enhance these a little more next week and get them onto the other body kits. After that the Kanga is ready to be passed to Tom to finish off his end of things on it too. This has come out nicely and after testing the actual ride that Tom has put together so well, this thing is going to be a favourite I think.
TOM
This week I’ve been working on getting the Kanga ready for release. We’ve now got all the kanga items up and running including all the variants and paint masks (although these still need to be applied to the Raider and Earwig variants), Diemensland has been updated with Kanga spawners and the loot tables have been updated to include the new Kanga items.
One of the hardest parts of developing the Kanga has been making the crash system safe so it never places you inside rocks or other peoples bases. After a lot of iteration we’ve settled on attaching an invisible capsule to the vehicle via a joint that can be broken by force, if broken then a crash is triggered. This allows you to bump into and drag across rocks and walls at slow speeds without crashing which is a whole lot less frustrating plus it doubles as excellent validation for the crash vehicle spawn location as we can replace the capsule with the crash vehicle. As well as watching for the joint to break we also check for any large changes in velocity over a small period of time and also test the pitch of the bike relative to the angle of the ground (if we just tested the pitch of the bike against the ‘up’ direction of the world then crashes would be thrown when riding upside down through a loop). Unfortunately early in the week I encountered a bug where If I crashed and the bike landed perfectly upside down I could then re-enter the bike which would instantly cause a crash and the crash vehicle would spawn in the rider position which would be under the ground at that instant meaning you could use this to glitch into rocks.
To fix this up I created a new type of vehicle entry that does some physics checks to make sure the rider has room to enter the vehicle, if this check fails the vehicle gets briefly put into a lift mode where it will try and turn itself upright, giving room to enter.
As well as this fix I’ve also discovered a reliable way to check if a point is inside a collider or not which I’ve added to the ownership stake validation, this should finally put an end to invulnerable rock bases even if players manage to glitch themselves into the rocks.
After reviewing the destruction changes we decided they still have a ways to go as we need to develop good ways to give feedback on the health of the vehicle and its attachments plus feedback on your actions to damage/repair them. In the interest of getting the Kanga update out sooner and not having to redo a lot of work as our whole item system gets overhauled we’ve decided to push the vehicle destruction changes back to itemv2.
I’ve put together our work in progress changelist so you can get an idea of what will be in the update
- Kanga added.
- Crash system added
- Bail crashes (crashing from exiting a high speed vehicle) added to all vehicles
- Goat has had orientation crashes and rider capsule crashes and velocity delta crashes added.
- Goat cannot be entered unless room for the rider is clear
- Player weight is now added to vehicles on entry and more vehicle handling attributes are affected by weight.
- Camera fixed so orientation is maintained on vehicle enter and exit
- Ownership stakes can no longer be placed inside of rocks or other geometry.
- Vehicle brake lights now brighten when braking
- DynamicLOD system added for vehicles, LOD budget and High LOD bias can be set in the graphics options menu.
- Vehicle scales fixed, removes physics rebaking step on spawn which will help considerably when loading many vehicles at once.
- Goat texture resolution increased to match Roach.
- The small 2m square foundation construction piece has had its volume scale corrected, making it take the correct amount of damage (was previously taking too much damage because volume scale was too small)
- Fixed bug where the player’s position in the physics system was not being updated whilst in a vehicle.
- Vehicle wheels now spin correctly in the air maintaining take-off RPM
- Vehicle reversing is now much slower than accelerating forward.
- Vehicle steering assist is now a twisting force rather than a pushing force
- Using the reverse key to slow a vehicle down will no longer reverse its steering direction.
- SDK update with all kanga and crash components added.
Not a tonne of pretty pictures from me this week. I’ve been putting the pieces back together after our significant project restructure, and the rabbit hole has taken me into bringing entity stats into ItemV2. The project restructure has felt a little like an open heart surgery. We’ve made the big cuts, and moved around the internal organs we needed to (note – do not do real surgery like this). Now we’re just stitching up everything and getting the heart beating again.
As I mentioned last week, I’ve been taking a look at the Biome and environmental effects system. As is the pattern, this has evolved into a refactor of a base underlying system, the entity stat system. We’ve talked about this a lot before, but as a refresher, this is the system that handles the interactions between all the different stats in the game, like health, nutrition, damage, speed, and more. It’s an incredibly complex system, that does a million different things. One of the fundamental parts of the system is the process of building an entity stats object, like for a player, which contains all stats that entity uses. We need to specify somewhere what all these data and relationships are. Previously, we did this in code, which was easy but not extensible. It wasn’t a thing that could be modded easily, or at all really. So I’ve been porting the entity stats building code over to a format that can be defined in the SDK. The challenge in this has been the huge complexity possible with entity stats, but it’s mostly been moving things around rather than having to come up with entirely new logic.
The map is also coming along. I now have the tools in place to start actually making macro builds of the map, which is a big step. Builds are on the horizon – when things aren’t so broken.
SPENCER
Continuing on from last week, I’ve been putting the structures in place so that our asset database can import and export asset manifests as needed. One requirement of this, is that we migrate all our content assets into the map SDK project so we have a clean separation of core logic and configuration. To make this possible, I had to migrate over 1000 code files stripping them of their dependencies on the core project.
Doing this manually would have taken me weeks… instead I utilized the AOT code generation framework I wrote a few weeks back and used it to dynamically rewrite almost all of our code in a form that can be used by the SDK. Long story short, this mostly involves reflectively finding all fields that Unity can serialize on an object, and emitting C# code so that the SDK can construct objects our main project can read, without all of the run time functionality included. We then mark all editor time scripts that need to be fully included and manually flag pieces of code not to be included using compile time #ifdefs.
This means we no longer need to doubly manage 2 code bases, and removes any overhead created by our expanding sdk.
As Cow_Trix described, we are now getting the heart beating again after the enormous restructure. Just to be clear, Cow_Trix and I are working in a different branch to the motorbike progress. The motorbike will be released before the work we are doing towards ItemV2.