Instructions on how to objectively test hitreg. Post your hitreg problems here.

Nordic · January 2016

This thread servers two purposes. Its first purpose is to provide instructions on how to correctly record hitreg data. It will also serve as a location to post the data you collect about hitreg.

We now have new tools we can all use to objectively test hitreg. The game now has a console command called "hitreg" that outputs data about how and if you hit your target.
Here is an example of the hitreg output from my log file with both a no reg and then a false positive against a fade.

Client  : 1068.079224 : Hitreg: No data for key '32083-1' found
Client  : 1068.311157 : 32090-1: Diff found for attack on Fade-1899 (physTime 1068.211): 
   srv.trace_fraction:             0.071534
   cli.trace_fraction:            0.0097454
   srv.trace_start.y:              -1.3020
   cli.trace_start.y:              -1.2316
   srv.trace_end.y:               4.8236
   cli.trace_end.y:               4.8941
Client  : 1068.375366 : 32092-1: Diff found for attack on Fade-1899 (physTime 1068.275): 
   srv.hit:                false
   cli.hit:                 true
   srv.trace_fraction:              0.94083
   cli.trace_fraction:              0.42324
   srv.trace_start.y:              -1.3020
   cli.trace_start.y:              -1.0717
   srv.trace_start.x:              17.8133
   cli.trace_start.x:              17.8006
   srv.trace_start.z:            -142.8070
   cli.trace_start.z:            -142.8590
   srv.trace_end.y:              -0.0017
   cli.trace_end.y:               0.2286
   srv.trace_end.x:             116.9316
   cli.trace_end.x:             116.9189
   srv.trace_end.z:            -129.6209
   cli.trace_end.z:            -129.6728
Client  : 1068.408203 : Hitreg: No data for key '32093-1' found
Client  : 1068.408203 : Server data nil
Client  : 1068.482910 : 32095-1: Diff found for attack on Fade-1899 (physTime 1068.383): 
   srv.hit:                 true
   cli.hit:                false
   srv.trace_fraction:            0.0073419
   cli.trace_fraction:              0.92640
   srv.trace_start.y:              -1.3020
   cli.trace_start.y:              -1.0808
   srv.trace_start.x:              17.8192
   cli.trace_start.x:              17.8297
   srv.trace_start.z:            -143.0782
   cli.trace_start.z:            -143.1285
   srv.trace_end.y:               4.3246
   cli.trace_end.y:               4.5459
   srv.trace_end.x:              83.3361
   cli.trace_end.x:              83.3466
   srv.trace_end.z:             -67.7398
   cli.trace_end.z:             -67.7901
Client  : 1068.544800 : 32097-1: Diff found for attack on Fade-1899 (physTime 1068.445): 
   srv.trace_fraction:            0.0061197
   cli.trace_fraction:             0.013319
   srv.trace_start.y:              -1.3020
   cli.trace_start.y:              -1.1728
   srv.trace_start.z:            -143.2422
   cli.trace_start.z:            -143.2582
   srv.trace_end.y:               3.0647
   cli.trace_end.y:               3.1940
Client  : 1068.581299 : Hitreg: No data for key '32098-1' found
Client  : 1068.581299 : Server data nil
Client  : 1068.649414 : 32100-1: no diffs found for attack on Fade-1899 (hit=false)
Client  : 1068.707520 : 32102-1: no diffs found for attack on Fade-1899 (hit=false)
Client  : 1068.742310 : Hitreg: No data for key '32103-1' found
Client  : 1068.742310 : Server data nil
Client  : 1068.816284 : 32105-1: no diffs found for attack on Fade-1899 (hit=false)
Client  : 1068.880127 : 32107-1: no diffs found for attack on Fade-1899 (hit=false)
Client  : 1068.913086 : Hitreg: No data for key '32108-1' found
Client  : 1068.913086 : Server data nil
retraced killed Nordic with Swipe

The hitreg command works as you would expect. When the game traces to see if it hits with a shot, everything used to control animation and position of the model is saved in a large json structure. This is done both on the client and server. The client saves the data with a unique key and waits for the server to send its copy of the shot. When the copy arrives, the structures are compared and if they differ, a warning is logged.

