Aiming Behind Target

[Nux]

This is an effect I've been sure of for a while but earlier got into an argument over whether it's actually happening.

Put simply, in unlagged I have to aim behind the target to hit it. What I mean is I find myself making note of where the alien had just been and then firing at that position whether or not it's still there on my screen. The hitbox lags behind the model. I recorded the following with fraps:



Now here's the thing. I don't know if I'm right about this. It could be that when I click the mouse, the target is indeed on my crosshair and it's merely a delayed animation/sound feedback that makes it FEEL like the hitbox was further back.

I'm going to see if I can shoot an enemy that never went over my crosshair, but in the meantime I thought I'd post this to see what others know about it.

[kevlarman]

Now here's the thing. I don't know if I'm right about this. It could be that when I click the mouse, the target is indeed on my crosshair and it's merely a delayed animation/sound feedback that makes it FEEL like the hitbox was further back.

you're correct about this, the original unlagged code to play the animation/sound when your client registers you clicking fire instead of when the server tells you "you fired" never made it into trem (they do have some annoying disadvantages). you'll probably notice this effect extremely diminished (though possibly not completely gone) when your client is the server.

[Nux]

Dang, is that so? This means that my perception is based on wrong assumptions (the case where my crosshair follows just behind a target and never passes over it should miss) and would be causing misses that I've attributed to missing the trailing hitbox. What this also means is that I've been 'waiting' for the animation/sound to hit just behind the target, which coincides with me actually firing at the target. If so, that is some really inefficient and inexact logic I've been working on all this time.

Either that or the concious element is completely unrelated and my twitch reflexes are doing fine without the assumptions.

