Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. osu!
  3. Development

Storyboard Analysing Tool

posted
Total Posts
5
Endaris
5,282 posts
Joined June 2010
Topic Starter
Endaris
Hello,

it's not much and I'm probably not going to develop it further but it definitely has its uses.
I've started developing the tool after my first couple SB mods with the goal of helping storyboarders with self modding their SBs in regards to performance and rankability.

Features


Plot the active sprites and commands against visible sprites and commands


You can use this to find the most costly parts of your storyboard and also check whether your SB is efficiently done by looking at how far the green line (active commands/sprites) is from the red line (visible commands/sprites).
In the perfect storyboard they're exactly the same and you only see a red line.
Grave issues are usually very very obvious in this graph, for example like this.

Autogenerate warnings based on the command usage in sprites
Element sb/c.png at line 714 with 2 warnings:
    Warning Level 4: ProlongedActivityWarning: Active time of sprite at line 714 is prolonged for 5478ms (47,52732951587715% of its active time) unnecessarily.
    Warning Level 1: FadeOutWarning: Sprite at line 714 is invisible for 5478ms (47,52732951587715%) of its active time.


Element sb/c.png at line 729 with 1 warnings:
    Warning Level 1: ProlongedActivityWarning: Active time of sprite at line 729 is prolonged for 814ms (7,062293944126323% of its active time) unnecessarily.


Element sb/c.png at line 744 with 1 warnings:
    Warning Level 1: ProlongedActivityWarning: Active time of sprite at line 744 is prolonged for 2255ms (19,564462953322924% of its active time) unnecessarily.


Element sb/c.png at line 759 with 1 warnings:
    Warning Level 2: ProlongedActivityWarning: Active time of sprite at line 759 is prolonged for 3695ms (32,057955925733125% of its active time) unnecessarily.


Element sb/c.png at line 774 with 2 warnings:
    Warning Level 4: ProlongedActivityWarning: Active time of sprite at line 774 is prolonged for 5136ms (44,560124934929725% of its active time) unnecessarily.
    Warning Level 1: FadeOutWarning: Sprite at line 774 is invisible for 5136ms (44,560124934929725%) of its active time.
While these may have false positives on rare occasions they can give a very good orientation when looking for problems. Find more information on interpreting warnings in the wiki.
I'll look into expanding the information on the specific warning types in the future.

Links

GitHub: https://github.com/Endaris/OsbUtilities
Download: https://github.com/Endaris/OsbUtilities/releases/download/0.2.1/netcoreapp3.1.zip
Wiki: https://github.com/Endaris/OsbUtilities/wiki/

How to use

Read the README of the github project.
Aside from that you can find a brief introduction in this part of a SB video mod I've done recently.

It crashed

The tool crashing usually indicates that there is something weird going on in the storyboard. You can open an issue on the github or post here with the storyboard in question and I'll look to fix the crash.

Can you please add...

No.
Damnae is currently working on some metrics and analytics within storybrew itself so that's probably going to be 10 times better.
Last edited by Endaris , edited 1 time in total.
Calvaria
182 posts
Joined June 2018
Calvaria
omg so good idea
DarkProjector
308 posts
Joined January 2012
DarkProjector
There is my tools for parsing and analyzing storyboard code, and help sb author how(which/where) to optimze their storyboad code: here

you can easily make your program cooler,good job :D
Endaris
5,282 posts
Joined June 2010
Topic Starter
Endaris

DarkProjector wrote:

There is my tools for parsing and analyzing storyboard code, and help sb author how(which/where) to optimze their storyboad code: here

you can easily make your program cooler,good job :D
Hi, thanks for your feedback!
This seems fairly interesting, would be even better if I could read your README though >.<'

I deliberately decided against adding automated optimization functions for various reasons:
  1. It encourages not fixing scripts that don't work as intended:
    When these scripts are passed around, people will start to use these scripts without using an optimization tool which would lead to very bad results.
  2. Lack of transparency
    For the storyboarder it is very difficult to judge what was optimized and why. Especially if something breaks. There's no learning experience from this.
  3. Things break easily
    The biggest challenge is to deal with broken scripts that spam obsolete, illogical, conflicting and redundant commands in the first place. Chances are you're going to break it for these due to the complexity of these cases. And these cases are what I care about the most.
Overall I trust the human more to fix the script than a script because the human knows the intention and can also find optimisations that are not apparent for a tool.
DarkProjector
308 posts
Joined January 2012
DarkProjector

Endaris wrote:

DarkProjector wrote:

There is my tools for parsing and analyzing storyboard code, and help sb author how(which/where) to optimze their storyboad code: here

you can easily make your program cooler,good job :D
Hi, thanks for your feedback!
This seems fairly interesting, would be even better if I could read your README though >.<'

I deliberately decided against adding automated optimization functions for various reasons:
  1. It encourages not fixing scripts that don't work as intended:
    When these scripts are passed around, people will start to use these scripts without using an optimization tool which would lead to very bad results.
  2. Lack of transparency
    For the storyboarder it is very difficult to judge what was optimized and why. Especially if something breaks. There's no learning experience from this.
  3. Things break easily
    The biggest challenge is to deal with broken scripts that spam obsolete, illogical, conflicting and redundant commands in the first place. Chances are you're going to break it for these due to the complexity of these cases. And these cases are what I care about the most.
Overall I trust the human more to fix the script than a script because the human knows the intention and can also find optimisations that are not apparent for a tool.
I agree your options and think that fixing their problems by theirselves is more important than depending something(tools/sb runtime/etc.) which could auto to fix/optimze their sb script. Currently the implement of osu!lazer storyboad runtime is not compatible with current osu!, thus there are some storyboards of rank maps will break behavior with lazer.That's reason why I hope osu! ranking criteria contains storyboard script checking.
Please sign in to reply.

New reply

0
1 / 5