Deathbubbles origin? Thread - qc

Looking for suggestions on improving the .origin for bubbles to make them look closer to the head area. As it is now in stanadard progs, the code is probably good, however, I am taking the corpse a step further, and giving it an avelocity , plus a movetype_bouncemissile so that its got some waterfriction of sorts. Quake never really made a movetype_swim per say, but the bouncemissile basically will do the same as movetype_fly but bounce off walls which is perfect for underwater physics purposes on corpses.

The main issue here, is I am giving the corpse a "random" deathframe , not calling the usual ones in playerdie () when we die in waterlevel > 2..... so its hard to say exactly where the head is located on a frame for frame basis. As an experiment I am doing:

if (self.owner.corpseflag & CF_CORPSE) // A corpse is creating the bubbles from its own.think
	{
	makevectors (self.owner.avelocity); 
        // Is this any good? corpse will have an avelocity to simulate water movement
        setorigin (bubble, (v_up * -13 + v_forward)); 
         }
        else
	setorigin (bubble, (self.owner.origin + '0 0 24')); // normal player dying, 24 units is head?

So will the makevectors give us the general direction the corpse is rotating into? Or do I need to normalize that first or thereafter?

Edited by: Teknoskillz

Um, you mean player.mdl and not h_payer.mdl right...
Then, what death frame are you in?

This is the standing player bounding box:

mins ' -16.0000 -16.0000 -24.0000'
maxs ' 16.0000 16.0000 32.0000'
size ' 32.0000 32.0000 56.0000'

'0 0 0' on the player model is basically just below waist center.
(This is done for rotates - 360 around z axis and about +/-15 deg. around the y axis as you look up and down.)

On a floor top at exactly Quake map z = 0, I have

origin ' 331.9905 64.8644 24.0312'

So the waist - which is the model "rotate" point for rotation around the y-axis:

A guestimate of head top is around 24 units above the model z = 0 waist.

Given your 1PV eye level view:

view_ofs ' 0.0000 0.0000 22.0000'

At 22 units above model z = 0, that is a pretty good estimate for head top.
In a stand frame.

In run or other frames, head top bobs around.

The issue with where the head is at in deathframes - you have to know which frame and then approximate the position.
You could do it with an editor that gives you coords.

In QME you could set vertice mode and go to a death frame and select a vertex.

'20.77 0.63 -15.62'
But... That does not translate to Quake map coords!

Note that I specify Quake map or model coords.
If you know that model x axis positive is positive v_forward - you could set origin to:

ent.origin + v_forward * 20 + -15 * v_up

The player bounding box does not change unless code changes it, nor does it ever rotate - Moddb.com

And I looked to see if makevectors returns normalized vectors. The manual does not say.

I will say they are used like they are already length 1, which is my understanding.

Good stuff !

I guess to do this right I would have to use Qme like that and write down manually the vertices like you did...then find a way to convert them with a forumla like you made for ent.origin , all on a case by case basis comparison of what frame we are in. Time consuming, but can be done.

This also ties in with something else I was doing where I made a .head_ent which is basicly a movetype_follow that occupies the approx coordinates of the players head, using the depictions you posted. Yes, during stand, thats the easy one, but run, attack , pain or die all are complex cases. After just posting in the other thread with the new player_jump frames, perhaps those are the best places to code in the offsets on such an ent for example.

While in this post I am only specifying an underwater death case and theres really no animation (not yet anyway), just 1 frame this definately gets me started in the right direction. On the head_ent, it was something more for like a hitlocaiton type damage system I experimented with and had some moderate success. But I will probably start another topic on that one.

Im not a modeler per say, though I have invited a good one to come here and maybe provide some insight on this. I always thought it should be possible to perhaps detect "occupied" pixels, for lack of a better explanation on a mdl in some way....then basically map them out manually and determine what part of the players body they correspond to. Q3 models probably already do this maybe, something like a tag system I think its called, DP seems to support it , plus skeletal / bones which Im not sure but also may similar?

Edited by: Teknoskillz