@Tom94

Tom Long Dong

Ask @Tom94

Sort by:

LatestTop

Previous

in which language are you coding pp stuff?

Difficulty calculation is C# obviously as it runs in the osu! client (pp uses a server version of that) and pp calculation itself runs in a seperate program written in C++.
Turns out C++ was not even required since even the limited CPU of the VM the pp processor is running in constantly sits below 5% usage. What's really hogging the performance is the database.

Related users

Was für eine Tastatur benutzt du? ^_^ Sorry, falls das irgendwo, irgendwie schon einmal gefragt wurde. :c

CM Storm Quickfire TK mit Cherry MX brown switches.
Liked by: DroppedBass

eine Frage: hast du dich schon mal mit CookEasy, Dustice, Shunsuke, crptnXn, Splinter und Bddav so reallife getroffen? :D

Nope.

http://pastebin.com/C3yuzrpq was denkst du?

Kenne mich mit Markow-Ketten auch nicht aus. Das Problem, das ich sehe ist selbiges wie bei ppv1: Maps wo hauptsächlich schlechtere Spieler spielen werden als schwerer als sie sind trainiert und geben somit zu viel pp. Das ist tatsächlich der Fall bei den meisten maps, vor allem denen die nicht der höchste Schwierigkeitsgrad im Set sind.
Liked by: DroppedBass

judging by your previous answer, does it mean that DT doesn't take the decrease in the hitwindow of the circle into account when calculating pp?

Read my answer again. It does. What sense would it make if it wouldn't?

If someone mapped the exact same map but 1.5x faster and with AR9.6 instead of AR8 and same with OD etc., would that give the same PP as the original map + DT? What about the same map with AR9.8 instead of AR7 and CS5.2 instead of CS4 and OD9.8 instead of OD7 etc. vs HR?

I'm assuming you did the transformations of difficulty values correctly. If yes, then those 2 scenarios would indeed give the exact same pp.

What about seeing the aim/speed/accuracy values of a score or a player themselves?

Both score and players are currently not possible. Would involve quite a bit higher database load which is currently not feasible. :/
Liked by: DroppedBass

Is it possible to see how much pp a map really gives me? If my first score gives 200 pp + 100% weighing = 200 pp. However, I don't receive 200, because the other scores get pushed down so I actually get less... Can something like this be implemented? I mean, knowing the exact amount of pp?

Another thing that I'd like to see in the game. Server + client changes are always a bit tricky, though, especially if they involve a time dependency on the pp calculations in yet another component.
Liked by: -cr1mmy- DroppedBass

Would it be possible to show the pp value of scores in-game some time in the future? Like maybe you click on a score and it goes to the screen with accuracy info, performance chart, etc, and somewhere in there the pp value is displayed? So people don't have to constantly go to the website to check

Yeah, I'd like to add this at some point.

I am a person who has higher pp scores than my successors yet they are ahead simply because they have more scores - does this not imply 'farming'? I need to do scores below my peak skill in order to overtake them. I love the ppv2 system, but it seems weighting is not sufficient enough.

A certain degree of farming is always required to ensure the performance isn't completely inconsistent and random.

In ppv1, all scores gave you 100% of the pp. Now in ppv2, the first score gives you 100% and the rest give you a decreasing number of pp because of weighing. How about if your top 10 performances give you 100%, while the rest are weighed as 0%. Would that be a potentially good system? If not - why?

You are wrong, ppv1 did the same thing as ppv2 albeit with a different modifier. More scores were important.
The system you describe would be very similar in terms of end results to the current system, but it would feel more "jumpy". You'd get good pp for new high scores until your top10 scores are about even and then suddenly you hit a brick wall where you gain no pp unless you get a new best performance. I'd say that's a lot more discouraging and frustrating to players than the current system.

Also about hidden, I think most people agree that it's easier to read at higher approach rates, so I think that the flat bonus I was talking about before should be slightly modified depending on the AR of the map. For exampe 12% for AR8, 10% for AR9, and 8% for AR10.3.

I agree with that and I think I'll change this when I get the chance. I won't use the exact values you propose, though. AR8 with HD deserves at least 20% imho while 8% for 10.3 sounds fair.

I think one of the biggest problems with ppv2 at the moment is that it values maps with difficulty focused on a single aspect too low compared to maps whose difficulty is equally spread over aim/speed/acc. Why not weight it someting like sqrt(aim^2+speed^2+acc^2)?

This is already done, but only to a smaller extent. Instead of ^2 it is ^1.1. I actually tried raising the exponent at some point, but the feedback was massively negative.

http://ask.fm/Tom94/answer/121595993038 Fitt's law would hit higher values across the board, not just HR - for example, it would nerf remote control jumps by considering them to be easier than the current model does. Overall, it would be a buff for HR compared to DT.

Again, the only difference to the current model would be to change the scaling by slapping a logarithm onto it. That's way too harsh, the logarithm goes up faaaar too slowly. Trust me I've tried all kinds of scalings you can imagine. Example:
1 pixel jump: difficulty 0
2 pixel jump: difficulty 1
4 pixel jump: difficulty 2
8 pixel jump: difficulty 3
...
1024 pixel jump: difficulty 10
Just no. It doesn't make any sense to value a movement which is almost stationary (less than half a hitcircle of distance!) a third as much as a screenjump.
Other lower scalings than a logarithm are more sensible but overall punish mostly maps which don't deserve to be. Balancing this isn't as simple as it sounds.
And lastly, no, it wouldn't buff HR compared to DT. I don't know where you are pulling this from but you are more than wrong. HR is dealing with far larger normalized distances than DT does due to the smaller circle size and a logarithmic scale would certainly hit those far more.

View more

Liked by: DroppedBass

Next

Language: English