So, I’m trying to measure the delay between pressing the mouse button and dealing damage on different heroes. (This is not the same as the delay between entering ‘firing primary’ and dealing damage, which I have measured, and as expected, is 0 on hitscan characters, and measurable on projectile characters).
I have a mouse overlay in OBS studio, so I can see in recordings that there is generally 2 frames (@60fps) between the overlay seeing the mouse action, and the first firing animations (damage splash/muzzle flash) on hitscan heroes.
What I’m trying to determine is at what point damage is actually dealt. Unfortunately, updating text in Workshop is far too slow, you’re already well into the firing animation by the time a hud text updates to notify you that damage has been dealt.
So what I want to know, is what visible workshop action is the fastest, and is it fast enough to occur within a 1/60th second of an action triggering?
(I’d like to get more precise than that, but I’m not sure how to do so. All my ideas for truly precision measurements would involve input automation, and I’m not really interested in getting myself banned.)
My best suggestion:
Have 2 rules, one for using primary fire, set a player variable to 0 and essentially start counting it up as fast as the workshop will phyiscally let you
(Im not on right now so I can’t check)
then another rule for when the player DEALS damage.
Then stop updating the variable and display the variable to see how long it took
That measures the time between the (player is) ‘firing primary’ event and (target has) ‘damage received’ event, which I can already measure by recording match time into variables on those events.
What I want is the time between physically pressing the mouse button and damage being dealt. Since my ‘timer’ for physically pressing the mouse button is recorded in the OBS overlay, I also need visible feedback on the ‘damage received’ event to record both events visually.
(Well, time between mouse press and entering the ‘player is firing primary’ event also works, since there is no time elapsed between is-firing and damage-received for hitscan heroes, which is the case I’m interested in.)
Ah I misunderstood the question.
If you can use your OBS to determine how long before OW detects your mouse input then you can add those two results together maybe?
That’s essentially what I’m trying to do, but it’s important to do it separately for each hitscan hero.
The assertion that I’m trying to test is whether or not there is a different amount of time between physically pressing the mouse button and Ashe firing, compared to pressing the mouse button and McCree firing.
Aye, so what you do is my previously mentioned code, between the game detecting the fire, and actually doing damage dealt, and then adding that number to your OBS number, and record it on like a Notepad like per se
McCree: 0.4 seconds
Ashe: 0.3 seconds
etc
etc
Right?
For hit-scan heroes, this time is always 0, by definition (and tested).
The question is, is there a different time between pressing the mouse button and the firing event for different heroes.
OH, logically I’d say no.
But the way to test that…
I guess it’s just the difference inbetween pressing the key on OBS and primary fire event?
Yes, that’s what I think. Or at least what I hope to measure. Unfortunately, text overlay is too slow to be a visual indicator that the fire event has occurred.
I’m trying teleporting the target 25 yards up in the air, teleport seems instant, but we’ll see when I look at it frame by frame.
Have ye thought about killing the player?
That seems certain to be slow.
Updating HUD text is 6 frames. Teleporting the target is 9 frames. I guess it wouldn’t hurt to try killing the player…
I was just hoping someone else had tried to measure something very precise and had an idea of what the fastest game actions are so that I don’t have to try everything in search of something fast enough.
Well I’m thinking, you’d see them start to ragdoll, the very first frame, and then MAYBE the hud could help?
12 frames in, you see a red arc on your hud. That red arc marks your position as the camera then pulls back to show you ragdolling.
Edit: It’s amazing how slow some of this stuff is. 12 frames is 200ms between when you die and when you see that you die. No wonder we so often get the feeling of ‘but I shot him!’ or ‘but I faded!’ or whatever… yeah, you did, but you were already dead.
My last guess is voiceline, honsetly
A voiceline wouldn’t have visual feedback, and you can’t hear anything when stepping a video one frame at a time. You could look at the audio waveform I guess. Hmmm.
thinking
Maybe I’m doing this wrong. As long as the delay is consistent, then I can still check if there’s additional delay difference between Ashe and McCree, right?
Whether it’s teleport, play effect, whatever, as long as it always takes the same number of frames from mouse click, then it shows they have the same latency.
Actually, yeah! You could, and if you know the delay then you can subtract that delay to find the actual numbers!
1 Like
Gahhh. Unfortunately, I now have video where it takes anywhere from 6 to 8 frames for a Play Effect to begin.
Also having already determined that muzzle flash starts 2 frames after button press, I now also have examples of it starting 1 frame after button press.
Not sure why, it should all be client-side. If the server disagrees it will cancel the action (much-complained about when people suffering a lag-spike see their damage disappear, but due to favor-the-shooter that doesn’t happen often.)
I think this is the way to measure it though, it’s just that because it has inconsistency it means needing to take an average over a large sample.
I’ve watched way too much frame-by-frame of headshots for one night, so I’ll put that off for later.
Also I need a better video player to do it with. VLC does not like it when you keep skipping back and forth and watching different bits frame by frame.
Thank you for your help!
You know that a lot of things depend on network latency, server load, and client timing, right? Every condition isn’t evaluated every frame, every value isn’t updated every frame, and some triggers require a network roundtrip to activate.
Add to that a variable framerate, and counting frames quickly becomes useless. You’re better off counting average milliseconds.
I would love to count milliseconds, but I don’t think there’s any way to do that for what I want to test.
Since part of my data is by definition coming from a video, (the mouse click overlay), I think I have to use frames as the best my measure that I have.
If you have a method that lets me use milliseconds, I’d like to hear about it.
(Also I’m recording at a fixed 60fps. Obviously frame drops or other variability would invalidate my data.)
(I haven’t fully read the post, so apologies if this is unrelated or unhelpful)
If I ever need to work with precise time measurements, I setup a “Chase Variable At Rate” action with a destination of 100000 and a rate of 1u/s.
I have a Keypress Manager that works using this method and allows me to detect down to around 0.03 seconds of input from a user. It’s pretty accurate, I should add. I’ve used macros to hold and release buttons after specific lengths of time and the Workshop is only around 10-20 milliseconds off at times.