First, I just want to say that your videos are great, they are miles above most of the other channels who teach Unity incorrectly (like framerate dependent lerping is a frequent culprit) yet have 100ks of views. I have modified your system quite a lot, but I still think I have discovered a potential bug in the way your bullet penetration raycast check works , shown at at 6:45. It would typically only matter if the MaxPenetrationDepth is a larger value though. Essentially, if you shoot a collider A, and the "backcast" ray hits another collider B, this means that the hit point of collider B will be the new trail/shot origin passed to the subsequent recursive call to DoHitscanShoot() - effectively meaning the space between collider A and collider B is ignored. You might already be aware of this, and it might be by design + I can't really think of a good alternative solution to avoid this, but I felt like it was worth mentioning
@@LlamAcademy I have come up with a solution. After the first raycast A, you do a second raycast B in the same direction but with the origin set to A's hit + a small step in the shoot direction to prevent hitting the same collider again. Then, if raycast B hit something, you do a new raycast C with origin at raycast B's hit, but in the backwards direction. Raycast C should hit the same collider as raycast A, but on the opposite side. Now you can compare raycast A and C's hit to get the depth of the collider. To continue checking for colliders, set the raycast A's hit variable to raycast B's hit variable (hitA = hitB), and repeat the raycast B and C step in a loop, such that the next iteration raycast B's origin is set to where the previous raycast B's origin hit. I hope that makes sense
Hi Chris, good tutorial as always, but I have a question. If you have random between two constants damage selected(i.e 10 and 25) and damage retention percentage for example 0.75. You get this weird thing where the first contact can do 10 damage and the second contact 25*0.7 = 17.5 damage. How do you recommend to fix this?
That is a great question! It probably makes sense to make the damage calculation consider the original damage amount instead of the maximums. It also probably makes sense to move the penetration calculation within the Damage Config. This becomes a little tricky for hitscan, but easier for projectiles. In this video I was considering constant damage or single curve falloff primarily. For those cases with random between range or random between curves we can end up in situations with this implementation where the second iteration could do more than the base. Let me put something together and make a branch on the repository and make a pull request. I'll reply here once it's up.
Hi! In GunScriptableObject script, there is a method called Clone. I notice that you create Gun scriptableObject via the Unity Editor and Instantiate it with Clone() method. Are we obliged to create an instance of these scriptableObjects after we created them via the editor? Why ?
We do this so when we are playing around in the Editor at runtime we don't accidentally modify the base values of the guns. In this series we've implemented Modifiers, which at runtime manipulate some of the configuration values. It is not mandatory to do if you do not use a modifier system, but it does help prevent accidental runtime changes to the base configuration of the guns.
Please continue your hard work😀
For sure 😊
Awesome 😮😮
🤩
omg my dream videooooo 😭❤ can you please research about rainbow six destruction system?
Bro first person controller joystick like granny game in unity pls make tutorial.
First, I just want to say that your videos are great, they are miles above most of the other channels who teach Unity incorrectly (like framerate dependent lerping is a frequent culprit) yet have 100ks of views.
I have modified your system quite a lot, but I still think I have discovered a potential bug in the way your bullet penetration raycast check works , shown at at 6:45. It would typically only matter if the MaxPenetrationDepth is a larger value though. Essentially, if you shoot a collider A, and the "backcast" ray hits another collider B, this means that the hit point of collider B will be the new trail/shot origin passed to the subsequent recursive call to DoHitscanShoot() - effectively meaning the space between collider A and collider B is ignored. You might already be aware of this, and it might be by design + I can't really think of a good alternative solution to avoid this, but I felt like it was worth mentioning
I did think about this but couldn't come up with a great solution for it. If you come up with something let me know! :)
@@LlamAcademy I have come up with a solution. After the first raycast A, you do a second raycast B in the same direction but with the origin set to A's hit + a small step in the shoot direction to prevent hitting the same collider again. Then, if raycast B hit something, you do a new raycast C with origin at raycast B's hit, but in the backwards direction. Raycast C should hit the same collider as raycast A, but on the opposite side. Now you can compare raycast A and C's hit to get the depth of the collider. To continue checking for colliders, set the raycast A's hit variable to raycast B's hit variable (hitA = hitB), and repeat the raycast B and C step in a loop, such that the next iteration raycast B's origin is set to where the previous raycast B's origin hit. I hope that makes sense
Would love to see different penetrations based on the impact system
Hi Chris, good tutorial as always, but I have a question. If you have random between two constants damage selected(i.e 10 and 25) and damage retention percentage for example 0.75. You get this weird thing where the first contact can do 10 damage and the second contact 25*0.7 = 17.5 damage. How do you recommend to fix this?
That is a great question! It probably makes sense to make the damage calculation consider the original damage amount instead of the maximums. It also probably makes sense to move the penetration calculation within the Damage Config.
This becomes a little tricky for hitscan, but easier for projectiles.
In this video I was considering constant damage or single curve falloff primarily. For those cases with random between range or random between curves we can end up in situations with this implementation where the second iteration could do more than the base.
Let me put something together and make a branch on the repository and make a pull request. I'll reply here once it's up.
@@LlamAcademy Thanks a lot! Your tutorials are very helpful.
I didn't forget :) this is a little more complex to handle than I initially was hoping. I may end up making a video about it
@@LlamAcademy Looking forward to see the video
Can you make a tutorial on how to enable ragdoll when falling plz😅
This is one of those videos that you keep the headphones on.
Hi!
In GunScriptableObject script, there is a method called Clone. I notice that you create Gun scriptableObject via the Unity Editor and Instantiate it with Clone() method. Are we obliged to create an instance of these scriptableObjects after we created them via the editor? Why ?
We do this so when we are playing around in the Editor at runtime we don't accidentally modify the base values of the guns. In this series we've implemented Modifiers, which at runtime manipulate some of the configuration values.
It is not mandatory to do if you do not use a modifier system, but it does help prevent accidental runtime changes to the base configuration of the guns.
@@LlamAcademy Thank you