You can make it waaay smaller if you gzip it also. Can throw a cryptostream on top of that too. For 50 bytes not neede tho but if it gets bigger like 5mb I would always gzip it
Hello Chris! Hope you're doing good pal! Chris, I have a question, right now I'm working on the modifier system and adding acid and flame rounds to the game. I have a simple question, there has been this functionality I'm trying to add to the Surface Manager, (its pining the effect to the object hit) so it works on moving targets, but I can't simply SetParent() because there has been this bug nagging me the whole day. The bug apparently happens because how unity handles parents and childs scales, when I set as a parent if the parent has the scale that is not (1, 1, 1) the scale of the children scale gets distorted. As an example: when I hit the ground that has a scale of (100, 1, 100) the bullet decal gets way bigger, currently the bullet decal is (0.07, 0.07, 0.05).
So, I know PlayEffects is responsible for instantiating the particle system at the hit point, so I started by passing the object hit as parameter. PlayEffects(Vector3 HitPoint, Vector3 HitNormal, SurfaceEffect SurfaceEffect, float SoundOffset, GameObject HitObject), Next I tried the following: instance.transform.SetParent(HitObject.transform); instance.SetActive(true); instance.transform.position = HitPoint + HitNormal * 0.001f; instance.transform.forward = HitNormal; That didn't work. Tried Setting the decal size to the original value after parenting: instance.SetActive(true); instance.transform.position = HitPoint + HitNormal * 0.001f; instance.transform.forward = HitNormal; Vector3 originalScale = instance.transform.localScale; instance.transform.SetParent(HitObject.transform); instance.transform.localScale = originalScale; Didn't work either... The only solution i tried that worked was kinda hacky and could bring performance overhead. // Create a new GameObject at the hit point GameObject impactPoint = new GameObject("ImpactPoint"); impactPoint.transform.position = HitPoint; impactPoint.transform.rotation = Quaternion.LookRotation(HitNormal); // Parent the new GameObject to the hit object impactPoint.transform.SetParent(HitObject.transform, true); // Parent the instance to the new GameObject instance.transform.SetParent(impactPoint.transform, false); instance.SetActive(true); instance.transform.position = HitPoint + HitNormal * 0.001f; instance.transform.forward = HitNormal; that way a new empty object is created and parented, and the scale of the child (bullet hole decal) don't get messed up. But yeah... Super hacky solution.
If you have any insight on how to fix this issue, I'd gladly take it. With this functionality I think adding the visual representation of the actual burning and acid rounds would be pretty straight forward. Thats the only thing left for the system to be done, then I can move forward with the project :)
Oh, hi again! For anyone that is reading and was having similar problems, I want to update you. I finally found a way to fix the issue, for me it worked flawlessly, it might not be the best solution for you. So onto the problem i was having: I wanted a way to parent impact effects onto the mesh/ whatever the bullet made contact with. What I wanted out of this was to have a lingering effect on the selected impact effect (like a "fire effect" that lingers for a while for a grenade launcher) and by having it parented to the hit object it would give the feeling of "burning" that object without messing with coroutines for that... Basically a simpler way of doing it. So I did fix the problem but I didn't rely on changing the Surface Manager. What I did was, instead of changing how the surface manager instantiates the particle / decals (effects in general) I handled that in a less destructive way withing the Special Effects itself. I call it destructive changing the surface manager because its an integral part of many systems, if you mess with that you'd have to mess with the object pool system to handle cases where the object is destroyed but had the effects parented to it... so you'd have to clear the objects from the pool list... and many other unforeseen problems could derive from that. So the Surface manager was untouched, it still instantiating the impact effects at the hitpoint normally. What i did was add an GameObject variable to the ImpactType Scriptable Object that variable holds the "lingering effect" for that impact type. On GunModifierApplier we already had the reference to this variable. So in my case I created the Acid Rounds (Impact Type ) and gave it an Acid like particle effect that plays for 5 seconds, had looping disabled and, had stop action as destroy(in my case destroy is fine because of how limited the quantity of the instantiated objects going to be). So after that on the Acid class that extends AreaOfEffect in the function Handle Impact I handled the instantiation: if (HitObjects[i].TryGetComponent(out IDamageableOverTime dot)) { GameObject acidEffect = Object.Instantiate(AcidEffectPrefab, HitObjects[i].transform.position, Quaternion.identity); acidEffect.transform.SetParent(HitObjects[i].transform); //Debug.Log("Applying damage over time to: " + HitObjects[i].name); dot.ApplyDamageOverTime(DamageOverTime, DamageOverTimeDuration); } Just like that i fixed the problem. I still have everything working as i wanted, the enemy loses its health over a period of time, he has the visual representation for that type of damage, and that works independently of any other system. Now I can have Flame rounds, Bleeding Rounds, whatever rounds and assign the proper effects to them if i want. Other Impact Types like Bullet (impact type) wasn't affected because the system only looks for the the specific impact type in this case "Acid Rounds" for applying the modifier only then the variable within Impact Type is necessary. So you don't need to give each Impact type Scriptable Object its "lingering effect"... If you're reading this and had similar problems, I hope this approach helps you!
Thanks for sharing your solution! I think I would handle this similar to how we have "Frost" and "Explode" classes as ImpactEffects. Instead of "AreaOfEffect", I would do a "DamageOverTime" Collision handler that does more or less what you're doing in the code above. In Llama Survival I also had burning & frost rounds using this style of implementation. I did need to spawn particle systems to follow the enemy around. You can do that either like you are now by instantiating a new particle system under the enemy (or using an object pool), or just having one already existing there and turning it on / off within your "DamageOverTime" Collision handler. I found limiting the number of effects per zombie was useful because if you had a high rate of fire gun with burning rounds you would have dozens of particle systems live on each enemy.
@@LlamAcademy oh yeah i didnt mentioned that but a DamageOverTime class was exactly what I did lol, its working pretty well and its clean. Thanks for the reply, keep going with your awesome knowledge, youre doing wonders for the community 💪! Btw what will you be doing in the next tutorial? i'm super excited for the next episode!
Target screen size should be set in custom Panel Settings file. Never name first element as root, name it “wrapper” for ex. You already have root in document, avoid confusion. And I am only 4 minutes into the video.
You can make it waaay smaller if you gzip it also. Can throw a cryptostream on top of that too. For 50 bytes not neede tho but if it gets bigger like 5mb I would always gzip it
Very true! I didn’t cover zipping here because the size was so small and I didn’t imagine the size would grow very much.
File.WriteAllText creates the file for you if it doesn’t exist. No need to create the file first ;)
I thought for sure I tried that and got an exception. Thanks!
Hey These are amazing, is it possible to import directly from github? I've never used it before. Or should I just copy each script one at a time in?
There’s a button on GitHub that allows you to download the whole project as a zip, or check it out with git
Hello Chris! Hope you're doing good pal!
Chris, I have a question, right now I'm working on the modifier system and adding acid and flame rounds to the game. I have a simple question, there has been this functionality I'm trying to add to the Surface Manager, (its pining the effect to the object hit) so it works on moving targets, but I can't simply SetParent() because there has been this bug nagging me the whole day.
The bug apparently happens because how unity handles parents and childs scales, when I set as a parent if the parent has the scale that is not (1, 1, 1) the scale of the children scale gets distorted. As an example: when I hit the ground that has a scale of (100, 1, 100) the bullet decal gets way bigger, currently the bullet decal is (0.07, 0.07, 0.05).
So, I know PlayEffects is responsible for instantiating the particle system at the hit point, so I started by passing the object hit as parameter.
PlayEffects(Vector3 HitPoint, Vector3 HitNormal, SurfaceEffect SurfaceEffect, float SoundOffset, GameObject HitObject),
Next I tried the following:
instance.transform.SetParent(HitObject.transform);
instance.SetActive(true);
instance.transform.position = HitPoint + HitNormal * 0.001f;
instance.transform.forward = HitNormal;
That didn't work.
Tried Setting the decal size to the original value after parenting:
instance.SetActive(true);
instance.transform.position = HitPoint + HitNormal * 0.001f;
instance.transform.forward = HitNormal;
Vector3 originalScale = instance.transform.localScale;
instance.transform.SetParent(HitObject.transform);
instance.transform.localScale = originalScale;
Didn't work either...
The only solution i tried that worked was kinda hacky and could bring performance overhead.
// Create a new GameObject at the hit point
GameObject impactPoint = new GameObject("ImpactPoint");
impactPoint.transform.position = HitPoint;
impactPoint.transform.rotation = Quaternion.LookRotation(HitNormal);
// Parent the new GameObject to the hit object
impactPoint.transform.SetParent(HitObject.transform, true);
// Parent the instance to the new GameObject
instance.transform.SetParent(impactPoint.transform, false);
instance.SetActive(true);
instance.transform.position = HitPoint + HitNormal * 0.001f;
instance.transform.forward = HitNormal;
that way a new empty object is created and parented, and the scale of the child (bullet hole decal) don't get messed up.
But yeah... Super hacky solution.
If you have any insight on how to fix this issue, I'd gladly take it.
With this functionality I think adding the visual representation of the actual burning and acid rounds would be pretty straight forward. Thats the only thing left for the system to be done, then I can move forward with the project :)
Oh, hi again! For anyone that is reading and was having similar problems, I want to update you. I finally found a way to fix the issue, for me it worked flawlessly, it might not be the best solution for you. So onto the problem i was having: I wanted a way to parent impact effects onto the mesh/ whatever the bullet made contact with. What I wanted out of this was to have a lingering effect on the selected impact effect (like a "fire effect" that lingers for a while for a grenade launcher) and by having it parented to the hit object it would give the feeling of "burning" that object without messing with coroutines for that... Basically a simpler way of doing it.
So I did fix the problem but I didn't rely on changing the Surface Manager. What I did was, instead of changing how the surface manager instantiates the particle / decals (effects in general) I handled that in a less destructive way withing the Special Effects itself. I call it destructive changing the surface manager because its an integral part of many systems, if you mess with that you'd have to mess with the object pool system to handle cases where the object is destroyed but had the effects parented to it... so you'd have to clear the objects from the pool list... and many other unforeseen problems could derive from that.
So the Surface manager was untouched, it still instantiating the impact effects at the hitpoint normally.
What i did was add an GameObject variable to the ImpactType Scriptable Object that variable holds the "lingering effect" for that impact type. On GunModifierApplier we already had the reference to this variable. So in my case I created the Acid Rounds (Impact Type ) and gave it an Acid like particle effect that plays for 5 seconds, had looping disabled and, had stop action as destroy(in my case destroy is fine because of how limited the quantity of the instantiated objects going to be). So after that on the Acid class that extends AreaOfEffect in the function Handle Impact I handled the instantiation:
if (HitObjects[i].TryGetComponent(out IDamageableOverTime dot))
{
GameObject acidEffect = Object.Instantiate(AcidEffectPrefab, HitObjects[i].transform.position, Quaternion.identity);
acidEffect.transform.SetParent(HitObjects[i].transform);
//Debug.Log("Applying damage over time to: " + HitObjects[i].name);
dot.ApplyDamageOverTime(DamageOverTime, DamageOverTimeDuration);
}
Just like that i fixed the problem. I still have everything working as i wanted, the enemy loses its health over a period of time, he has the visual representation for that type of damage, and that works independently of any other system. Now I can have Flame rounds, Bleeding Rounds, whatever rounds and assign the proper effects to them if i want.
Other Impact Types like Bullet (impact type) wasn't affected because the system only looks for the the specific impact type in this case "Acid Rounds" for applying the modifier only then the variable within Impact Type is necessary. So you don't need to give each Impact type Scriptable Object its "lingering effect"...
If you're reading this and had similar problems, I hope this approach helps you!
Thanks for sharing your solution!
I think I would handle this similar to how we have "Frost" and "Explode" classes as ImpactEffects. Instead of "AreaOfEffect", I would do a "DamageOverTime" Collision handler that does more or less what you're doing in the code above.
In Llama Survival I also had burning & frost rounds using this style of implementation. I did need to spawn particle systems to follow the enemy around.
You can do that either like you are now by instantiating a new particle system under the enemy (or using an object pool), or just having one already existing there and turning it on / off within your "DamageOverTime" Collision handler. I found limiting the number of effects per zombie was useful because if you had a high rate of fire gun with burning rounds you would have dozens of particle systems live on each enemy.
@@LlamAcademy oh yeah i didnt mentioned that but a DamageOverTime class was exactly what I did lol, its working pretty well and its clean. Thanks for the reply, keep going with your awesome knowledge, youre doing wonders for the community 💪! Btw what will you be doing in the next tutorial? i'm super excited for the next episode!
Target screen size should be set in custom Panel Settings file.
Never name first element as root, name it “wrapper” for ex. You already have root in document, avoid confusion.
And I am only 4 minutes into the video.
That's one way to do it for sure!