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.
When the first time BanG Dream Girls Band Party announce the English version is coming in March, I looked up for a new phone candidate. My budget is not much, just uh, 3 million IDR and this will be used for long-term fashion. Here's the criteria I'm looking for:
Camera doesn't have to be very good, but camera which stabilize when taking photos of text is needed.
It must comes with at least 64GB of internal storage. Some people says that it's too much, but trust me, having such big storage will come handy in the future.
Should be recent. 2016 release should be good.
OS must be Android. Bypassing region lock in Play Store with Android is easier than in iOS, and some of my games are region-locked. The Android version doesn't have to be too new, but Android 7.0 is preferred.
Must have at least 3GB of RAM.
Must have fingerprint sensor (rear-mounted is preferred). I don't want to bash the power button.
CPU and GPU should be powerful enough. The CPU should be somehow comparable with Intel Atom Z3560. Snapdragon 6xx series chipset looks promising in this case.
Not to mention screen size. The maximum screen size is 5.5". Bigger than that and I won't able to hold it properly and/or tapping far notes in School Idol Festival.
Dual-SIM at least.
Inputting those criteria to GSMArena phone finder shows up some result, but decided to filer what I think looks best, and my impression on it:
SAMSUNG Galaxy S7 and it's variants. People reports playing School Idol Festival with SAMSUNG phone is bad as very old phone. People says the touchscreen is horrible and randomly drops notes, so no for this one. Not to mention it's very expensive.
OnePlus (any type). Not sure if it's in Indonesia, and I can't find any reports about running School Idol Festival in it. Expensive.
ASUS ZenFone 3 series. Same as OnePlus above, except it's available in Indonesia, and it's cheaper than OnePlus probably.
OPPO Series. No idea about running School Idol Festival there. Also it's expensive here and some people says the performance is awful.
Xiaomi Redmi Note 4. My friend use this one and strongly recommends me this one. It's cheap and suits what I needs, but someone reports playing School Idol Festival there is awful. My friend doesn't recommended the MediaTek version though.
Motorola Moto X4. Same as OnePlus above.
ZTE series. Same as OPPO above, but no idea about performance.
LG G5. I don't know why I put this here. Looks good, but only 32GB of internal storage.
Motorola Moto G5S+. Looks fit my criteria. I don't like the camera placement (can easily scratched) and the front-mounted fingerprint makes me think twice. Not to mention the audio is horrible according to GSMArena review.
And the last, Xiaomi Mi A1 (one that I choose; not the 5X variant). Very similar to Moto G5S+ above, and literally someone in SIF Discord confirms the phone to be work with SIF. Doesn't come with Radio FM but it actually has receiver. Cheaper than Moto G5S+ and better, a bit.
(Note that impression above are subjective!)
And then somewhere in early March I got my Mi A1. Testing time.
School Idol Festival runs fine. No stutters. No lags. Performs exactly same as my previous phone, ASUS ZenFone 2 (which uses Intel Atom Z3560). Testing the Japanese version of Girls Band Party, unfortunately lags out when doing Live! and when reading some stories (probably there are too many Live2D objects to load and render). My older ZenFone 2 still performs way better, probably because Girls Band Party is way more optimized in x86 platform than ARM. But since v2.0.0 of the game, the lag is significantly minimal now. Only lags a bit when doing multi live with LIVE FEVER (all effects enabled). Not sure how my ZenFone 2 handles v2.0.0 now, probably without any lag at all.
Battery life is good. You know what, the first time I extensively testing this phone is by playing SIF and reaching the top 1100. Long run test (2 hours) for reaching 25k event points only consume 20% of battery, which is I can consider very good, although not as good as Redmi Note 4's 4100mAh battery, but I can say it's acceptable.
For the Global version of Girls Band Party, surprisingly, less laggy than pre-v2.0.0 Japanese version of the game. In math, the lagness will be notated as "v2.0.0 JP < v1.1 WW < pre-v2.0.0 JP" where v2.0.0 JP is the most less lag.
To end this up, Girls Band Party performs better in x86 phones (BLACK SHOUTsly ZenFone 2), but x86 phones are horrible in terms of battery life, and it gets really hot in short time.