So what was this stuff I read about lagging hitboxes? I seem to recall reading an FAQ [used to be here: http://alternatefire.planetquake.gamespy.com/unlagged_faq.html] by the guy who made unlagged. I've read elsewhere about a 'lean' issue that caused the model to separate from the hitbox, but this was supposed to be unrelated. Is this all just misconception?

I appreciate the input kevlarman. I'd still like to test a trailing aim properly though, for the sake of destroying a false belief in me if for no other reason.

EDIT: I don't know if you consider demos reliable, but the effect can be see there too. It's hard to record this happening on the fly because fraps brings down my fps the more detailed the video is (the gif above was done with a direct fraps recording, no demos), but I'm definitely hitting even when the crosshair never passes over the target.

[cron]

Here's the site for unlagged: http://www.ra.is/unlagged/
He addresses many issues with unlagged, and possible fixes. It might be the case that the dretch model's bounding box should be adjusted slightly.

[/dev/humancontroller]

This is an effect I've been sure of for a while but earlier got into an argument over whether it's actually happening.

Put simply, in unlagged I have to aim behind the target to hit it. What I mean is I find myself making note of where the alien had just been and then firing at that position whether or not it's still there on my screen. The hitbox lags behind the model.

(server side) sv_fps = ?
(server side) MAX_UNLAGGED_MARKERS = ?
(client side) cl_maxpackets = ?
(client side) snaps = ?

I'm going to see if I can shoot an enemy that never went over my crosshair, but in the meantime I thought I'd post this to see what others know about it.

STATUS?

[Nux]

On the 1.1 client I'm using currently (when I made this thread I was playing on GPP):

sv_fps = 20
MAX_UNLAGGED_MARKERS = (can't find / not sure if it exists in this version)
cl_maxpackets = 30
snaps = 25

Status: Anecdotal evidence.
I've noticed it happen frequently but cannot easily record it happening unless you consider demos a reliable recording.

[/dev/humancontroller]

cl_maxpackets = 125 (on the client) for minimal client-to-server input lag (though the setting is irrelevant when running a local server or when connected to a server on your LAN).
sv_fps = 125 (on the server) for smoother mover/missile physics, and for more precise rollbacks, ie., positions recorded every 8ms (see the note below!).
snaps = 125 (on the client) to allow the server to send every available snapshot, for minimal server-to-client lag.

MAX_UNLAGGED_MARKERS = (can't find / not sure if it exists in this version)

MAX_UNLAGGED_MARKERS is a compile-time constant in the game module. increase that from 10 to, say, 256 (and recompile your game module), to support several-second rollbacks with sv_fps = 125 (with MAX_UNLAGGED_MARKERS = 10 and sv_fps = 125, rollback is limited to ~80ms).

run a server with timescale = 0.2?
also, see cl_packetdelay and sv_packetdelay.

[Nux]

Thanks I'll test these settings tomorrow, though I have no control over what settings the servers I visit use so I'd like to know if that affects what values I should assign.

EDIT: In case you were interested I've uploaded a demo of me playing just now which shows the effect occurring at times that coincide with my memory of them occurring (so if the demo is unreliable, it's consistently coincidentally unreliable at the exact same times.) Look at 7:53 of the last game for a particularly notable example.

[ULTRA Random ViruS]

BTW nux: I tested again and again for about 5+ hours (school closed for weather conditions) when i had no internet with the 'aim behind target' thing, its normal if i host a LAN server simulating the usual 300 ping i get. Most of my unlagged shots actually hit when i aimed ahead by about 2 units.

But i still do get ur 'aim behind target' problem on US official greatly. I've noticed if i shoot somewhere between middle-front of the dretch with md, it will not hit but it hits with half a hitbox behind as well. The reason why i didnt notice this until recently is because i barely use md due to my mouse and computer built in lag.

My best theory is probably the calculation in server-side (yeah i admit defeat, i looked at the source, unlagged is server-side) for the ping as for my case, america-australia is actually faster than australia-america, same deal for us to europe.
I've noticed this because some lucky americans get 180 ping or lower for south-east-asia and australia servers while those asians and us get 250+ for western american servers. (i actually dont get that, but most eastern aussies do get 250 ping only) and it might be the same for you and some of your servers.

[/dev/humancontroller]

its normal if i host a LAN server simulating the usual 300 ping i get.

retarded statement is retarded.

[ULTRA Random ViruS]

You should know what i mean.
I did:

Code: [Select]

devmap atcs
sv_packetdelay 300
!bot add ! aliens 5
!bot add ! aliens 5
g_unlagged 1
g_bot_infinite_funds 1
g_bot_infinite_funds 0sv_packetdelay is a cheat cvar so i have to use devmap anyway. With this on i also used cg_drawbbox 1 just to make sure i'm not missing.

[ULTRA Random ViruS]

*caugh caugh*
Sorry for bringing up this topic from the dead, but here's the biggest evidence i can find for this topic, although it's in the reverse direction.

Here's my theory on how it works:
It's the path in which the send/receive signal takes that are different, resulting in different pings.

I do tests on certain servers in which a volunteering dretch strafes side to side, and i lock onto him with my mouse, using a lasgun. I fire slowly, and if it doesn't hit, i adjust forwards/backwards until it hits. I then estimate the ms/distance i aim ahead/behind the dretch and this follows up:
For US official, i have to aim back about a maximum of 40 units [~100 ms, or one whole dretch and a bit behind] againts dretches.
On Fg* Server, i have to aim ahead about a maximum of 60 units [~150 ms, or two whole dretches ahead] againts dretches.
On Asia unofficials witout unlagged on[i usually don't use unlagged there for humans] i have to aim ahead ~40 units [mathematically speaking, its almost exactly 44.8 units] from a constant ping of 98 (sometimes goes up to 200 randomly) againts dretches. Lagged seems more reliable for me on this server.

Anyway an example of the path theory, since i live in australia connecting to an american server, the 'send' would be travelling under the pacific ocean which results in me sending the signal early , while the receive signal could be travelling through Japan, which results in me receiving the signal late.
Each side can only predict the ping by averaging the two signal speeds together which means my lower ping could be as low as the eastern australians [~250] if the signals take the shortest path.