I was thinking how to solve this request (tl;dr: hardrock storyboard toggle) and all mess with new 16:9 scaling gave me an idea.

Flags! What are these?

Flags indicate in which cases the given code line must be executed or/and what must happen under certain conditions. They must have backward compatibility so old SBs won't ruin.

What flags are possible?

• HR — the line will execute only if HardRock mod is on.
• same for Hidden, DT, HT, FL... Could be useful too.

• ST, TK, CB, OM — for execution only in specific game mode (Standard, Taiko, CtB, o!m)

• HD — the line will execute only if monitor has big resolution (e. g. 1600x1200 or higher) or if user has powerful pc. In second case there sould be an option for this (like 'low-end pc' in options menu but contrary). Needs for betmaps like this.

• 09 — ... only if monitor's aspect ratio is 16:9
• 10 — ... 16:10

• DO (Disable Override) — Flag determines whether storyboard element is disabled upon Storyboard disable. Allowing strobing/pulsing to be disabled, while keeping things like storyboarded backgrounds or collab names intact.
or
• EW (Epilepsy Warning) — Epilepsy warning mark. Will disable only flashing part.

Paremeters of _P command also can be moved into flags (FH for horizontal and FV for vertical flip)

Let me give an example:

Sprite,Pass,Centre,"Sample.png",320,240
_F,0,1000,3000,1,1,HRHD

I don't know what format for them is the best, just 2 letters or letters with a divider (HD|HR) or with toggles (-HR|+HD, which means 'only if hardrock is off and if HD mode enabled) or with toggles or even with parameters (H=R), let programmers decide what is better.
I think that a toggle plus a flag is the best alternative as players will be able to set parameters needed on certain conditions and the other ones under the different circumstances. For example one option is with common resolution and the other one is at 16:9 monitor's aspect ratio.

A detailed example.
Lets fix this with flags:

This code rotates arrows by different angle, place numbers at top and swap them. Cool?

Please, comment if you have any ideas about another flags.

[Dellirium] wrote:

Cool?

Cool.

But how do you plan to add it to the editor GUI? Should it be similar to how you make difficulty specific storyboards? IMO that might be confusing.

but anyway, support. I could see this being helpful even if it will not be in the editor.

JeMhUnTeR wrote:

But how do you plan to add it to the editor GUI? Should it be similar to how you make difficulty specific storyboards? IMO that might be confusing.

The same way as loops and triggers \:D/

Or just by adding some toggles (like 'flip' or 'diff specific') and new layers.

Я олдфаг!

у анубарака в доте какой то оп манабёрн.

It's probably not going to be added to the editor GUI. How many options are accessible through the GUI?

I know there's a duplicate idea somewhere, but this is a lot more descriptive.

I agree if we talking about HR. Dunno how HD\DT\FL flags may be useful.

tiper wrote:

I agree if we talking about HR. Dunno how HD\DT\FL flags may be useful.

'roads' when in flashlight mode, stack hints when using hidden, 'OMG YOU ARE A CHEATER' when using DT+HR on Insane difficulty etc. xD

TheVileOne wrote:

I know there's a duplicate idea somewhere, but this is a lot more descriptive.

Please, find it. I only know one about HR.

[Dellirium] wrote:

tiper wrote:

I agree if we talking about HR. Dunno how HD\DT\FL flags may be useful.

'roads' when in flashlight mode, stack hints when using hidden, 'OMG YOU ARE A CHEATER' when using DT+HR on Insane difficulty etc. xD

Cool idea. A secret SB for the DoubleTimers or hidden players. So much potential.

YES PLEASE.

Well, I think it's rather difficult to implement this with GUI, but I think for such advanced feature like this a simple scripting is enough.

I would really like the HardRock part!

There could probably be mode-specific flags, too. For example, the spotlight effects in Talent Shredder make no sense whatsoever unless you're playing standard.

MillhioreF wrote:

There could probably be mode-specific flags, too. For example, the spotlight effects in Talent Shredder make no sense whatsoever unless you're playing standard.

Right. Added!

BUMP

