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.