Storyboard enum parsing inconsistent with stable
See original GitHub issueDescribe the bug:
Setting the Looptype
parameter of a storyboard animation to a high integer works on stable, but behaves incorrectly on lazer.
Found on the SB of Feryquitous - (S).0ngs//—::compilation.[TQR-f3]: As an example, the counting units’ digit animation (01:55:238, .osb line 169448) is declared like this:
Animation,Foreground,Centre,"sb\HUD\timer\counter.png",330,240,10,108,16
with Looptype
set to 16.
Moreover, manually changing say Foreground
to 16
gives a parsing error on stable and deletes the sprite, but on lazer it imports fine and the animation is still visible. Changing Animation
to 16
gives an error on stable and deletes the sprite, but on lazer it imports fine except that the animation disappears.
Probably the same bug, but the error handling is a different issue.
Screenshots or videos showing encountered issue:
Stable behaviour - all digits count properly, as if Looptype
was LoopForever
(note that it starts from 8 because of fade):
Lazer with auto mod - units’ digit counts to 9 only once, as if Looptype
was LoopOnce
(starts from 0, ignoring fade):
Lazer with cinema mod - same as previous except it properly starts from 8:
I got the auto behaviour a few days ago and a couple times today, but now only the last behaviour happens. I think it’s just inconsistent and not specific to the mod.
osu!lazer version: Latest release 2020.1204.0 / 9064ca9
Logs:
N/A - tell me if they would help
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (5 by maintainers)
Top GitHub Comments
Right, 0 and 1 are also unambiguous, that’s what I meant. Fair enough, I guess an
IsDefined
check of whatever falls out ofEnum.Parse
should do.To be clear, it’s not anything not a string value, it’s values outside of the valid range which in this case is
{0, 1, LoopOnce, LoopForever}
.I don’t think logging will do much, so long as people use external tools to create storyboards (i.e. for as long as we don’t have a scripting language of our own) this is always going to be the case. It’s just going to be unnecessary verbosity in all regards, imo.