I want to bring this idea back to the frontpage as it would encourage more storyboard usage. The sooner it is added the better.

Widescreen Storyboarding

All of my Yes!

We need this for sexy taiko storyboarding. Taiko will get even more authentic.

I once made a thread about mod-specific storyboard events, including HardRock mod which is mentioned here.

I want to cheat #1 on my own maps using FL-HD(-HR) specific .osbs I don't submit.

Jenny wrote:

I want to cheat #1 on my own maps using FL-HD(-HR) specific .osbs I don't submit.

You can already do that without mod flags, and it's a bannable offense if you're caught (though I don't think anything will be done about it until osz2, where it'll no longer be possible)

I know, silly~

And if you really want to be mean, you could add a flag for when someone puts HT on your deathstreamy map: "Un-Fun Mode Activated!'"
And then if someone has put DT: "DOG MODE ENABLED!"
IF you're putting DT on there, you ought to add toggles forNC (DT's secret counterpart) or FadeIn [FI] which is osu!mania's Hidden counterpart.
Then you got PF, where you could have it say "You're a perfectionist! How dare you."
And with SD, you could have it play "Sudden Death" from the Super Smash Bros series..
So much more fun possibilities if you include all the mods for flags, instead of just focusing on the few.
And, just for silly fun, if you put on Auto, it'll say "Cookiezi mode enabled".

Additionally, there could be a storyboard element that happens if you're currently in danger (below half health) Like a character in the BG sweating when you're on the brink of death, but feeling cool when you're doing good.

Yeah, I can see where this is going, and the future is VERY friendly.

I support this with invisible stars.

I would like to add a flag type.

Disable Override

Flag determines whether storyboard element is disabled upon Storyboard disable


Useful: Allowing strobing/pulsing to be disabled, while keeping things like storyboarded backgrounds or collab names intact.

TheVileOne wrote:

I would like to add a flag type.

Disable Override

Flag determines whether storyboard element is disabled upon Storyboard disable


Useful: Allowing strobing/pulsing to be disabled, while keeping things like storyboarded backgrounds or collab names intact.

I think you're going about that wrong. What you want is to mark the flashes so they can be turned off independently of the storyboard. This was part of early talk on the subject of this thread (elsewhere in other threads from long ago)... the idea of layers for epilepsy and HR objects. Marking objects so they're unaffected by Storyboard disable is asking for trouble. To be truly safe, there needs to be a way to turn off storyboards... I have no faith in the system when it comes to dealing with flashes perfectly.

And really that's probably a better way to go... the OP here looks like a well formed idea, but it's really not. It goes into a lot of detail about the names, but not a lot into what should be accomplished and how to accomplish it. Name are one of the easiest things to do and should normally be put off to avoid collisions (ie HD and HD). And there's no point talking syntax when you're still glossing over the real details of what you want to do (really, there's no way to write a full unit test for this... people want it, and there's a lot of handwaving, but there's not a lot of concrete examples covering exactly what everything is exactly supposed to do). The glossing furtheer hides the fact that although it presents one example of what it wants to do it's not a very good approach. For one, these things aren't really being used as flags... there's checks for both a "flag" being on, it being off, and a neutral base state... resulting in an ugly +- system to cover the states. These are used to essentially override an object with another based on a predicate... in a pretty kludgy fashion compared to any solution that actually represents that things override.

But getting back, an HR layer approach is a better solution for that issue... although "layer" is not necessarily that important, you could do this as objects flagged as HR important. The idea of an HR layer is that the layer flips with HR automatically. It behaves as normal when HR is off, and when HR is on, everything attached/marked/flagged as HR gets automatically flipped for you. No need for adding second object lines or kludges. Of course, you'll probably want a flag in there to say "don't flip this sprite" so that sprites that should appear right side up (ie text) are just moved and don't appear upside down.

So, in short, although I like the general idea in this thread, I'm positive that things can be done in a better way than in the OP. What this thread should really be focusing on is coming up with exactly what sort of things people want the storyboarding to do, ignoring things like names and syntax and flags which are implementation details that can easily be done by the person who codes it.

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.