Sign In To Proceed 2z1z44

Don't have an ? 5p1p6t

osu! to create your own !
forum

Hyperdash fruits don't always spawn correctly in CTB [confirmed] 563m3v

posted
Total Posts
211
show more
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.
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.
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.
Pseudo code (hopefully better than the current one)
SPOILER
prevFruit.x = 256; // Arbitrary initial values
prevFruit.t = -Inf;
minX = 0; // Leftmost catcher position
maxX = 512; // Rightmost catcher position
prevMove = 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 with

foreach (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;
}
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 comments
EDIT2: brief explanation
Last Remnant_old
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. Current algorithm will take a look at $i+1 fruit's time and X coordinate and decide whether fruit $i will become hyper or not.

This needs just a small tweak:

Let's say that at past example we concluded that fruit $i doesn't need to be hyper (in other words, jump $i - $i+1 is catchable), now we also need to check fruit $i+2 (and maybe $i+3, although cases with 4 fruits in a row are very rare, I know only 1 map). If we conclude that jump $i - $i+2 isn't catchable, we must make both fruits $i and $i+1 hypers.



Here jumps 1 - 2 and 2 - 3 are catchable, while jump 1 - 3 isn't, which is shown on the next picture.

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.
Last Remnant_old
Yeah, the smallest droplets in middle of slider also causes break (as if in my example fruit 2 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? )
Please test again on test build.
The behavior seems to have gotten worse - none of the scenarios in my example map work correctly any longer.

-In the 3-note jump, the first fruit hyperdashes while the second doesn't, which is probably intentional. However, due to the catcher slowing down once you're under the next note while still in hyperfruit status, it's impossible to get over far enough to catch the third fruit. Both should still grow hyperdashes.
-The spaced stream doesn't grow hyperfruits at all, and so is still impossible.
-The slider has reverted to the state it was in after the first fix:

MillhioreF wrote: 2k1855

The first fruit of a slider now gives hyperdash up to the droplet as it should, but the droplet doesn't renew the hyperdash status and Ryuuta only moves at normal speed (which isn't always enough.)

MillhioreF wrote: 2k1855

-In the 3-note jump, the first fruit hyperdashes while the second doesn't, which is probably intentional. However, due to the catcher slowing down once you're under the next note while still in hyperfruit status, it's impossible to get over far enough to catch the third fruit. Both should still grow hyperdashes.
The second fruit absolutely needs hyperdash while the first doesn't really require that (getting hyperdash on both fruits makes sense though).
Sliders :
Hyperdash on sliders doesn't works ryuuta seems to stop at the droplet, even if the droplet is hyperdashed the ryuuta stops on it.

1-1 jumps :
Seen too many extra hyperdashes appearing on many maps.

1-1-1 jumps :
Doesn't seems to spawn in the good placements. Most of the time only the first fruit is hyperdash'd and the behavior is kinda same as sliders, the ryuuta stops in the second fruit.

statementreply wrote: 232z60

The second fruit absolutely needs hyperdash while the first doesn't really require that (getting hyperdash on both fruits makes sense though).
If there's the same spacing between the 3 fruits the 2 first fruits should be hyperdash'd. Makes much more sense for mapping, and also in term of readability of the map.
http://ha.ppy.sh/ss/1273 It should be exactly the opposite, only the center one requires hyper.
A screenshot alone means nothing. Please provide an isolated case in an .osu.
All right, here's one for the tutorial. (Watashi mp3 was too short) The first and third fruits become hyper, making the pattern uncatchable. If the second and fourth fruits were hyper though, it would be.
http://puu.sh/1IMkE
Please test again, there was a bug in my previous change.
http://ha.ppy.sh/ss/1277 The pixel jumps are again uncatchable, no hyper dash appears x_x
http://puu.sh/1IUWb (on tutorial)
First three patterns are uncatchable.

EDIT: Fixed link
There are some unnecesary HDashes as well, taking this map as reference, which contains extreme patterns: http://osu-ppy-sh.tvgratuite.org/s/19156 [Sp's Darkness]

In the described cases, those notes had a not-so-long distance with the next ones, thus they shouldn't be HDashed.
I've noticed that droplets are totally ignored during sliders making them quite impossible to catch for most cases.

Here's a map to easily test play them : http://osu-ppy-sh.tvgratuite.org/p/beatmap?b=46477&m=2 @ 00:22:537 (1,2,3) -

