Research and develop better humanization

[fs-c]

See especially manianalytics (the name is a work-in-progress, haha).

[salami0133]

idk I made this really quick in vs... maybe it helps as inspiration

[fs-c]

My current idea is more along the lines of computing a function of the density of the current map at any point in time and then just scaling that function based on the humanization level provided. The function value at a point in time could then be used as the offset for hitpoints at that time, +-0-5ms or something. I'm still not sure how viable this is, that's what the stuff in v0 is helping me find out.

In regards to your image: do you think that a flat out miss chance for every hitobject would make plays more legit? I mean I'd probably sooner suspect you of hiding something if you missed completely random notes that were really obvious/easy than if you hadn't missed those. (I also don't plan on providing a GUI in the foreseeable future, seems like too much work for too little payoff.)

[salami0133]

well it was just an inspirational thing but yeah it makes sense...

[salami0133]

I have tried a paid bot/client/hack before and it had an "unstable rate" (offsets) and "bpm streaming" slider from 150 to 300 meaning you could adjust how well the bot would hit the notes at a certain speed

[fs-c]

Stuff to think about (red is from the beatmap, blue from the replay):

Maniac without -u.

Maniac with -u -10,20.

Some random replay from the global ranking

I'm lazy and didn't add a scale yet so I couldn't take a screenshot at the exact same time for each replay yet but its still informative I think. Just added one, they are now all from the same timeframe.

Some points until I look into this further

• Always add random values to both "ends" of an hitpoint, tend towards "enlarging" it.
• Maniac still doesn't manage to hit perfectly, it's just inside osu's tolerance range. (See #57 , potentially)
• I don't know what's up with some hitpoints being way larger than they should in the replay since the guy got only >=200s, maybe it's a bug in my replay parsing logic.

[fs-c]

Well this looks very promising.

[salami0133]

damn, that's nice

[fs-c]

Global top replay of this map

Maniac without -u

TwoThree points:

• That player is insane, he's not even 100 milliseconds worse than maniac on average, what the fuck.
• Offsets produced by maniac mirror the action density the best, which is not surprising considering that maniac also takes some time to "press a key", but this time is always roughly constant. I didn't think of it/expect it though.
• Somewhat worrying is the fact that (probably) only top-level players are as consistent as the screenshots above and it would most likely be significantly harder to emulate a middling player using this method. This is also illustrated by comparing the graph in my previous post, which was taken from one of the lower scores on the global top 50 of that map, with the top 1 replay -- the former is significantly more inconsistent.

[fs-c]

Cleaned up an off-topic conversation.

[fs-c]

I'm actively working on this in humanization-refactor-1 at the moment, preview builds which may be highly unstable or not even functional can be downloaded from the Actions tab (just select the most recent one and download the "builds" artifact). Run maniac.exe -h for information on how to control it, the interface changed.

I gotta say that the current implementation looks pretty decent, it drops down to 200s on dense parts but hits consistent 300s when there isn't much going on.

Parts that still need work:

• Looking at the replay in a somewhat advanced replay viewer will look really dodgy (see picture at the bottom), needs some finer randomization.
• It only adds to the action times at the moment, although I guess it should mix in a couple of too-early hits as well? In any case, it should definitely increase the time spent pressing down to look more like human replays.

The same section as above but with the experimental build:

[Meister69]

I hope I'm not missing a really obvious explanation in how to use the new humanization options but I can't make it work. Is the argument supposed to be in [X] format or in a [X,Y] format?, because I tried both and none of them seems to work, it just takes the default value of 0. Also, just wanted to ask if you're considering providing a way of donating to this project, since you're amazing and I'm sure I'm not the only one who loves your work.

[fs-c]

Ah, you're probably seeing a debug log I forgot to remove/update -- in the current build of the experimental branch the humanization is applied by default and not adjustable. For future reference, I try to keep maniac -h as up-to-date as possible, even on experimental branches, so it should usually serve as the source of truth.

Looks like the issue lies elsewhere though: I accidentally pushed some in-progress work in regards to allowing users to scale the offset that's actually added to the actions through a fixed modifier, this is also mentioned in maniac -h (which was part of the accidental push). I'll implement that real quick and post back here once I'm done.

[fs-c]

Pushed the update, maniac -h is now correct. I'd start with maniac -u 100 and start experimenting from there. Please note that this is really rough around the edges right now (see the above hitpoint slider, it's really obvious) but it's a step in the right direction.

[fs-c]

@Sensest After thinking about this for a bit, I'm not so sure about donations. Maybe I'll reconsider once the project has matured a bit and set up a Patreon or something. Or maybe I'll offer a version with some QOL improvements (a GUI, for example) that'll be something like 5$/month, at some point. Not sure yet, definitely going to work on a solid base of features before I consider anything like that though.

In other news, I played around with the dataset some more and separated the absolute error in a timeframe into a positive (i.e. too early) and a negative (i.e. too late) part:

What's interesting about this is that it shows that early keypresses are (a) significantly more rare (or significantly less pronounced, meaning they are closer to the target) than late ones and (b) almost completely independent of the beatmap density. This probably won't factor into the humanization algorithm immediately since it's more of a post release polish but interesting to know nevertheless.

[fs-c]

I recently pushed some changes that would add a random offset between -5 and 5ms to every humanized action when using the new experimental humanization. I feel like this should be customizable. Perhaps with --humanization for the offset that scales with density and --randomization (or maybe --static-humanization?) for random offsets in a static range.

[fs-c]

I have to refactor the config parsing because it turns out that the library I was using previously incorrectly handles some cases that I really want to have (default and implicit arguments, most notably). I consider the experimental humanization mostly stable at this point in time so this is essentially the only thing that's holding back a merge into master at this point. Soon.

Edit: Might roll my own, there appears to be not a single simple argument parsing library out there that just works as expected.

[fs-c]

Config refactor is done. I'll wait a couple of days and if nobody starts screaming by then I'll merge the humanization refactor (+ config refactor I guess) into master. At which point I will probably take a break from this project for a little while.

[fs-c]

Merged, I'll close this now since the original goal of this issue (to develop better humanization) has been met. Once I can think of more improvements I'll open an issue, I'll of course also be happy to review suggestions in regards to this.

New release should be up in a bit.