is there a way to do location specific damage in QC?

[Error]

[Urre]

[GiffE]

[Spike]

[Urre]

[frag.machine]

[Spike]

[frag.machine]

[GiffE]

Would it also be possible to just check which tag the trace_endpos is closest too?

[Urre]

[Karatorian]

While I'm sure that engine support would make this all easier, I bet it could all be done with fairly generic QuakeC as well.

The basic idea goes like this. Create invisible target location entities for each player and update their positions in PlayerPostThink. (Which could get kinda complicated, depending on how accurate you wish to be. But possible.)

Then change the attack code to use these entities. By referencing a field to specify the target player and another to specify which part was hit, it should be fairly basic.

However, without using much in the way of extensions, I'm not sure how easy it'd be to make the targeting part work. I don't know exactly what traceline will and won't hit. So it might be difficult to make the entities that represent the target areas be nicely invisible and not interfere with the rest of the physics while still being targetable.

Any thoughts on this?

[Cobalt]

[Spike]

why did you change the makevectors logic? with that you broke pitch angles. only solid_bsp entities have correct the correct angles_x sign for makevectors. assuming you're going for visuals, you want .angles and not v_angle.
My code was written in the context of the projectile, thus 'other' was the victim, and 'self' was an impactor (read: a nail), which is why it used other.angles instead of self.angles. If you're tweaking the shotgun for a sniper rifle or whatever, then you'll need to ensure that the impact point (self.origin in my code) is actually still correct (eg: becomes trace_endpos). If you don't fix that then you're just testing which side of the enemy the player is on rather than where they actually hit.

[Cobalt]

[Cobalt]

So lets say we are touching a player, this code seems to return perfectly the side touched , but if the player changes angles_y for example, since the hit box does not rotate with it, how could we recalculate the new side?

I had asked LH a similar question years ago and he said we need to use dotproduct, but it was to really see what side if the face we are closest to. I had the code working but forgot where I put it. We could use similar here to get started on this job, but of course there is the issue when the angle is a% toward one side and b% on the other.

Not sure if it makes things easier but in the mod I am putting this in, its using Frikbots and I believe Frik has a Phys_obj ent spawned around the outside of the hitbox with a movetype_fly to avoid the old "demonland" wav thud noise and maybe some other stuff Im not sure. Id have to look further, but it might match the players angles_y or it could be modded to match them. Looking at this concept, could this code merely spawn something similar as perhaps a trigger field which rotates with the players angles_y then we check for that ent specificly? Or do we get more mileage doing more involved calcs the other way?


Also wanted to bring up the previously mentioned issue about the Z calc for a headshot not working when the target is a percentage lower or higher then the attacker. I thought that could merely be cured with some basic trig, but it seems there is something missing. Also I noticed if you change the start of the Z for the traceline higher to a point representing the players actual eye level, you fix this, at least for the cases where the target is super close with the same Z origin.
As the target gets higher, you have to aim higher within what looks like a proportional area relative to the new z, but I am at a loss to get there completely - same goes for when the Z is lower for the targ vs the attacker.....