Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makron cannot be gibbed #889

Open
ghost opened this issue Sep 7, 2022 · 4 comments
Open

Makron cannot be gibbed #889

ghost opened this issue Sep 7, 2022 · 4 comments
Labels

Comments

@ghost
Copy link

ghost commented Sep 7, 2022

The two halves of Makron's corpse cannot be gibbed because:

  1. The torso is spawned in as a separate entity that cannot take damage.
  2. gib_health is set to -2000, but Killed() contains a check that prevents health values below -999.

Because gib_health is set for the Makron, I assume that this is a bug, not a feature.

The solution for (1) (borrowed from kmquake2) is to make the torso able to take damage and add a function makron_torso_die for gibbing the torso. (2) can be solved by adding an exception based on targ->classname in Killed(). Both worked for me.

If you want I can do a PR for this.

@BjossiAlfreds
Copy link
Contributor

BjossiAlfreds commented Sep 7, 2022

Another thing to think about with (1) is that it's spawned at a fixed origin relative to the legs, so there is no bound checking. Maybe increase the size of the hitbox (but not bigger than the Makron itself) and trace from the legs opposite the facing direction?

As for (2) I'd just remove that check entirely. I did that over 10 years ago in my mod and never looked back. You can then add a -99 lower cap to the HUD health display code so that -100 and above don't get cut off.

@ghost
Copy link
Author

ghost commented Sep 7, 2022

Would 60x60x30 be large enough for the hitbox? Also, my understanding of the issue is a bit fuzzy, but doesn't makron_die() already spawn the torso at a fixed distance opposite the facing direction of the legs?

If that check is indeed only there to ensure that negative health values fit on the HUD, removing it and changing the HUD health display code as you suggest would make more sense than adding an extra check.

@BjossiAlfreds
Copy link
Contributor

BjossiAlfreds commented Sep 7, 2022

I use -24x-24x0 to 24x24x16, I find that works really well.

The origin offset is axis aligned, it's not calculated from the makron's forward vector. And also, there is no bounds checking, so the torso will happily spawn inside a wall if the destination happens to be that.

My code looks like this, feel free to use it if you want. If you do, make sure torso mins and maxs are set before calling.

static void set_torso_origin (edict_t *self, edict_t *torso)
{
	vec3_t	v;
	trace_t	tr;

	AngleVectors (self->s.angles, v, NULL, NULL);
	VectorMA (self->s.origin, -84.0f, v, v);

	tr = gi.trace (self->s.origin, torso->mins, torso->maxs, v, self, MASK_SOLID);

	VectorCopy (tr.endpos, torso->s.origin);
}

(I also made the torso MOVETYPE_TOSS and made torso_think call M_WorldEffects, but that's just extra stuff for custom maps/situations.)

@Yamagi
Copy link
Member

Yamagi commented Sep 16, 2022

If you want I can do a PR for this.
Yes, please do! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants