Rotating player view

[Commodus]

Yea, skew's method with polar coordinates sounds very possible...

 

BTW, when you say

 

comp_R_A = (R . A) / ||R||.

 

||R|| is the magnitude of the vector right?

[Fardreamer]

Here's a funny occurence... I applied the calculations in CG_PredictPlayerState() (in cg_predict.c) just before the call for Pmove... but it works only when I perform a saber attack that blocks mouse control like DFA or a backstab, and then pops back to normal. It's probably because mouse-controlled angles are calculated during Pmove() and not before... now all I have to do is find the thing that disables the call to PM_SetPMViewAngles in Pmove and I'm done!

 

[edit]

Update:

 

Apprently the mysterious function is PM_SetPMViewAngle(), which applies an angle and calculates the ps->delta_angles (dunno what they are). It works fine and my client always faces the opponent! Unfortunately there's a problem with other vectors... it seems as though movement, projectile direction, etc are calculated before the new angle is applied, so the results are screwy gameplay... the forward button doesn't always move forward, but in changin directions according to the opponent's orientation... I'm trying to figure out what's going on.

[skew]

I ran into the same little snag when I was working on a 2d fighting mod for jkii.

 

I was making sure the players faced each other by adjusting their pm->ps->viewangles[YAW] (in pmove_single) to either 0 or 180, depending on who had the greatest X coordinate in their origin. It was a silly little hack but it worked for the time being. But only for rotating the player model. The input and everything still needed to be transformed relative to the new orientation. And with school this past semester, I had no more time to devote to it.

 

I will probably give it another go in a week or so and see what I can come up with. If you wanna see some silly little screens, ive got some up at:

 

http://skew.telefragged.com/mods/jk2/jedifighter/

 

As a side note, the last mod I was working on for jk2 was a tie fighter clone:

 

http://skew.telefragged.com/mods/jk2/tiefighter/

 

This is something I will definitely continue in the coming few weeks.

[skew]

Commodus,

 

Yeah, I use that notation for vector magnitude.

[Wudan]

That's some crazy crazy stuff you've been working on there. CRAZY!

[Fardreamer]

Actually I think that the bug is due to differences between the server and the client code... I only modified cg_predict and not g_active which also calls a Pmove. I checked the movement code and it works eactly as I expected: applies the player speed to a forward vector caclulated from viewangles (after we update them).

 

And where'd the coding forum go?

[Fardreamer]

Well, I did it, I had to add SetClientViewAngles to my new angle in g_active.c for the new angle to be recognized by the server, and it works like a charm

 

I still miss the coding forums though

[Wudan]

I'd like to see an announcement on how they've decided to make finding the answers to your questions 100x harder as a thank-you for the community helping to make this site the corner-stone of the JO editing community.

 

Now we have mapping, coding, skinning and god-knows-what all stuffed in to one forum! Yay!

[Fardreamer]

Skew, your projection system didn't work for me... but maybe that's because I was using a problematic cross product function.

 

In any case, I wanted to know if this method, which I used before in JK1 game scripts (it works), makes any sense to you... someone supplied it, I never understood what's really going on.

 

I normalize the player's forward vector - f

I normalize a vector from the origin to my point in question - p

I get the cross product of f with p - let's call it u

if u's z value is positive, the point is on the right, if negative point is on the left.

 

Could you explain how this works?

[skew]

Sure, I can explain it. I dont know if youve taken any physics classes (specifically mechanics) but this might sound familiar.

 

If youve got two vectors, A and B. The cross product of these two vectors is obviously ortohogonal to both A and B. So you can think of it like this. A and B both lie in the same plane. Your cross product vector, vector C, is going to go either in the direction of the normal vector of this plane, or in the opposite direction of the normal vector in this plane.

 

Now, theres something called the right hand rule (used all through physics and math for different things... but I digress) which basically says this. While sticking your thumb straight up, if you laid the edge of your right hand down parallel to one of these vectors (lets say vector A), and rotated your hand (pivoting at the wrist) so it is now parallel to vector B, the tips of your fingers just traced out an arc. Now, if you rotated your hand counterclockwise, your vector C goes in the direction of your thumb (upwards). If instead you had to turn your hand clockwise, you flip your hand over and your vector C faces in the direction of your now inverted thumb. In simpler terms, curl the fingers of your right hand in the direction of the arc and your thumb will point in the direction of the cross product.

 

