Forums » StepMania Development » [SM 5.1] New noteskin format and modifier system

I am currently working on a new noteskin format, notefield, and modifier system for SM5.1. The purpose of this is to create more flexible systems with more capabilities and leave behind the design mistakes accumulated from the last 10 years. The downside is that all previous noteskins and options screens and scripted mod simfiles will be incompatible.

[size=24]Noteskins[/size]
[size=18]Advantages[/size]
* Quantizable holds: A hold can be colored by the time that the tap occurs at.
* Not tied to game types: The same noteskin can be used for multiple game types, at long as it supports the buttons.
* Not limited to 192nd quantization: The new quantization system works on how many times a given set of sprite states occurs each beat. So if the noteskin says that frame 3 on the sprite sheet occurs 5 times per beat, then any note that is 0.2, 0.4, 0.6, or 0.8 from the beat will be shown as frame 3. The judging and simfile format are still tied to 192nds.
* Not controlled by 100 confusing undocumented metrics: Everything is done in lua, with the flexibility that gives. And it's documented in an example noteskin.
* Column width set by noteskin: The noteskin returns a width and padding for each column, so different columns can be different widths. The column positions are calculated from the width and padding totals. Previously, the column positions were hardcoded in the gametype.

[size=18]What to remake[/size]
* Hold body graphics: The hold body graphics are now in one piece instead of three. Top cap, body, and bottom cap are all in one image. (otherwise making it render without seams and gaps would be a nightmare)
* Lua files: New lua needs to be written for noteskins. notes.lua may look intimidatingly long, but that's because more than half of it is comments explaining each part.

[size=18]Noteskin format[/size]
And the other lua files there.


[size=24]Modifier system[/size]
[size=18]Advantages[/size]
* Per-column: Different columns can have different modifiers applied.
* More detailed: Each attribute of a note is moddable in many ways, instead of the special cases someone thought of 10 years ago.
* Explainable with simple math: Figuring out exactly what "SuddenOffset" does, where it makes the notes disappear, in the old system requires reading the source code, figuring out what the center line is, then converting from percentage to pixels. In the new system, it's relatively easy to define a mod that makes notes with a y offset less than 128 visible, and y offset more than 128 invisible.
* Themes can define their own fancy effect mods: I've done this so much when bored.

[size=18]What to remake[/size]
* Options screen: I haven't decided exactly how to rewrite the options screen to accomodate the new system yet. Speed mod, perspective, note zoom (mini), and reverse seem like the core mods to support. So I've got something lined up to cover those.

[size=18]Detailed description[/size]


[size=18]Other stuff[/size]
* More info for Notefield board.lua: The width of the field is passed in through WidthSetCommand, so that the board can still be used as a screen filter. It doesn't need to fetch the style to figure out the width.
* Columns can apply mods to actors: The notefield columns provide functions to make it easy to put judgment flashes in each column (so a column flashes blue on a W1 and red on miss) and have the flashes be positioned correctly with any mods in use.
Example Notefield board.lua. Note that it supports both SM5 and SM5.1, providing screen filter and judgment flashes in both. But non-trivial mods are only handled in SM5.1, because positioning the judgment flashes on the receptors in SM5 would require a ton of code.


[size=18]Estimated preview[/size]
I'm planning to have a preview build for people to try out in a month. Until then, it's open for people that build from source to pull that branch to try it out. If there are any major missing features in the noteskin system, now is the time to point them out. Rather than comb through the existing noteskin system and figure out what every godforsaken metric does, I built it the stuff that seemed necessary.
(anybody pulling SM5.1 source needs to be using VS2013 or GCC 4.8, or clang version with C++11 support, then run "git submodule update --init" after pulling)

Last edited: 29 September 2015 5:53pm

< cybik> til Kyzentun fixes bugs for breakfast
--
< maxvg1> shakesoda: then why do i still play lol
<@shakesoda> because you're an ITG player. And thus, a masochist
--
<@shakesoda> Kyzentun: I think you might need to put down the meshes for a bit
Reply
Along with these new changes, will we be able to simply copy over the image files of a previous noteskin and re-factor in the missing lua files and whatnot? I'll find it pretty annoying to copy/color all those gorilla faces again.


Just sayin'
Reply
Only the hold images should need to be recreated. Textures for the other parts should be reusable.
< cybik> til Kyzentun fixes bugs for breakfast
--
< maxvg1> shakesoda: then why do i still play lol
<@shakesoda> because you're an ITG player. And thus, a masochist
--
<@shakesoda> Kyzentun: I think you might need to put down the meshes for a bit
Reply
Is calling GAMESTATE function allowed in new noteskin?

Last edited: 5 October 2015 6:32am

Reply
Why would you need to call GAMESTATE functions in a noteskin?
< cybik> til Kyzentun fixes bugs for breakfast
--
< maxvg1> shakesoda: then why do i still play lol
<@shakesoda> because you're an ITG player. And thus, a masochist
--
<@shakesoda> Kyzentun: I think you might need to put down the meshes for a bit
Reply
My noteskin calls GAMESTATE:GetCurrentGame():GetName() to switch graphics by gametype.
kickbox/default noteskin calls GAMESTATE:GetCurrentStyle(pn):GetStepsType() to switch graphics by StepsType and buttons.

Last edited: 5 October 2015 11:39am

Reply
1. Noteskins should not depend on the current game type. One of the goals is to move to a system where there is no current game type, and any chart can be played or viewed.
So "local game = GAMESTATE:GetCurrentGame():GetName();" is bad.

2. Kickbox stepstypes are going to use different button names for the Human and Insect stepstypes. So the noteskin will see a button named "UpLeftFist", and know that it's different from the "LeftFist" button used by the Human stepstype.
So "if (GAMESTATE:GetCurrentStyle(pn):GetStepsType() == "StepsType_Kickbox_Human") then" seems completely unnecessary.

3. I'm not sure what "if stt ~= "StepsType_Dance_Octo" or (sButton ~= "UpLeft" and sButton ~= "UpRight" and sButton ~= "DownLeft" and sButton ~= "DownRight") then" is supposed to do. Are you just making it so that certain receptors have two parts and others don't?

4. If there are two notefields on screen during routine, and you have to manually hide the receptors for one, that's a bug in routine mode.
So "if (styleType == "StyleType_TwoPlayersSharedSides") and (pn ~= GAMESTATE:GetMasterPlayerNumber()) then" isn't necessary.

I think I covered all the places you used GAMESTATE in your noteskin. I might have misunderstood some of them.
< cybik> til Kyzentun fixes bugs for breakfast
--
< maxvg1> shakesoda: then why do i still play lol
<@shakesoda> because you're an ITG player. And thus, a masochist
--
<@shakesoda> Kyzentun: I think you might need to put down the meshes for a bit
Reply
1. In 5.0, some gametype using same button name, but have different look. (ez2/maniax, beat/kb7)

3. StepsType_Dance_Octo is used only in my old StepMania fork. So it makes no sense.

Understood for 2. and 4.
Reply