fix: shotgun not applying knockback on frag

[WofWca]

This fix is primarily aimed towards improving #53, but it is also useful on its own.

This is me on #53 and with cg_gibsMaxRandomVelocity 0 shooting at a low HP enemy, before the fix, then after:

shotgun-knockback-before.mp4

shotgun-knockback-after.mp4

[LegendaryGuard]

This fix is acceptable, although I think adding a new PMF flag (PMF_NO_KNOCKBACK) is a bit risky, I would try to find another alternative. Therefore, modders are left with no alternatives for using these resources, because pm_flags is a networking variable that depends on the engine and is limited to 16 bits.

Have you ever tried with client->ps.pm_type == PM_DEAD or client->ps.eFlags & EF_DEAD in the conditional you tweaked in g_combat.c?

[WofWca]

Hmm yes, this isn't great, I didn't know that this also affects the network struct.

Have you ever tried with client->ps.pm_type == PM_DEAD or client->ps.eFlags & EF_DEAD in the conditional you tweaked in g_combat.c?

I have checked, and this might have looked nicer, but would suffer from the same problem, because we set the flag in player_die, which means that the next pellet will check it and apply no knockback:

baseq3a/code/game/g_combat.c

Line 430 in 81eeaa0

self->client->ps.pm_type = PM_DEAD;

I will investigate applying knockback based on these

baseq3a/code/game/g_local.h

Lines 277 to 282 in 582b7a3

	// sum up damage over an entire frame, so
	// shotgun blasts give a single big kick
	int damage_armor; // damage absorbed by armor
	int damage_blood; // damage taken out of health
	int damage_knockback; // impact damage
	vec3_t damage_from; // origin for vector calculation

[WofWca]

Closing in favor of #58

[ensiform]

Couldn't you have continued same PR with more commits added to it? Any commits to your fork's branch that is linked on the PR will update the PR fwiw. Getting a lot of noti noise from all these minor PRs.

[WofWca]

Couldn't you have continued same PR with more commits added to it?

I took a different approach, sometimes it's sensible to have a different MR in such a case so that it's easier to understand what happened reading the comments.

Getting a lot of noti noise from all these minor PRs.

Are you talking about just this PR and the one that supersedes it or about all my PRs? One giant PR with lots of changes is not easy to review and is not easy to merge, because one little thing that's not good enough will block the rest of the good changes. I though that's common to make PRs as small as reasonably possible.