currently a bunch of default hitsounds and skin elements are technically unrankable in the current ranking criteria, which has been causing a lot of confusion among mappers/bn's/qah/whatever when people use these files in their mapsets. we've just been allowing them to be ranked for obvious reasons, but it would be really nice to have these files compiled somewhere and added as an official exemption to the rc. this would ensure we have a standard for all default files, and that there is never any confusion in bn work stuffs
forum
[Proposal?] Ensure default files are rankable
posted
Total Posts
13
Topic Starter
agree
Agree.
And I guess one aspect of this might be for that 5ms delay hitsound issue? Another possible solution is to fix the default files instead (though it is a bit beyond ranking criteria discussion) otherwise it seems a bit weird to treat hitsounds with inequity, anyway.
Also I do think if mappers use default hitsounds as custom hitsounds, then they should be evaluated under the RC frame or it might require additional scheme to evaluate if such custom hitsounds (or files) are for real default ones, which could be somewhat needlessly tiresome (my opinion tho).
And I guess one aspect of this might be for that 5ms delay hitsound issue? Another possible solution is to fix the default files instead (though it is a bit beyond ranking criteria discussion) otherwise it seems a bit weird to treat hitsounds with inequity, anyway.
Also I do think if mappers use default hitsounds as custom hitsounds, then they should be evaluated under the RC frame or it might require additional scheme to evaluate if such custom hitsounds (or files) are for real default ones, which could be somewhat needlessly tiresome (my opinion tho).
agree
agree with this, actually having it written down somewhere for clarity would make sense
it's basically what we've been doing anyway, like not dq'ing maps for using the default normal-finish as a custom hs, even though it technically has >5ms delay
could just add something like "if custom elements are part of the default set these criteria (delay for hs, dimensions for skin elements, ...) don't apply"
it's basically what we've been doing anyway, like not dq'ing maps for using the default normal-finish as a custom hs, even though it technically has >5ms delay
could just add something like "if custom elements are part of the default set these criteria (delay for hs, dimensions for skin elements, ...) don't apply"
+1
I agree with making the default files rankable, however I feel that their use should still be discouraged due to the problems that would otherwise make them unrankable ( such as the default soft-hitnormal having about 10ms of delay providing misleading feedback ).
There are also plenty of fixed versions used by mappers ( for example, this version of the default soft-hitnormal with close to no delay ), so why not gather these fixed versions and provide a link to them in the rc ?
Phrasing would end up being something like " [lasse's sentence], however their use is discouraged ; files from [thread or something containing rankable versions] should be used instead. "
There are also plenty of fixed versions used by mappers ( for example, this version of the default soft-hitnormal with close to no delay ), so why not gather these fixed versions and provide a link to them in the rc ?
Phrasing would end up being something like " [lasse's sentence], however their use is discouraged ; files from [thread or something containing rankable versions] should be used instead. "
agree with regraz
what we need to do is not saying "uh even we have a hitsound with >5ms delay but it's a default one so fine" cuz a >5ms delay on any hitsound will influence the playing experience
would be good if we just get delayed default hitsounds fixed
what we need to do is not saying "uh even we have a hitsound with >5ms delay but it's a default one so fine" cuz a >5ms delay on any hitsound will influence the playing experience
would be good if we just get delayed default hitsounds fixed
I agree that it would be better for the default samples to be fixed but that's outside of our scope in RC discussion. Would have be to directly brought up to the devs.
which files are messed up currently?
Topic Starter
apparently these ones:
- particle50.png (file too large)
- particle100.png (file too large)
- particle300.png (file too large)
- approachcircle.png (file too large)
- hitcircleoverlay.png (circle too large)
- sliderstartcircleoverlay.png (circle too large)
- sliderendcircleoverlay.png (circle too large)
- sliderfollowcircle.png (file too large)
- taikobigcircleoverlay.png (file too large)
- taikohitcircleoverlay.png (file too large)
- fruit-catcher-fail.png (plate too large and not centred)
- fruit-catcher-idle.png (plate too large and not centred)
- fruit-catcher-kiai.png (plate too large and not centred)
- normal-hitfinish.wav (delayed)
- soft-hitwhistle.wav...maybe? it's not true delay but its active part is still past the 5ms cutoff from what i can tell..
this should be addressed by this commit to by saying that it cannot exceed dimensions where things start overlapping that wouldnt normally overlap https://github.com/ppy/osu-wiki/pull/1471/commits/ba56bb11df27448d868a98d9e89c8f4ef9a0d417
changes may need up to 6 hours to go live
changes may need up to 6 hours to go live