boq

Can’t reproduce, unless I turn below option on. Do you have it enabled?

Could you clarify step 2? On macOS (and most other systems) there is a difference between switching to a specific keyboard layout and a specific input mode (usually started with a specific key or key combination like Kana key or Alt+apostrophe - see https://support.apple.com/en-gb/guide/japanese-input-method/jpimf6ffb247/mac). Switching to IME input mode is treated as user intention to type text instead of sending game inputs.

Incomplete information: please clarify if it’s about preedit window (text in green border) or candidate popup below (which is known to sometimes hide behing game window). Or preferably attach a video of you typing.

Right now, I can’t reproduce it:

Glowing color is controlled by color field next to has_glowing_text and not by style of any of lines. Since this field it’s omitted here, it defaults to black, which for usability reason it renders as off-white.

Sprite was moved to different atlas, command is missing “atlas":"items"

You seem to be writing those files in your local encoding/codepage (Windows-1252? ISO/IEC 8859-1?).

This not supported, game always expects all text files to be encoded in UTF-8.

Both commands actually fail, but error is hidden due to how /execute works (it would be visible with trace command)
In future we are likely to instead make command not compile at all on missing function.

Does this issue still appear on updated JVM? Crash report should end it "vm_info: OpenJDK 64-Bit Server VM (21.0.7+6-LTS)"

Could you provide contents of any of those? It’s not clear what exactly crashes (game or launcher)?

Note: closer to “won’t fix”, legacy formatting characters are not supported.

Suggested steps and “expected” section are bit mismatched, behavior as described is unchanged from 1.21.4. World reload always clears in-memory values, so the change was only affecting /data modify, which in 1.21.5 got changed, per changelog: - The `ItemDropChance` field now defaults to `1.0` if not specified

The fix makes both `ItemDropChance` and `ItemRotation` (not reported, but had same issue) written independently from item state.

Debug world-only issue: light is preserved from previous version, but actual blocks change, so positions that changed from solid to non-solid are dark.

Running "Erase Cached Data" fixes it.

The changelog for 24w37a specified that minecraft:item_name has lowest priority, so this issue is no longer valid and can't be reopened.

Resolved, except for signs

It seems attached file has some trailing junk (probably a header packet from some other stream). We've recently swapped Ogg decoders and non-compliant files are no longer accepted.

Is it also happening without minecart experiments turned on?

For future reference: it was a combination of MC-272333 and spawnRadius gamerule set to 1000

The issue is caused by this entry in advancements/<uuid>.json

"bengamin98:#crafting_datapacks": {
    "criteria": {
      "View": "2022-07-05 14:44:45 -0500"
    },
    "done": true
  },

Same data would not load in 1.18 and probably many versions before it.

As far as I can tell, this is a manual change done in external editor, so unless that happened entirely in game (i.e. somehow that wrong name migrated from included packs to player data instead of being rejected) this bug seems invalid.

Only \u0000 can be used for padding, updated log message

Same root cause as MC-162693.