I've succeeded to catch sometimes the droplets adjusting my dash during the hyper, in other words it's greatly luck based. For other maps it seems like they're just impossible to catch.


I didn't notice any changes, droplets are still very hard to catch.
Droplets are not supposed to be always catchable.
If so, that can be discussed in the CTB rules thread to avoid putting sliders at such high speeds that they need to be HDashed. Otherwise, they'll be incopatible with:

  1. Your map must theoretically be SSable. This generally means you must be able to catch absolutely all fruits, including droplets. This ties in the previous point, but is fundamentally for different reasons.
Yep, I'm still formulating a solution in my head. No such maps have been ranked yet, right?
CTB specific maps? I don't any of the ones ranked (after the approval of those rules) with that issue.
Please re-test all non-drop specific cases.
http://puu.sh/1Kntd
First three patterns: There should be hyperdashes somewhere for all the fruits to be catchable, preferably on all fruits except the last one of each pattern. (3 note jumps)
The last pattern: The 3rd fruit should be spawn hyperdash. (jumps after hyperdash)
I have fixed all these cases. Please test furrther :).
3-note jump is working beautifully!

Spaced stream is a bit awkward since every 3rd fruit isn't hypered, but it should be fine, since it's still possible to catch everything. CTB players might even welcome this, since it's harder to catch the stream than it would be if every fruit was hypered.

Sliders with big droplets are still perfect.

Aside from missing the little droplets, which may not be such a big deal, sliders with only small droplets in between sliderends are a bit strange. If you aren't already moving in the direction you need to go when you catch the hyperslider fruit, the screen will darken and Ryuuta will turn red, but he won't actually get a speedboost and will miss the next fruit, making these unintuitive to catch. Normal fruit and sliders with only big droplets aren't affected by this - you can catch the fruit, wait a few milliseconds, then start moving and still make it to the next fruit.


Gonna edit this post once I analyze a map that's very hard but SS-able on the public build, making sure there aren't any hyperfruit where they aren't needed.
Can you cite an example for the slider-with-small-droplets issue? I'll take a look at it.
http://puu.sh/1KH7M (on tutorial)
00:03:808 (4) - Hyperdash isn't necessary
I'll drop a few more .osu files for Watashi here with bugs that need fixing.

http://puu.sh/1KH0l - a triplet before some back-and-forths makes an unnecessary hyperdash spawn.
http://puu.sh/1KH54 - Ryuuta seems to overshoot the end of this slider if you keep holding right!
http://puu.sh/1KHbb - This is catchable, but suffers from the slider-with-small-droplets issue.
Fixed all these issues. Please check for any regressions and/or new cases.

I've written up exactly what was wrong with the previous calculations, for anyone interested enough: http://blog.ppy.sh/post/39917651337/get ... dash-right
Anyway really interesting patch!
I'll expect this when this releases.
It doesn't appear that there were any regressions. The triplet with back-and-forth was fixed, but Ryuuta still overshoots the slider in my second example difficulty. The slider-with-small-droplets issue seems to be somewhat better, but it's not completely fixed as far as I can tell. I might have to record it and slow down the recording to take a closer look at what's going on.

