I don't know what about my incredibly straight forward post incited such a detailed and over thought out observation of my comment.
I was not really thinking about epilepsy warning more than giving storyboarders a way to decide which elements are affected by storyboard disable option in Visual settings. I had thought about the possibility of dividing the storyboard up into sections and have a toggle that enables/disables each layer individually, but I have not been able to visualize how that would work.
I guess you would at most need 3 layers (each with a flag/space indicating which layer it is in).
Generic Layer: Regular storyboard
Background: Storyboarded backgrounds/large images
Effects: Particles/strobing
Applying this structure to the flag system doesn't seem like too unrealistic. I don't know how storyboard is handled in osu! so my opinion will be very restricted.
I'm going to make the assumption that visual settings are checked before a song starts. It's probably determining whether to draw or not draw elements in the storyboard. My C# is very limited. I know Java, and I'm just starting to learn C, I'm unfamiliar about how the mutant hybrid of the two works. It's probably designed to load storyboard in chunks, which will mean implementing this will take up more resources to load the storyboard or it would load out of sequence.
My thoughts in psudocode.
Player requests song to start.
1. Storyboard toggles are checked
If storyboard is not disabled, load all
else
load flag indicators into memory (there should be only 1 disable related flag indicator per storyboard line-do not allow more than one flag)
check for flag indicator (no flag indicator defaults to general level, EP is the strobing level, and the other is background layer) and compare it to storyboard toggles that are disabled) If toggles do not match, add to list of storyboard to load.
2. Once all elements are checked (for various flags), load storyboard.
I assume that the other flags would work in a similar way. It would gather the flags, and then compare them to a gamestate. If it's HDFL, then load elements with HD || FL flags or load a different behavior when this state is matched. Toggle states would work a bit differently than a flag which would have a preprogrammed change like flipping an element for hard rock.
Unsure what the best way of handling toggle states. A possible option is have a list of actions under certain states somewhere, and if the states are met, then load this state instead of the original state. Duplicate flags shouldn't be an issue, because it would be looking for the first instance of a flag. If there are more than one flag, then all relevant flags are checked. The end result is a list of storyboard actions that have been given the go ahead to be loaded into the game.
3. Start game when loading is complete
---------------
I would like it if we could change all these things through the design editor. I don't think it's necessary to force users to remember all the storyboard flag markers, and it would be far less error prone if we could set everything through the editor. If this were implemented, it would require more effort on part of the storyboarder to ensure that elements are in their proper category.
I would also support a rule that says strobing must be placed in the strobing layer. It would be easier to enforce if we could just tell them to how to set pulsing through the editor. (I would really want an integrated .osb reader/editor to go along with this). It would make storyboarding a lot more accessible to mappers. That's a different request though.