I'm glad to see this is being reconsidered, though I'd like to say myself that something shouldn't be considered bad just of how visually appealing it may be. I also don't believe low SV hinders gameplay or is any more annoying than regular reading. The notes are on the screen far longer when SV is low so you have more time to read what the patterning is which makes up for the difficulty of reading close density where overlap is over 50%.Raiden wrote:
That level of overlapping may be a challenge for some players but for me (and many others) is just plainly annoying and hinders gameplay experience a lot (not to mention it looks aesthetically horrible). Imagine having clutters of unreadable notes in standard, or an infinite amount of teleporting notes on o!mania (I know I should not compare to other game modes, but it is just to give an example).
Regardless, we will surely reconsider the 50% overlap rule during revision depending on what further feedback we get.
forum
[Proposal] Taiko ruleset draft (General)
posted
Total Posts
70
Right, well I'm trying to get at what sorts of justifications should be permissible. Mere intensity/loudness, to my mind, should NOT be ample reason to break the guideline for ninjas (c.f. my second-to-last paragraph).Raiden wrote:
Avoid using smooth SV changes which include variable snapping and keep the variation low enough to avoid overlaps. This is to ensure proper readability of the notes and their snappings.Not sure if you read through this guideline but it pretty much includes everything from ninja notes to turtle notes. (maybe it needs some reword to be easier to understand)
As long as you have enough justification to use the ninja notes, you can break the guideline. I think there is no need for further regulations regarding this.
Topic Starter
The limits of rankability of controversial stuff (which we cannot really cover subjectively as a rule) will be on the nominators' judgement (and ultimately, the QAT).
As someome relatively external to Taiko, in no way this guideline covers all the cases you mentioned. It covers one really specific sitiation (smooth SV changes with variable snappings) and then provides the reason for that (ensure readability). While I understand that the reason also applies for other situations such as ninja spinners, the guideline itself doesn't mention them nor imply them. You need to rewrite the rule if you want it to cover more cases (maybe something along the line of "Avoid using SV changes in a way that's detrimental to readability such as ninja notes, smooth SV changes with variable snapping and turtle notes") or o explicitly cover the other cases as additional guidelines.Raiden wrote:
Avoid using smooth SV changes which include variable snapping and keep the variation low enough to avoid overlaps. This is to ensure proper readability of the notes and their snappings.Not sure if you read through this guideline but it pretty much includes everything from ninja notes to turtle notes. (maybe it needs some reword to be easier to understand)
As long as you have enough justification to use the ninja notes, you can break the guideline. I think there is no need for further regulations regarding this.
The "Omit first bar line" feature of an uninherited timing point must be used when a BPM change <First case>/ Metronome reset would hinder gameplay experience aesthetically by adding unnecessary bar lines. <Second case>I would like to elaborate the above rule a bit.
Some bar lines should be kept in case of the bpm changes indicating a delay on some notes.
Here's an example: (Source: https://osu.ppy.sh/b/1107717 I am not self-promoting )
You can see that there are a couple of RED timing points. Only
03:46:647 -
03:49:606 -
03:52:565 -
these 3 points uncheck "Omit first bar line" (that means the bar lines of them are kept).
IF based on the potential rule of "Omit first bar line", the above points should have their bar lines removed (since they have BPM changes), but that is NOT the case.
Bar lines ought to be kept to show 'bar divisions' clearly even though there are various BPM, when it comes to just a part of delay within a main bar division. I think it should be a part of RULE because the uses of bar lines actually represent the use of timings, in terms of rhythm division. Mappers should have a clear mind on how to use bar lines appropriately.
The unnecessary red timing point should be put on the metronome original BPM/timing. <-- clarify it a bit
Please refer to the photo of timing again. The base bpm of that screened session is actually 81.5 (where is 03:46:647 - ).
Some green timing points are added to make the Effective SV become more comfortable to read. They are adjusted to fitting the Effective SV of BPM=81.5.
E.g.: BPM of 03:48:119 - 80.25*1.02=81.855~81.5
> The extra multiplier is calculated by this formula: Base BPM (the BPM which the music follows concretely, not the delay/accel. one) / Delay(accel.) BPM
Green timing points should be used appropriately to make the Effective SV of notes become comfy for reading when there is BPM variation within a main bar division.
Topic Starter
I responded to ZiRoX in PM (it does include all edge cases as both turtle and ninja notes cause overlaps)
And Skylish: the rule clearly says "when it would hinder gameplay aesthetically by adding unnecessary bar lines". If the bar lines are not unnecessary... why would you need to omit them?
Regarding second case, guideline 1 applies.
Edit: actually, I think we will need extra rewording on that guideline. Thank you for your feedback
And Skylish: the rule clearly says "when it would hinder gameplay aesthetically by adding unnecessary bar lines". If the bar lines are not unnecessary... why would you need to omit them?
Regarding second case, guideline 1 applies.
Edit: actually, I think we will need extra rewording on that guideline. Thank you for your feedback
Topic Starter
Closing for revision of round 1.
Thanks everyone for your feedback. Expect some weeks for this to come back!
Thanks everyone for your feedback. Expect some weeks for this to come back!
unlocked thread, updated the first post with the results of discussing the concerns in the ubkrc
Raiden's gonna post a summary
Raiden's gonna post a summary
Topic Starter
Hello! We're back for Round 2.
List of changes:
We felt some of the overlap/sv change guidelines were incomplete, so to compliment the new Rule 1 (more ahead), we made 3 new guidelines.
Addition to guidelines/new guidelines
Additions to Glossary
This guideline definitely needed some rewording.
Rewordings
Seeing the feedback on rule 1, we decided to scrap it completely.
Rule changes
Round 2 is officially open for feedback! Will be closed again on Sunday, 19th of March for revision.
List of changes:
We felt some of the overlap/sv change guidelines were incomplete, so to compliment the new Rule 1 (more ahead), we made 3 new guidelines.
- Avoid rhythms which are in no way predictable. Rhythm can be made intuitive through the usage of consistent timeline gaps bridging between different snappings or rest moments.
- Avoid abrupt slider velocity changes within patterns that already overlap (e.g. 1/4 streams). Smooth slider velocity changes should be used in these cases to ensure that the patterns stay readable.
- Substantial overlapping should be avoided so that the color of each note is still readily readable and does not pose unnecessary visual disturbance. Overlapping should only be done if the song's pacing or note snapping at that point could justify it.
- Variable Snapping: A combination of multiple different ways to snap notes within a short span of time due to the song’s fluctuating nature at that point.
- Rest moment: A period of time without notes used specifically to allow the player to rest their hands and prepare for the upcoming patterns.
This guideline definitely needed some rewording.
- A
void using smooth SV changes which include variable snapping and keep the variation low enough to avoid overlaps. This is to ensure proper readability of the notes and their snappings-> Avoid using smooth Slider Velocity changes over sections which include variable snapping. Doing so impacts the readability of these snappings, so keep the variation low enough to avoid overlapping. - Glossary:
Speedup/Slowdown-> Smooth Slider Velocity changes
Seeing the feedback on rule 1, we decided to scrap it completely.
A note must not overlap more than 50% of the upcoming note(s)-> Each note must have its color clearly distinguishable from the previous and upcoming notes.
Round 2 is officially open for feedback! Will be closed again on Sunday, 19th of March for revision.
How about a guideline to avoid making the map too repetitive when something else could be done?
I mean i'm pretty sure we can all agree that noone wants to see a map that spams the exact same rythm with the exact same pattern for 8 measures because the song stays the same.
I mean i'm pretty sure we can all agree that noone wants to see a map that spams the exact same rythm with the exact same pattern for 8 measures because the song stays the same.
partially disagree: this gives room for even less consistent mapping. sometimes if a song doesn't need a drastic change the correct solution is to avoid making it change too muchChromoxx wrote:
How about a guideline to avoid making the map too repetitive when something else could be done?
I mean i'm pretty sure we can all agree that noone wants to see a map that spams the exact same rythm with the exact same pattern for 8 measures because the song stays the same.
for lower difficulties, you're better off keeping the pattern similar because such changes will have a greater impact on the map quality and/or difficulty, because the skeleton uses as many anchor points. changing these anchor points for the sake of variety will affect how the difficulties work between each other and how the difficulty itself works within itself. i think new mappers are better off starting simple then adding flavor as experience is gained rather than the other way round.
you don't want to start with drawing a very finely detailed gothic-lolita dress then a more generic one you know
"A note must not overlap more than 50% of the upcoming note(s)" this rule was good 
Each note must have its color clearly distinguishable from the previous and upcoming notes.This is kind of a vague sentence now. To be a rule I think there needs to be a strict definition of being "clearly distinguishable" like how it initially was (the 50% thing). If we cannot define it it should rather be a guideline where we can let people to judge. Some people can read it while 80% is overlapped, and those people would claim that this is not against the "rules". On the other hand some people can't clearly distinguish even when only 50% is overlapped.
I don't think we need to duplicate this in both rules and guidelines.
With extremely fast songs Kantan/Futsuu diffs would try to use less 1/1s and 1/2s than they would do with normal bpm songs, which leads them to contain really small quantity of notes on the playfield with SV 1.40. Also in these diffs I don't think that "optimal distance of separation" has to be 1.40 sv, because they won't include 1/2s or 1/4s anyway.DakeDekaane wrote:
It is completely fair, and it's more recommended to do. If you use a lower SV, more notes will appear on playfield and new players would just get lost.Niko-nyan wrote:
This isn't fair if a new player play like 225 bpm (without DT) and the Slider Velocity is 1.40 for Kantan and Futsuu so make some exceptional for certain BPM requirement.
It's really painful for new players to react at 270bpm 1.4x sv, because that's just a blink of an eye and they have to recognize the color and decide which finger they should move within that short amount of time. If this makes the quantity of notes on the playfield too many, it's probably already a Muzukashii diff.
Kiai time should be only used for the chorus or emphasized parts of a song. Kiai flashes/short kiais are discouraged for several reasons: they disturb the gameplay experience especially on low-end PC users, and can cause trouble for epileptic users.Isn't this related to all game modes? I think it should rather go to General ruleset instead of Taiko ruleset. Finalized CtB and STD rulesets don't contain this too, but we know that overusing kiais causes these problems in any game modes.
idk how people find "you mast be able to see how many notes there are and what color they are" is vague
like what else would clearly distinguishable entail
the kiai part thing is because the immediate effect of it is more score per note btw
like what else would clearly distinguishable entail
the kiai part thing is because the immediate effect of it is more score per note btw
Just like we have a rule of spinner in std "Spinners must be long enough for Auto to achieve 1000 bonus score. Short spinners are unreasonably difficult to complete.", why not for Taiko's overlapping limit? "Short spinners are Unreasonably difficult to complete" is a vague sentence so that's why we made a minimum objective limit of auto gaining at least 1000 bonus score. Imo if this has to stay as a rule more strict definition would be good.
Also if the score multiplication is what matters regarding the use of kiai most, then it should be included in additional explanation too.
Also if the score multiplication is what matters regarding the use of kiai most, then it should be included in additional explanation too.
Topic Starter
How is that vague in any way? It clearly states what it is as a rule, if one cannot see how many notes there are or what color they are, it would be plainly unrankable. The additional guidelines for this are just that, guidelines. This rule is to avoid edge cases.Doyak wrote:
Each note must have its color clearly distinguishable from the previous and upcoming notes.This is kind of a vague sentence now. To be a rule I think there needs to be a strict definition of being "clearly distinguishable" like how it initially was (the 50% thing). If we cannot define it it should rather be a guideline where we can let people to judge. Some people can read it while 80% is overlapped, and those people would claim that this is not against the "rules". On the other hand some people can't clearly distinguish even when only 50% is overlapped.
I don't think we need to duplicate this in both rules and guidelines.Kiai time should be only used for the chorus or emphasized parts of a song. Kiai flashes/short kiais are discouraged for several reasons: they disturb the gameplay experience especially on low-end PC users, and can cause trouble for epileptic users.Isn't this related to all game modes? I think it should rather go to General ruleset instead of Taiko ruleset. Finalized CtB and STD rulesets don't contain this too, but we know that overusing kiais causes these problems in any game modes.
For the kiai guideline, the fountain and shining is way more prominent in taiko than the rest of the modes, hence the use of those is discouraged more in this mode.
No, it is unpractical to make a numerical limit to the overlap rule as no one in their right mind would take a ruler or zoom to count the pixels every time they mod something that seems close to be unreadable. The current rule looks pretty good as it is.Doyak wrote:
Just like we have a rule of spinner in std "Spinners must be long enough for Auto to achieve 1000 bonus score. Short spinners are unreasonably difficult to complete.", why not for Taiko's overlapping limit? "Short spinners are Unreasonably difficult to complete" is a vague sentence so that's why we made a minimum objective limit of auto gaining at least 1000 bonus score. Imo if this has to stay as a rule more strict definition would be good.
Also if the score multiplication is what matters regarding the use of kiai most, then it should be included in additional explanation too.
Also no, from what I know the score multiplication was never even a factor. The only factor that led us for this guideline was visuals: avoiding kiai overusage to better the experience of low-end computer players, as it causes higher load time and can therefore make the system lag.
i'm legit mad if the game loads the texture every single time you trigger a kiai instead of loading it once and displaying it at appropriate timesRaiden wrote:
The only factor that led us for this guideline was visuals: avoiding kiai overusage to better the experience of low-end computer players, as it causes higher load time and can therefore make the system lag.
--
common senseDoyak wrote:
This is kind of a vague sentence now. To be a rule I think there needs to be a strict definition of being "clearly distinguishable" like how it initially was (the 50% thing). If we cannot define it it should rather be a guideline where we can let people to judge. Some people can read it while 80% is overlapped, and those people would claim that this is not against the "rules". On the other hand some people can't clearly distinguish even when only 50% is overlapped.
no one is gonna let a stream pass because someone can read the colors in the pixel-wide crescent of colors available for reading and we're not gonna nazi the shit out anything that overlaps
also reading skill is a skill that exists
A note must not overlap more than 50% of the upcoming note(s)-> Each note must have its color clearly distinguishable from the previous and upcoming notes.
Topic Starter
Every single rule and/or guideline is accounted for Default settings, yes.
Topic Starter
aaaaaaaand closing for round 2 revision
ok since there wasn't much to dispute over this time and the things that raised concern were explained here, i'll go ahead and bubble this draft.
The only exception to this bubble is the glossary as this thing can undergo further changes as we progress with the difficulty specific draft
The only exception to this bubble is the glossary as this thing can undergo further changes as we progress with the difficulty specific draft
Popped bubble to add the few things that we came up during the process of making the specific criteria:
Draft has been ported to over here
summary of changes
rules: no taiko template backgrounds
guidelines: variable bpm songs may normalize scroll speed to a single speed
avoid visually obstructing notes with active spinners + 1/2 gap after spinners
1/2 gap before spinners should be used to avoid overlapping and offbeat starting
Discussion is open until the same day as taiko specific
Draft has been ported to over here
summary of changes
rules: no taiko template backgrounds
guidelines: variable bpm songs may normalize scroll speed to a single speed
avoid visually obstructing notes with active spinners + 1/2 gap after spinners
1/2 gap before spinners should be used to avoid overlapping and offbeat starting
Discussion is open until the same day as taiko specific
So there is a guideline for the base slider velocity, I have two comments on it. I think base slider velocity should be included in the terms, and I think there should be a rule, not a guideline for the maximum and minimum allowed base slider velocities. Like no below 0.8 or 1.0 and no above 1.8 or 2.0. For certain songs 1.2 or lower base slider velocity is warranted, especially in 250 or higher bpm easier difficulties. Also for certain songs 1.6 or higher base slider velocity is warranted, especially in 80 or lower bpm songs.
added "Base slider velocity can be controlled in the timing panel and additional changes can be made through inherited (green) timing points." as osu! has it on their rc for Slider Velocity
Why do you think there should be a rule on base slider velocity? Seems excessive and unnecessary for me and the explanation you provide includes "for certain songs" which hints at "oh there's a fuckton of exceptions"
What good do you think would limiting the base Slider Velocities you can use to make maps bring?
Why do you think there should be a rule on base slider velocity? Seems excessive and unnecessary for me and the explanation you provide includes "for certain songs" which hints at "oh there's a fuckton of exceptions"
What good do you think would limiting the base Slider Velocities you can use to make maps bring?
Same base Slider Velocities are just unreasonable. Like the min and maximum base slider velocities allowed in the editor (0.4 and 3.6) are too excessive for any map.Okorin wrote:
added "Base slider velocity can be controlled in the timing panel and additional changes can be made through inherited (green) timing points." as osu! has it on their rc for Slider Velocity
Why do you think there should be a rule on base slider velocity? Seems excessive and unnecessary for me and the explanation you provide includes "for certain songs" which hints at "oh there's a fuckton of exceptions"
What good do you think would limiting the base Slider Velocities you can use to make maps bring?
Topic Starter
"Unreasonable" is too subjective, therefore → guideline.
It seems guidelines are highly underrated, they are supposed to NOT be broken unless exceptional circumstances are met. Which means most of the times you have to follow them anyway.
It seems guidelines are highly underrated, they are supposed to NOT be broken unless exceptional circumstances are met. Which means most of the times you have to follow them anyway.
Hmm true. You should have valid reasoning for breaking a guideline.Raiden wrote:
"Unreasonable" is too subjective, therefore → guideline.
It seems guidelines are highly underrated, they are supposed to NOT be broken unless exceptional circumstances are met. Which means most of the times you have to follow them anyway.
Topic Starter
While we were discussing some stuff, an issue was brought up: the 1/16 slider extension that is used to "patch" the known missing slider tick bug. Since ppy himself told us not to do this anymore, we are adding it as a rule for the General Taiko draft for the time being. Once the bug is fixed, this rule will no longer be in effect.
Added rule:
edit: it is also known that opening AiMod sometimes causes bugs, so we decided to add a guideline as well. Again, once the bug is fixed, the guideline will be nuked.
Added guideline:
Added rule:
- You must not wrongly snap sliderends to correct missing slider ticks. This behaviour is unintended and will be corrected in the future.
edit: it is also known that opening AiMod sometimes causes bugs, so we decided to add a guideline as well. Again, once the bug is fixed, the guideline will be nuked.
Added guideline:
- Use AiMod with caution. It is known to cause bugs related to base Slider Velocity.
maybe add something like this aswell
[/quote]
- Use AiMod with caution. It is known to cause bugs related to base Slider Velocity. Be sure to check your Slider Velocity in your difficulty's notepad after using AIMod
custom combo colors shouldn't be used ever? add that as a rule? they're pointless.
Topic Starter
@Kin: I do not think that is necessary as it is way too redundant. The statement "it is known to cause bugs related to base Slider Velocity" already compells people to check their base SV in the timing tab when they open AiMod for whatever reason. Checking in the .osu notepad is not compulsory.
@tatatat: why would you want a rule like that? no one ever uses combo colors in taiko - and even if they did, their behavior does not affect the editor nor the playability whatsoever.
@tatatat: why would you want a rule like that? no one ever uses combo colors in taiko - and even if they did, their behavior does not affect the editor nor the playability whatsoever.
Excuse me,
And after I've read this, I think that it's okay for me everything, except the minor one.
If this draft aim to replace the content on osu!taiko-specific Ranking Criteria , so the common word should be add too, for the ease to let the newbie (including me) understand. Like Don/Red Note
And after I've read this, I think that it's okay for me everything, except the minor one.
Maybe "Break Time" should be add here too since the word "Break Time" are more common to used than the word "Rest Moment"Gameplay elements wrote:
Rest Moment/Break Time: A period of time without notes used specifically to allow the player to rest their hands and prepare for the upcoming patterns.
If this draft aim to replace the content on osu!taiko-specific Ranking Criteria , so the common word should be add too, for the ease to let the newbie (including me) understand. Like Don/Red Note
Topic Starter
Break time is used to refer to the actual break time, where there are no notes in the playfield for a considerable amount of time and where the letter of accuracy shows up. So break time is not appropriate since it is not a direct synonym to rest moment in taiko.
In any case, rest moment is actually more common than break time.
In any case, rest moment is actually more common than break time.
Rest Moment=Break≠Break Time
Raiden wrote:
Break time is used to refer to the actual break time, where there are no notes in the playfield for a considerable amount of time and where the letter of accuracy shows up. So break time is not appropriate since it is not a direct synonym to rest moment in taiko.
In any case, rest moment is actually more common than break time.
Seems like I've misunderstand something, it's my bad. uwuNardoxyribonucleic wrote:
Rest Moment=Break≠Break Time
Thanks!
custom combo colors are wasted file space. ehh, its probably not important though.Raiden wrote:
@Kin: I do not think that is necessary as it is way too redundant. The statement "it is known to cause bugs related to base Slider Velocity" already compells people to check their base SV in the timing tab when they open AiMod for whatever reason. Checking in the .osu notepad is not compulsory.
@tatatat: why would you want a rule like that? no one ever uses combo colors in taiko - and even if they did, their behavior does not affect the editor nor the playability whatsoever.
having all combo colors set would be at most 200bytes added to the .osu filesize.tatatat wrote:
custom combo colors are wasted file space. ehh, its probably not important though.Raiden wrote:
@Kin: I do not think that is necessary as it is way too redundant. The statement "it is known to cause bugs related to base Slider Velocity" already compells people to check their base SV in the timing tab when they open AiMod for whatever reason. Checking in the .osu notepad is not compulsory.
@tatatat: why would you want a rule like that? no one ever uses combo colors in taiko - and even if they did, their behavior does not affect the editor nor the playability whatsoever.
it takes one MILLION bytes to make a megabyte.
it would take over five thousand taiko difficulties with all eight custom combo colours set to waste a megabyte of space.
In conclusion, I don't think that's something to worry about.
By default settings in the Edtior, Combo Colours should not be a worry.
I wanna suggest a topic about the usages of sliders and spinners.
> Tick Rate of slider would be 3 in the snappings of 1/3 and so on. Meanwhile, the spinner 'tick rate' is set as 1, in which every 1/4 beat will create a hit in the spinner.
Here's the contradiction, if a spinner is put exactly in 1/3 snappings, the spinner may be incomplete due to unfinished '1/4 snaps'.
For example https://osu.ppy.sh/s/557316 :
> I want to put a spinner in a 2/3 snap, expectedly it should display 4 hits under 1/3 snapping scale.
> However, under the default settings of 'tick rate' of spinner, 2/3 (<3/4) is counted as 2/4, hence displaying only 2 hits.
In general cases, we solve this issue by extending the spinner in purpose to 1/1 for fulfilling the 4-hits feeling. This could be a potential guideline about the usages of sliders and spinners.
Another topic wanna be discussed is the positioning of BG photo.
As of my modding experience, I have seen some mappers, especially rookies, are unfamiliar with the adjustment of BG position for a better visual effect, by editing in the .osu in notepad. Relevant concept and knowledge should be told inside the guidelines as well.
SV leniency is another impt topic. In high BPM (I would define it as BPM>200, or it needs another defination), the base SV of Kantan and Futsuu should be able to be exceptionals of current guidelines. A clearer statement about the leniencies of SVs in lower difficulties should be stated as:
More precised values should also be advised, like Kantan = 1.00x Futsuu 1.20x under BPM=260 etc..
I wanna suggest a topic about the usages of sliders and spinners.
> Tick Rate of slider would be 3 in the snappings of 1/3 and so on. Meanwhile, the spinner 'tick rate' is set as 1, in which every 1/4 beat will create a hit in the spinner.
Here's the contradiction, if a spinner is put exactly in 1/3 snappings, the spinner may be incomplete due to unfinished '1/4 snaps'.
For example https://osu.ppy.sh/s/557316 :
> I want to put a spinner in a 2/3 snap, expectedly it should display 4 hits under 1/3 snapping scale.
> However, under the default settings of 'tick rate' of spinner, 2/3 (<3/4) is counted as 2/4, hence displaying only 2 hits.
In general cases, we solve this issue by extending the spinner in purpose to 1/1 for fulfilling the 4-hits feeling. This could be a potential guideline about the usages of sliders and spinners.
Another topic wanna be discussed is the positioning of BG photo.
As of my modding experience, I have seen some mappers, especially rookies, are unfamiliar with the adjustment of BG position for a better visual effect, by editing in the .osu in notepad. Relevant concept and knowledge should be told inside the guidelines as well.
SV leniency is another impt topic. In high BPM (I would define it as BPM>200, or it needs another defination), the base SV of Kantan and Futsuu should be able to be exceptionals of current guidelines. A clearer statement about the leniencies of SVs in lower difficulties should be stated as:
Under high bpm difficulties, the base SV of Kantan and Futsuu could be lowered, for the sake of the readabilities of respective level players.
More precised values should also be advised, like Kantan = 1.00x Futsuu 1.20x under BPM=260 etc..
I know how math works... T_TNoffy wrote:
having all combo colors set would be at most 200bytes added to the .osu filesize.
it takes one MILLION bytes to make a megabyte.
it would take over five thousand taiko difficulties with all eight custom combo colours set to waste a megabyte of space.
In conclusion, I don't think that's something to worry about.
Topic Starter
Spinners do not work like that, actually. They are dependant on how long it is as well as the OD of the map. In any case, it is not a rhythmic component of a map and therefore having a guideline for them that is not avoiding its visual interference with other gameplay elements seems completely trivial.Skylish wrote:
By default settings in the Edtior, Combo Colours should not be a worry.
I wanna suggest a topic about the usages of sliders and spinners.
> Tick Rate of slider would be 3 in the snappings of 1/3 and so on. Meanwhile, the spinner 'tick rate' is set as 1, in which every 1/4 beat will create a hit in the spinner.
Here's the contradiction, if a spinner is put exactly in 1/3 snappings, the spinner may be incomplete due to unfinished '1/4 snaps'.
For example https://osu.ppy.sh/s/557316 :
> I want to put a spinner in a 2/3 snap, expectedly it should display 4 hits under 1/3 snapping scale.
> However, under the default settings of 'tick rate' of spinner, 2/3 (<3/4) is counted as 2/4, hence displaying only 2 hits.
In general cases, we solve this issue by extending the spinner in purpose to 1/1 for fulfilling the 4-hits feeling. This could be a potential guideline about the usages of sliders and spinners.
Skylish wrote:
Another topic wanna be discussed is the positioning of BG photo.
As of my modding experience, I have seen some mappers, especially rookies, are unfamiliar with the adjustment of BG position for a better visual effect, by editing in the .osu in notepad. Relevant concept and knowledge should be told inside the guidelines as well.
It is a reasonable suggestion, however it would end up becoming redundant as you would need a concrete value for every single existing BPM that is not average. Consider that it is a guideline and that it may be broken under exceptional circumstances.Skylish wrote:
SV leniency is another impt topic. In high BPM (I would define it as BPM>200, or it needs another defination), the base SV of Kantan and Futsuu should be able to be exceptionals of current guidelines. A clearer statement about the leniencies of SVs in lower difficulties should be stated as:
Under high bpm difficulties, the base SV of Kantan and Futsuu could be lowered, for the sake of the readabilities of respective level players.
More precised values should also be advised, like Kantan = 1.00x Futsuu 1.20x under BPM=260 etc..
This topic is however tied to Taiko ruleset draft (Specific) so I don't know why you're directing your concern here