How to use the hitreg command:
The hitreg command can not be used on any server. It must first be enabled by a server admin. This means you will need to run your own server, or ask your favorite server admin to enable it for you.
The server admin can enable hitreg to be turned on with the following console command. "sv_tests 1"
Once a server admin has done that, a client can then type "hitreg" in console to begin recording data to the log.
"sv_tests 1" and "hitreg" will need to be re-enabled after each map change.

The client will see the following in his console confirming that hitreg has been turned on.

Client  : 412.793579 : hitreg checking on, prec 2

Server operators and admins, sv_tests should not be used for fun. It is similar to cheats, but instead of allowing anything it only allows a few debug tools to be turned on. Think before you turn on tests. The hitreg command does not give anyone an advantage, but it does dramatically increase the clients bandwidth usage. I would only allow a couple individual players to test hitreg at a time so that you do not stress the server.

The following server operators are willing to turn on sv_tests if you private message them:
SupaFred of TheThirstyOnos,
Ghoul of Survival of the fattest and Ghouls Box,
Wyzcrack of TacticalGamer,
Shameless of Tactical Freedom,
Wooza of Wooza's Server
Furs of the NSL Wraith Servers
Rusty of Diamond Gamers will on Wednesday evenings
Zero of Ibis servers.
More server operators may be willing but these are the only ones that have confirmed it for me.

You can contact them via the NS2 discord. Link here.

So now you have used the hitreg enabled. Look for "srv.hit" and "cli.hit" in your console or log to see if you actually had a hitreg issue.
While viewing the log I typically press Control -> F and search for "srv.hit" to find the hitreg issues. Your log is found in your "C:\Users\YOURUSERNAME\AppData\Roaming\Natural Selection 2" folder. You may see a lot of "diffs found" but those are unimportant. There is not a hitreg issue unless there is a discrepancy between srv.hit" and "cli.hit" such that one is true and the other is false. I have two examples shown below.

This is a no reg on a fade. The server (srv.hit) says it was a miss, and my client (cli.hit) says it was a hit.

Client  : 1068.375366 : 32092-1: Diff found for attack on Fade-1899 (physTime 1068.275): 
   srv.hit:                false
   cli.hit:                 true

This is a false positive on a fade. The server (srv.hit) says it was a hit, and my client (cli.hit) says it was a miss.

Client  : 1068.482910 : 32095-1: Diff found for attack on Fade-1899 (physTime 1068.383): 
   srv.hit:                 true
   cli.hit:                false

How to provide data to the developers about hitreg:
The developers are looking for a video similar to this. (demonstrates one of the few remaining hitreg issues)(Video by Ironhorse)
Or similar to this video I made showing the fade hitreg issues I have used in my examples above.

You need to make a video with the following traits:

The video shows you getting a no reg or false positive.
Shortly after you get the no reg or false positive, the console in shown in the video. You can open up the console with the tilda "~" key which is right above the tab key.
Server side blood is turned OFF in ns2+. It can give misleading information when testing hitreg.
Video must be high quality. The developers need to be able to see what was going on.
Video ideally would be 60 fps. This makes it easier for the developers to see what was happening.
Uploaded to a place the developers can access the video. Youtube works great because it allows 60fps videos.
Having net_stats on screen can help a lot also.

If you wanted to above and beyond in gathering data for hitreg, it would be nice if you provided the log along with the video. The developers do not need the whole log, but just posting a portion of it like the example I gave at the beginning of this post would be nice. If you post it here, please put a spoiler around it. You could also upload your log to pastebin.com and link it here. If you do not want to post your log publicly I would private message @Ironhorse.

It did not take me long at all to record and upload that video. Not counting time playing ns2, it probably takes me about 5 minutes to set up, edit, upload, and post a video like above.

If you do not know how to record your gameplay, don't worry it is easy. There is a lot of free software available to use. I would start by reading this reddit guide to pc gamplay recording.

Ironhorse uses Nvidia Shadowplay and AVS video editor. I personally use the free softwares, Open Broadcaster with avidemux video editor. If you need any help recording your gameplay to capture hitreg feel free to ask.

IronHorse · January 2016

It's important to note that we need as high quality of a video @ 60 fps as possible so that we can slow it down when reviewing.

Nordic · January 2016

IronHorse wrote: »

It's important to note that we need as high quality of a video @ 60 fps as possible so that we can slow it down when reviewing.

