It is possible to make signs dyed with any color dye glow, but if a sign is only colored using the § symbol and corresponding codes, neither ink sac does anything. If a sign is bolded/italicized using § codes, dye can be used to color it, then it can be glow-ified.
It should also be noted that a normal ink sac will not darken an already glowing sign made pre-1.16.220.
This is an issue for mapmakers & builders using multicolored signs as they are still illegible.
After some further testing:
if dye is used on a sign w/ formatting codes, any black text not explicitly coded will change color and it will be possible to glow-ify the sign
this seems to be because ink sacs will not do anything to signs that the game thinks are black
What should happen:
It should be possible to glow-ify colored signs regardless of the method used to color them
The colored sections of signs should glow even if there is uncolored text on the sign
What actually happens:
Only signs colored with any dye can have a glow ink sac used on them, making multi-color signs difficult/usually illegible.
Attachments
Comments 7
The changes you've made to the description are closer, but still not quite right. It's not that "ink sacs will not do anything to signs that the game thinks are black". The issue is that the formatting color codes encode both the hue and the brightness, and the changes that the dye makes to the "regular" hue and brightness don't override them. I believe that's by design, because the "regular" properties are generic while the formatting codes are specific, and you normally expect a specific setting to override a generic one.
To be exact, the formatting color codes are §0–§f. The code value is a hexadecimal digit representing the 16 numbers from 0 to 15. When translated from hexadecimal to binary, bits 0–2 specify the hue and bit 3 specifies the brightness. This means that "gold" (encoded as §6) is the dark brightness of "yellow" (encoded as §e, hexadecimal for 14). In other contexts, these colors might be named "brown" and "yellow", or "yellow" and "bright yellow"
The formatting codes for bold, italic, etc. don't override the sign's "regular" hue and brightness because they have nothing to do with color.
Since the way it currently works is fairly easy to explain and obeys a consistent internal logic, I'm pretty sure it's working as intended. In that case, which means that your "what should happen" expectations would constitute a request for a feature change. However, if you prefer to submit this and wait several weeks or months for Mojang to tell you so explicitly rather than submit a feature request on the Feedback site, we can do that, too. Just say the word.
In the meantime, I'm closing this as Awaiting Response in case you decide to submit the feature change request and don't respond. If you do, this ticket will automatically reopen.
If, when you say glow ink sacs change brightness, you mean to the brighter color (eg §2 [green] -> §a [light green]), that's not what I've seen; the glow ink sac only seems to affect the "luminosity" of the text on the sign, a separate property not applicable to small sections, related to color, or given a code. If I misunderstood you, correct me.
The sign on the right is fully visible in the dark, as opposed to the sign on the left. Despite them having the same color codes (these two just had white dye applied), the right sign does have a different "luminosity" value.
[media]
I think the issue could still be identified in not being able to dye "black" signs, or just that the game doesn't make a distinction between plain black signs and color-coded signs. If I need to make a feedback post instead of a bug report I can; but I also view this as MCPE-117516 not really being fully fixed & maybe even a parity issue (see MCPE-129123 & duplicates).
I think I know what causes this. This may be the issue of being unable to use glow ink sacs on undyed signs. Try dyeing the sign first (even though it won't be displayed, since the text already has a set color), and THEN applying the glow ink sac.
Either way, it was fixed in the beta before this was even reported.
Just tested, I was right. This is not really what Auldrick is describing, it quite simply is caused by the inability to use glow ink on undyed signs in general.
In fact, formatted colors will actually have unique tones as well.
Here's an update so you don't think we've stalled out on you. I've talked at length with LateLag on our mods channel, and now I understand that my model for how sign colors work is flawed. It's only a small flaw, but the consequence is that it actually is possible to apply glow ink sacs to brighten the color of text governed by a formatted color code (except if it's black). To make things even more complex, Mojang made changes to how it works in each one of the last few Beta releases, so I need to figure out which of those changes made it into 1.17.0, which additional ones have already been fixed in the current Beta, and whether anything you're reporting in this ticket still needs a bug report (versus all of it already having been fixed in later Betas). As I'm sure you can guess, we're kind of busy here since we just had a new release (lots of new bug reports), so please be patient while I work this out. Thanks!
Definitely a problem if you destroy and remake a multicolored sign that's next to another sign using the same color codes. The newly (re)placed sign will have text that's noticeably less luminant than the existing sign, even though it uses the exact same color codes.
The fact that you now have to consume glowing ink sacs to get the signs to visually match is one problem.
The fact that it's not at all clear how to even apply a glowing ink sac to a multicolored sign (e.g., the apparent need to dye it first) is another problem.
The combination of these two issues creates substantial user confusion and irritation.
Partially confirmed in 1.17.0 on Windows 10. However, I think you're misunderstanding what's happening.
To start, lets establish some terminology. Text colors come in 8 hues: black, blue, green, aqua (cyan), red, purple, gold (yellow), and gray (white). Each of these has two brightness levels, dark and bright.
Signs have separate properties for what I'll call the "regular hue" and the "regular brightness". "Regular" in this context means that these properties are applied to text by default, that is, to text which you haven't specified any particular color for.
The § formatting color codes, on the other hand, are how you specify a particular color for a portion of text, starting with the code and ending with either a §r reset code, the next color code, or the end of the text. The § color codes allow you to have text portions of different hues and/or brightnesses on the same sign. Since they are more specific then the regular hue and brightness, the formatting color codes override the regular properties.
With this understanding you should be able to see what's happening now:
Dyes change the sign's regular hue.
Glow ink sacs set the sign's regular brightness to bright.
Black ink sacs set the sign's regular brightness to dark.
None of these items affect text governed by formatting color codes. For those, you have to remake the sign to change the colors. However, a sign that contains a mixture of text covered and not covered by formatting color codes will be partially affected.
There's one more thing to note: Because black ink sacs are co-opted to reset the regular brightness to dark, they cannot be used to turn the text black; you have to use actual black dye for that. This is the only exception I know of to the rule that bone meal, ink sacs, lapis lazuli, and cocoa beans can be used anywhere as a substitute for the corresponding dye colors.
With this explanation in mind, do you still think there's a bug? If so, you may want to revise your description and summary for clarity.