So you can see that if vector A was the forward vector of your player and vector B is the vector from your origin to the point in question, then if you did the right hand rule test... if the vector C pointed up (positive Z), then vector B is on the left of vector A and vice versa if C pointed down.

 

As for the mechanics reference earlier, the torque vector tau is equal to the cross product of the radius vector with the force vector. Which I'm sure you already knew but maybe it'd help you recall the right hand rule better.

 

Also, I'm curious as to why the other method didnt pan out. Do you think you could paste some sourcecode in here? Mathematically it should work...

 

EDIT: Since the order of the cross product is important, I figured I'd clarify. The vector C I'm referring to is this:

 

C = A x B.

[Wudan]

for those of you following along at home, I give you CrossProduct from q_math.c:

00189 void CrossProduct( const vec3_t v1, const vec3_t v2, vec3_t cross ) {
00190         cross[0] = v1[1]*v2[2] - v1[2]*v2[1];
00191         cross[1] = v1[2]*v2[0] - v1[0]*v2[2];
00192         cross[2] = v1[0]*v2[1] - v1[1]*v2[0];
00193 }

If you don't really understand what a vector (vec3_t, for our purposes here), it's a structure containing 3 numbers, mostly either coordinates(x, y, z) or angles (pitch, yaw, roll). Vector functions don't really care which kind of vec3_t you throw in because the structure is the same. This function takes 2 vectors and outputs a third, just so you know.

[skew]

Fardreamer,

 

You still alive?

[Fardreamer]

Yes... sorry I didn't reply but I was gone for the week. In any case, I appreciate your explanation... I am quite proficient in vector math but I never took any physics classes, which might have been useful for working on 3d games

 

I pretty much understood that the positive Z would indicate whether the cross product vector is pointing up or down, but I wanted to know what it boils down to in math principals (I don't like swallowing formulas without understanding their underlying logic). So thanks for clearing that up.

 

As for your other system, I'm pretty sure I used a bad cross product function that wasn't written by me (in which case this system won't work either); I'll have to rewrite it. I haven't applied this in JO source yet, but in an application I'm programming at work... I'll need it pretty soon for my mod, though (checking whether blaster bolts are coming in from left or right), I just haven't gotten around to implementing it yet

[skew]

I ran into the same little snag when I was working on a 2d fighting mod for jkii.

 

I was making sure the players faced each other by adjusting their pm->ps->viewangles[YAW] (in pmove_single) to either 0 or 180, depending on who had the greatest X coordinate in their origin. It was a silly little hack but it worked for the time being. But only for rotating the player model. The input and everything still needed to be transformed relative to the new orientation. And with school this past semester, I had no more time to devote to it.

 

I will probably give it another go in a week or so and see what I can come up with. If you wanna see some silly little screens, ive got some up at:

 

http://skew.telefragged.com/mods/jk2/jedifighter/

 

As a side note, the last mod I was working on for jk2 was a tie fighter clone:

 

http://skew.telefragged.com/mods/jk2/tiefighter/

 

This is something I will definitely continue in the coming few weeks.

 

If anyone is still alive here, I finally released Jedi Fighter (beta 2) a few weeks ago. Expect a final version by June.

 

Check it out!

 

http://www.moddb.com/mods/jedi-fighter

 

Watch the trailer here!

 

(This BBCode requires its accompanying plugin to work properly.)

 

 

 

 

[ForceFox]

If anyone is still alive here, I finally released Jedi Fighter (beta 2) a few weeks ago. Expect a final version by June.

 

Check it out!

 

http://www.moddb.com/mods/jedi-fighter

And this page has some helpful info on phenq.

Watch the trailer here!

 

(This BBCode requires its accompanying plugin to work properly.)

 

 

 

 

 

I'm still here and this is awesome.