Updated OP noting that, and underlined.

Narfwak · January 2016

Stickied post! Thanks for the write-up, Nordic!

Nordic · January 2016

I also rewrote the instructions to be easier to read.

Samdaman · January 2016

You might also want to show the "net_stats" at the time as well to make sure the server isn't under load or having packet loss. Also might want to mention what mods are running on the server / client.

Yojimbo · January 2016

@Nordic Do me a graph on win lose ratio for aliens / marines across ALL servers plx

Soul_Rider · January 2016

I was having a discussion with Nordic about this, and how I felt that these were not 'hit-reg' related at all, but merely an artefact of a server/client model. In one of the videos Nordic linked me, I was able to fairly clearly show what I mean, so I will replicate what I explained here, and show why I just think this is normal operation. However, further examination lead me to some anomalies for my world view, so I may need some correcting. If anyone who knows better wants to correct me, I am all for learning more.

Basics of a client server model

The client receives a packet from the server, with a timestamp/key.
The client compares the information with it's own matching information for that moment.
The client takes the server packet, and uses it as authoritative information, recalculating itself as necessary.
Between this packet, and the next packet the client receives, the client is running in prediction. This means it predicts what is happening in the game world.
The server receives all the updates from the other clients, and does it's AI calculations, then sends that packet to the client to be compared.

I am going to try and explain with a theoretical example, then I want to look at a 'no reg' video that Nordic recorded.

Example
You are a marine are tracking a lerk. Your client receives a packet advising of the lerks position and velocity.

In the last packet received, the lerk is flying towards you, and strafing right.
The client continues to predict the lerk as moving right, which is where you shoot it.
When the client receives the next packet, it finds out the lerk player had strafed left and dived.
According to the server information, the player was actually .1 of a unit to the left of where your client had predicted it. This causes your shot to miss according to the server, even though your client said it was a hit based on the predicted information.
Because the server is authoritative, the client info is corrected with the server information.

If this was happening 'live' you'd have a really jittery game, as other players positions would be constantly corrected on your screen. This is where the Interpolation (interp) comes in.

Before rendering to the screen, the latest packets are stored and compared against the client data. This is done in the 100ms buffer time, so you are always 100ms behind what it happening on the server, but you have a very smooth experience in the game.

While the 100ms interp should cover these discrepancies, it doesn't entirely. As soon as your ping goes over 100ms, the time taken to receive the correct information exceeds the interpolated commands, which means you are excessively running in prediction and likely to see exagerated results.

In a high speed, high movement game, prediction is always going to get things wrong. The client in the above case would register a hit, but the server packet would then come along and say, no, it was a miss.

Nordic showed me a stream of examples, and the relevant logs, and the one thing I noticed after initially speaking to him, that indicated this is normal was that almost all the occurrences of 'hit-reg' issues seem to have happened when target is colliding with something, thus rapidly altering it's velocity.

Any shots towards the edge of a model in these instances should be expected to bring these conflicting results, as edges will be in different places. If these videos were showing it happen in centre model shots with no lateral movement on a LAN, then I would have to rethink.

From every frame in the logs I have seen, regardless of hit-reg discrepancy or not, they show variation between where the client thinks the player is and where the server thinks the player is, so this leads me to confirm my initial suspicions.

Here is a 'No-Reg' video on a skulk:

This video partially makes my point, but also potentially disproves it, I need some further advice on this. Here is a partial of the log from the hitreg tool.

Client  : 831.958740 : 25053-1: Diff found for attack on Skulk-3746 (physTime 831.8588): 
   srv.hit:                false
   cli.hit:                 true
   srv.trace_fraction:              0.97227
   cli.trace_fraction:              0.39117

I am assuming I understand these correctly, but could be wrong.

I believe the trace fraction shows the length of the trace. The client traced a hit at a distance of .4 units, the server at almost 1 unit. This was likely to be the floor.

I have taken 2 stills, one as close as I can get on you tube to the frame the gun fired, and the 2nd when the hit displays clientside. Look for the skulk vs the crosshair:

I am so lucky he fired a tracer round on this particular attempt

As you can see skulk nowhere near line of sight.

This is the point just as the clients 'hit' registers:

If you slow the video down enough, you see that as the skulk lands, it looks like it is going off towards where the bullet ends up firing, but jinks back, at the marine and then away again. The landing and sudden change of direction would certainly fit the issues as I have described.

