I have fixed the issues with HT/DT, and pushed out a new test build. I would like people to test this on the test server before making it live to ensure I haven't broken everything, if at all possible.
This is a different bug where if there's a droplet in between two slider ends, it doesn't get hyperdashed. Nothing to do with reverse arrows.VelperK wrote:
Also, you should take a look at this one:
http://osu.ppy.sh/p/beatmap?b=27737&m=2
This is somewhat different, we're talking about a reverse slider, not 3 circles.
There are some jumps that are possible, but there are some that not, like the short map above, even with this trick is impossible.peppy wrote:
At a code level, the above should still be possible (though hard), which is why I'm asking for a specific test beatmap to be created so I can check.
peppy wrote:
At a code level, the above should still be possible (though hard), which is why I'm asking for a specific test beatmap to be created so I can check.
osu file format v9
[General]
AudioFilename: tutorial.ogg
AudioLeadIn: 0
PreviewTime: -1
Countdown: 0
SampleSet: Normal
StackLeniency: 0.7
Mode: 2
LetterboxInBreaks: 1
[Editor]
DistanceSpacing: 1
BeatDivisor: 4
GridSize: 32
[Metadata]
Title:osu! tutorial
Artist:Peter Lambert
Creator:peppy
Version:CTB Test
Source:
Tags:
[Difficulty]
HPDrainRate:7
CircleSize:5
OverallDifficulty:7
ApproachRate:7
SliderMultiplier:2.56
SliderTickRate:4
[Events]
//Background and Video events
//Break Periods
//Storyboard Layer 0 (Background)
//Storyboard Layer 1 (Fail)
//Storyboard Layer 2 (Pass)
//Storyboard Layer 3 (Foreground)
//Storyboard Sound Samples
//Background Colour Transformations
3,100,163,162,255
[TimingPoints]
255,374.123148869836,4,1,0,100,1,0
4650,-50,4,1,0,100,0,0
[HitObjects]
112,192,1751,1,0
256,192,1845,1,0
400,192,1938,1,0
496,192,3247,5,0
256,192,3435,1,0
16,192,3622,1,0
0,192,4744,6,0,B|512:192,1,512
OMGeldnl wrote:
There are some jumps that are possible, but there are some that not, like the short map above, even with this trick is impossible.peppy wrote:
At a code level, the above should still be possible (though hard), which is why I'm asking for a specific test beatmap to be created so I can check.
I think the DT bug was succesfully resolved IMHO, I tried different maps and they all play very well! But I don't have problems with waiting a bit longer either, in case there is a little glitch or somethingpeppy wrote:
I am going to leave this second issue until the first has been made public and confirmed as resolved, as I'd rather not create problems on top of problems.
We should create another thread for the other bugs?peppy wrote:
DT is fixed and will go live soon. I'm talking about the other yet-to-be-confirmed bug mentioned in the last few posts.
eldnl wrote:
There are two problems with hyperdashes and doubletime ...
- First off, when a song have hyperdashes without mods, some of them dissapear when you play with doubletime, and most of them are uncatchable.
- In a second place we have the hyperdashes even when you play with dt, most of them are uncatchable too.
I have an example, please play this map with doubletime: http://puu.sh/13QUy
As you can see the first jump doesn't have hyperdash and is perfectly catchable, in the second jump we had an hyperdash which dissapeared with the doubletime, but it is still catchable; the third jump had an hyperdash too, but it isn't catchable with doubletime, and in the last jump we have an hyperdash even with dt, which is impossible to catch ...
discuss please.
nope, that shit about miliseconds or frames or whatever does not exist, that jump is practically uncatchable with 120fps or more because the catcher stops in the next fruit, and because of that the next fruit is uncatchable. . . when you play with 60fps the catcher doesn't stop in the next fruit and keep going to the other fruit, not sure if you can understand this xDMillhioreF wrote:
Yes, exactly. It was already possible, but you have to be pixel perfect - apparently playing with 60 FPS gives you a few milliseconds of leeway.
nope ://MillhioreF wrote:
Oh, so you did do the jump with 60 fps... that explains it then! 60 fps makes pixeljumps catchable after all...
Does double time count? You do get a high velocity than normal.MillhioreF wrote:
It's been confirmed that this map's jump is sometimes catchable due to some weird song start lag... Supposedly it wouldn't happen if you placed the notes ~5 seconds after the song starts, but I haven't tested that.
EDIT: also hardrock makes hyperdashes appear, so it doesn't count
that's why it doesn't count eitherManchineel wrote:
Does double time count? You do get a high velocity than normal.MillhioreF wrote:
It's been confirmed that this map's jump is sometimes catchable due to some weird song start lag... Supposedly it wouldn't happen if you placed the notes ~5 seconds after the song starts, but I haven't tested that.
EDIT: also hardrock makes hyperdashes appear, so it doesn't count
that's why it doesn't count eitherThen we have a solution! use Hardrock or double time for the problem.
you retrograd person, stop trolling these kind of threads and gtfo.Manchineel wrote:
that's why it doesn't count eitherThen we have a solution! use Hardrock or double time for the problem.
More score, more people happy. Also you'll gain more skill this way!
Genius.
60fps is not faster, there is something different with the hyperdash I think.Seph wrote:
actually running on vsync 60fps makes my ryuuta move faster than it should be (or its just me) but i tried doing it on some pixel jump and i apparently caught that pixel jump on rainbow tylenol when i pause and switched from unlimited to 60fps. though playing on it makes ryuuta control hard as fuck
Thank you.MillhioreF wrote:
Speaking of which, the doubletime bug was resolved long ago, so I'll change the topic name (unless someone objects)
What about XAT trying to mod CtB diff wich can't even determine if the maps are FCable ?TheVileOne wrote:
Fixing this would only please a small group of players, while gamewide bugs/ bugs affecting wider ranges of people take higher priority.
Regarding this: Even with the hyper-droplets, they seem to be a bit unstable and those sliders are very hard to catch. Can someone confirm this?Drafura wrote:
http://osu.ppy.sh/p/beatmap?b=27737&m=2
00:45:257 (1,1,1) - Kinda same problem some elements of sliders seems to trigger the hyper showed in the fruit and some not.
I'm most worried about getting huge limitation in term non hyper jump difficulty for ctb mapping than for converted maps. Non hyperdashed jumps are part of CtB, think about Zhsteven's maps, he don't use that many hyperdashes, and it is the intetended behavior he wanted while mapping.Deif wrote:
That means it's a pretty well memorised map. I'm quite sure somebody who hasn't played it so much won't be able to do a nice performance there. It's challenging enough even with the new HDashes in my opinion, but I'm pretty sure most pros will rage about the "simplicity" of such a popular map.
I'm thinking that this would also help find out cheaters, to some degree. People would take advantage of this limitation and cheat their catcher with some boosted speed.peppy wrote:
I also added an alert when watching a replay which moves faster than humanely possible, which only displays on the test build. Might be handy for checking any replays you think may not be legit, and pointing them out to me in a PM for confirmation.
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.TheVileOne wrote:
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.
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;
}
MillhioreF wrote:
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.)
The second fruit absolutely needs hyperdash while the first doesn't really require that (getting hyperdash on both fruits makes sense though).MillhioreF wrote:
-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.
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.statementreply wrote:
The second fruit absolutely needs hyperdash while the first doesn't really require that (getting hyperdash on both fruits makes sense though).