Question Player Orientation affecting projectile movement after it's shot

Creating a hurtbox for detecting hits. This hurtbox is currently following the player looking direction and, when enabled, will move toward the local X. Everything looks normal if the player camera is not rotated; it follows the correct line in any direction. However, if the projectile is in flight and the player turns, the hurtbox also moves in the space. Is there a way to un-link these with the current hierarchy set up? Or am I using the wrong approach with rb.AddRelativeForce(x); in the OnEnable(); method?

If this thread is better suited for the Physics forum, let me know.

I was hoping to have the hurtbox as part of the weapon prefabs so that their starting locations could be altered by the weapon type. I'm also not currently instantiating hurtboxes in the script because I want to eventually implement object pooling for ranged attacks with variable spawn rates.

DaggerFlippedNormals(Clone) is generated at runtime from a prefab with the HurtBox as part of it, if that matters.

The Hierarchy appears as
Player Object
>PlayerCamera
>DaggerFlippedNormls(Clone)
>HurtBox (disabled)

Code (CSharp):

1. private float hurtBoxUpTimeLeft;
2.     private WeaponStats parentWeaponStats;
3.     private IWeapon parentWeaponInterface;
4.     private Rigidbody rb;
5.     private Vector3 startingLocation;
6.     private Quaternion startingRotation;
7.  
8.     private void Awake()
9.     {
10.         rb = GetComponent<Rigidbody>();
11.     }
12.  
13.     private void OnEnable() //hitbox is enabled on leftclick
14.     {
15.  
16.         //look at how these variables line up omg i'm gonna cry;
17.         parentWeaponStats = GetComponentInParent<WeaponStats>();
18.         parentWeaponInterface = GetComponentInParent<IWeapon>();
19.  
20.         startingLocation = transform.localPosition;
21.  
22.         hurtBoxUpTimeLeft = parentWeaponStats.HurtBoxUpTime;
23.         transform.localScale = parentWeaponStats.HurtBoxSize;
24.  
25.  
26.         //TODO: rotation is following the player for ranged attacks, it shouldn't
27.         //TODO: allow rotation to follow player only for melee attacks
28.      
29.         rb.AddRelativeForce(parentWeaponStats.HurtBoxVelocity * Vector3.forward, ForceMode.Impulse); //travelling the wrong way on the X axis...
30.  
31.     }
32.  
33.     private void Update()
34.     {
35.         hurtBoxUpTimeLeft -= Time.deltaTime;
36.         if(hurtBoxUpTimeLeft <= 0)
37.         {
38.             transform.gameObject.SetActive(false);
39.         }
40.     }
41.  
42.     private void OnDisable() //hitbox disabled when hurtBoxUpTimeLeft < 0
43.     {
44.      
45.         rb.velocity = Vector3.zero;
46.         transform.localPosition = startingLocation;
47.     }
48.  
49.     private void OnTriggerEnter(Collider other)
50.     {
51.         if(other.gameObject.TryGetComponent<IDamageableByPlayer>(out IDamageableByPlayer damageable)) //make sure the entity hit can be damaged by the player
52.         {
53.             parentWeaponInterface.WeaponHitSomething(damageable); //using the weapon interface, we do whatever the weapon is supposed to do inside the "WeaponHitSomething" function!
54.         }
55.    
56.     }
57.  
58.  
59. }

 

Make sure your projectile isn't parented to your weapon. It should be its own object under the scene root.
It is ok to use its localPosition, even preferred, but only after you made sure it's not parented to a wrong object, an object that will also move and/or rotate.

lol nice

 

Well your title has nothing to do with your actual problem, I'm trying to parse the rest of what's going on ...

 

Figured this was the problem, but was hoping there was an easy way to unlink the projectile after it was enabled. The hurtbox is currently a child of the weapon itself and relies on that to get relevant stats from the parent components. This implementation works perfectly for melee applications but, in its current state, is unusable for ranged. Thanks for steering me in the right direction.

 

Well, your entire setup is quite weird. Hitboxes, or 'hurtboxes' as you call them, naturally belong to whatever needs to be hurt. Not the other way around. Normally you'd set this up so that while both objects have colliders, you want your hurtbox to be on the receiving end.

If your projectile have supersonic velocities, like typical bullets do, then you don't even care about the source collider, you instead test the collision by casting rays.

But with things like boomerangs and missiles when you do need to equip the mesh with a collider, to be able to react once physics detects an appropriate collision, you determine the hit target and apply damage to it. Usually the biggest trouble with the system is how exactly to make a scalable solution that will stay healthy and maintainable in the long run, due to cross-communicating nature of its parts that are independent by definition, but the issues are never about which component is parented to what.

So when you say

I really don't have a proper response how to fix this, apart from suggesting to maybe rethink how you're approaching this?

 

Yeah the terminology isn’t exactly right. The flow of an attack goes like this.

Player Clicks ->
“WeaponAttack();” function triggers ->
hurtbox (or attack box whatever you may call it) is enabled ->
if the hurtbox generated by the weapon collides with an enemy, reference the weapon interface function “WeaponHitSomething();” ->
All relevant on hit effects are applied.

I’ve opted to slightly back track this code and leave it for melee options only. Ranged projectiles will have to be handled differently because of the way the stats are pulled from the parent component.

 

Yeah but why would you parent the receiving end (hurtbox) to a source (weapon)?

I am also unable to understand this. Can you explain more?

When you're saying 'hurtbox' and 'attack box' do you mean like the part that is supposed to bring hurt? Because a hitbox is exactly the opposite thing, that's what threw me off. Usually we all care much more about how to receive the hurt.

Regardless I still can't understand what the problem is. Can you explain again why you think that inheriting weapon's transform would be undesirable? This is already massively derailed because of terminology, but let's try this again.