Apart from one small anomaly (or a huge elephant in the room if you like)!

If the client thought the skulk was where the hit was given, why wasn't it displaying the skulk where it thought it was?
As this was just after landing, was it the 'hitbox doesn't fall at the same speed issue'?

Answers on a postcard....

EDIT ---

In my opinion, that skulk video is the only 'genuine' hit-reg issue on all the videos Nordic showed to me, but this is more a lucky catch than meaning these other messages are anything other than normal operation.

IronHorse · January 2016

@Soul_Rider Looks like the user in that video is using server side confirmed blood, an NS2+ option.
That setting basically hides certain hitreg issues. One should not use it when recording footage looking for issues.

Nordic · January 2016

IronHorse wrote: »

@Soul_Rider Looks like the user in that video is using server side confirmed blood, an NS2+ option.
That setting basically hides certain hitreg issues. One should not use it when recording footage looking for issues.

It is my recording, and I am not using server confirmed blood in that video.

Soul_Rider · January 2016

I am so tempted to hit that disagree button @IronHorse.....

Also shows he didn't actually read my well informed argument, as he would have seen Nordics name mentioned many times.

IronHorse · January 2016

Nordic wrote: »

IronHorse wrote: »

@Soul_Rider Looks like the user in that video is using server side confirmed blood, an NS2+ option.
That setting basically hides certain hitreg issues. One should not use it when recording footage looking for issues.

It is my recording, and I am not using server confirmed blood in that video.

Impossible. The blood is far too behind from the model, and the blood shows exactly at the same time as the crosshair hit indicators and dmg numbers.
Blood should show some 400 ms before those occur, (show up on the model instead) and it's obviously not happening. You definitely had server side blood on for that video.

Nordic · January 2016

Soul_Rider wrote: »

Text

The hitreg command only reports if there is an error, which in my experience is mostly false positives where the server says I hit but my client says I did not. Most people probably do not notice this, and I doubt they feel the need to complain. Almost all the videos I shared with you were these false positives. Only 2 of the videos I showed you were actual no regs, or what most people consider a hitreg issue. You are using one of those videos in your example which does show the tool is working.

The other videos I showed you may be "normal operation" but it does not matter. They may just be "merely an artefact of a server/client model." I was simply reporting them as errors found. I will continue to report them internally until I am told it is no longer desired.

IronHorse wrote: »

Impossible. The blood is far too behind from the model, and the blood shows exactly at the same time as the crosshair hit indicators and dmg numbers.
Blood should show some 400 ms before those occur, (show up on the model instead) and it's obviously not happening. You definitely had server side blood on for that video.

In my previous videos I was using server confirmed blood, but you pointed out that I should not be for the purposes of these videos. After that conversation I immediately turned it off. It was set to off for that video.

Soul_Rider · January 2016

@IronHorse - Assumptions again, you know this video is of a No-Reg though don't you? So there never was a server side hit, so there can never be server side blood or hit numbers. That damage number is from the previous round that hit the target.

Can you stop trying to just brush this aside, and actually read my post?

bs_ · January 2016

Pastebin in the comments. Quality sucked, i screwed up the resolution downscale and youtube didnt like it.

I can make another one if it helps, but I figured there wasn't much point.

Nordic · January 2016

For reference, his log is found here. It was in his youtube description. http://pastebin.com/euuAe2si

@bs_ in future videos it would help a lot if you could show the console during the pauses. It is hard to match up the video with the log unless you open up the console so the developers can see the hitreg output.

If possible, ahigher quality video would go a long ways. Especially if it was 1080p at 60fps.

Otherwise, thank you for sharing. I saw that the log shows there were 62 no regs in that video.

bs_ · January 2016

Nordic wrote: »

@bs_ in future videos it would help a lot if you could show the console during the pauses. It is hard to match up the video with the log unless you open up the console so the developers can see the hitreg output.

The #numbers show up in the log

SupaFred · January 2016

If you want to test this on The Thirsty Onos servers just pm me and I'll set you up.

Nordic · March 2016

I am bumping this because I am seeing more complaints about hitreg lately.

bs_ · March 2016

weird

Instructions on how to objectively test hitreg. Post your hitreg problems here.

Comments