{"content":"\n \n \n <\/a>\n <\/div>\n \n \n eldnl<\/a>\n\n \n Former osu!catch Champion: 2013\n <\/div>\n \n \n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 2,930 posts\n <\/a>\n <\/div>\n\n \n ed March 2010<\/strong>\n <\/div>\n <\/div>\n\n \n \n \n \n \n Topic Starter\n <\/span>\n <\/div>\n \n \n eldnl<\/a>\n\n \n 2013-01-02T02:23:47+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n TheVileOne wrote:<\/h4>Are you sure you really wanted this?There wont be super difficult CTb maps as you know it now, because anything past a certain degree of catchability is now hypered. So anything that is 1.9 plus horizontal is now a hyper in With a dance Number, when before only some of them were. Fixing this is going to drastically reduce the difficulty of maps and its not like you can just bring that difficulty back.<\/blockquote>I think is not the correct way to fix this, the spacing are fine as it is, the only problem are the \"pixel jumps\" and there should be a way to fix them without changing anything else.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/span>\n <\/div>\n \n peppy<\/a>\n\n \n \n \n <\/div>\n\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 19,323 posts\n <\/a>\n <\/div>\n\n \n Here since the beginning<\/div>\n <\/div>\n <\/div>\n\n \n \n \n \n \n peppy<\/a>\n\n \n 2013-01-02T02:31:02+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n I will be looking at this this week. The issues lie in sub-frame calculation issues.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/div>\n \n TheVileOne<\/a>\n\n \n osu! Alumni\n <\/div>\n \n \n \n <\/a>\n\n <\/div>\n \n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 8,434 posts\n <\/a>\n <\/div>\n\n \n ed March 2010<\/strong>\n <\/div>\n <\/div>\n\n \n \n \n \n \n TheVileOne<\/a>\n\n \n 2013-01-02T02:43:49+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n peppy, I'm not sure it should be \"fixed\" in the sense that all fruits that meet a certain criteria should be hypered. Because if that is the case, it will alter maps that were previously possible without said hypers. I'm sure there will be hate if people start playing their uber pro map and find these hypers that weren't there before, because the algorithm was broken before, and now the fixed result is easier than how people knew it.I am not a super pro or regularly play CTB. So I cannot speak on behalf of the pro community without the pros assessing their favorite maps and potential changes to the patterns. Really we need people checking difficulties for pattern consistencies and checking how far one should reach for a pattern.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/span>\n <\/div>\n \n MillhioreF<\/a>\n\n \n Pro Tester\n <\/div>\n \n \n \n <\/a>\n\n <\/div>\n \n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 5,004 posts\n <\/a>\n <\/div>\n\n \n ed July 2011<\/strong>\n <\/div>\n <\/div>\n\n \n \n \n \n \n MillhioreF<\/a>\n\n \n 2013-01-02T02:47:41+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n The idea is that only fruits which were impossible before (or possible only with certain FPS that gives you faster speed than intended) will have hyperdashes added, and all other hyperdashes will stay as they were. If it wasn't important that this was the case, the hyperdash fix would already be complete and have gone live.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/span>\n <\/div>\n \n peppy<\/a>\n\n \n \n \n <\/div>\n\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 19,323 posts\n <\/a>\n <\/div>\n\n \n Here since the beginning<\/div>\n <\/div>\n <\/div>\n\n \n \n \n \n \n peppy<\/a>\n\n \n 2013-01-02T02:55:03+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n The fix is not live because it is not accurate enough, correct. Please wait for further updates from me. This is #1 priority as it is causing imparity with public build releases at the moment, and thus holding up other features.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n statementreply<\/a>\n\n \n Pro Tester\n <\/div>\n \n \n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 307 posts\n <\/a>\n <\/div>\n\n \n ed June 2009<\/strong>\n <\/div>\n <\/div>\n\n \n \n \n \n \n statementreply<\/a>\n\n \n 2013-01-02T09:06:42+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n Pseudo code (hopefully better than the current one)<\/span>SPOILER<\/a>prevFruit.x = 256; \/\/ Arbitrary initial valuesprevFruit.t = -Inf;minX = 0; \/\/ Leftmost catcher positionmaxX = 512; \/\/ Rightmost catcher positionprevMove = Normal; \/\/ Bit flags, Normal=0\/\/ SpaceLeniency and TimeLeniency may (or may not) depend on CircleSize and OverallDifficulty respectively\/\/ Old (public build) behavior is roughly equivalent to SpaceLeniency = CatcherWidth * 0.1875 and TimeLeniency = 0\/\/ when successive hyperdashes are not encountered withforeach (fruit in fruits){ if (fruit is spinner or something like this) { continue; } fruitLeft = Max(0, fruit.x - CatcherHalfWidth + SpaceLeniency); fruitRight = Min(512, fruit.x + CatcherHalfWidth - SpaceLeniency); minX -= Max(0, fruit.t - prevFruit.t - ((prevMove & LeftFullDash) != 0 ? 0 : TimeLeniency)) * DashSpeed; maxX += Max(0, fruit.t - prevFruit.t - ((prevMove & RightFullDash) != 0 ? 0 : TimeLeniency)) * DashSpeed; prevMove = Normal; if (minX > fruitRight) { prevFruit.isHyperDash = true; prevMove |= LeftFullDash; minX = fruit.x; maxX = fruit.x; } else if (minX >= fruitLeft) { prevMove |= LeftFullDash; } else { minX = fruitLeft; } if (maxX < fruitLeft) { prevFruit.isHyperDash = true; prevMove |= RightFullDash; minX = fruit.x; maxX = fruit.x; } else if (maxX <= fruitRight) { prevMove |= RightFullDash; } else { maxX = fruitRight; } prevFruit = fruit;}<\/pre><\/div><\/div>The point is that we work out the reasonable range the catcher is currently able to reach, and base hyperdash spawning on this.For each jump in the 3-note jump situation alone, we can catch the two notes with dash starting from the right side of the first fruit (and ends up hitting the left side of the second fruit). But considering the 3-note jump as a whole, this algorithm should be able to detect that the third fruit is without reach, spawning hyperdash on the second fruit.EDIT: various fixes and some commentsEDIT2: brief explanation<\/div>\n <\/div>\n <\/div>\n\n \n Last edited by statementreply<\/a> 2013-01-03T16:16:34+00:00<\/time>, edited 1 time in total.\n <\/div>\n \n \n <\/div>\n <\/div>\n \n \n \n Last Remnant_old\n <\/span>\n \n \n \n \n <\/div>\n\n \n \n \n \n \n Last Remnant_old<\/span>\n\n \n 2013-01-02T12:04:20+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n Simply put,Let's say that there is a FOR loop that goes through all fruits and that we are currently at some fruit $i<\/strong>. Current algorithm will take a look at $i+1<\/strong> fruit's time<\/strong> and X coordinate<\/strong> and decide whether fruit $i<\/strong> will become hyper or not.This needs just a small tweak:Let's say that at past example we concluded that fruit $i<\/strong> doesn't need to be hyper (in other words, jump $i<\/strong> - $i+1<\/strong> is catchable), now we also need to check fruit $i+2<\/strong> (and maybe $i+3<\/strong>, although cases with 4 fruits in a row are very rare, I know only 1 map). If we conclude that jump $i<\/strong> - $i+2<\/strong> isn't catchable, we must make both fruits $i<\/strong> and $i+1<\/strong> hypers.Here jumps 1<\/strong> - 2<\/strong> and 2<\/strong> - 3<\/strong> are catchable, while jump 1<\/strong> - 3<\/strong> isn't, which is shown on the next picture.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/span>\n <\/div>\n \n peppy<\/a>\n\n \n \n \n <\/div>\n\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n <\/span>\n <\/a>\n <\/div>\n \n \n \n 19,323 posts\n <\/a>\n <\/div>\n\n \n Here since the beginning<\/div>\n <\/div>\n <\/div>\n\n \n \n \n \n \n peppy<\/a>\n\n \n 2013-01-02T12:22:09+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n That isn't the only case, but it is one of them. I have already allowed for this. Thanks for your input with proposed solutions, but please wait until I make further changes as I already know exactly what is wrong and how I will fix it.Keep in mind my current fix fixes not only the main case you specify, but others which were mentioned by Millhiore. We are not dealing with a single point of failure here.<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n Last Remnant_old\n <\/span>\n \n \n \n \n <\/div>\n\n \n \n \n \n \n Last Remnant_old<\/span>\n\n \n 2013-01-02T12:48:44+00:00<\/time>\n <\/a>\n <\/div>\n <\/div>\n\n <\/div>\n\n \n \n Yeah, the smallest droplets in middle of slider also causes break (as if in my example fruit 2<\/strong> was droplet) and other things mentioned by MillhioreF.There is one more thing I would like to ask, not much related to this, but it is connected to \"traversing the distance\" with catcher :In past weeks \/ months we could see that lags \/ pauses and other tricks (even not tricks, just some PCs having natural lags that are helpful) could be used to make your catcher cover more distance for the same time (thus many players used this to get these same impossible jumps we are trying to fix). This is because catcher's movement and song aren't synchronized. I'm not exactly sure why, since song's timer is updated on 10ms intervals. Isn't it possible to tie catcher's movement to song, same as hitObjects are synced (in other words, update catcher's position by the fixed distance each time the song timer is updated)? This means that in each update catcher may either stay put, or move left or right by that same distance.This is also related to your recent implementation of ALERT feature, which is triggered for almost any replay (probably because each PC has some kind of lag that makes catcher's speed uncontrollable and variable)PS. Since we want equal conditions for everyone, I think something could be done about this. (already present check that won't submit your score if catcher is faster or slower isn't good enough, maybe make it more strict? )<\/div>\n <\/div>\n <\/div>\n\n \n \n <\/div>\n <\/div>\n \n \n \n <\/a>\n <\/div>\n \n \n <\/span>\n <\/span>\n <\/span>\n <\/div>\n \n peppy<\/a>\n\n \n \n \n <\/div>\n\n <\/div>\n \n 2h3h54