this map cannot be qualified while the score limit goes past the main client's 32-bit integer limits - attempts to do so will result in an instant disqualification as the main client will force scorev2 to be toggled on and, therefore, make the score not submit. this makes ranking the map pointless unless either stable is hotfixed to submit v2 / expand the score limit or osu!lazer officially takes over as the main client
since stable isn't ever getting fixed and lazer already has leaderboards, we may as well push this <3
will bubble now, can be qf'd whenever deemed ready
timing stuff:
00:00:187 (1) - -5
01:18:797 (1) - -15
02:19:547 (1) - -15
03:05:274 (1) - nailed it 👌
04:57:289 (1) - nailed
06:52:444 (1) - parsee is so cute
08:50:938 (1) - -10 this whole section (including the 5 red lines following this one)
10:52:717 (1) - i was stuck on yuugi for so long
11:06:679 (5) - -25 and resnap
11:07:047 (1) - delet
rest of yuugi theme is OK
12:41:396 (1) - -15 this whole section
14:59:891 (1) - -18 ALL OF SATORI (whole section)
17:28:512 (1) - -12 whole section
20:27:185 (1) - -15 ORINNNNNNNNNN
23:30:576 (1) - -16 whole section
25:33:523 (1) - -15 the bird (and yes the whole section)
28:31:122 (1) - MINUS TEN all of last remote
31:46:649 (1) - already modded this earlier #1517812 still applies
have fun having your editor freeze every time u save the timing >:)
01:18:782 (1) - this could use -10 still
01:54:782 (1) - -10 here as well
also u forgot to move a bunch of svs and resnap a bunch of stuff lol just check aimod
damn we need this attention to detail for other touhou OSTs, especially newer ones that have next to no representation in osu.
I'm sorry to be this guy but the way the Fonts are handled in the storyboard is very problematic.
Based on what I take away from the .osb ALL fonts run through the transformation of ALL the other fonts as well, resulting in a total of ~2400 sprites being active through pretty much the entirety of 30min while only visible for a very small fraction of that time.
This leads to not only an unnecessary filesize increase of an estimated 3+MB but could very well also induce performance issues on weaker machines. This should definitely get fixed.
I'm just throwing one random sample here, it looks like this everywhere from line ~40000 to ~170000:
Sprite,Background,Centre,"sb\f\glow\0031.png",0,0
M,8,144,534,130,215,99,143
M,8,534,924,99,143,-106,-23
M,8,924,1354,-106,-23,556,443.5
M,0,1303,,556,443.5
M,8,76160,76354,-254,293.5,346,293.5
M,0,76354,78497,346,293.5,371,293.5
M,8,78707,79880,371,293.5,556,443.5
M,8,182629,182817,-254,293.5,346,293.5
M,0,182817,184879,346,293.5,371,293.5
M,8,185020,185254,371,293.5,556,443.5
M,8,292888,293070,-254,293.5,346,293.5
M,0,293070,295433,346,293.5,371,293.5
M,8,295750,297277,371,293.5,556,443.5
M,8,409521,409725,-254,293.5,346,293.5
M,0,409725,411766,346,293.5,371,293.5
M,8,411923,412431,371,293.5,556,443.5
M,8,527959,528146,-254,293.5,346,293.5
M,0,528146,530754,346,293.5,371,293.5
M,8,530780,534063,371,293.5,556,443.5
M,8,649876,650072,-254,293.5,346,293.5
M,0,650072,652131,346,293.5,371,293.5
M,8,652280,652704,371,293.5,556,443.5
M,8,758871,759070,-254,293.5,346,293.5
M,0,759070,761156,346,293.5,371,293.5
M,8,761336,764383,371,293.5,556,443.5
M,8,897882,898070,-254,293.5,346,293.5
M,0,898070,899195,346,293.5,371,293.5
M,8,899335,899879,371,293.5,556,443.5
M,8,1030230,1030435,-254,293.5,346,293.5
M,0,1030435,1048209,346,293.5,371,293.5
M,8,1048453,1050807,371,293.5,556,443.5
P,0,1200220,1201980,A
S,0,1200420,,0.5
F,0,1200420,1200470,0,1 <--- sprite is actually visible for 1.5 seconds here
F,0,1201880,1201980,1,0 <--- aaaand it's gone
M,8,1223517,1223715,-254,293.5,346,293.5
M,0,1223715,1226576,346,293.5,371,293.5
M,8,1226628,1227169,371,293.5,556,443.5
M,8,1407545,1407732,-254,293.5,346,293.5
M,0,1407732,1410340,346,293.5,371,293.5
M,8,1410516,1412168,371,293.5,556,443.5
M,8,1530688,1530849,-254,293.5,346,293.5
M,0,1530849,1533015,346,293.5,371,293.5
M,8,1533128,1533510,371,293.5,556,443.5
M,8,1708203,1708374,-254,293.5,346,293.5
M,0,1708374,1710860,346,293.5,371,293.5
M,8,1711062,1713132,371,293.5,556,443.5
M,8,1903589,1903758,-254,293.5,346,293.5
M,0,1903758,1906117,346,293.5,371,293.5
M,8,1906239,1906636,371,293.5,556,443.5
M,8,2032112,2032293,-254,293.5,346,293.5
M,0,2032293,2034639,346,293.5,371,293.5
M,8,2034862,2037021,371,293.5,556,443.5
I'm in touch with robicoco rn to smooth out the fonts even more as there is still a good amount of fonts that is initialised 1-3min too early, mostly those in the transition phases between songs. Which is a massive improvement compared to before but still has to be considered a problem that we should fix before requalification.
There is some optimisation you could do for the firework-ish effect around 12min:
Sprite,Background,Centre,"sb\p3.png",0,0
R,0,727397,,-1.570796
C,0,727397,,254,46,46
V,0,727397,,0.2,0.3
F,2,727397,727697,0,0.8
M,6,727397,727897,136,0,136,480
P,0,727397,752863,A
F,0,727897,,0
R,0,752363,,-1.570796
C,0,752363,,254,46,46
V,0,752363,,0.2,0.3
F,2,752363,752663,0,0.8
M,6,752363,752863,568,0,568,480
F,0,752863,,0
Right now you reuse the sprite quite a while later again while going through all the transformations again.
In terms of performance it would be best to divide this into 2 sprites that are active for half a second instead of having 1 sprite that is active for 25s but only visible for 1s. In that case you'd need to make sure that both parts have additive coloring enabled as that is currently in one command only.
In case you used storybrew and OsbSpritePools to achieve this (wild guess), you can set the MaxPoolDuration property of the pool to a lower value (e.g. 10000 instead of its default 60000).
why isnt the artist "Team Shanghai Alice"? as far as i remember, ZUN published the game under that label. I want to know, because that could apply too to his og name (Jun'ya Ota).
orin is generally pretty cheerful, matching her song title, and the way she's portrayed in the storyboard doesn't really reflect that too well (plus, where are the spirits??)
here's a better background with an art style that fits the previous two https://puu.sh/FxCpU/79827f3e4c.jpg
here's a scaled down ver that fits the current sb https://puu.sh/FxCsE/e6801c783a.jpg
and here's the twitter source https://twitter.com/kamindani/status/801781508943949824
hitsounds like the ones at 09:05:856 (2,3) - give little to no feedback and should at the very least be louder
The mustard knows where it is at all times. It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the mustard from a position where it is to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position that it was, is now the position that it isn't.
In the event that the position that it is in is not the position that it wasn't, the system has acquired a variation, the variation being the difference between where the missile is, and where it wasn't. If variation is considered to be a significant factor, it too may be corrected by the GEA. However, the mustard must also know where it was.
The mustard guidance computer scenario works as follows. Because a variation has modified some of the information the mustard has obtained, it is not sure just where it is. However, it is sure where it isn't, within reason, and it knows where it was. It now subtracts where it should be from where it wasn't, or vice-versa, and by differentiating this from the algebraic sum of where it shouldn't be, and where it was, it is able to obtain the deviation and its variation, which is called error.