tag:blogger.com,1999:blog-8200259307795996652.post4826146914529557696..comments2024-03-14T08:29:28.786+03:00Comments on Touhou lossless music collection: Girls' Frontline statistics, parts of the missing chapter.rwxhttp://www.blogger.com/profile/11961724108899856582noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8200259307795996652.post-24987188731815992352019-05-01T16:25:51.463+03:002019-05-01T16:25:51.463+03:00>In case you weren't already aware
I wasn&#...>In case you weren't already aware<br />I wasn't aware. In fact it never occurred to me to check amounts of result ids in one log, that'd be instantly noticable. And indeed, this is how the length each log is decided - they return at most 10 most recent results for every unit (doll/equip/fairy) type except 3-5* equips, which get 20 [since the fairy update]. Sometimes there are less, due to an additional temporal cutoff maybe.<br />As I noted in the previous post most of the time it's not a problem, craft rates aren't that high outside of rateups. After the update on 2019-03-05 the situation got slightly worse: they disconnect the cache from the live database at around Kalina daily bonus time (04:00 in server UTC-8 timezone), likely to do some scheduled automatic DB maintenance - it is visible (for me) through log updates which stop refreshing and return the same results for about 45 minutes. Even then I still get CR [capture ratio] > 0.98 for dolls. During the rateups... yeah, it's pretty bad (again, see the previous post's chart). I didn't get around to doing something about it yet, but at least each epoch has CR values attached so you can see the degree to which results could be trusted.rwxhttps://www.blogger.com/profile/11961724108899856582noreply@blogger.comtag:blogger.com,1999:blog-8200259307795996652.post-53827611641770983372019-04-30T16:36:17.413+03:002019-04-30T16:36:17.413+03:00Whoops, a quick check ingame shows that it's a...Whoops, a quick check ingame shows that it's actually 10 results now, not 11! (I may either have been remembering incorrectly, or they may have changed it at some point)Anonymoushttps://www.blogger.com/profile/16334101228754108941noreply@blogger.comtag:blogger.com,1999:blog-8200259307795996652.post-90154313130122793342019-04-30T16:25:07.644+03:002019-04-30T16:25:07.644+03:00Pretty interesting article! I was linked this by a...Pretty interesting article! I was linked this by a friend in discord, and just wanted to mention a couple of things that might be of some relevance to you. <br /><br />In case you weren't already aware, production log data only returns a max of 11 results for any one specific result (was it 11? It may have been 12 or 13...it's been quite some months since I've taken a look at it, so I forget the exact number). What this means is that once you hit 11 entries for any particular T-Doll, additional entries for that specific T-Doll gets dropped from the list and it no longer shows up. <br /><br />The end result of this is extremely skewed data if you do not take this into consideration - this is actually the main reason that the chinese GF statistics website is considered useless, because it does not account for this and as a result the data is incredibly unreliable. Let's take, as an example, a theoretical situation where you have a craft pool of 4 dolls total - one of each rarity at one 2*, one 3*, one 4*, and one 5*. <br /><br />Per the official craft rates given by the developers, the correct rarity breakdown is 60% for a 2*, 27% for a 3*, 10% for a 4*, and 3% for a 5*. This means that given a slice of 50 craft results, you would expect ratios on the level of 30:13:5:2 for each rarity. <br /><br />However, because any entry past the 11th gets dropped from the data list, the actual results you will return from a slice of 50 are incredibly different. Each specific T-Doll is capped at 11 entries, meaning that even if one T-Doll is far more common than the others, you will only return 11 copies of it from one particular slice. Thus, an example of the data that you would get would be something like this:<br /><br />2* <br />2*<br />2*<br />3*<br />2*<br />2*<br />4*<br />2*<br />2*<br />5*<br />2*<br />3*<br />4*<br />2*<br />2*<br />2* (this is the 11th entry - thus, 2*s will no longer show up after this entry)<br />3*<br />3*<br />3*<br />3*<br />4*<br />3*<br />4*<br />4*<br />3*<br />3*<br />5*<br />3*<br />3* (this is the 11th entry - thus, 3*s will no longer show up after this entry)<br />4*<br />4*<br />4*<br />5*<br />4*<br />4*<br />-- and so on<br /><br /><br />As a result, a slice of 50 production results would most likely return a ratio of 11:11:11:11:6, because after it runs out of 2*/3* rarities to show, it can only show 4*/5* rarities afterwards. If you ran the statistics on this slice without knowing of the issue, you would mistakenly conclude that the rates for higher rarity T-Dolls are massively higher than they actually are. <br /><br />This is the reason why the chinese GF statistics database shows ridiculous 5* rates for specific recipes - since it pulls production log data without accounting for this, the ratio of high rarity dolls is skewed and you end up with recipes that claim to have a 15-20% 5* rate, even when this is clearly demonstrably false by anyone actually using the recipe. <br /><br />This issue is also exacerbated by so-called "voodoo" recipes, where one person will spam the same unique recipe a couple hundred times in a row - when doing so, that person passes 11 copies of a specific T-Doll in a short amount of time, and thus all of the common T-Doll results are dropped out of the data. When the data scraper then proceeds to pull production log data, it will detect this user and thus conclude that the "voodoo" recipe must have a disproportionately high success rate, when in actuality it's simply skewed data from overloading the production log with high craft amounts in a short duration. <br /><br />Anyway, this is fairly simple to account for - when you are data collecting, you either need to confirm that no results have been dropped from the data set by ensuring that each data update contains no more than 11 new entries of any specific T-Doll (very difficult to do given the update frequency of the refresh log, as high-activity periods will overload the production log), or by only collecting data up until it contains 11 copies of any specific T-Doll (though this has the side effect of not being able to collect much data at a time, making large data sets harder to get and data collection slower). Anonymoushttps://www.blogger.com/profile/16334101228754108941noreply@blogger.comtag:blogger.com,1999:blog-8200259307795996652.post-55509055576718876342019-04-22T02:29:23.767+03:002019-04-22T02:29:23.767+03:00I'm having mixed reaction to the new client.
O...I'm having mixed reaction to the new client.<br />On one hand, there are definite improvements: multiturn planning, fairy reclassification, fixed crash in the menu, several annoying modal dialogs changed to sliding notifications, dorm size expansion.<br />On the other, now entering repair bay takes 2 seconds even on emulator, battles jerk and lag just before the ending summary, dorms look worse with the black bars, first retreat on a map sometimes hangs for a second before displaying confirmation dialog, planning mode fails to continue if an enemy runs into you on SF turn and the client still leaks memory.<br />It's almost like their quality control doesn't exist, so developers fix one thing and break another in the process.rwxhttps://www.blogger.com/profile/11961724108899856582noreply@blogger.comtag:blogger.com,1999:blog-8200259307795996652.post-33238311196686879462019-04-15T13:37:28.740+03:002019-04-15T13:37:28.740+03:00Don't know how everyone else who was affected ...Don't know how everyone else who was affected dealt with lags, but, since it forced me to discover Leapdroid, for me it was a temporary annoyance followed by permanent improvement (playing on PC).<br />Just hoping that new client doesn't ruin everything again, I'm out of fallback options now.rwxhttps://www.blogger.com/profile/11961724108899856582noreply@blogger.comtag:blogger.com,1999:blog-8200259307795996652.post-72198473676647483032019-04-15T07:00:37.942+03:002019-04-15T07:00:37.942+03:00Thanks for the write-up, it's a very interesti...Thanks for the write-up, it's a very interesting read.<br />Here's hoping the new client coming soon ends those lag issues already.Anonymousnoreply@blogger.com