First draft wording:

Sliders should only have as many nodes as needed to form the main body of their curve. Writing messages or drawing pictures using slider node points after the points of the main curve adds nothing to a beatmap and may potentially break or complicate convert processing for future game modes.

Improved wording based on feedback:

Slider nodes must affect their slider's curve. Using additional nodes to write messages or draw pictures may potentially break or complicate processing in future game modes or updates.

This primarily addresses issues like the following:



These techniques do not currently cause known harm to any major game modes, but could very well dramatically impact efforts to develop new rule sets for the game in the future or potentially break at any time if new behavior is added.

+1

-1. Just imagine when your initial intention is just to make the slider decelerate/accelerate like K.O.K.O.R.O & S.A.T.O.R.A.R.E, or make a literal spam of nodes like that sliderart in The Sun, The Moon, The Star.

The explanation is okay but the first sentence sounds absurd when taking out of context. I think we should take something more into account to prevent accidentally applying to those cases.

Basically the core message is "Slider nodes should be reasonable", when writing silly text or forms is not reasonable. Everything else is subjective and can be adjusted or just be fine.

It's clearly to prevent abuse (as always).

I agree with Zelzatter Zero that the first sentence is misleading, it doesn't even address the issue itself. Using more nodes than necessary is very common and has nothing to do with messages or drawings.

Also, since when are we implementing RC rules based on potential issues that might come up in the future? I remember several proposals being denied for exactly that reason. If anything, this can be dealt with once it becomes a problem.

This kind of stuff would never be possible in the first place if the rule/guideline about ".osu editing is allowed only for achieving things not possible in the editor" was still in place. To be fair I have no idea when or why that one was removed. It captures the intention of not allowing unreasonable things through notepad editing just because you can much better than the proposal in my opinion.
These nodes would clearly affect the slider if the sliderlength wasn't artificially cut through .osu editing after all...

You could also just summarise this with "don't add stupid stuff that doesn't contribute to the experience".

For the wording, as already noted by Zelzatter Zero, the current wording has some implications when you take it out of context. You would need to add a glossary definition for "main body of a slider curve" to make the actual message clear and to be honest, I don't think I want that glossary entry. Not sure if something like "Sliders cannot have additional nodes that are placed past their length." is better but when I hear "main body" I immediately feel like there is a "side body" floating around somewhere.

Overall I don't think such a rule is good or needed.
The root of the issue lies in editing the length of sliders via the .osu file. If you want to support P sliders with extended length (that aren't addressed by this proposal!), then there should be no problem at all to also support this slidernode gimmick. Yes, it's stupid but it shouldn't pose any more problems than extended P sliders in the first place. Just because it doesn't have an immediate value for the beatmap doesn't mean it should be banned.
There are ranked maps with bookmarks, unnecessary green lines, storyboard puzzles and and humoric comments on non-visible part of storyboard sprites. It's not relevant but it doesn't hurt. Why make the cut here?

+1, but...

The wording of the first sentence is vague and misleading. For instance, this rule could be applied to sliders which do not "fill" to the end of their nodes, like this:


Although this slider has a node that extends out from its main body, there is no gameplay difference to a similar slider whose nodes are enveloped by the slider body.

I suggest an revision to the first sentence that says:

Sliders must consist of nodes which reflect its shape.

I think that this covers the crux of this proposal (i.e. sneakily placing nodes into a slider in order to spell hidden messages). The revision I made would essentially mean that slider nodes must have some discernible effect on its slider body. I agree that this rule is required, lest sliders act in unexpected ways in the future. But it could be worded better.

Adam_S wrote:

+1, but...

The wording of the first sentence is vague and misleading. For instance, this rule could be applied to sliders which do not "fill" to the end of their nodes, like this:


Although this slider has a node that extends out from its main body, there is no gameplay difference to a similar slider whose nodes are enveloped by the slider body.

The worst part is that this kind of slider can be done through editor, when the SV is high enough and the snap divisor is small enough for it to happen.

Adam_S wrote:

I suggest an revision to the first sentence that says:

Sliders must consist of nodes which reflect its shape.

I think that this covers the crux of this proposal (i.e. sneakily placing nodes into a slider in order to spell hidden messages). The revision I made would essentially mean that slider nodes must have some discernible effect on its slider body. I agree that this rule is required, lest sliders act in unexpected ways in the future. But it could be worded better.

But there's a problem (although it's pretty rare) that mapper do not actually put any hidden messages into it, just put literally nonsense but it somehow works (extract from one of my maps):



Notice how the curve is made. It doesn't seems to reflect the shape but it apparently works. There's no hidden message in here either.

The main issue is that this proposal mainly focus only on our common sense. I think it deserves to be a guideline rather than a rule.

Zelzatter Zero wrote:

Notice how the curve is made. It doesn't seems to reflect the shape but it apparently works. There's no hidden message in here either.

This is a false equivalence. Spelling out hidden messages in slider bodies is a consequence of .osu editing, while your slider is just a consequence of how Bezier control points work. With enough nodes you can get anything to look like a circle. I think that your slider still consists of nodes which reflect its shape because each node has its effect on the slider body, even if it may seem that node placement is arbitrary.

Zelzatter Zero wrote:

The main issue is that this proposal mainly focus only on our common sense. I think it deserves to be a guideline rather than a rule.

Classifying something as a guideline implies that it can be broken under exceptional circumstances, so long as it fits the map. I don't think there's a way for messages only visible in the editor to have any representation in music. The only reason at all for mappers to put hidden messages is as a little easter egg for people willing to hover over every slider in the editor.

I still stand by my position that this rule should be added to the RC.

Endaris, if you're referring to https://github.com/ppy/osu-wiki/pull/3588 it didn't cover this kind of stuff anyway. I "removed" (just reworded) that because of the confusion people had with it

I don't like OP's suggested wording because it implies you need to make curves efficiently. also the note about complicating convert processing is both unnecessary and misleading, the format gives you enough information to conclude which slider points have no effect on the curve

so how about "Slider nodes must affect their slider's curve"?

clayton wrote:

so how about "Slider nodes must affect their slider's curve"?

I think you worded it better than I did. My only gripe would be that it might be straying away from the original goal of disallowing node drawings/messages. It would be nice to add on some of Ephemeral's proposal:

Slider nodes must affect their slider's curve. Using node points to write messages or draw pictures only visible in the editor does nothing to enhance gameplay.

well there are a few other ways you can add nodes to not affect the curve. my wording would also disallow (for example) straight lines made of more than two nodes, tons of nodes stacked on top of each other, etc., which is basically what people would consider "rules" anyway but it's not written in RC yet.

wasn't meant to address exactly and only the same issue as Ephemeral's

True. I don't think there's any incentive for mappers to go through the effort of making the examples you said, though. There's no a-ha going on where mappers leave easter eggs for people to find. It would just be painful and unnecessary to create sliders with pointless nodes like that.

Besides, what I gave would only be an addition to your rule proposal, and arguably the most popular way people use nodes which do not affect their slider's body. It wouldn't mean that the examples you gave would suddenly be allowed.

tbh i gotta disagree with this one.

now, i think that this could be a problem going into lazer, but at it's current state, i don't really think it's necessary. some mappers (like pata-mon) use sliders extending off of their tails, mainly due to how the editor handles sliders at lower beat snaps. i think it'd be pretty cool to go into the editor and find a secret message in there

i've updated the OP's proposed wording to better reflect the feedback given so far in this thread

Hurts just reading this

Ephemeral wrote:

i've updated the OP's proposed wording to better reflect the feedback given so far in this thread

hm i see. ig i have to agree, although i'll miss secret messages like "we live in a society"

The only real issue is the fact that this is just you stating you don't like messages being shared within sliders, it's understandable to a degree but I feel like it's mostly harmless and you're doing no one any justice with this change let alone fixing anything that needs to be mended. Unless it's something highly offensive I see no reason for this to be a rule as it stunts out creative efforts and makes mapping "boring" for some of us.

BlastTheKidd wrote:

The only real issue is the fact that this is just you stating you don't like messages being shared within sliders, it's understandable to a degree but I feel like it's mostly harmless and you're doing no one any justice with this change let alone fixing anything that needs to be mended. Unless it's something highly offensive I see no reason for this to be a rule as it stunts out creative efforts and makes mapping "boring" for some of us.

yeah but then a concern would be in lazer, slider nodes might be calculated differently, so the "we live in a society" slider would be glitched out. i personally don't mind, but i think most mappers will agree on this change

update: so i looked through this one map, and came across this slider:



it's classified as a slider message slider, but unlike the "we live in a society" slider, it's apart of the slider

raising the point about lazer when lazer is available for us to see things in already? osu isn't just going to break a ton of older maps.

improved wording in OP is better, suggestion about not writing messages / drawing pictures seems ok if one of the main goals here is to stop that, but I still think this note about "break or complicate processing" is dumb because it's impossible to make an invalid curve via adding more nodes

most of the sliders with pictures drawn at the end use a red anchor before it that the slider never reaches anyway. it's as if they don't exist as far as the game should care

i'm chiefly concerned about future lazer rulesets that might use node mapping in any convert routines to try and approximate curve distance to translate it into other game mechanics - wouldn't stacking them like messages do cause issues with calculations in that regard?

Ephemeral wrote:

i'm chiefly concerned about future lazer rulesets

Well the future lazer rulesets should then keep in mind that stacking slider notes into messages is a thing. Also those convert routines should be using calculated slider paths sampled through time instead of node paths.

The red marking would represent the samples