There are still a few misplaced hyperdashes, too. I've put up a difficulty with 3 examples from Talent Shredder of fruit that are hyperdashed, but don't actually need hyperdashes to be caught. (Sorry if they would have been better if they were each isolated, but I think they might be related, and also it's simpler to import this way)
Click here!


These cases involve calculations at the turn of single calculation frames. I have tweaked it slightly, so please test all previous cases for regressions. If you are still seeing hyperfruit being made where they weren't before, I think these are best left to for edge cases where lag could cause a miss/hit.
somethimes the catcher is crazy,
this bug appears when you fail the "end hdash fruit"
:3

scarlet rose

lineqtxz wrote: 1y59p

somethimes the catcher is crazy,
this bug appears when you fail the "end hdash fruit"
:3

scarlet rose
1. Trigger hyperdash
2. Change direction before hyperdash ends while holding dash key
3. Ryuuta moves in the opposite direction at hyperdash speed (should be normal dash speed)
I find the "change direction" hyperdash speed to be correct. You shouldn't be changing direction until it ends :P.

peppy wrote: 73101g

I find the "change direction" hyperdash speed to be correct. You shouldn't be changing direction until it ends :P.
It seems that hyperdash exits ~4ms before accurate timing now (~22ms before, with an additional 1-frame slowdown), which could make it harder to control on exiting. If you stop moving or change direction a bit earlier, the catcher could be quite far away. I'm not quite sure about the outcome of such changes though, let's see how pro ctb players feel about the change :P

Another bug is that when you miss the target fruit of a hyperdash, the graphics is stuck in hyperdash mode (red catcher, dimmed background).

Red: change direction 10ms early
Green: change direction at the accurate timing
Blue: change direction 10ms late
Not to the scale

statementreply wrote: 232z60

It seems that hyperdash exits ~4ms before accurate timing now (~22ms before, with an additional 1-frame slowdown), which could make it harder to control on exiting. If you stop moving or change direction a bit earlier, the catcher could be quite far away. I'm not quite sure about the outcome of such changes though, let's see how pro ctb players feel about the change :P
It's quite tricky to handle the ryuuta now, specially in over-HDashed songs, where you now need to do a lot of fine movements to control those HDashes. The only song I can think that could be benefited with this new movement algorythm is Cirno's Perfect Math Class, imo...
From my quick tests, hyperdash spawning is now just about perfect, and droplets are even catchable due to the "tighter" hyperdash controls.

However, it's become much harder to actually hit hyperdashes because of this, and I probably speak for most of the CTB community when I say that they'd rather have FC-able maps with the old hyperdash controlling than SS-able maps with the much tighter, harder controlling. Maybe you should save a better droplet solution for a future patch. Perhaps adjust droplet location only on sliders that are hypered to fall into the natural hyperdash range? Not high priority though.

statementreply wrote: 232z60

lineqtxz wrote: 1y59p

somethimes the catcher is crazy,
this bug appears when you fail the "end hdash fruit"
:3

scarlet rose
1. Trigger hyperdash
2. Change direction before hyperdash ends while holding dash key
3. Ryuuta moves in the opposite direction at hyperdash speed (should be normal dash speed)

peppy wrote: 73101g

I find the "change direction" hyperdash speed to be correct. You shouldn't be changing direction until it ends :P.
I think I got it wrong. It's definitely a bug.
1. Catch the starting fruit of a hyperdash (but do not complete the hyperdash)
2. Try moving ryuuta around
Now ryuuta keeps at hyperdash speed until he moves onto the position (x) of the target fruit of that hyperdash.
Topic Starter
good to see that I'm doing nothing here and it's my post lol good job guys and peppy :3/
Well, to be fair, I edited your post after a few pages xD


In other news, peppy, statementreply, Deif and I have been discovering bugs in and ironing out the hyperdash on the test server the last couple of days. There's still a couple of minor bugs, (which will probably get their own threads) and hyperdashes are a bit tighter now to make up for formula changes, but all maps should now be FC-able and probably even SS-able. The changes are virtually done, so expect the patch to go public soon.
A huge thanks to you guys for the timely testing. This is one of those bugs that I have trouble fixing alone because I don't have the skill or knowledge of these edge cases. Hopefuly the fix was worth the hours put into it.
Finally that's out of the way. Achievement Get
So it's getting better and better really good
Peppy so when is the release expectation day? Still needs like a month?
If so then I'll also help you when I get er in a near future

MillhioreF wrote: 2k1855

From my quick tests, hyperdash spawning is now just about perfect, and droplets are even catchable due to the "tighter" hyperdash controls.

However, it's become much harder to actually hit hyperdashes because of this, and I probably speak for most of the CTB community when I say that they'd rather have FC-able maps with the old hyperdash controlling than SS-able maps with the much tighter, harder controlling. Maybe you should save a better droplet solution for a future patch. Perhaps adjust droplet location only on sliders that are hypered to fall into the natural hyperdash range? Not high priority though.
Most experienced people will find the change to be very hard to adapt to, since it would seem like all the luck you needed to hit the pixels was transferred to the hyperdash controlling thing. I mean, now if I go and try some TAG4, only chance will tell if I'll be able to have total control of the Ryuuta when it's in hyperdash status so no, this is a regressive change and I suggest to fix the speed of these special fruits back to their normal state.

Basically I tried to hit my directional keys <- / -> the same way I did with some TAG4 like http://osu-ppy-sh.tvgratuite.org/b/58064?m=2 and it was a total failure compared to the old hyperdash controlling state. If you want to improve the skill spectrum of CtB, you're doing it the wrong way.

P/D: I totally agree in fixing the Hyperdash-not-always-spawning bug, but try to do just that and not change other gameplay aspects of the game.

Sorry for my grammatic mistakes.

VelperK wrote: 442m2f

Most experienced people will find the change to be very hard to adapt to, since it would seem like all the luck you needed to hit the pixels was transferred to the hyperdash controlling thing.
No, just no. It wasn't as much hard as you're predicting (for me) in 99.9% of the songs. I've been testing different TAG4 difficulties, as it seems to be your major preocupation, and these are the results (disregard NoFail and multiply all the scores by 2):


Comparing to my average scores in those songs, I must it those are only normal tries and not spectacular scores (I didn't pretend to do OMGWTFBBQ records anyway). That means the gameplay in those songs has not (or maybe slightly) changed with the last changes. StrangeProgram is probably the most benefited song of those, as there were a lot of speedy sliders that used to be impossible before.

I encourage experienced players to go into the test build and help to develop this new HDash system, instead of complaining and not offering any constructive solution.

Deif wrote: 4o495

VelperK wrote: 442m2f

Most experienced people will find the change to be very hard to adapt to, since it would seem like all the luck you needed to hit the pixels was transferred to the hyperdash controlling thing.
No, just no. It wasn't as much hard as you're predicting (for me) in 99.9% of the songs. I've been testing different TAG4 difficulties, as it seems to be your major preocupation, and these are the results (disregard NoFail and multiply all the scores by 2):


Comparing to my average scores in those songs, I must it those are only normal tries and not spectacular scores (I didn't pretend to do OMGWTFBBQ records anyway). That means the gameplay in those songs has not (or maybe slightly) changed with the last changes. StrangeProgram is probably the most benefited song of those, as there were a lot of speedy sliders that used to be impossible before.

I encourage experienced players to go into the test build and help to develop this new HDash system, instead of complaining and not offering any constructive solution.
And I encourage you to try this map 5 times in both osu! builds (the public and the private): http://osu-ppy-sh.tvgratuite.org/b/74845

Please, do post the results of each osu! build and then say the same.

VelperK wrote: 442m2f

And I encourage you to try this map 5 times in both osu! builds (the public and the private): http://osu-ppy-sh.tvgratuite.org/b/74845

Please, do post the results of each osu! build and then say the same.
Tried it with the original AR in both versions. Just 1 try was necessary:


Same accuracy, and 2 misses of difference. The test build fixes some pixel-jumps the original map has but on the other hand, the sudden direction changes are harder now.

Nevertheless, that's not a very good example, as it's not even following the criteria of rankability in CTB maps.
Also note that the post of mine Velper quoted was a fairly old post. Since that one, peppy made an update to make the new hyperdashes smoother (they were totally unplayable at the time)
peppy's response is most likely going to resemble this "Deal with it!"
Topic Starter
what about keep the change of the hyperdashes only for between-sliders jumps, and restore the old hyperdashes for everyting else?

eldnl wrote: 2g1ve

what about keep the change of the hyperdashes only for between-sliders jumps, and restore the old hyperdashes for everyting else?
^This.
(Sorry I couldn't connect these days to test. /mylife)

Uh. I still can find extra unrequired hypers.
For example : http://osu-ppy-sh.tvgratuite.org/s/40071 [Posthumous] @ 01:31:959 (2) -

I don't really like the new behavior of the hyperdashes... I think i'll have to rethink many of my patterns in quite all my maps, I used them to make huge jumps wich don't require an accurate timing, the update about this point is basically the oposite of how I see an hyperdash and how I use them in mapping.
There are still some remaining hypers, yes, but it sounds like they'll be fixed in a later release:

test build IRC wrote: 582k1x

[21:33] <@peppy> i'm not calculating back 2 objects
[21:33] <@peppy> to see last turn direction
[21:33] <@peppy> but it gets complicated here
[21:33] <@peppy> it 2 objects back was a hyperdash
[21:33] <@peppy> the hyperdash will end centered
[21:34] <@peppy> which would mean you need this hyperfruit
[21:34] <@peppy> not sure if worth fixing
I should probably unresolve this thread and just move it to low priority. The extra fruits here shouldn't break anything, just make some jumps slightly easier.
From dev blog :



I thought that was the point of the update. I can understand some extra hypers, but the new hyper behavior isn't kinda modifying a lot the difficulty of the maps ? I don't want to taunt or something... I hope my attitude isn't going to be missinterpreted.
found unnecessary hyperdash
http://osu-ppy-sh.tvgratuite.org/p/beatmap?b=131891&m=2
Anyway I can't adapt character's movement in test build, too smooth XD
Is this situation also kinda patch or just some error? While eating hyperdash, character moves slowly than the original server so I can't even fc some easy insane maps.
This thread should be untagged as "resolved" and put back into the Confirmed: Low Priority section.
Yeah, it probably should, because of that remaining edge-case.
This is going live with current test build unless there are any complaints in this thread. If you do have a complaint, please cite examples using isolated cases in .osu files (see Millhiore's previous posts) else tehy will be ignored.
The problem here is a bit broader than what you think, since literally all hyperdashes are affected by this change we cannot give you "an isolated case" like you want so you can code something else, all we can do is tell you that the ryuuta is a lot more hard to control than in the public build now when in hyperdash status (and it was hard enough in the public one) so yeah, most experienced people will complain and you will not be able to understand because you are not an experienced player, or even a CtB player.

So go ahead, unleash the unrest in the people and continue with your "Deal with it" attitude, as always.
That issue is unrelated to hyperdash spawns and has already been deemed invalid.
He said we could discuss that topic here as well.
If you want, show us an isolated pattern that is nearly impossible to play with the new ryuuta movement. You say you can't, but you can.
I can show you my results on a map full of hyperdashes in both the test build and the public build if you want, so you can see how harder it is.
Most of the map does not matter. It is already known that it's harder. You need to prove that it's an issue that its harder. There needs to be some case where it severely affects one's ability to play. Just because you haven't adjusted to the new movement is no indication that it's a problem.

TheVileOne wrote: p102h

Most of the map does not matter. It is already known that it's harder. You need to prove that it's an issue that its harder. There needs to be some case where it severely affects one's ability to play. Just because you haven't adjusted to the new movement is no indication that it's a problem.
I urge you to actually get ON the game and watch me play and telling you specifically what affects my ability.
That will not solve anything. I am not the one you need to convince. You heard peppy, you must provide a .osu or you will be ignored. i'm just instructing you how you need to go about getting your opinion heard. This is going live before anything will be changed so it's pointless to continue on with this CTB community will complain about it argument. If they will complain, it will be an inevitable conclusion.

But until then you'll need more concrete proof. Show us a pattern that's exceptionally difficult to that was quite trivial previously. If you cannot do such things, then you will not be able to get past peppy's opinion in your thread about the old behaviour being an ultimately buggy approach to hypering. I'm leaning on peppy's side after he said that, because if the old hyper code was preventing me from making it to a fruit, because it was cutting hyper too short, then it is in my benefit that it aims towards the center of the hyper now.

I haven't spend very much time at all with the new hypers with the way of linking, but I don't see it as being harmful if it goes live. Because we wont know what the community will think unless they actually have to deal with it. So until then, either show that it's an issue or be patient and see if your theorized backlash happens.


Is there some form of qualification to be considered a CTB player?


Edit: Okay. I understand the complaints now and I would agree with those complaints. This may restricts certain songs to an even more skilled player base when previously these songs would have been able. Because there's a tendency that if you miss one hyper you're going to miss all the hypers after that, and there's lots of internal ms counting that needs to go on where players need to keep in mind how long they need to hold the press before returning back. If they are off, then they come up short. However this change isn't that noticeable.

It would be more enjoyable if it were like the old behavior, but I could get used to it like this, especially with some practice. But the harder the difficulties get, the harder it is to catch them. It would be nice to be able to overshoot the plate by some amount to avoid completely missing it. I feel indifferent.


I cannot tell the difference really. If I could hit the hyper before the update, I can still hit it, and if I couldn't hit it, I still can't.

TheVileOne wrote: p102h

If you want, show us an isolated pattern that is nearly impossible to play with the new ryuuta movement. You say you can't, but you can.
For the hardest ones : All 1/4 hyperdashes, and more than 2 consecutive hypers @1/2 changing direction like this. Does this really require a .osu to understand ?

All others hypers are dizzy and make the players feels he's going too far, even after testing it for a good amount of time I still have this impression of going too far and this breaks a lot the reading/design of the maps.

Btw I read that we have a similar amount of time to catch them than a 300 in std. But in std they don't break their combo for getting a 50 or a 100 plus if they have a 100 on the first circle they can allways get a 300 on the second circle. In CtB if you're late for a first fruit sometimes you'll not be able to catch the next one (I'm not saying that this is an issue, I just compare the two gamemodes, and explain that the two gamemodes are really different in term of gameplay).
My agreement is slowly fading away.

Hyper linking at 161 bpm seems only marginally different. I'm playing with a Dance number and i'm hitting the hypers just fine. There's no noticable sense that it's harder to hit them. I realize though that it changes with the OD, so maybe the song's I'm picking aren't ridiculous enough to matter.
I've done some testing too, and with the most recent test build update, hypers don't seem HARDER per se, maybe just slightly harder. But they're definitely somewhat different to control, which is probably why people are complaining - they're different. I'm fairly confident that if the pros play with the new hyperdashes for just one week, they'll be almost as good as they were with the old hyperdashes, maybe equally good.

(Note that there was another formula tweak about 20 hours ago from this post, so disregard anything from before then for the sake of what I'm saying)
Ruin CtB's hyperdashes already and get the build public at once for god's sake.
bump.

this difficulty has no need of any hyperdashes at all, but the test build added a lot of them to it, thus ruining the creator's intention of giving the player a challenge for only dashing.

diff: http://puu.sh/1NPS6 - "Lemon tree (non-hyper dash)"

and those jumps that were replaced with hyperdashes are not that hard to begin with, see how important it is to fix this kind of stuff before making it go live? it could be exploited as hell and then fixed, and there we will have people complaining on how their records got stolen with some bug that was fixed one week later.
Your attitude is really wrong. If you posted without that whole last paragraph, it would actually be a productive post. I will look into the map and show why the hyperdashes have been added. It is likely they will stay where they are though.
I checked every case in this map, and they are all edge cases which would be catable on approximately 30% of PCs, based on random luck. Maps made like this will need to be unranked and re-made if they wish to avoid hyperdashes, because they are not cachable in 100% of cases and this patch is made to fix that.
This patch is made for getting CtB easier in other words.
People who play competively and focus on getting nice records will most certainly get a decent PC to be at the pair of the rest and try to train the maps in the difficulty they were just made, while people who play for fun or the "casual" players will just not care/notice about this.

By the way, It'd be nice if you explained what kind of PC is unable to catch some jumps of that map which were hyper'd in the test build.
There are certain jumps i can't catch, because they require 150 FPS to barely catch them and 160+ to catch them normally and I only get 140. These special cases likely require more frames than that.
I completely disagree with that statement, in fact, it is so wrong that some people exploit the 60fps limiter to catch pixel jumps (ExGon for example told me he changes to 60fps in some spot of a map just to be able to catch a fruit which didn't enable him to FC it)

Btw, you can come online and watch me play that map in the public build with the 120fps limiter if you want.
60 FPS is unplayable on CTB.

It may be some aspect of my PC that's related to how much FPS I get, but it's definitely related to how fast I can move the ryuuta. The less frames I get, the slower the ryuuta moves. That's just how it is in my case.

TheVileOne wrote: p102h

There are certain jumps i can't catch, because they require 150 FPS to barely catch them and 160+ to catch them normally and I only get 140. These special cases likely require more frames than that.
I hope you mean before the patch. If not, please provide examples.
Eh it's actually possible. I tried on test build. I rescind my complaint, but I am interested in how only a certain number of machines can catch fruit.
The new patch is made to resolve that. In the public build, timings were incorrect. You can check my blog post for the specifics.
hello I played ctb for 2 years and I totally this fix thank you
Topic Starter

GuruK wrote: 4h2v2b

hello I played ctb for 2 years and I totally this fix thank you
Completely unnecesary hyperdash here:



Isolated osu. here: http://puu.sh/1Omap

VelperK wrote: 442m2f

Completely unnecesary hyperdash here:



Isolated osu. here: http://puu.sh/1Omap
I didn't really understand why Big Black streams are hyper dashed now .-.
Topic Starter
It is fixed now?
No, and i'll ask peppy to go further with his last change to the dash behaviour in hyperdash status since it's almost fixed, though it still sucks a bit.
Last Remnant_old
Here is one case of unnecessary hyperdash:



As we can see, the jump between fruit 4 and fruit 5 is catchable (there is no hyper on fruit 4). The jump between fruit 1 and 3 is equally spaced both in position and time as jump 4-5, which means that hyperfruit on fruit 2 shouldn't be there (jumps 1-3 and 4-5 are both equal and catchable without need for hypers anywhere).

PS. Here are elements I used:

0,0,500,1,0,
256,0,732,1,0,
512,0,964,1,0,
512,0,1200,1,0,
0,0,1664,1,0,
Please sign in to reply.

New reply 3p1g1j