When server is unpure, shaft beam leaking outside crosshair even though cg_truelightning 1

ioquake3 support
#1

The first demo shows the leaking, the rest shows it does not happen in pure or under any circumstances in vanilla quake 3. As you can see the leaking only happens when moving and jumping while shooting, standing still it stays in crosshair.This is a freshly compiled ioquake 1.36. Does this happen on your system too? I can’t use pure server since I need unpure for my mod to work correctly.

I will add that I was debugging an issue with my mod earlier, and I found that none of the changes I was making to a file were being applied unless the server was unpure. I imagine this could be the same so a change that was made in official ioquake that broke unpure lg went under the radar because testing only occured in pure server?

#2

now im getting it in pure as well, and in vanilla quake 3 although there it is a lot less notable with only small leaks happening. honestly scratching my head at this, must be something fucked up on my machine…

#3

In my testing with the latest ioquake3 source, both pure (using QVMs in baseq3/pak8.pk3) and unpure (using ioquake3 QVMs) feature lightning moving off crosshair when moving and jumping. I haven’t looked into it further.

#4

Right now im in the same place not getting any difference between pure and unpure. I have been able to reduce or remove the lag with some settings though they are not really viable for proper online play which I need. Higher snaps combined with higher server fps seems to reduce it so its mostly straight except during some extreme movements, but higher server fps has other drawbacks like higher ping, 40 would probably be the max I would go and thats not sufficient. g_synchronousClients from what I understand turns off movement prediction and completely eliminates the issue, but at the cost of making movement laggy and rocket jumps feel weird; I saw a post that said you needed sv_fps 125 to get good physics on it, which again is a problem. But this seems to be a clue towards the issue having to do with the prediction. Again I seem to be getting it in quake 3 vanilla as well to a smaller extend, so I might just have to go all out and rewrite the lightningbolt function to always be straight no matter what on truelightning 1; though I am slightly skeptical of doing that because it might just be covering up a deeper issue.

#5

For now I seem to have found a fix to make the line straight, at least visually clientside. I did a test though where I connected to a vanilla quake 3 server with my modded ioquake and found the issue still happening, which indicates its a clientside problem I think? So I think a clientside fix should be enough, here is the code:

in cg_weapons, in function static void CG_LightningBolt( centity_t *cent, vec3_t origin )

comment this line:
VectorCopy(cent->lerpOrigin, muzzlePoint );

below should be this line, uncomment it:
VectorCopy(cg.refdef.vieworg, muzzlePoint );

Further below this code messes up the height of the beam, but removing it also seems to produce weird behavior with truelightning at 0 so instead of outright commenting it I wrapped it in an if statement to not run when true is 1:
if(cg_trueLightning.value != 1){
anim = cent->currentState.legsAnim & ~ANIM_TOGGLEBIT;
if ( anim == LEGS_WALKCR || anim == LEGS_IDLECR ) {
muzzlePoint[2] += CROUCH_VIEWHEIGHT;
} else {
muzzlePoint[2] += DEFAULT_VIEWHEIGHT;
}
}

#6

I just noticed the line occurs more than once, it should be the upper one in the section for the “CPMA” truelightning code