In this thread I want to discuss the following guideline for Storyboarding:

Avoid illogical, conflicting and obsolete commands. Commands of the same type whose intervals overlap, have their ending time before their start time or are bound to impossible to reach triggers, are either not working as intended or obsolete, and should either be removed or adjusted to work as intended.

This needs a cleanup in some way because what this guideline states is simply not true.
Commands of the same type whose intervals overlap can work as intended.

Example:
This map has a lyrics effect with sprites and commands that look like this (line 6316 of the .osb at the point of writing):

Sprite,Background,Centre,"sb\lyrics\306b.png",0,0

 S,0,12027,,0.3

 M,1,12027,16527,178.65,370,160.7,370

 F,0,12177,12327,0,1

 F,0,12177,14163,1,0

As you can see, the times of the Fade commands overlap and thus technically fall under this guideline, however the effect actually works intended and osu! fades the sprite in from 12177 to 12327 and then proceeds to fade it out from 12327 to 14163.

The guideline states that this kind of command combination will not work as intended and thus the second command should get changed to

 F,0,12327,14163,1,0

instead.

The thing is that it does work as intended without that change.

The clarification I hope to achieve in this thread is:
Do these sprite commands violate the guideline?

From a technical point of view I'd say yes because the commands clearly overlap and a different .osb parser might not be able to correctly interpret it.
From a pragmatic point of view I'd say no because it works as intended.

Right now it's impossible to tell which of these interpretations is adequate. In this thread I want to discuss which one is adequate.
The result of the discussion should be an adjustment of the guideline in either one or the other direction so that there is no room for interpretation.

It seems that your example can result in unintentional effects though.

Gonna use this code to simplify things, but it's essentially the same thing as your example:

Sprite,Foreground,Centre,"sb\file.png",320,240

 F,0,1000,1500,0,1

 F,0,1000,2000,1,0

What ends up happening here is the sprite goes from 0 -> 1 opacity between 1000ms and 1500ms, but then at 1501ms it immediately goes to 0.5 opacity (or very slightly below that) and then fades out to 0 opacity from there.

So I'd argue it can lead to cases where the effects are unintentional. Of course, these effects could also be deliberate too, but I feel like writing storyboards like this is incredibly inelegant.

Ah that's good to know.
I didn't investigate the issue in detail and by eye the minor jump in opacity was not perceivable. I recently modded another SB that had a similar issue with Scale commands and I couldn't visually perceive the SB misbehaving either although it should supposedly be much easier than with a Fade command...

As you stated though, it is still something that can result in an effect working as intended.
Considering that many effects in modern storyboards are generated through automation, the perception of an effect as "working" will often be the deciding factor in using it opposed to the technical correctness of the generated .osb code. This means that the presence of such an inelegant .osb-script cannot be assumed to always be something not "working as intended".

This makes the specific term "working as intended" problematic from a modding perspective because there is no way to tell whether it is intended or not without asking. Naturally this means that it is something that should always be brought up when noticed so that the SBer can review and potentially adjust.

I'm going to develop this scenario a bit further for the sake of discussing the guideline:
Let's say inelegant .osb code was identified. The SBer looks at the issue and confirms the code to be working as intended. It turns out that reworking the responsible .osb-generating script to generate an elegant .osb script with the same visual representation would require a huge effort of several hours.
Would this be a sufficiently good reason to "break" the guideline?
In my opinion, yes.

I'm asking this because compared to most other guidelines in the RC there is technically no grey zone in which it is up to discussion whether the guideline was violated or not. There is always a computable and achievable solution to any violation of this guideline. It's not about subjective opinions but meeting a technical requirement of "script quality" that does not affect the visual representation of the storyboard at all.

With these things in mind and going with the mindset that .osb code should be elegant, this is more a rule than a guideline. The SBer will never be able to give a reason why the .osb should not be fixed other than issues regarding the .osb-script generation itself.
Personally I think it makes sense to keep it as a guideline to allow inelegant .osb code to get ranked if the overhead for fixing it would be too high. If that is how this guideline should be interpreted an adjustment such as the following would make more sense:

Avoid illogical, conflicting and obsolete commands. Commands that have their ending time before their start time or are bound to impossible to reach triggers are either not working as intended or obsolete, and should either be removed or adjusted to work as intended. Commands of the same type whose intervals overlap should have their intervals and parameters adjusted so that they no longer overlap unless both the associated effect is working as intended and the adjustments would require unreasonable effort.

Not sure if the grammar of the last sentence is correct / easy enough to understand like that.

it's a guideline, so I think you can remove "unless both the associated effect is working as intended and the adjustments would require unreasonable effort". this would be necessary language only if it were a rule

lgtm otherwise, this is probably what everyone would want in the first place, it was just lazily tested before

I think we can probably remove mention of the "inelegant" code altogether honestly. As long as the storyboard doesn't actually error it should be fine. The only concern it would cause is it would make the .osb a lot less readable, but that only affects like 20 people anyway.

The line should only be drawn when we have two commands that basically do the same thing, and so would fall under it being obsolete (e.g. 1000ms->2000ms and 1000ms->1999ms).

your example might work, yes. But it seems like bad practice. Its likely that its an unintended effect.

mo the only reason I disagree with u is that this is a guideline-- I think guidelines should recommend good practices, even if there is a lower baseline of "fine"

change looks fine to me with claytons suggestion:

Avoid illogical, conflicting and obsolete commands. Commands that have their ending time before their start time or are bound to impossible to reach triggers are either not working as intended or obsolete, and should either be removed or adjusted to work as intended. Commands of the same type whose intervals overlap should have their intervals and parameters adjusted so that they no longer overlap.

does anyone have issues with it?

I think that's fair enough.

https://github.com/ppy/osu-wiki/pull/3433

editmerged