[SM 5.1] New noteskin format and modifier system

That playerizing idea sounds interesting. It would require some way of specifying that certain polygons in the model are for the player texture, and a way to shift the player texture without affecting the rest of the model. That's going to be difficult.

If that's the case, it'd probably be more apposite to just have a whole group of polygons on the note that we can "turn off" in routine mode and replace with another that has the playerized textures, instead of futzing around picking individual polygons and replacing textures on them.

Basically, a really simple version of bodygroups, like in Source.

I'll look into changing the model system for that idea later. It's a good idea, it's just on the back burner for now.


For the moment, I want to talk about the Expand modifier in the old system. Part of my ongoing series of "mods in the old system behave poorly" posts.
The problems with Expand are a bit harder to spot than some. At first glance, Expand just makes the notes spread and contract, repeating every 2pi seconds, stopping during stops and delays.
But it turns out that to do this, the engine updates a global variable every frame. This variable is not reset between songs. So you play a song twice, and the Expand effect is synced to the music differently.
Additionally, stops and delays are handled by simply not updating if the frame update occurs during a stop or delay. There is no adjustment for a stop that does not begin and end on a frame boundary. So every stop causes the sync of Expand to drift by a few milliseconds.
If you try to use Expand in a gimmick simfile, and you actually care about exactly which arrows are visible, the complete lack of sync guarantee will cause problems.

This is just one example of the problems in the old system. I've made videos about Boost + speed mods acting funny, and Hidden/Sudden + offset having weird effects, and there's also the weird effects you get from setting Alternate or Cross or Split to negative values (which I don't have a video of). Hallway and Distant shift the notefield's y position. So turn them up high enough, and the field just flies off the top of the screen. Reverse makes Hallway/Distant tilt the opposite way, so you can't make an effect where the notefield is tilted and the receptors slide up and down with reverse.
Every time I look at some new part of the old system, I find some weird side effect like this. There's no sync guarantee. There's no direct control. It's just a random agglomeration of special cases that isn't suitable for general usage at all.

Edit: And then I discover the chunk of code for the column positions used by Invert. This loop runs every frame, 16 iterations per player. Even if you're playing dance single, 4 columns, this loop runs 16 iterations for you. Nothing used in the body of this loop even changes every frame. This doesn't need to update every frame, it should run once, when the steps or style is set, and be done. The effect of this instance may be small, but this is the kind of complete waste that really irritates me.

Tipsy is also not synced to the music.
(link goes to an old version of the code because I moved the tipsy code to ArrowEffects::Update to make it more efficient, and I didn't want people accusing me of screwing it up)
OpenITG has unsynced Tipsy too.

Yikes and three fuckin' quarters.

I knew about the Boost weirdness (and also discovered that Stealth is just a cranked-up Hidden rather than a visibility/transparency mod, much to my chagrin), but most of these are unpleasant surprises.

Yeah, making the mods and notefield behave consistently and have some actual extendable functionality (rather than just a bunch of slapdash, hard-coded junk) is at least as important, if not more so, than improving the noteskins.

LATE-NIGHT SYMPATHY EDIT: If I had the money I would send you a whole box of cookies

One last question: would it be possible to have two different "fallback" states for a NewSkin's quantizations?

For my first foray into making a Noteskin, I want it to alternate between two colors (namely white and gray) when it encounters multiple notes in a row that aren't in its quantization scheme. This way, even when certain notes don't have specific quant colors, they are still identifiable to a good extent.

For example (using SM5's default quants):
quintuplet 20ths would come out as ★☆★☆★|★☆★☆★|etc...
and nonuplet 36ths come out as ★☆★★☆★★☆★|★☆★★☆★★☆★|etc...

I think it'd be handy.

The system doesn't have any way to consider other notes around the one being quantized. Each note is considered in isolation, using only the beat it occurs on (and mods that multiply and offset the quantization).
I could extend the system to have multiple fallback quantizations, and cycle through them as needed.

I could extend the system to have multiple fallback quantizations, and cycle through them as needed.

Yeah, that's what I meant. Not actually counting anything, just cycling through the fallbacks until it gets back to a "known" note. Sorry, I'm bad at explaining stuff.

Also I'm pretty sure my old janky laptop has a short in it, RIP
Stuck in phone 4 now

Okay, so dragging my portable drive all over the place, I've been making significant progress on my first noteskin concept. It's going to be pretty similar to hanubeki, that is, a no frills universal noteskin, but made out of simple vector shapes instead, with a bit more variety and faithfulness to the presentation of the original games which SMs game modes are based on (for example, kb7 will have wide notes in the 4th lane like O2Jam). The biggest difference however, is that this noteskin attempts to occupy a happy medium between quant-colored and lane-colored noteskins. Notes are mainly quant-colored, but have a lane-colored outline applied via a mask, so that both position and timing information is represented succinctly. I would also at the least like an "inverted" variant of the noteskin where are the lane color is primary, and quantization is applied with the mask outline (this would be great for PIU and beatmania players, who usually play with lane colors only).

I already have all of the "point" notes done and am starting to think about hold/roll/lift bodies, and even write bits and pieces of the lua. However, digging through the NewSkins that exist, there seem to be three major hurdles to what I want:

1. Nothing in the Lua suggests that masks are actually usable for anything like applying static or quantized colors, only playerising notes. This obviously torpedoes my coloring idea. Of course I can always make more state maps "baking" the outlines into all the notes, but another major principle of this skin is to keep things light, not using a lot of data. Having to make both quantized outline state maps and lane outline state maps for every single note graphic would make things pretty large, and things would only get worse if I add more quantizations.

2. Speaking of playerization, my original idea was to make small colored disc graphics with 1p, 2p, etc. on them and then overlay them on the notes, (kinda like that one series of PIU routine skins.) But I'm not sure how that would work since overlaying a non-note graphic on a note isn't a thing. And I can't pre-bake that, since it needs to be independent of note orientation.

3. I know there can be non-note things programmed into a noteskin like column flashes and stuff, but those are tied to certain note events. I'm not sure if we can create thing in the notefield that have nothing to do with notes at all. For example in a note skin for keyboard play (and hopefully, a "ksmash" game type I will develop for SM6, to separate pad & KB play) I'm hoping to add a "hand separator" line to the receptor area, for both this noteskin and others. Think of it as replacing the color split in "retrobar_splithandwhiteblue", getting the same information across while being freed to use other lane colors, or even no lane colors at all.

1. Masks are half-baked because I didn't have a strong guideline for what they should do or how to implement them. I'm not even sure they're a good way to do anything.

2. This goes beyond what I had considered. Quantization and playerization need some kind of rethink.

3. Maybe the noteskin needs to have something equivalent to the NoteField layers file that is in the theme. You could stick something in the receptor for the middle column off to the side.

I'm leaning towards letting noteskin stuff as-is for a couple months while I work on stuff like score data and people discuss what a noteskin needs to be capable of.