Granular Sign Formatting.
Pheotis opened this issue ยท 13 comments
Priority SGKV Parity Feature: Colours.
By default, user-specified foreground (light) & background (dark) config options are used to colour signs.
An enum designates all signs as dark (defaulting to the foreground colour) or light (defaulting to the background colour).
Although simpler than SGKV's solution, is it less capable.
As such, SGKV's solution must be available for advanced users, probably as a hidden config option.
foregroundSignColorOverride:
- birch: DARK_BLUE
- spruce: INVERT
- warped: (B0F6FF)
- dark_oak: (244, 247, 158)
backgroundSignColorOverride:
- birch: RED
- spruce: DEFAULT
- warped: (B0F6FF)
- dark_oak: (244, 247, 158)Also, the migrator will need to be updated to import knarvik's color data as hidden configs when applicable
IIRC, the existing pointer/listing system was implemented to allow users to modify how prominently gate types colour-code.
The default was originally a bit controversial, so the customization option was made rather prominent.
It helped that it was a single integer config value, and that it could be explained with a short comment.
One of the limitations of a default-level config toggle is that it needs to be simple, intuitive, short, and documentable via a short (one or two line) comment. Under that limitation, it is difficult to make a truly capable advanced colour management system.
Whereas the pointer/listing/foreground/background system encompasses four lines of yaml and 8 lines of comments, an expandable custom colour system could easily swell to 46+ config lines and require a lengthy explanation comment.
For that reason, I think custom colours are a bit more suited to a hidden config section.
signColorOverrides:
- birch: INVERT
- spruce:
- foreground: (FFF2C4)
- background: (244, 247, 158)
- pointer: 3
- glow_ink_colour: MAGENTA
- warped:
- foreground: (82FFFF)
- glow_ink_colour: GREEN
- dark_oak:
- foreground: (D0D7F7)
- background: BLUE
I don't see why color per sign type deserves to be any more hidden than pointer and listing. The colors are overridden by dye if applied anyways. We could use foreground/background instead of default/inverted to prevent any confusion.
Per-type-colors allows for sign colors that are readable by default (assuming the colors have been changed by an admin), without requiring players to waste dye.
signColorOverrides: - birch: INVERT - spruce: - foreground: (FFF2C4) - background: (244, 247, 158) - pointer: 3 - glow_ink_colour: MAGENTA - warped: - foreground: (82FFFF) - glow_ink_colour: GREEN - dark_oak: - foreground: (D0D7F7) - background: BLUE
I'm not sure birch: INVERT should be allowed, as that implies some arbitrary way of deciding if that changes the foreground color, background color or both. It also implies birch: YELLOW is valid, but doesn't say anything about which color is changed to yellow.
Allowing pointer/listing per sign-type seems interesting, but is perhaps a bit overkill.
I'm not sure what glow_ink_colour is supposed to mean. Are you saying we should allow setting the color the glow effect is designed around if not dyed? Can we even do that?
I only see the need for this to be valid:
signColorOverrides:
- spruce:
- foreground: #FFF2C4
- background: #f4f79e
- warped:
- foreground: #82FFFF
- dark_oak:
- foreground: #D0D7F7
- background: BLUE
Could we make an exception for the SG-Command add-on and leave the per-sign-colors non-hidden? While they are potentially confusing to edit by hand, changing the colors with tab-completable commands and command help info is just as easy as changing any other config option.
I'm not sure birch: INVERT should be allowed, as that implies some arbitrary way of deciding if that changes the foreground color, background color or both.
Currently, we have an enum somewhere that designates all signs as either a DARK_SIGN or a LIGHT_SIGN.
For DARK_SIGNs, the foreground is the primary colour and the background is the secondary colour.
For LIGHT_SIGNs, the foreground is the secondary colour and the background is the primary colour.
I believe that INVERT should simply override our enum and force a specific sign type to be the opposite type.
birch is a LIGHT_SIGN, however, if someone adds birch: INVERT, we should treat it as a DARK_SIGN.
It also implies birch: YELLOW is valid, but doesn't say anything about which color is changed to yellow.
True, that will always be a problem; although we can caution against it in the documentation, someone is bound to do it.
Since this is an advanced/hidden config, we can probably just make both the foreground and the background YELLOW.
Allowing pointer/listing per sign-type seems interesting, but is perhaps a bit overkill.
This is perhaps overkill, but if the point of ColourOverrides is to allow as much customisation as possible, I think it wouldn't be a stretch to support these.
I'm not sure what glow_ink_colour is supposed to mean. Are you saying we should allow setting the color the glow effect is designed around if not dyed? Can we even do that?
Yes; we can set the colour of the glow effect, even if it is not dyed.
I only see the need for this to be valid:
- spruce: - foreground: #FFF2C4 [...]
#FFF2C4 is a comment in yaml; which is a problem unless we force our users to escape their number signs (#).
Could we make an exception for the SG-Command add-on and leave the per-sign-colors non-hidden? While they are potentially confusing to edit by hand, changing the colors with tab-completable commands and command help info is just as easy as changing any other config option.
Definitely.
#FFF2C4 is a comment in yaml; which is a problem unless we force our users to escape their number signs (#).
- OAK:#f4cccc,#CCF4CC works perfectly fine in my fork, but I'm guessing that's because it's part of a string not beginning with #. We could always automatically escape the # in SG-Command, or use &#FFF2C4 like some plugins use.
If we go to this extent of customization, shouldn't we also allow customization of the colors used for the different portal types? We should allow both setting the default type colors for foreground and background, as well as setting the portal type colors for each specific sign type. An important argument for allowing those to be customizable is to be able to choose colors differentiable by users with different types of color blindness.
If we go to this extent of customization, shouldn't we also allow customization of the colors used for the different portal types? We should allow both setting the default type colors for foreground and background, as well as setting the portal type colors for each specific sign type. An important argument for allowing those to be customizable is to be able to choose colors differentiable by users with different types of color blindness.
This has been on the to-do board for a while, but we had put it on hold until the gatefile rework.
(it was planned as text overrides to be inserted into the gatefiles themselves).
Definitely something we could do though, perhaps something like this?
signColorOverrides:
- birch: INVERT
- spruce:
- foreground: (FFF2C4)
- background: (244, 247, 158)
- pointer: 3
- glow_ink_colour: MAGENTA
- warped:
- foreground: (82FFFF)
- glow_ink_colour: GREEN
- dark_oak:
- foreground: (D0D7F7)
- background: BLUE
- gate_file_name:
- foreground: (FFF2C4)
- background: (244, 247, 158)
- pointer: 3
- glow_ink_colour: MAGENTADefinitely something we could do though, perhaps something like this?
signColorOverrides: - birch: INVERT - spruce: - foreground: (FFF2C4) - background: (244, 247, 158) - pointer: 3 - glow_ink_colour: MAGENTA - warped: - foreground: (82FFFF) - glow_ink_colour: GREEN - dark_oak: - foreground: (D0D7F7) - background: BLUE - gate_file_name: - foreground: (FFF2C4) - background: (244, 247, 158) - pointer: 3 - glow_ink_colour: MAGENTA
I'm not talking about per-gate colors. I'm talking about these:
private static void loadFlagColors() {
flagColors = new HashMap<>();
flagColors.put(PortalFlag.BACKWARDS, new ChatColor[]{ChatColor.of("#240023"), ChatColor.of("#b3baff")});
flagColors.put(PortalFlag.FORCE_SHOW, new ChatColor[]{ChatColor.of("#002422"), ChatColor.of("#b3fffc")});
flagColors.put(PortalFlag.HIDDEN, new ChatColor[]{ChatColor.of("#292800"), ChatColor.of("#fffcb3")});
flagColors.put(PortalFlag.FREE, new ChatColor[]{ChatColor.of("#002402"), ChatColor.of("#b3ffb8")});
flagColors.put(PortalFlag.PRIVATE, new ChatColor[]{ChatColor.of("#210000"), ChatColor.of("#ffb3b3")});
flagColors.put(PortalFlag.FANCY_INTER_SERVER, new ChatColor[]{ChatColor.of("#240023"), ChatColor.of("#FFE0FE")});
}I'm not talking about per-gate colors. I'm talking about these:
Ah. That could also work... something like this?
signColourOverrides:
- spruce:
- foreground: (FFF2C4)
- background: (244, 247, 158)
- pointer: 3
- glow_ink_colour: MAGENTA
flagColourOverrides:
- a:
- foreground: (FFF2C4)
- background: (B3FFB8)
- b:
- foreground: (210000)
- background: LIGHT_BLUE
```More like this, as we could allow setting the color for each sign:
signColourOverrides:
- spruce:
- foreground: (FFF2C4)
- background: (244, 247, 158)
- pointer: 3
- glow_ink_colour: MAGENTA
- flags:
- a:
- foreground: (000FFF)
- background: (FFF000)
flagColourOverrides:
- a:
- foreground: (FFF2C4)
- background: (B3FFB8)
- b:
- foreground: (210000)
- background: LIGHT_BLUE
```More like this, as we could allow setting the color for each sign:
Sounds like a plan!
Another, possibly neater, option is to expedite https://github.com/stargate-rewritten/Stargate-Webserver/issues/1 and solve it with that.