READ THE DRAFT HERE 4o3257

Hi!

Here's the draft for the storyboarding section. We took out some of the clutter, but also added some things that weren't previously there (regarding lyrics, for example). The Allowance section and Rules about the overlay layer (which is ... relatively recent) are also new, I think, so please read the whole thing.

If something is suspiciously absent we probably declared it to go to the general section instead of staying in the storyboard only section. If you notice anything critical missing please yell!!

Optimisation article 2v5p4u

We moved a big chunk of things into a (currently) in-draft article about optimising storyboards. The following things need to be done still:

1. Certain things lack examples.
2. A few ToDo's need actual wording

486x28

Please use this forum thread to drop on the draft! Alternatively, for smaller questions and such the RC discord instead!
First round of revision starts either when on this thread dies down or a week from now on 2024-03-23 (yyyy-mm-dd)

The storyboard must not throw errors upon loading.

I don't know what the right wording would be bc I don't what receiving an error looks like, but this should probably use less programmer-y language than "throw" (e.g. "must not show an error window")

---------------------------------

Image files used in storyboards must not exceed an area of 12,000,000 pixels. This is to keep file size and loading times reasonable. So 4000 × 3000 is fine, for example.An image's area is equal to its width times its height.

the rule is okay but the stated reason is kind of questionable to the point that I wouldn't include that sentence in RC. I can make a smaller image area-wise that will both be larger filesize and load slower

also, I think just saying area=w*h is easier than giving a random numbers example

---------------------------------

Do not use the Scale (S) commands if a sprite already has Vector Scale (V) or vice versa. Behaviour of the two commands together can have inconsistent results depending on your framerate.

I'm not sure if the stated reason needs this much detail. it may be detrimental because not all clients behave the same

---------------------------------

Sprites in the OverlayOverlay layer should not significantly hinder gameplay.

---------------------------------

If the storyboard contains lyrics or credits to s, make sure they are on screen at the proper times, readable, and spelled correctly. If you are unsure of or do not speak the language of the song, the lyrics, timings and spellingwith a native speaker during the modding process.

---------------------------------

Avoid commands which behave in unintended or inconsistent ways. If it is unclear, confirm the intent with the creator.

I don't really understand how confirming the creator's intent would resolve the problem of this guideline. isn't it saying that they should use commands in the expected ways, regardless of the creator's intent?

---------------------------------

seems good overall. I haven't looked at the optimisation article since that still seems WIP, but I will say I think this part of RC doesn't necessarily depend on that either -- I think it would be fine to get this part in and then add the optimisation suggestions later.

clayton wrote: 5b1y29

Image files used in storyboards must not exceed an area of 12,000,000 pixels. This is to keep file size and loading times reasonable. So 4000 × 3000 is fine, for example.An image's area is equal to its width times its height.

the rule is okay but the stated reason is kind of questionable to the point that I wouldn't include that sentence in RC. I can make a smaller image area-wise that will both be larger filesize and load slower

also, I think just saying area=w*h is easier than giving a random numbers example

i don't think the rc needs to explain what an area is. would just remove that sentence

clayton wrote: 5b1y29

Do not use the Scale (S) commands if a sprite already has Vector Scale (V) or vice versa. Behaviour of the two commands together can have inconsistent results depending on your framerate.

I'm not sure if the stated reason needs this much detail. it may be detrimental because not all clients behave the same

the reason is correct as the clients don't behave consistently by themselves nor between each other, hence "inconsistent". the shorter explanation is that it "leads to undefined behaviour"

clayton wrote: 5b1y29

Avoid commands which behave in unintended or inconsistent ways. If it is unclear, confirm the intent with the creator.

I don't really understand how confirming the creator's intent would resolve the problem of this guideline. isn't it saying that they should use commands in the expected ways, regardless of the creator's intent?

this is more directed at beatmap hosts who aren't also doing the storyboard i believe, as this is referring to overlapping commands, which can be used both incorrectly (causing weird behaviour) and deliberately (for neat effects or optimisation)

however, this seems to have been changed to

proposal gist wrote: 442o2r

- **Avoid strange-looking effects.** If it is unclear whether the effect is intended confirm this with the creator.

which doesn't quite match what i thought it was supposed to mean before, so i'm a bit confused