swimming hitboxers are uh... nice... and more extrapolation!

(SCDS_reyalP) #1


Notice if you are swiming just below the surface of the water, your head would be like 2 feet up.

I would suggest using the prone ones instead, maybe nudged a bit in Z.

:moo:

(bani) #2

are you displaying the players bb from cgame’s pov? or are you having the server send over debug railtrals from server’s bb?

(SCDS_reyalP) #3

i’m taking the origin on the client, and doing the same calculation the server does for size and head position (taking into account crouch, prone and view angles).

I also did hit prediction on the client, using the same code to draw a box on the client (like g_debugbullets) and it matches up very well with the one sent by the server (modulo antilag bugs). If the player is standing still, it lines up within a unit or so.

edit:
if anyone wants the code, I can post it. It’s a bit of a mess tho. Quite a bit I ripped from the unlagged2 source.

(TwentySeven) #4

yeah.
fixing the unlagged bugs is pretty easy.
store the ent->s.pos.trbase in the lookup, not the ent->origin
store the trails at the very end of clientendframe() not where it is now.
store the current level.time as the timestamp, do not adjust it.
use the cmd->servertime as the lookup time, not the current frame timegettime() cmd lookup thing.

(bani) #5

unlagged2.1 stores trbase, but snaps it for some unknown reason.

there is also a builtin ~50ms lag in the engine which will foul up your backward reconciliation until you take it into account.

(SCDS_reyalP) #6

The code I used from unlagged 2 wasn’t related to unlagging. I just adapted the bounding box debugging (modified to calculate the same size and headposition the server would use) and weapon effect prediction (modified to show a stationary bounding box if a client would have been hit)

Having the body and and head box displayed all the time is quite informative. It also made me really appreciate how much detail there is in the ET animations. Too bad the hit detection doesn’t match them at all…

(TwentySeven) #7

Bani: ah no, if you use level.time for the markers time, and cmd->servertime for the lookup there is no 50ms fouling.

I’ve already confirmed this in UrT by sending down an ent of the reconciled position from cmd->servertime and comparing it to a client side marker on the frame the cmd was generated.

I’ll see if I can rummage up some screenshots of it all working at various pings.

IIRC the reason theres no 50ms fouling is that cmd->servertime is already the “fudged” time.

(TwentySeven) #8

Reading through the unlagged 2.1 stuff - looks correct.
He’s now using level.time for the trails and cmd->servertime for the lookups - Good good.

Glad thats all sorted out :slight_smile:

(bani) #9

when I ported unlagged2.1 to ET, I added some debug to compare clientside BB position vs server’s backward reconciled position.

Thats when I noticed that the backward reconciled positions were ~50s behind.

This is not a guess. This is what was observed through direct observation and testing.

and yes I use cmd->servertime and level.time.

I don’t know yet why it is the case, but it is.

It may be something ET cgame is doing to commands, which may explain why UrT isn’t seeing it.

(TwentySeven) #10

Bani, then personally I think theres something else broken in Neils unlagged, possibly the history que itself - because we’re running UrT on ET and it’s exactly the same as Q3 in regards to antilag and the way cmds work.

You think perhaps it might be something else in the ET cgame source then?

Urt running on ET.exe - G_antilagvis 1

www.methodtim.net/27/NoMovement.jpg Screenshot of a stationary player.
There is a 20x20x20 neon red box sent from the server, and a 20x20x20 neon teal box stored on the frame the command was generated. As you can see, stationary, there is a 100% overlap leading to nice blending.

www.methodtim.net/27/FullStrafeJumpSpeed.jpg Screenshot of my 90 ping bittorrent leeching friend bouncing past at full speed. Boxes are off by ~1 gameworld unit. Its not 50ms though.

www.methodtim.net/27/BoxesOffBy1UnitDueToSnapping.jpg Same session, still my LPB point of view, but a closer look at the error between boxes. Other player was moving at ~30kph when shot was taken :stuck_out_tongue:

www.methodtim.net/27/90pinger.jpg And finally, same story, but from my 90 ping (and giant crosshair?!) lovin’ friend.

Cheers Bani. Maybe I’ll get around to compiling Neils latest stuff and see if I can figure out why you’re seeing this 50ms problem. You know if anyone was seeing it in Q3?

(bani) #11

i assume neil didnt see it in q3.

keep in mind etmain does player movement somewhat differently than q3. just plonking unlagged2 into UrT probably wont tell you much.

those are interesting occasional shots, but how does it look through an entire jumping arc? say, unloading an entire clip while a player is jumping…

(bacon) #12

@SCDS_reyalP: Try going into the water from a crouch :slight_smile:
It doesn’t appear to set hitboxes for swimming, so if you go in prone it should use the most appropriate hitboxes…

(bani) #13

btw, water etc.

this is one of the clearest examples where server doesnt accurately know what client is displaying, because client plays whatever animations it thinks is best for a situation.

so player might be shown ‘standing’ in the water and server thinks theyre swimming horizontally, and vice versa. so the bb will have little bearing on reality.

its a legacy problem from rtcw and is the direct cause of one of the flamethrower invisible-flames bugs (client thinks muzzlepoint is underwater, server thinks its above water).

(SCDS_reyalP) #14

Of course

/me smacks head for not realizing that.

(TwentySeven) #15

Sorry for hijacking the thread.

www.methodtim.net/27/g36one.jpg <- g36 on full auto while D bounces past.
www.methodtim.net/27/g36two.jpg <- g36 on full auto, back the other way
www.methodtim.net/27/10RoundsASecondMp5.jpg <- mp5 (10 rounds a second, fast as our auto guns go) on full auto while he does a swan dive off the roof.

Of course, Im an lpb in those shots so its not a big deal that its pretty clean.

www.methodtim.net/27/hpbone.jpg
www.methodtim.net/27/hpbtwo.jpg

My leeching kiwi friend again. Things are still pretty good, even with his ping and fps wobbling around like that. FPS wobbles are probably due to PB, don’t know conclusively how else it affects things though.

(DensitY) #16

Just to point some things out with my system

PB was enabled ( :disgust: )

4xAA 16xAF 1024x768… with MIRC running and DC++ running with speed capped to 5kb/sec

256/128 DSL connection (:moo:)

if someone is jumping around like mad normally one every 6-8 Boxes are off, normally by a max of 4-5 units which isn’t actually that much when youre moving at the Speed that you can in Urban Terror…

On a connection that doesn’t have a leeching freak like me, Antilag bounds bounds going off would be rare (normally a rounding of the min/max value in most cases).

in any case it leads to The UnLose for our antilag system in Urban Terror for ET.
:drink:

(pgh) #17

Fuck, who needs pr0gamers, we have teh pr0testers. :]

Wish we had a topic like this per big bug… :] Explains alot to players (eg, me) and gives a good understanding to how things work and are fucked up.

(bani) #18

pmove is quite different in q3 than it is in ET. if UrT works off the q3 pmove base code then its quite different to etmain so making comparisons for UrT antilag and ET antilag isnt quite comparing the same thing. ETmain pmove still has “issues” we are working out.

btw does UrT antilag snap the reconciled positions?

(TwentySeven) #19

Yeah, UrT pmove is its own ungainly beast, but yeah its based on q3 pmove from an aeon ago.

Hmm lemme dig.

Nein, we don’t snap the player positions inside the antilag at all. Not sure what the reasoning was or if there even was any?

(TwentySeven) #20

Oooh, something to note that I’d completely forgotten.
Do NOT try and test antilag from a localhost’d server or connection -guess Im just so used to flipping up a dedicated server I dont even think about it anymore.

If you run as a localhost your timestamps will be off by 50ms - this is a quake 3 bug and MAY be what you’re encountering, bani.