So, while working with the scripting API, I’ve noticed that when a color is customized with the color picker so that it no longer matches any color in the palette(the red box with the exclamation point appears), Aseprite tries to assign the color to the index that is nearest its color value. If it can’t find a similar color, or if all colors are the same, it gives it an index of 1.
I don’t know if this is a bug, or the intended behavior, but when using app.fgColor.index and app.bgColor.index commands it can really mess up what colors the API is editing with Palette:getColor() and Palette:setColor(). This is creating a bug where editing a color in a scripted color picker can cause Aseprite to jump to different index positions and begin editing colors that weren’t meant to be edited.
Is there a way that Aseprite can assign an index number equal to #palette to custom colors since the palette only goes to #palette - 1? That way, a scripter can check if the index is indeed equal to #palette and therefore a custom color not indexed in the actual palette.