There are limits in SIF about maximum user before problem start to arise. So let's start to discuss about it.
Have you wonder about invite codes? The code that you use to add someone as friend? This one can only hold up to 999999937 unique code (and actually only can hold 999999937 users), or it will start to collide with first user in the SIF, second user, and so on. Basically, that invite code is calculated using this formula (source):
Next is user credentials. Believe it or not, your account credentials is stored in keychain. It's in plaintext by default in Android (GameEngineActivity.xml) or in iOS, it's built-in keychain storage. This credentials consist of random characters in UUID form (but actually is not really UUID-compilant) and random 128 hexadecimal character. The UUID also only uses hexadecimal characters, and generated randomly when user is creating account. So the chance of this one collide is 2.935x10^-37 %. How long is it? Very very long, that waiting for the 999999937 invite code limit took less time than waiting this one to collide.
Well, all those thing are depends on environment, bit rot, and the current phase of moon. Maybe when we observe the moon phase to decide when to fasting, that UUID just collide each other, damn.
Is a keyboard a board "of" keys, or a board "for" keys?
In music context (piano, synthesizer, computer), it will be "board of keys".
First, I take a look at definition of keyboard, which is "A set of keys on a piano or similar musical instrument.". The use of "of" word in "A set of keys" makes this clear that for piano, a keyboard is a board of keys. Board of keys also makes sense for computer keyboard if that's not enough for you. So, what exactly is "board for keys" then? Board for keys is actually key hook (or key hanger, you name it). In Indonesia language, "board for keys" means "papan untuk kunci" and "board of keys" means "papan kunci". Since "papan kunci" doesn't fully makes sense, so it should be "papan tuts" in music context. "ivory" or "key" in English means "tuts" in Indonesia for music context. Unfortunately in English, key for keyboard and key for opening a door is both called "key" (or "keys" if there are more than 1 key).
A simple tip: If you search "board of keys" and "board for keys" in Google (with the double quote), you'll get different result. The former will be more music-related and the latter will be key hook. Honestly, I would say this is situation where the use of "for" and "of" can cause significant context differences.
As a Tae Hanazono fan, this question really surprise me and bothers me at same time.
Recently some people complain about Live Simulator: 2 timing. I exactly remember that Live Simulator: 2 code the note accuracy based on my previous article regarding SIF note handling, but they say it doesn't seems right, so I decide to test it in Live Simulator: 2 and SIF. The difference were significant but not very. I decide to record my SIF note tapping observation video below.
(Sorry for the 30 FPS video; Google Play Games just can't record thing in 60 FPS, yet).
I used 1.6second note speed (note velocity = 250px/s) and WHITE FIRST LOVE (Normal) beatmap.
As you may know, SIF use this timing table
From now on, ignore the "C" column and focus on "A" and "B" column. However the statement "For swing, Perfect = Great accuracy; Great = Good accuracy" still applies in this context.
Probably you were wondering, how big is 128 pixel? The short answer is, the tap icon diameter. Tap icon diameter is roughly 128 pixels (there are some padding added but actual size in-game files is 128x128px).
One example, when I tap the 2nd note in that video, I time it to be slightly inside idol icon radius and getting good. It's actually true, because the tap icon diameter is 128px, and as basic geometry math tells you that circle radius is half of the diameter, so the tap icon radius is 64 pixels. If you look at the table, 40-64 pixel result in "Good" judgement.
Another example for long note case, when I started the long note in 3rd note, but when I release it, it result in miss. It may looks like should fall in "Bad" range (because the distance is <128px) but if you look it correctly in table above, 112-128 range result in "Miss" judgement.
Now what's the use of that "128px" in Miss row? That 128 value is only used for tapping the note, not for release. Look at 0:37 and you'll see long note which I tap and result in "Bad" judgement (and if you observe carefully, the distance is actually 128px). But why? The answer is, to prevent you tapping the note too early. Say, you tap the note in 200px distance, but since maximum distance is 128px, the game doesn't register "tap" to the note.
What if you missed the note completely? In 0:54, I missed a note in the left side, but it's count as "Miss" when the distance of the note is 128px. In this case, we can conclude that distance 112px or higher result in "Bad" for single note and result in "Miss" for long note trail.
That observation assume 0 timing offset. If timing offset start into play, things start get trickier. I haven't observe when timing offset comes into play, so the rest of this writing is entirely subjective. Winshley said from reddit that "it's almost impossible to get late "Bad" tap with -50 timing offset". That means the note judgement tap range is shifted, but not the 128px range. If my calculation is right, the late "Bad" tap (64-112px range) in -50 timing offset, is 114-162px. However, the maximum limit is 128px, so the range is actually 114-128px. There's only 14px gap between, and with note speed of 0.5 second (to be exact, 0.571428 second), it will be impossible to get late "Bad" tap at all and you'll either get late "Good" or late "Miss".
Because this is based on observation, real-life observation, that means my previous article is invalid (which is completely theoretical). I'll plan to fix all of this mess in Live Simulator: 2 and add SIF timing offset instead of global offset which shifts the whole beatmap time.
At last, I've played WHITE FIRST LOVE song in 5 days a row and I'm not even getting bored of it.
