Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Improve UI skin modding support #12500

Open
2 tasks done
GGGuenni opened this issue Nov 19, 2024 · 0 comments
Open
2 tasks done

Feature request: Improve UI skin modding support #12500

GGGuenni opened this issue Nov 19, 2024 · 0 comments

Comments

@GGGuenni
Copy link
Collaborator

GGGuenni commented Nov 19, 2024

Before creating

  • This is NOT a gameplay feature from Civ VI, BNW, or outside - see Roadmap
  • This is NOT a gameplay feature from Vanilla Civ V or from G&K - If so, it should be a comment in Missing features from Civ V - G&K #4697

Problem Description

The modding support for UI skins lacks a lot of usefulness and feels really clunky when used

I still think the UiElementDocsWriter is essential for the UI Skin mod support but the table didn't really feel useful while working with it.

Issue 1: Copying the whole UI element path out of the table for every element is really cumbersome.
-> The Table should probably only contain the whole path (e.g. MainMenuScreen/MenuButton) or it should just be a link to a formatted json containing all the skinVariants so it can easily be used to start a new mod.

Issue 2: Having all states of a UI element being different skinVariants feels kinda confusing. Also having skinVariants that only take tint into account and ignore the rest is even more confusing
-> Each SkinVariant should should specify one UI element with all its states

Issue 3: Most UI elements have no way to modfiy their font and icon colors
-> This one is a really big limitation of the current version. Preferable there would be a way to define a default color that is used by all states of the UI element and a way to specify different colors for different states.

Related Issue Links

No response

Desired Solution

The json mod structure I am aiming for for skinVariants:

{
    "skinVariants": {
        "MainMenuScreen/MenuButton": {
            "foregroundColor": Color
        },
        "PolicyScreen/PolicyButton": {
            "image": "imagepath",
            "imageTint": Color,
            "foregroundColor": Color,
            "iconColor": Color,
            "states": {
                "notPickable": {
                    "imageTint": Color,
                    "foregroundColor": Color,
                    "iconColor": Color,
                },
                "notPickableSelected": {
                    "foregroundColor": Color
                }
            }
        }
    }
}

The big question is how to generate docs for such a structure (or the mod boilerplate of the structure itself) without being a burden for everyone working with UI stuff in Unciv (looking at the getUIColor comments in PolicyPickerScreen).

My plan would be to update existing calls to stuff like Table() (e.g. MainMenuScreen.kt l91) to use a class (e.g. ModdableTable) that is used to define default values and to generate the docs (Similar to BorderedTable.kt). For doc generation, I'm currently looking into KSP if it could be (mis)used as a feasible solution that removes regex limitations like having to pass parameters as Strings or ints instead of variables to improve the development experience.

Alternative Approaches

Well as pointed out in #11124 dropping skinning support all together would remove the need to do anything really. I'm not entirely sure if the lack of skin mods comes from no one interested in them, there not being a good example to work from or the mod support being too limiting. I think it would be sad to drop them, but I mean if no one is using it and it just increases code complexity then ¯\(ツ)

Additional Context

Input welcome if UI Skins should be pursued any further or get dropped all together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant