Uploaded image for project: 'Minecraft (Bedrock codebase)'
  1. Minecraft (Bedrock codebase)
  2. MCPE-132441

New glowing-ink sign mechanic frustrates multicolor sign replacement

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Resolution: Duplicate
    • 1.17.0
    • None
    • None
    • Unconfirmed
    • Multiple

    Description

      As reported in other tickets, the new glowing ink sac mechanic for signs causes confusion when used with multicolor signs. In this ticket, I highlight a particular user story and suggest a new mechanic to resolve the confusion.

      Issue:

      The user has numerous signs that have multicolored text created using the § symbol. For example, the signs are used like highway signs at tunnel interchanges, so there are several signs of the same type using the same color scheme within close proximity. Many of these signs were created before 1.17. Occasionally, the user may need to replace one of the signs in order to edit its text.

      Steps to Reproduce:

      1. **Using a pre-1.17 version of Minecraft, create two adjacent signs from the same materials, placing them so they are under substantially similar lighting conditions. Use the color codes §1 through §6 to color the text of the signs, using different colors on different lines. 
      2. Load the world in 1.17.
      3. Break one of the signs.
      4. Replace the sign using exactly the same text, including the color codes.

      Expected result:

      **The re-placed sign looks identical to the existing sign.

      Actual result:

      The re-placed sign is substantially dimmer than the existing sign. If the dimmer color codes (§a-f) are used on a darker material, the writing may be illegible, especially if the user's screen brightness or contrast is low.

      While it is possible to use a glowing ink sac to make the sign match pre-1.17 sign colors, the user will be frustrated attempting this, because the glowing ink sac will refuse to apply to the sign unless it is first dyed. Dying the sign black, and then applying the glowing ink sac, may work. Even after discovering this, the user may be deeply frustrated at the need to obtain a new material in order to obtain the previous behavior.

      The user may not discover this workaround without consulting the Internet, because it's not obvious. The user may be reluctant to dye their signs, because (a) it consumes resources; (b) black ink is among the more inconvenient dyes to obtain; and (c) the user may worry that applying dye to a multicolored sign will remove the § codes (or their effects) and thus be resistant to trying the dye. (The user may also think that applying the dye could result in a new set of colors that blend the §-code colors and the dye colors, like dying leather armor.)

      Suggested change:

      Alter the way glowing ink sacs affect signs as follows:

      1. A sign that has not been dyed should be treated as if it was dyed black when acted upon with a glowing ink sac.
      2. Create slightly different mechanics for signs with and without § codes, as detailed below.

      If the sign doesn't have § codes:

      The first time a glowing ink sac is applied to it, the text is made bright ("glowing").

      The second time a glowing ink sac is applied to it, the sign itself becomes a low-intensity light source.

      If the sign has § codes:

      Any text that would be colored by a § code is rendered using the pre-1.17 intensities, regardless of whether a glowing ink sac has been applied.

      The first time a glowing ink sac is applied to it, the sign itself becomes a low-intensity light source.

      The second time a glowing ink sac is applied to it, all text on the sign, including text that is the "base" color, will use the "glowing" intensity.

       

      This revised mechanic would give the glowing ink sacs a use, while not frustrating users with a significant investment in the existing colored-text codes.

      Attachments

        Issue Links

          Activity

            People

              macwhiz Robert Levandowski
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: