Some help about vectors and coordinates

[ChOwW]

Hello everybody,

I am trying to make some basic modifications to the quake engine, in order to understand a little more vectors and aiming, but without any help of other ports.

As you have maybe noticed, when we fire something, the coordinates are always right into the center of the screen, no matter the position of our view.

However, what I am trying to achieve is a little more "difficult" to do...

I am trying to make a Goldeneye64 "aiming system" clone, in order to understand a lot more how vectors are working. To be honest, I am really lost about that, and I know the Wii-QuakeGX port has that system done with the wiimote.

I have made some basic changes in gl_screen.c ( SCR_UpdateScreen(void) ) in order to make the crosshair appear:

Code: Select all

(...)
	else if (cl.intermission == 2 && key_dest == key_game)
	{
		Sbar_FinaleOverlay ();
		SCR_CheckDrawCenterString ();
	}
	else
	{
		if (bCrosshair)
		{
			Draw_Character (scr_vrect.x + crossx , scr_vrect.y + crossy, '+');
		}
		else
		{
	       	    crossx = vid.width/2;
		    crossy = vid.height/2;
		}

and some changes in in_win.c ( void IN_MouseMove (usercmd_t *cmd) ) to move the crosshair to the x/y coordinates of my screen resolution.
I know, I tried some things before, but I need to seriously clean A LOT OF THINGS on that engine...

Code: Select all

(...)
	old_mouse_x = mx;
	old_mouse_y = my;

	mouse_x *= sensitivity.value;
	mouse_y *= sensitivity.value;
	
	if (in_mouselook.value)
	{
		V_StopPitchDrift ();
		
		bCrosshair=false;

// That SHOULD disable the view!!
// But doesn't work...

	// If we are aiming____
	 if (in_mlook.state & 1)
	{
		bCrosshair = true;

		crossx +=  mouse_x * aim_sensitivity.value;
		crossy += mouse_y * aim_sensitivity.value;

		if ( crossx <= 0 ) crossx = 0;
		if ( crossx >= vid.width) crossx = vid.width;
		if ( crossy <= 0 ) crossy = 0;
		if ( crossy >= vid.height) crossy = vid.height;
	}
	 else	{

		cl.viewangles[YAW] -= m_yaw.value * mouse_x;
		cl.viewangles[PITCH] += m_pitch.value * mouse_y;

		if (cl.viewangles[PITCH] > 80)
			cl.viewangles[PITCH] = 80;
		if (cl.viewangles[PITCH] < -70)
			cl.viewangles[PITCH] = -70;
	}
}

with some screen debugging added, here's the result:


(res: 640*480)

However, now that I can move my crosshair anywhere on my screen, the most difficult thing is to aim to that position.
After some time, I've noticed that I had to check PF_aim (void) [pr_cmds.c] to be able to fire where I wanted to aim...

But that's nearly ununderstandable for me actually...

After the basic changes, I've maybe got an hint, but that drives me crazy :

in PF_aim (void) :

Code: Select all

(insert 90% of PF_aim here ... )

if (bestent)
	{
		VectorSubtract (bestent->v.origin, ent->v.origin, dir);
		dist = DotProduct (dir, pr_global_struct->v_forward);
		VectorScale (pr_global_struct->v_forward, dist, end);
		end[2] = dir[2];
		VectorNormalize (end);
		Q_DPrint("HIT!!!!!!!!!!!"); // How does that part of code work?
		VectorCopy (end, G_VECTOR(OFS_RETURN));
	}
	else
	{
		if (bCrosshair) // bCrosshair is the bool to check if we are aiming with the crosshair coordinates
		{
			crossaim[0]= crossx;   // CrosshairX coord
			crossaim[1]= crossy;   // CrosshairY coord
			crossaim[2]= dir[2];    // Direction of the player?
			VectorNormalize (crossaim);  // Make crossaim a vector 
			VectorSubtract(pr_global_struct->v_forward,crossaim,crossaim);  // substract our current view with our coodinates?
			VectorCopy (crossaim, G_VECTOR(OFS_RETURN));    // Returns the vector where to shoot
			
		}
		else
		VectorCopy (bestdir, G_VECTOR(OFS_RETURN));
	}

And with some "lol"esque tries, I've been able to shoot in this direction:


(res: 640*480)

thanks in advance for the help...

[Baker]

I'm skeptical anyone is going to help you make a client-side bot. A legitimate project would asking this in the QuakeC section.

I'm just stating what I bet everyone this thinking reading your post, there is no reason that this would be a client-side engine modification to achieve what you are trying to do.

Especially when the server-side aim help already does this!

Besides, any competent engine coder can see by the mere file names you aren't messing with a Wii port. in_win.c? That's Windows. Everyone knows this. And your screenshots are vanilla Quake --- your screenshots don't even show any evidence you are making a mod.

People aren't stupid, ya know ... :roll:

[ChOwW]

No Baker, you get it totally wrong.

I'm not going to make a client-side bot (and I don't know why you thought of that). As I just said above, I am just trying to understand how to make a goldeneye 64-like aiming system, in order to understand simply how to translate a screen coordinate into a vector. So, if you played it, I pressed&hold a button, a crosshair appears, I move it, and it shoots where I want to shoot.

Nothing more.

Also, I've only stated that the wii port has already a system like that. Have I said anywhere that I am USING IT? Of course not. You've however noticed that I Just use a stock new vanilla GlQuake port.

But my goals were quite simple: I just want to create a simple "TC" which imitates GE64 but on Quake. Just for educational purposes.

I know there is an "aiming help" built in PF_aim and linked in QC, but that doesn't help me at all actually...

[gnounc]

He wants view independant aim, where your aim can be offset from screencenter and your cursor toggled.
and probably a slight zoom in, and lookspring.

toggle cursor and zoomin can be accomplished by bindings.
vew independant aim is something ive always been curious about for headtracking,
but i cant rememeber if i read about someon ever doing it or not.

[Spike]

you basically need gluUnProject.

combine the modelview and projection matricies into a single modelviewproj matrix. invert that. transform the 2d coord (with z = 1) by that modelviewprojinv matrix. divide by w. do the same with the 2d coord with z=0. you now have two 3d points. one at the near clip plane and one at the far clip plane.
subtract near from far and you have your direction vector. vectoangles it and you have the angle to send to the server.
note that the view position is not the same as the player entity position, so you'll need to make sure the ssqc deals with view_ofs properly, or to modify the view matrix appropriately beforehand.

the pf_aim builtin works purely in 3d. it will not help with cursor->3d, but it can help correct your aim afterwards, allowing you to be a bit sloppy with your aiming.

note that the dp prydon cursor extension implements much of this stuff already.
also, this doesn't help with making a clientside aimbot at all, just cursor-based aiming.