[Should Have] - Generating styles through Lua entirely

[Zly-u]

For example setting background panel colors individually by index through lua and etc.

[Morxemplum]

I don't think this is a must have. That's absurd. It's a Could Have at most.

[AlphaPromethium]

Should Have*

[Morxemplum]

Even then we shouldn't necessarily get rid of Style JSONs entirely. It makes it a lot easier to hot swap styles.

[Zly-u]

Considering how many people(including me) wanted this functionality I made it as "must", but you do you.

[Morxemplum]

Looking back on this now I don't necessarily think that we should initialize styles through Lua (but hey, you do you) but I do think that it will be useful to be able to manipulate more style attributes through Lua, such as the background panel, main, text, and player colors, along with 3D override color. I'll storyboard out some Lua functions that will try to accomplish this feat with the most intuitive design.

[Morxemplum]

Alright so the best way to go about this design-wise is to try and use named arguments, which I think is the easiest way to try and do this on Lua's end. This is the best design choice because it allows pack developers to modify styles without implementing too many different Lua functions dedicated to setting color, while at the same time offering the most flexibility on tweaking individual attributes of a color in a similar way to how it is done in a style JSON.

Like how the engine parses the JSON, we want to have fallback values for any attributes that are not given through the named arguments. We can just simply refer to the JSON parsing code to use for the fallback values of any attributes that are not given.

Given below is a Lua "pseudocode" example of how the Lua syntax would work, but of course the actual function implementation will have to be done through C++, not Lua. The most relevant part of the code block are the function calls themselves.

-- For Style setting functions that will require an index
function setBGColor(index, colorProperties)
        colorProperties.optional = colorProperties.optional or "Fallback value"
        print(index);
        print(colorProperties.value)
        print(colorProperties.valueTwo)
        print(colorProperties.optional)
end

-- For Style functions that only focus on the color properties
function setMainColor(colorProperties)
        colorProperties.dynamic = colorProperties.dynamic or false;
        colorProperties.color = colorProperties.color or {0, 0, 0, 255};
        colorProperties.pulse = colorProperties.pulse or {0, 0, 0, 0};

        print("Dynamic: "..tostring(colorProperties.dynamic));
        local colorString = "Color: {";
        for i = 1,#colorProperties.color do
                colorString = colorString..colorProperties.color[i]
                if (i ~= #colorProperties.color) then
                        colorString = colorString..", "
                end
        end
        colorString = colorString.."}";
        print(colorString)

        local pulseString = "Pulse: {";
        for i = 1,#colorProperties.pulse do
                pulseString = pulseString..colorProperties.pulse[i]
                if (i ~= #colorProperties.pulse) then
                        pulseString = pulseString..", "
                end
        end
        pulseString = pulseString.."}";
        print(pulseString)
end

-- How these functions will be called
-- For the index, traditional parentheses are used. The first argument is an integer that is required. The second argument is a table filled with different named parameters that will be used to set the color information
setBGColor(1, {value = 10, valueTwo = "Cake"});
print()
-- This function only needs color information, as index doesn't matter here. You can use Lua's table calling trick to accomplish this easily
setMainColor{color = {255, 0, 0, 255}, pulse = {0, 255, 0, 0}};

[Morxemplum]

We're actually revisiting this, because now with manual style control, that makes this possible to accomplish. Which mean this will be addressed soon. I think we'll need to still work with the finer details.

In all honesty, I think we should get rid of a lot of the attributes with dynamic colors. They make JSONs unorganized and can be hard to memorize. I personally would just repurpose the "color" field to parse HSVA instead of RGBA. It would remove almost all of the dynamic properties entirely.