Guns don't shoot to the crosshair

[programmer]

Hello!

I recently found that guns (in vanilla quake) don't shoot to the crosshair's center. I installed the simple "laser sight" mod http://www.gamers.org/pub/idgames2/q...s/lazsight.txt to look into the problem and to find the real bullet destination:
http://imgur.com/MSuthnm
http://imgur.com/DfByIM6
Black crosshair is a real destination, white is an expected destination.

How to fix that issue? Using Quake C.

[Dark_Duke]

I had never really noticed the issue before.

Are you asking how to fix the issue permanently without the use of the mod? If so, check out his source below. You could implement it permanently into the Quake source code and modify the original crosshair, if you so wished and recompile the engine. There is more to his source, its all contained in the lazsight zip folder, they are labeled .QC files

/****
	Laser cross hair

	By Scott Ramsay

	Use "impulse 45" to toggle sight on/off
****/




/**
  SDR_SightThink

  Updates the sights position, angle, and shape
**/

void () SDR_SightThink =
{
	local vector org;

        makevectors(self.owner.v_angle);
	org = self.owner.origin + v_up*16;

        traceline (org, org + v_forward*2048, FALSE, self);

        if (trace_fraction == 1.0)
	{
		// move sight inside player if can hit anything
        	setorigin(self, self.owner.origin );
		return;
	}

	// check if target is damageable and set proper model
	if (trace_ent.takedamage)
		setmodel (self, "progs/cross2.mdl");
	else
		setmodel (self, "progs/cross1.mdl");

	// move sight at line of sight collision
	self.angles = vectoangles(v_forward);
        setorigin(self, trace_endpos );

	// mark think to update sight position
	self.nextthink = time + 0.05;
};



/**
  SDR_SightMake

  Create the laser site entity
**/

void ()	SDR_SightMake =
{
	local entity cross;

        self.sight_out = TRUE;

	cross = spawn ();
	cross.owner = self;
	cross.movetype = MOVETYPE_NOCLIP;
	cross.solid = SOLID_NOT;

	setmodel (cross, "progs/cross1.mdl");
	cross.classname = "laser_sight";

	setorigin( cross, self.origin );

	cross.think = SDR_SightThink;
	cross.nextthink = time + 0.05;
};

crosshairs are for n00bs

[Baker]

Quake as it was released and by extension WinQuake and GLQuake didn't have the crosshair positioned correctly in the center of the view.

It's off center.

You would have to use a modified engine, they all have the crosshair properly centered.

[programmer]

You would have to use a modified engine, they all have the crosshair properly centered.

Quake engine or QuakeC mod or both?

QuakeSpasm doesn't have: (quakespasm.pak is installed)
http://imgur.com/iBUysx5

[Baker]

I guess you are referring to a crosshair that will adjust up/down/left/right to where it would hit the wall? DarkPlaces and Qrack have some sort of feature that wll do that. It's in the engine, but that little mod you found might do it in QuakeC.

That being said, I guess I don't understand what you are wanting.

The GLQuake crosshair won't ever match the same spot, but you could type "crosshair 0" to turn off the "real" crosshair.

[wicked_lord]

Just adjust the crosshair.

cl_crossy "0" = default
cl_crossx "0" = default

mess around with it a bit.

mine is currently set at

cl_crossy "3"
cl_crossx "2"

[R00k]

this is a feature of ProQuake also!
both in DP(i think) and Qrack you can use cl_crosshair_static...
this will center the xhair but also pin point it in 3d to where it will hit.

also in Qrack there is gl_laserpoint 1 but u need enable enhanced particles.

[Spike]

issue 1:
the quake engine has limited networking precision. essentually there are only 256 'notches' with the vanilla protocol, which is really quite course and ugly. many engines improve this by using 16bit angles, for 65536 different 'notches', but it needs both the client and server to be updated and compatible. any lack of precision should be unnoticable.

issue 2:
the engine truncates angles when trying to send. obviously this is most noticable with 8bit angles. this biases your shots to the left by half a notch. this can be resolved clientside, or serverside, but NOT both. with 16bit angles, you won't notice, but it may still be there.

issue 3:
the view position is at origin+22, the firing position is at origin+16.
the actual point on the wall is thus 6qu lower than where the crosshair actually indicates. the exact pixel count varies with distance to the wall. if you're standing right next to it, your shots will only hit a quater of the way from the bottom or so. the effect diminishes by distance.
there's a few things that mods might do to try to solve this, but at the end of the day all they really achieve is that they automatically chose a different point to hit.
an engine can hack in the weapon height value and actually move the crosshair to better indicate where the shot will hit. obviously this will not work too reliably as it won't know the sizes of monsters, or even if they're solid.
obviously, both the mod and engine trying to do something about it will undo the other's work.
and if sv_aim is still enabled, then the y coord of the crosshair is pretty much completely irrelevant anyway (other than for shooting buttons).

