sometimes -4 and sometimes +4, i'm not sure which is correct
forum
Offset; what is your and why?
posted
Total Posts
91
I get the exact same thing so I decided to just go with the middle and put 0. I still don't know if that is right or not because everyone is saying different things.marcostudios wrote:
sometimes -4 and sometimes +4, i'm not sure which is correct
Its possible. My asus xonar ds had a UO of -70. Yes, sounds were very early compared to the music.Brimroth wrote:
a bad soundcard won't give me the sounds ~100 ms early, since it won't know the sounds are coming, it might give the sounds 100 ms late though, which my offset clearly doesn't imply.lolcubes wrote:
Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.
Edit: What I said was uncalled for.
Still though, I was saying using a 0 UO is a possible option since I check every map for it's timing when I go to play anyways. Personally though I use a universal offset timed to peppy's original offset map and check by using the hit error bar for quick reference. If I feel the timing is really wrong I then use audacity to make sure I get a correct one.
Still though, I was saying using a 0 UO is a possible option since I check every map for it's timing when I go to play anyways. Personally though I use a universal offset timed to peppy's original offset map and check by using the hit error bar for quick reference. If I feel the timing is really wrong I then use audacity to make sure I get a correct one.
Is peppy's offset map supposed to be on -6 and then we check for timing in the offset wizard or are you supposed to change it to 0 and then use the offset wizard to check for timing?
Using audacity does NOT WORK, because mp3 decoders all add arbitrary offset to the beginning of tracks. Using 0 is fine if 0 sounds right to you. On most sound hardware it will not.
Leave it on it's default "-6." Think of it like it's actually a "0" (but it's not). UO works in opposite directions to editor/local/online offset, so work backwards. It's the same thing imo.Mathsma wrote:
Is peppy's offset map supposed to be on -6 and then we check for timing in the offset wizard or are you supposed to change it to 0 and then use the offset wizard to check for timing?
Krier's method! Krier's method! Krier's method! Krier's method! Krier's method!
Remember hitsounds are a sound file. They have a start and end, and the punchline is longer than 1ms, which is why you want to sync it in UO starting from a large positive offset and work your way down until it synchronizes. IMO (and other's O's) this is the best way to do it. If you keep decreasing your UO it may still sound in sync for another few ms, but that's wrong (apparently
).Peppy is talking about opening the mp3 file to check for the offset. It's not what I have been doing because of what he just said. Yeah though, that 6ms switch is proved wrong though; thanks peppy for confirming it. Recording and checking songs in audacity however can still work.
Here are some tests I have done using audacity, peppy's default offset wizard song, and the options offset wizard with the game focused at unlimited fps.
Here are some tests I have done using audacity, peppy's default offset wizard song, and the options offset wizard with the game focused at unlimited fps.
A random +50ms record
This shows it should be roughly +3ms
Looking at kriers method
+2ms (first track) this is 1ms before the audio syncs up
+1ms (second track) is where it first syncs
-5ms (third track) still the same as the previous track
-8ms (Fourth track) is the very last one before it gets out of sync.
-9ms (last) track which is only a 1ms difference. From what you can see it just jumps a huge amount.
From +1ms all the way to -8ms it's all in sync the same way. Also notice that it's not close to the +3ms offset that I have determined from above. When you measure the difference in the -9ms track however it shows that the offset should still be +3ms. I'm assuming the wav files being used have low sound gaps at the start of them which isn't helpful to the human ear to measure it. The wav files I use for my hitsounds have no low sound gap at the start and wav doesn't require decoding, so it makes for a pretty precise hit.
+1ms (second track) is where it first syncs
-5ms (third track) still the same as the previous track
-8ms (Fourth track) is the very last one before it gets out of sync.
-9ms (last) track which is only a 1ms difference. From what you can see it just jumps a huge amount.
From +1ms all the way to -8ms it's all in sync the same way. Also notice that it's not close to the +3ms offset that I have determined from above. When you measure the difference in the -9ms track however it shows that the offset should still be +3ms. I'm assuming the wav files being used have low sound gaps at the start of them which isn't helpful to the human ear to measure it. The wav files I use for my hitsounds have no low sound gap at the start and wav doesn't require decoding, so it makes for a pretty precise hit.
Thank you for proving Law of Kriers! (i.e. stop adjusting as soon as it sounds in sync from + offset)Dexus wrote:
-8ms (Fourth track) is the very last one before it gets out of sync.
-9ms (last) track which is only a 1ms difference. From what you can see it just jumps a huge amount.[/b]
Btw, do you think this "jump" is a hardware problem or osu!?
It could be different for everyone else, but it sounds like the problem Mathsma is experiencing. I also noticed it in my first test where I couldn't tell the difference between -1 and -9, but it doesn't happen all the time. Re-tests allowed me to tell values -4 to -9 were out of sync.
If it jumps by that amount, I don't think measuring the offset from it is reliable. It could still be off/random.
I wish I could set my offset to -2.5ms, because that's what I think it actually is. (-2 and -3 indistinguishable)
By using a similar method to the one Dexus used (recording the audio output with +50 UO). I used auto mod instead of using the ticks of the offset wizard. I got an UO of +15ms (with my other method I got +16 ± 2.63 ms).
Then, when I adjusted the UO accordingly, the pulses were still constantly off by ~2ms. Changing the UO slightly didn't have any effect on that, until it jumped by about 10ms when I set the UO to 20 (and the jump was noticeable while hearing). It seems that the music or hit-sounds timings are snapped to certain time points.
Increasing the fps seems to not have an effect on this (tried changing from 500fps limiter to Unlimited that runs at about 800fps. It was the same). With 60fps v-sync the alignment was unstable (for some ticks they were off by 2ms, while in others they could be off by about 50ms)
Then, when I adjusted the UO accordingly, the pulses were still constantly off by ~2ms. Changing the UO slightly didn't have any effect on that, until it jumped by about 10ms when I set the UO to 20 (and the jump was noticeable while hearing). It seems that the music or hit-sounds timings are snapped to certain time points.
Increasing the fps seems to not have an effect on this (tried changing from 500fps limiter to Unlimited that runs at about 800fps. It was the same). With 60fps v-sync the alignment was unstable (for some ticks they were off by 2ms, while in others they could be off by about 50ms)
Well, I wish I had access to the WAV files that the pings in the offset wizard in the options so I could tell really what the waveform looks like, but my theory is that it has a slight gap at the start of it making the measurements incorrect. As for the way I tested it, I stopped every time and started the song from the beginning to measure each millisecond change.
I'm going to test and see if I can cut out these gaps and match to the same way peppy has his mp3 and see what results I get
I wouldn't trust the auto mod because from time to time I can see in the hit error bar it's wrong; same thing can be said about the relax mod. I'm guessing it's an anti-cheat method or the bot itself gets offset due to the community offset.
From what I saw, yeah the v-sync/low frame rate method made for unstable tick rates so I figured unlimited would suffice to be the most accurate reading.
I asked peppy if it was possible to get float value offsets, but I don't think it's even possible (or really needed for that matter)
I'm going to test and see if I can cut out these gaps and match to the same way peppy has his mp3 and see what results I get
I wouldn't trust the auto mod because from time to time I can see in the hit error bar it's wrong; same thing can be said about the relax mod. I'm guessing it's an anti-cheat method or the bot itself gets offset due to the community offset.
From what I saw, yeah the v-sync/low frame rate method made for unstable tick rates so I figured unlimited would suffice to be the most accurate reading.
I asked peppy if it was possible to get float value offsets, but I don't think it's even possible (or really needed for that matter)
now you doDexus wrote:
I wish I had access to the WAV files that the pings in the offset wizard in the o...
No, I decompiled things that I probably shouldn't have.Dexus wrote:
Thank you very much Lach. Is it skinnable?
Welp, it'd be amazing if it was skinnable. I quickly checked and there is a gap at the start (it's small though). It would be better if I could cut it short at a high point to make it easier to offset.
You can see the waveforms merge together to the right, that's about at 8ms it happens which I recorded this with a +3 UO.
You can see the waveforms merge together to the right, that's about at 8ms it happens which I recorded this with a +3 UO.
The metronome sound is skinnable (just add those files to your skin folder).Dexus wrote:
Welp, it'd be amazing if it was skinnable. I quickly checked and there is a gap at the start (it's small though). It would be better if I could cut it short at a high point to make it easier to offset.
You can see the waveforms merge together to the right, that's about at 8ms it happens which I recorded this with a +3 UO.
While testing with the offset wizard in the options menu (and using my hitsounds instead of the metronome sound). The situation was similar to the last case, (though the UO range where the sounds matched was different). In detail:
- UO 50: The recording suggested the UO should be -7 (the time difference was very audible).
- UO -7: The recording suggested the UO should be -5 (the time difference between the pulses was just a bit audible).
- UO -5: The recording suggested -3.
- UO -3: The recording suggested -1.
...
- UO 3: The recording suggested +5
- UO 5: The recording suggested -2 (the time difference was very audible).
- UO -2: The recording suggested 0.
There seems to be something wrong with either my PC, the method of testing, or the game that makes it so UO only affects the offset in large ms intervals. I will keep +16UO offset since that is the offset that statistically gives me the most accuracy while playing the game (and also the previous recording test gave me a value in an interval that included +16).
Another test with -50ms UO
The first two are the WAV files, the third is the actual mp3 file for the song, and the last one is my recording.
Great to see the metronome files are skinnable, now to get more precise results. The above was done with the default.
Edit:
Interesting to say the least; I cut the wav file shorter and did another test at +50ms, here is the resultant
Here are the mono metronome sounds that I used which were cut short if anyone else is interested in using them http://puu.sh/6vcUM.zip
Be sure to check your wav files that you're using to play with though, some of them have gaps at the start which can be a couple milliseconds off. I'll eventually write a post if anyone needs assistance in doing this.
Edit:
So I did more testing, here I used +18 UO; The labels for what I did are on the left. The last line the reference is the blip on the right. The community offset isn't applied in the options offset wizard I guess... Peppy please do something about this community offset, either apply it everywhere or nowhere.
The metronome sounds are not skinnable.
I just skinned them...Lach wrote:
The metronome sounds are not skinnable.
Does using local offset cause the same phenomenon?
Anyway I've tried messing with local offset on some maps that felt off, and all I did was mess up my accuracy with every change.
It gives me peace of mind to just use kriers' method in the UO, because this way when I do change hardware/pc/soundcard, I just sync it again and all maps I played in the past should sound exactly as off as the last hardware I used. Just mentally adjust your timing for any map that is actually off because it's too much of a mission to do tests for every single map. The more I play a map, even if it is off, the better accuracy I get. Human brain le amazing.
Anyway I've tried messing with local offset on some maps that felt off, and all I did was mess up my accuracy with every change.
It gives me peace of mind to just use kriers' method in the UO, because this way when I do change hardware/pc/soundcard, I just sync it again and all maps I played in the past should sound exactly as off as the last hardware I used. Just mentally adjust your timing for any map that is actually off because it's too much of a mission to do tests for every single map. The more I play a map, even if it is off, the better accuracy I get. Human brain le amazing.
Local offset should be fine to mess with, but I don't think "krier's" method is valid, the community offset fudges it which can be seen in the very last screenshot I posted. I compared the audio in the editor timing section, the offset wizard, and with auto and both the editor and offset wizard were wrong but auto was correct. This all depends on if auto handles the hits with or without the community offset (or if the CO stacks ontop of it). I'm also not sure how the CO is even applied exactly, but from what I see it's a hidden local offset (+22) that is applied when you go to play a map.
So in theory if you were to sync up in the offset wizard to that map it can still be wrong because when you go to actually play the map it would be 22ms too late. I have recorded some people and checked their rates: cookiezi was hitting correctly but his hits were 40+ milliseconds off (I have no clue what his offset is); just today I recorded thelewa's hits and he was 20-30ms off even though he was hitting super stable with hard rock (he uses 0 UO).
Also, from what I have checked, a lot of the hitsound wav files have gaps at the start of them that aren't really audible and can cause you to mistime your hits. With a slightly wrong offset and hitsounds with delays it could sync up but it would be really difficult to manage. There's also that visual anticipation that can happen when hitting notes.
So in theory if you were to sync up in the offset wizard to that map it can still be wrong because when you go to actually play the map it would be 22ms too late. I have recorded some people and checked their rates: cookiezi was hitting correctly but his hits were 40+ milliseconds off (I have no clue what his offset is); just today I recorded thelewa's hits and he was 20-30ms off even though he was hitting super stable with hard rock (he uses 0 UO).
Also, from what I have checked, a lot of the hitsound wav files have gaps at the start of them that aren't really audible and can cause you to mistime your hits. With a slightly wrong offset and hitsounds with delays it could sync up but it would be really difficult to manage. There's also that visual anticipation that can happen when hitting notes.
I put different samples into my skin folder and named them accordingly.
"tick tick tick tick"
"tick tick tick tick"
metronomehigh.wav and metronomelow.wav and then reload your skin? I think metronomelow is what plays in the offset wizard itself. The metronomehigh is used in the editor for the 4th beat.
This sounds fishy. I don't suppose you were around when Cookiezi was trying to HR Mythologia's End before the online offset of +20ms was applied?Dexus wrote:
So in theory if you were to sync up in the offset wizard to that map it can still be wrong because when you go to actually play the map it would be 22ms too late. I have recorded some people and checked their rates: cookiezi was hitting correctly but his hits were 40+ milliseconds off (I have no clue what his offset is); just today I recorded thelewa's hits and he was 20-30ms off even though he was hitting super stable with hard rock (he uses 0 UO).
I'd believe some small values, but 22, 30 and 40 ms is just too much. We aren't that useless at discerning sounds. I believe I speak for the entire human race when I say I'm offended.
Dexus wrote:
metronomehigh.wav and metronomelow.wav and then reload your skin? I think metronomelow is what plays in the offset wizard itself. The metronomehigh is used in the editor for the 4th beat.
fuck you lach
Did some of my own testing recording in audacity.
It would seem that the following range of UO values will always produce the same time difference between ticks in audacity, your ranges may differ:
60: 67ms
50 ~ 59: 57ms
39 ~ 49: 47ms
28 ~ 38: 37ms
19 ~ 27: 27ms
9 ~ 18: 17ms
-1 ~ 8: 7ms
-10 ~ -2: -3ms
x ~ -11: -13ms
I stopped at -11.
By now you can see something is wrong in the way osu! handles the UO. Either that or this is the true meaning behind "hardware delays."
In my case, -2 is where the ticks sync together, and also why I can't tell the difference between lower negative values. This is not just audacity either, the NON-difference in tick intervals is clearly audible in how it only changes approximately every 10ms. It's also why you should start from the positive end when using kriers' method.
Basically, sync it and leave it, fine tuning is impossible. Either way, when my UO was on 0, it was actually 7ms ahead of "0" and by putting it on -2/-3... I essentially did not adjust my offset by 2 or 3ms, I adjusted it by 10ms!!!
My previous posts about being more consistent were probably very true, except for that last screenie where I tried to justify something that was obviously placebo.
It would seem that the following range of UO values will always produce the same time difference between ticks in audacity, your ranges may differ:
60: 67ms
50 ~ 59: 57ms
39 ~ 49: 47ms
28 ~ 38: 37ms
19 ~ 27: 27ms
9 ~ 18: 17ms
-1 ~ 8: 7ms
-10 ~ -2: -3ms
x ~ -11: -13ms
I stopped at -11.
By now you can see something is wrong in the way osu! handles the UO. Either that or this is the true meaning behind "hardware delays."
In my case, -2 is where the ticks sync together, and also why I can't tell the difference between lower negative values. This is not just audacity either, the NON-difference in tick intervals is clearly audible in how it only changes approximately every 10ms. It's also why you should start from the positive end when using kriers' method.
Basically, sync it and leave it, fine tuning is impossible. Either way, when my UO was on 0, it was actually 7ms ahead of "0" and by putting it on -2/-3... I essentially did not adjust my offset by 2 or 3ms, I adjusted it by 10ms!!!
My previous posts about being more consistent were probably very true, except for that last screenie where I tried to justify something that was obviously placebo.
I recorded from cookiezi's twitch plays, that's where I got the values from. You can be in sync with the hitsounds/approach circles and still get within 10ms. Human error is pretty big. We react slower than 100ms that is for certain. Also there's latency from within the computer to your ears, so you're hitting in tune with it but the actual sound placed isn't in sync.
Yeah I've known that osu! handles the UO incorrectly for a while. Also tuning in the editor/offset wizard is wrong as I said because afterwards a local offset of +22ms is applied.
See these threads:
t/176630?hilit=+offset
t/151718?hilit=+offset
t/115695?hilit=+offset
Yeah I've known that osu! handles the UO incorrectly for a while. Also tuning in the editor/offset wizard is wrong as I said because afterwards a local offset of +22ms is applied.
See these threads:
t/176630?hilit=+offset
t/151718?hilit=+offset
t/115695?hilit=+offset
Would it be correct for me to use my UO of -2 (-3) and then apply a -3 local offset to maps? That should give me 0 right? Not counting badly timed maps.
Also can you post a real example map of this 22ms community offset making everything wrong in audacity, I'd like to check it out for myself because I'm not very good at working with audio. I'm more of a practical person.
Also can you post a real example map of this 22ms community offset making everything wrong in audacity, I'd like to check it out for myself because I'm not very good at working with audio. I'm more of a practical person.
- O n i - wrote:
0 because i have no idea how to set it up
Is there a reason why the offset has ranges of 8ms? Could it be because of the BPM? Would changing the BPM to 240 reduce the offset range to 4ms, and so on? Also, do these ranges only affect audio and not the time windows? Maybe the actual timing windows can be fine tuned but not the audio.
You didn't look at this even though I said it like 3 times?
The first two are in the options menu and the editor, both are off (You can see the gap pretty well). The last one is recorded in the actual gameplay and it's in sync better than the previous recordings (look at the note on the right).
The first two are in the options menu and the editor, both are off (You can see the gap pretty well). The last one is recorded in the actual gameplay and it's in sync better than the previous recordings (look at the note on the right).
Is that in the offset wizard map? Because it doesn't happen for me.
I used a UO -2, checked with audacity in UO and editor... both out by 3ms, as opposed to 13ms with a UO of -1 or higher.
I start the map with Auto, and in audacity it's out by 2ms. I'm also using metronomelow.wav as my normal-hitnormal.
I adjusted my local offset to test. I'm afraid to say that local offset also suffers from the same 10ms phenomenon that UO does, it's within 2ms on most of its hits, then occasionally, one will be 12ms out. The greater my local offset value, the more often it will be out by 12ms until it's always out by 12ms. It's not happening on every hit, just some of them.
22ms where? I found other problems though.
I give up, not going to mess with any offset from now on, my UO will stay -2, and I'll learn to deal with this value since it's closer to 0 than 0.
*EDIT*:
In addition to my other post where everything measured in the UO wizard was -13, -3, 7, 17, 27, 37, 47, 57. Here is some more random shit from actual gameplay.
In Auto, Local offset of:
"-20" gives me 22ms
"-15" gives 12ms
"-10" gives 14ms
"-5" gives 2ms and 12ms
"0" gives 2ms and rare 12ms
(now the other direction)
"+5" gives 8ms
"+10" gives 11ms (close +1)
"+15" actually gives 15ms (wow)
"+20" gives 19ms (close -1)
Weird that -5 and -15 give the same... and -10 being greater than -15.
Since +15 gave me 15ms on UO -2... I set UO=0 and tried again. It gave 8ms and 18ms hits.
On UO -2, +19ms gives me 18ms and 28ms hits. I set UO=0 and tried again... it gave me 13ms hits.
I then decided to try UO=0 and local offset=0 and it gave me 2ms hits, same as my -2 UO. (Except no rare 12ms)
But in the UO wizard, -2 would give 3ms hits and 0 would give 13ms hits.
I think it's safe to say that the UO wizard and editor are not to be trusted at all, since actual gameplay is yielding different results.
I used a UO -2, checked with audacity in UO and editor... both out by 3ms, as opposed to 13ms with a UO of -1 or higher.
I start the map with Auto, and in audacity it's out by 2ms. I'm also using metronomelow.wav as my normal-hitnormal.
I adjusted my local offset to test. I'm afraid to say that local offset also suffers from the same 10ms phenomenon that UO does, it's within 2ms on most of its hits, then occasionally, one will be 12ms out. The greater my local offset value, the more often it will be out by 12ms until it's always out by 12ms. It's not happening on every hit, just some of them.
22ms where? I found other problems though.
I give up, not going to mess with any offset from now on, my UO will stay -2, and I'll learn to deal with this value since it's closer to 0 than 0.
*EDIT*:
In addition to my other post where everything measured in the UO wizard was -13, -3, 7, 17, 27, 37, 47, 57. Here is some more random shit from actual gameplay.
In Auto, Local offset of:
"-20" gives me 22ms
"-15" gives 12ms
"-10" gives 14ms
"-5" gives 2ms and 12ms
"0" gives 2ms and rare 12ms
(now the other direction)
"+5" gives 8ms
"+10" gives 11ms (close +1)
"+15" actually gives 15ms (wow)
"+20" gives 19ms (close -1)
Weird that -5 and -15 give the same... and -10 being greater than -15.
Since +15 gave me 15ms on UO -2... I set UO=0 and tried again. It gave 8ms and 18ms hits.
On UO -2, +19ms gives me 18ms and 28ms hits. I set UO=0 and tried again... it gave me 13ms hits.
I then decided to try UO=0 and local offset=0 and it gave me 2ms hits, same as my -2 UO. (Except no rare 12ms)
But in the UO wizard, -2 would give 3ms hits and 0 would give 13ms hits.
I think it's safe to say that the UO wizard and editor are not to be trusted at all, since actual gameplay is yielding different results.
It really is out of our hands, we can't do anything to fix a technical issue unless it has to do something with the drivers. The whole stepped offsets could be due to the resources peppy uses for audio rendering. I'm not sure what could be better or if what he is using is worse, but it's a thought.
Also, Did you check the maps yourself to see if when you sync'd up the offset properly it was correct? I don't really trust auto and using it to measure for results because I believe an anti-cheat method is put in to cause random offsets for it.
Ah, another thing. Has anyone tried this on opengl to see if there is a difference? I have been using directx the whole time while testing.
I would be willing to head an offset assistance team to go and correct the offsets of maps with online offsets if we were given a certain method to get a correct UO so everyone is on the same page.
Also, Did you check the maps yourself to see if when you sync'd up the offset properly it was correct? I don't really trust auto and using it to measure for results because I believe an anti-cheat method is put in to cause random offsets for it.
Ah, another thing. Has anyone tried this on opengl to see if there is a difference? I have been using directx the whole time while testing.
I would be willing to head an offset assistance team to go and correct the offsets of maps with online offsets if we were given a certain method to get a correct UO so everyone is on the same page.
I heard of this before, but I thought it was a random value within that 10ms, not exactly 10ms jumps, which was really weird to me. Well that takes care of that. Thanks.Ziggo wrote:
Regarding your 10ms jumps: http://osu.ppy.sh/forum/p/1733400
peppy said: "osu! is only accurate to 10ms on Windows 7+ due to limitations in the Windows audio subsystem."
Yes, but always 3ms off. Play Auto and it's 2ms off. I noted lots of random 10ms jumps during gameplay... that shouldn't happen and I don't know if it's Auto or if it's a result of "gameplay." The hit-error bar and results screen show "0" which does not necessarily mean it's 0, but possibly that we can't see what value it actually is. There is no way to check though, because of what Ziggo posted. We'll never know for sure if Auto is doing it.Dexus wrote:
Also, Did you check the maps yourself to see if when you sync'd up the offset properly it was correct? I don't really trust auto and using it to measure for results because I believe an anti-cheat method is put in to cause random offsets for it.
I saw no evidence of 22ms differences between UO/editor/gameplay either. I'm still a bit confused about this CO. It seems fine. Wasn't it supposed to fix mis-timings between editor/gameplay? Seems like it's doing its job. Old maps might have a problem, but that's understandable... Evidenced by many 22ms online offsets on old maps.
Myke B wrote:
- O n i - wrote:
0 because i have no idea how to set it up
WOW! So I just learnt about offset by seeing this thread and followed some advice, and I can say that my accuracy has instantly improved. I've always had troubles with hitting notes early and slowly getting unsynced in streams by pressing too fast, and I wondered what I'm doing wrong because I'm pressing exactly to the hitsounds. I had my keyboard set to a 8ms delay (switch on the back) and that noticeably shifted my hits on the graph to the right. But I was still pressing 10~ ms too early so I stared at the offset wizard until I determined that 9ms looked the most comfortable. I played a few maps that I've had trouble on and comparing the replay I can determine without a doubt that this has "fixed" my problem . I still have issues with hitting too early but that's just my eagerness to press something as fast as I can (AR5 is hard but AR9/10 is easy.. k) but I'm slowly fixing that.
. I still have issues with hitting too early but that's just my eagerness to press something as fast as I can (AR5 is hard but AR9/10 is easy.. k) but I'm slowly fixing that.