[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.

Noteskins
Advantages
* 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.

What to remake
* 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.

Noteskin format
And the other lua files there.


Modifier system
Advantages
* 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.

What to remake
* 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.

Detailed description


Other stuff
* 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.


Estimated preview
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)

---

Will this break the OptionsList used in PIU-style themes?

It breaks anything that sets modifiers, since the whole basis of the modifier system is changing. I might write some lua option rows to handle the basic modifiers like speed, perspective, note size, and reverse, maybe something for hidden offset and sudden offset, then leave the rest to rot.
Since lua option rows do not work with OptionsList, OptionsList will have to do something different. Lua can be embedded in a gamecommand, so it could be done very awkwardly that way. Maybe.

The first stage is just to release a preview build at the end of October, to see if people are going to start porting noteskins. If nobody is going to port noteskins, then I'll just abandon doing the rest. (and likely abandon serious improvements to stepmania in general)

Update:
The StepMania 5.1 Alpha has been released so that people can start porting noteskins.

---

I tried moving the stock dance noteskins to a folder and copied all noteskins from the NewSkins folder. When in gameplay, they only show pixels. How can I make these new noteskins work?

I don't understand what you said, but old noteskins and NewSkins are 100% incompatible with each other. They have to be ported.

NewSkins load from the NewSkins folder, don't move them.
NewSkins are loaded from a different folder from the old NoteSkins because I wanted to be able to run unported themes and noteskins on 5.1 Alpha easily. So this alpha build has both the old and new systems, and you have to read the documentation that I mentioned in the release notes to see how to enable the new system.
Enabling the new system is just adding a single actor to ScreenGameplay, in any layer.:
t[#t+1]= use_newfield_actor(144)

144 is the reverse offset, the distance from the center of the field to the receptors.

---

I was supposed to test the new noteskins from the NewSkins folder. I decided to transfer all stock dance noteskins to a back-up folder and I copied everything from the NewSkins to the Noteskins/dance folder. Showed only dot noteskins.

Edit: ninja'd

Yes, that doesn't work. It will try to load them as old-style NoteSkins. You can pick a NewSkin in the options menu, I think. (I don't have 5.1 alpha installed yet).

You have to add a lua option row for picking a newskin.

Add this to the options screen metrics so players can pick a noteskin for the newfield:
LineNewSkin="lua,newskin_option_row()"
And of course edit the LineNames metric for that screen to include NewSkin.

---

In ScreenGameplay decorations.lua


in theme metric:



The Newskins were available in PlayerOptions screen. During gameplay, it still return dot noteskins.

Here is portion of log that describe the error:

1. Did you put the NoteSkins back after you realized that moving them was a mistake?

2. If ScreenGameplay decorations.lua doesn't exist, you don't have to load the fallback background background. You could just do this:
return Def.ActorFrame{use_newfield_actor(144)}

The key concept here is that the function "use_newfield_actor" returns an actor that will handle the complex part of enabling the newfield. The actor can be added wherever is convenient on gameplay. As long as its OnCommand runs, it'll run.

---

It is now working. Thanks!

I can finally port those damn noteskins I've been longing for, butterfly and classic