1. osu! forums
  2. osu!
  3. Feature Requests
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +135
show more
posted
Widescreen Storyboarding

All of my Yes!
posted

Saten wrote:

I would really like the HardRock part!
posted

Saten wrote:

I would really like the HardRock part!
posted
We need this for sexy taiko storyboarding. Taiko will get even more authentic.
posted
I once made a thread about mod-specific storyboard events, including HardRock mod which is mentioned here.
posted
I want to cheat #1 on my own maps using FL-HD(-HR) specific .osbs I don't submit.
posted

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)
posted
I know, silly~
posted
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.
posted
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.
posted

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.
posted
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.
Please sign in to reply.