boq

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.

This was very likely fixed 23w06a, please post exact steps to reproduce in 23w07a or later

@unknown This bug has no known reproduction steps. Would you mind sharing how exactly did you confirm this?

Let me restate:

> there is a period of time after receiving a preview before which the preview will not be signed. This gives players time to react to a potentially malicious preview received from the server.

That means if you write a message and quickly send it, you will still sign exactly what you have written, no matter what was in preview. Which means that any tampering of that type will be visible in chat report.

If it's about development, then failing fast is better approach than requiring creators to check every provider separately - it's immediately noticeable, making it harder to accidentally release pack with undiscovered error.

And in both cases first reaction after seeing broken font should be checking logs anyway.

Only the misconfigured character should not load, do you agree?

No, I do not agree and I don't see a use case for it. Accepting partially broken data is just causing more problems.

I will ask again: why can't you just fix broken texture? Why does your setup requires game to do it for you?