the thing being converted is the curve, not the curve's points-- if it makes something normal in osu! it'll make something normal everywhere else. if a future ruleset purposely changes the math to calculate curves, they should expect to break every slider because they're ignoring the curve types (so... don't do that. pretty sure that's not even an option with lazer because it makes no sense)

Why not reword it to state that you should generally avoid memery that doesn't contribute to the map, relate to the song, or otherwise serve any purpose beyond "haha fonny xd"?

Cause honestly that's what it seems this post takes issue with but it feels like an XY problem case where it targets slider nodes when really the problem is pointless memery. If you target the actual problem you can also cover potential future cases of pointless memery (like in storyboards or .osu files or whatever) rather than make a new rule for each case.

This shouldn't affect mapsets where the song itself is a meme and the map's memery is reflecting the song's memery. As clayton pointed out the nodes of themselves aren't really an issue (honestly if specific nodes started mattering even maps with end nodes that extend past the sliderends would be problematic). If it's thematic or relevant and doesn't go overboard it should be fine. I don't think a rule like this needs objective criteria but subjective evaluation instead.

Maybe as a guideline and focusing on pointless memes I could agree with this rule, but currently even with the reword I feel like it doesn't actually address the issue. There's a time and place for dumb jokes and the ranked section shouldn't be that imo.

I not agree with that suggestion, because converts can't be really perfect. For example: in taiko converts has strange usage of dons & kats, sometimes unreadable SV, revers sliders with high bpm make so fast bursts and they not really playable. Mania converts has strange rhythm and patterns too. Convert system can't be better than mappers. We need focus on mappers' works, not on converts. Anyway, some mapping styles use strange anchor's usage, their sliders can break converts of new gamemodes too. Also game has glitch wub sliders, sliderarts and a lot of different stuff with potential chance to break new converts.

Ephemeral: need some clarification about why you want to add this

only out of concern for beatmap processing => close the thread, false concern
only out of concern for "dumb jokes" in Ranked => open new thread, that's a larger scope
anything else => comment more =)

if this is conclusively confirmed to have no possible impact on converts or future processing of beatmaps in forward rulesets (lazer) then i have no qualms with closing the proposal

tbh I still don't really see the point for this either.

Can't process in lazer? That's just bad coding, since the current one can do it just fine.

Jokes? I think the Code of Conduct one would cover it way better.

Converts? Why it should be a thing in the first place? Taiko and Mania only take slider length into account, while CtB is literally STD but flattened horizontally. If STD work then I see no reason how the other one isn't.

lazer will support practically any rhythm game ruleset possible going forward, which is where my concern comes from

I agree on the proposed wording and rule change, but the reason seems off the interest of mapping community. This opinion is purely from a standpoint of a modder and mapper, as I do not have much information about the beatmap processing mechanics, and I believe this should be the case of a lot of mappers as well. This should be a good place to address the point that we are looking for preventing node abuse for non-gameplay intent. Three points here:

1. Ranked maps faces towards public, and using ranked maps to convey anything other than directly related with gameplay should be disallowed as we provide the pure version of the game. This really looks like a "backdoor attack" or "bug" and this rule change proposal can fix this issue.
2. This does not lie under code of conduct bracket as that is more focused on modding and mapping discussions, rather than putting some information in the map. Ranking criteria is one of the place to filter maps with issues out of ranked status.
3. This also may not be covered by the general code of conduct since the message itself may just be something plain like "I love osu". Thus I think focusing on the "unnecessary" part of the nodes would be a better wording, rather than raising code of conduct concerns.

Thus I would go for a slightly reworded version of the original draft after the definition sentence:

Slider nodes must affect their slider's curve. Writing messages or drawing pictures using slider node points after the points of the main curve adds nothing to the game content of a beatmap and may potentially break or complicate convert processing for future game modes.

Here's my take on what you want to disallow in this case:

The length value of a slider must never be edited manually for any other purpose than snapping the slider properly to complex timing. Using additional nodes to write messages or draw pictures may potentially break or complicate processing in future game modes or updates.

at least in my mind this would disallow writing messages outside of the slider while not talking about curves and whatnot because the way those are made use .osu editing to snap the slider back to leave nodes outside that wouldn't normally be possible ingame


moved it back to rc because idk why it was finalized / denied without anyone saying anything to that effect?

that seems agreeable

Is there a good way to check this? The existing aimod flag for a large number of nodes wouldn't catch all cases mentioned in oko's description and frequently puts up false flags for complex sliders too. It'd be nuts to expect BNs to check every slider via .osu code to see if it's rule-abiding or not.

Mapset Verifier has since added a check for this that has less false-positives and false-negatives than AiMod:



I'd say that's sufficient enough. Even if users don't use MV it'll be used before rank by BNs anyway, and it hasn't been an issue since to my knowledge.

Converts would most likely be fine as clayton mentioned earlier - nodes are just a guide for the path and shouldn't be read directly when converting rulesets.

So I don't think we need a specific rule for this.