It has been mocking me the last months that the catch RC is getting much less 'beginner' friendly. While reading through everything a couple of times I found quite a few flaws in the current way some rules and guidelines are written. Because of this I decided to do some big revamps in the wording with the following goals in mind:

1. Remove 'hidden' rules. Quite a few guidelines have hidden rules in their explanation, this shouldn't be done and instead should be stated separately under the rules.
2. Remove double written rules. In some cases we specified a rule in the rules and guidelines. This is rather unneeded and can instead be merged into one. This is most likely a left over from a couple rule changes and probably forgotten to clean-up.
3. Making it easier to read from a global view. The wording of some rules can be quite confusing and unreadable, especially when the object type is stated sometimes at the start or just after the start of the sentence. This change addresses this by following a simple schema when possible:
   (Object type) (Optional snap type) (Rule/Guideline indication) (Criteria).
4. Making the term 'Basic' clearer. For 'Higher-snapped' we specify that it is a type of snapping. For 'Basic' we don't do this right now making it a possible place for confusing. To resolve this I've renamed 'Basic' to 'Basic-snapped' to make the writing style consistent with the 'Higher-snapped' term which also makes it more readable from a global point.
5. Remove unneeded examples to make the RC less of a text wall. While other modes their RC is snapping based instead of our ms based, adding a lot of extra examples is rather unneeded and makes it more confusing.

Besides this I also fixed some typos. For example the Platter rules had written 'repititions' instead of 'repetitions' in a rule.

I did not want to write 20+ rules in the thread so all changes of the rework can be found here. An easy comparable view with the changes can be viewed here.

When discussion is being done here, please keep in mind to not talk about introducing or removing rules. I mainly want this change to be focused on the above points, so keep this in mind. Besides all the changes I also have more plans to rework, but that would make the scope of this proposal too big.

Looks good IMO. While we're at it, I would like to bring to discussion the following: "Individual 1/3 and/or 1/4 patterns must not persist for more than one bar (4 and 5 objects respectively)", since it's being moved from a guideline to a rule.

I think the original intention of the rule was to avoid 1/3 and 1/4 streams from extending too long, allowing at most a 4-plet or 5-plet stream, respectively. So, this wouldn't be allowed, as it's 5 consecutive 1/3 fruits:



Then there's an issue with the concept of "bar" being used, since a bar technically extends from downbeat to downbeat (or big white tick to big white tick). The first one is that the length of a bar depends on the timing signature. A second one, and an extension of that first one, is that the number of fruits that fit in a bar can extend for a lot more than what is currently specified. So in a map with a 4/4 timing signature, a bar can actually fit 12 fruits at 1/3 snap.

An additional issue with this (new) rule is that, since the wording is a bit vague and contradicting, it's quite open up for interpretation. So, for example, some could say the following image is borderline unrankable, since it's 4 objects using 1/3 snaps (so, it's a 1/ pattern) within a single bar:



In conclusion, since we're turning that into a rule, I'd make sure the wording actually conveys what is intended, i.e.:

Proposal wrote:

Consecutive 1/3 and/or 1/4 fruits must not persist for more than one beat (4 and 5 fruits respectively)

Or something along this line.

(Side note: It's also been on my mind that it's quite weird that density guidelines are still snapping based when other rules are ms based, and that's probably part of what you're working on for your next proposal. But I think this change should be made in an interim way, so that's why I still brought this up to discussion)

ZiRoX wrote:

In conclusion, since we're turning that into a rule, I'd make sure the wording actually conveys what is intended, i.e.:

Proposal wrote:

Consecutive 1/3 and/or 1/4 fruits must not persist for more than one beat (4 and 5 fruits respectively)

Or something along this line.

Wording it like this could work but now you would allow 4 or 5 fruits in multiple beats in one measure. Beat 1 can have 5 notes then in beat 2 we have nothing then again in beat 3 we could have 5 fruits again. This doesn't seem like the intention of the rule at all so instead changing the wording to:

Proposal wrote:

Consecutive 1/3 and/or 1/4 fruits must not persist for more than one beat (4 and 5 fruits respectively), and can only be used once in a measure.

ZiRoX wrote:

(Side note: It's also been on my mind that it's quite weird that density guidelines are still snapping based when other rules are ms based, and that's probably part of what you're working on for your next proposal. But I think this change should be made in an interim way, so that's why I still brought this up to discussion)

While I partially agree with you that it seems strange. Making this ms based would mostlikely make it much more wordy and imo more confusing.

Good qol change, looks nice.

thank you for this, it would be great to see an overhaul

while on the topic, it would be convenient if the rules were ordered to be more digestible. for example in platter rules, I doubt hypersliders would come to mind for a newer mapper to use or remember.

Greaper wrote:

ZiRoX wrote:

(Side note: It's also been on my mind that it's quite weird that density guidelines are still snapping based when other rules are ms based, and that's probably part of what you're working on for your next proposal. But I think this change should be made in an interim way, so that's why I still brought this up to discussion)

While I partially agree with you that it seems strange. Making this ms based would mostlikely make it much more wordy and imo more confusing.

The main difference between ms-based and snapping-based is whether bpm-independent or not. For example, even though I don't think there should be consecutive five 1/4 objects in ~bpm90 songs (equal to consecutive five 1/2 objects in 180bpm) but there is no sense that we allow for one and disallow for another.

i agree with these changes but imo some changes are excess.

Higher-snapped dashes should not be followed by antiflow patterns. If used, the movement after the dash must be walkable.
was changed into
Dashes that are higher-snapped should not be followed by antiflow patterns.

This is really useless. This sentence means basically the same thing without the second part "movement after dash should be walkable". I guess the correct change should be just removing the movement-part. This is just an example, but I hope you see my point

agree with the proposal altho i wanna add something like when we renamed "basic dash" into "basic snapped dash" it is still not resolving confuseness about what "higher snapped dash" is. A lot of people confuse with the definition of higher snapped dash/hdash especially for asian players / people with lack of english skills.

Example in RC it's written as "Higher-snapped dash/hyperdash: Any dash or hyperdash that doesn't meet the requirement to be a basic one, i.e. the time between the objects is less than the threshold to be classified as basic."
Giving an example with ms value like basic dash has would help people to understand it easier i think
Example : "As an example, a hyperdash between objects less by 250 ms in a Platter classifies as a higher snapped hyperdash. a dash between objects less by 125 ms in a Platter classifies as a higher snapped dash"

Liyac wrote:

while on the topic, it would be convenient if the rules were ordered to be more digestible. for example in platter rules, I doubt hypersliders would come to mind for a newer mapper to use or remember.

I do agree that hypersliders are something a new mapper (hopefully) doesn't put in a Platter. It is currently already sort of ordered as followed:

1. Hyperdash rules
2. Dash rules
3. Spinner rules
4. Density rules

To me this seems like a good order, and if we would split it up into different topics then most likely it will become more of a mess.

fayew wrote:

This is really useless. This sentence means basically the same thing without the second part "movement after dash should be walkable". I guess the correct change should be just removing the movement-part. This is just an example, but I hope you see my point

The sentence does indeed mean the same, but we have the following as one of the goals of this proposal: 'Making it easier to read from a global view'. This is being done so the rules/guidelines feel more organized when reading them.

Besides this, the last part was only removed because it was a double written rule, which was already covered in one of the existing rules for the Salad diffs.

Xinely wrote:

agree with the proposal altho i wanna add something like when we renamed "basic dash" into "basic snapped dash" it is still not resolving confuseness about what "higher snapped dash" is. A lot of people confuse with the definition of higher snapped dash/hdash especially for asian players / people with lack of english skills.

Hard agree that this should be addressed, although I'm planning to address the whole basic-snapped and higher-snapped terminology after this proposal since it is quite a brought topic and will most likely touch a lot of rules/guidelines.

The rename of 'Basic dash/hyperdash' into 'Basic-snapped dash/hyperdash' is done so it feels more aligned with the term 'higher-snapped'. Now with 'basic-snapped' you instantly know it is refering to a snapping type instead of making it ambugous that it refers to something completely different like a weak dash/hyperdash.

Looks good and ofcourse i support this as I i also contributed in some wording and proofreading, a really nice cleanup and I'm more than fine with pushing this on the wiki, and then potentially propose new RC discussions on the reworked version

Xinely wrote:

Example in RC it's written as "Higher-snapped dash/hyperdash: Any dash or hyperdash that doesn't meet the requirement to be a basic one, i.e. the time between the objects is less than the threshold to be classified as basic."
Giving an example with ms value like basic dash has would help people to understand it easier i think
Example : "As an example, a hyperdash between objects less by 250 ms in a Platter classifies as a higher snapped hyperdash. a dash between objects less by 125 ms in a Platter classifies as a higher snapped dash"

I've already said my thoughts in BN server but overall I approve the rework. The only thing I would add is the ms part similar what Xinely said.

Agree with

Okay so after some thinking we probably should also add a 'Snapping reference table' if people seem to struggle with the term 'higher-snapped'. While I don't want to touch the subject too much in this proposal, at least adding a table containing all the difficulties with all the snapping types in a quick overview would surely help as a temporary fix. Besides this placing it below the glossary (so after the basic-snapped and hyper-snapped explanation) is most likely the best place to put it.

Greaper wrote:

Okay so after some thinking we probably should also add a 'Snapping reference table' if people seem to struggle with the term 'higher-snapped'. While I don't want to touch the subject too much in this proposal, at least adding a table containing all the difficulties with all the snapping types in a quick overview would surely help as a temporary fix. Besides this placing it below the glossary (so after the basic-snapped and hyper-snapped explanation) is most likely the best place to put it.

The table would look as followed

looks gucci

I approve the table

Table looks great

The table surely helps to understand. love it

Some wording suggestions while reading the overhauled RC:

RC wrote:

Dashes that are basic-snapped [...]
Hyperdashes that are basic-snapped [...]
...

> Basic-snapper dashes [...]
> etc

So those are in par with the wording order used in the glossary. Found in Salad/Platter/Rain subsections.

~

RC wrote:

Dashes that are higher-snapped must always be followed by walkable distances.

> [...] must always be followed by a walk.

Again, more loyal to the glossary. Found under Salad, but similar rules under Platter could also be reworded:

RC wrote:

Hyperdashes that are basic-snapped may be used in conjunction with antiflow patterns. [...] 1.2 times the trigger distance when followed by a walkable movement walk, [...]

and

RC wrote:

Hyperdashes that are higher-snapped should not be followed by antiflow patterns. [...] 1.1 times the trigger distance and the movement after the hyperdash must be walkable a walk.

~

There's also a small inconsistency on the edge dash rules for Salad and Platter, maybe it can be made the same for both:

Salad RC wrote:

Edge dashes must not be used. They require extremely precise timing which cannot be expected of less-experienced players.

and

Platter RC wrote:

Edge dashes must not be used as they require extremely precise timing which cannot be expected of less-experienced players.

~

Other than that, looking good. The overview table is a nice touch, though it's a bit of a bummer to scroll up to the glossary when checking individual difficulties while having the RC open.

Slightly offtopic: Lower AR/OD limit for a Cup is 4 but Salad has a lower limit of 6? Maybe that can be tackled down with another thread, as it's a big gap.

Applied all the feedback points except for the first one. As mentioned in the goals of this proposal, I want to make it as readable as I can, this is for both the global overview as readability of a single rule on its own. While I agree that writing it as you suggested is more compact and probably better when reading it standalone, having all rules/guidelines changed that way makes it really unreadable and I tested this with quite a lot of people and gave them both version, and all of them choose the current version which uses the pattern described in the OP at the "Making it easier to read from a global view." point.

For your offtopic concern, we are better of discussing this in another thread.

Anyway will leave this thread open for 24~ hours before creating a PR. An overview with all the changes can be found here.