[programmer]

JFYI I use https://github.com/Triang3l/WebQuake for my project.

issue 1:
...
issue 2:
...
issue 3:
the view position is at origin+22, the firing position is at origin+16.

Thank you very much! I updated MSG_Read/WriteFloat/Coords to use floats.
sv_aim 2, firing and laser sight positions are at origin+'0 0 22':


New problem: starting position of bullets is at the center of the screen. I'll look into this further.

[Dutch]

New problem: starting position of bullets is at the center of the screen. I'll look into this further.

This is easily fixed in QC.

Go into weapons.qc and locate the W_FireRocket() function. Note the line that reads:

setorigin(missile, self.origin + v_forward*8 + '0 0 16');

This is spawning the rocket at a point 8 quake units in front of the player relative to his pitch (up-down) angle and 16 quake units above the z-center of the player (without regard to any angle). The culprit is in the z-offset. If you replace the code with this:

setorigin(missile, self.origin + v_forward*8 + self.view_ofs - v_up*;

it should come straight outta the barrel of the rocket launcher regardless of where you aim. What this does, is it bases the z-positioning of the rocket origin in relation to the player's view offset and pitch angle.

EDIT: you should be able to place the "+ self.view_ofs - v_up*9" part in all of the projectile spawn functions (GL, super NG and NG) for their setorigin call with similar results, but you may need to tweak the numbers a bit to your liking.

EDIT2: Keep in mind, however, that this WILL alter gameplay if you are a 20-year veteran of quake. You will notice that shooting down while looking over edges will not be the same (i.e. you may blow yourself up, because the rocket is no longer spawning where your crosshair is, and will be traveling slightly under your crosshair, which brings you back to your original problem).

To fix this, you will need to set the rocket's velocity in relation to a traceline from where the rocket spawns to where the player is aiming in the game world (basically, where the player's view comes in contact with an object such as a monster or a wall). We will have to run some traceline functions for this.

I went ahead and whipped this up and tested it. You can replace the entire W_FireRocket() function with this code:

/*
================
W_FireRocket
================
*/
void() W_FireRocket =
{
local entity missile, mpuff;
local vector org, end;

self.currentammo = self.ammo_rockets = self.ammo_rockets - 1;

sound (self, CHAN_WEAPON, "weapons/sgun1.wav", 1, ATTN_NORM);

self.punchangle_x = -2;

missile = spawn ();
missile.owner = self;
missile.movetype = MOVETYPE_FLYMISSILE;
missile.solid = SOLID_BBOX;
missile.classname = "missile";

// set missile speed

makevectors (self.v_angle);
traceline (self.origin + self.view_ofs, self.origin + v_forward*10000 + self.view_ofs, FALSE, self);
end = trace_endpos;
org = self.origin + v_forward*8 + self.view_ofs - v_up*8;
traceline (org, end, FALSE, self);
missile.velocity = normalize(trace_endpos - org);
missile.velocity = missile.velocity * 1000;
missile.angles = vectoangles(missile.velocity);

missile.touch = T_MissileTouch;

// set missile duration
missile.nextthink = time + 5;
missile.think = SUB_Remove;

setmodel (missile, "progs/missile.mdl");
setsize (missile, '0 0 0', '0 0 0');
setorigin(missile, org);
};

New or modified code is highlighted yellow. You should be able to use this to alter the other projectiles as a learning experience, because the others will vary (especially the grenade launcher). I know I threw a lot at you there, but I just got home from work and am totally beat...I also don't know how much you know, so if any of that needs explaining, don't hesitate to ask. I will respond ASAP...and don't be surprised if a more experienced coder chimes in and helps you with a better method, I'm not all that great myself and haven't figured out all the subtleties behind everything, but to my knowledge (and quick testing) this works pretty well.

Happy coding and welcome aboard!

[Spike]

Thank you very much! I updated MSG_Read/WriteFloat/Coords to use floats.

New problem: client is unable to connect to any public servers, nor play existing demos.

[programmer]

I'm not all that great myself and haven't figured out all the subtleties behind everything, but to my knowledge (and quick testing) this works pretty well.
...
Happy coding and welcome aboard!

Wow! Thank you! ---

New problem: client is unable to connect to any public servers, nor play existing demos.

It's not a problem I'm trying to make an entirely new game.