mojira.dev

boq

Assigned

MC-300979 The movement and duration messages in the demo introduction screen now have a text shadow Confirmed MC-300457 Dialog is unescapable when action or exit_action is set to run_command with a command that would produce a signed chat message Fixed MC-299876 Labels for booleans within dialogs are rendered in a slightly different shade of white than normal Community Consensus MC-299548 "run_command" dialog actions don't work if chat is hidden Fixed MC-298516 While running /dialog clear and /dialog show every tick, pressing the warning button just after joining the world can crash the game Fixed MC-298492 Disconnecting through dialog in configuration phase causes the client to crash. Fixed MC-298466 When clicking the "yes" button to confirm command execution in a dialog, if the player is put into another dialog, the click sound from the "yes" button will not be played until it is closed Fixed MC-298405 Text components in the "label" of input controls in dialogs don't support "hover_event" Confirmed MC-298155 Dialog command_template using a multiline text input causes player to be kicked out of the server due to illegal characters in chat (which is \n) Fixed MC-298144 The initial value of minecraft:text input type is limited to 32 characters, regardless of max_length field Fixed MC-298104 The max_lines field of multiline text input control is unrestricted, lagging the game Fixed MC-297972 Dialog body content is misaligned Fixed MC-297917 The client stops responding when showing a dialog with an extremely wide button Fixed MC-297906 Running a command with a large output whilst on a dedicated server causes a kick and no logged output Fixed MC-297901 Upon entering a dialog while viewing the credits, the background does not reflect the current state of the world Confirmed MC-297848 The menu background is not shown for a short amount of time when leaving a world from a dialog Fixed MC-297822 Exiting a dialog by clicking a button causes any items currently being held in the cursor slot to be thrown into the world Confirmed MC-297807 Clicking "Save and Quit to Title" in the dialog warning menu takes you to the server list even if the world is singleplayer or locally-hosted LAN Fixed MC-297803 The string "menu.custom_screen_info.contents" misspells "personal" as "pesonal" Fixed MC-296866 Predicates of particular namespaces failed to be accessed on /execute Fixed

Reported

No issues.

Comments

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?

Ok, let me clarify things a bit:

  • This report has nothing to do with space providers - change was introduced in resource loading cleanup

  • Old behavior was never intended to be seen as a feature, as is any other part of pack error handling

  • Packs should always load without warnings. If your "feature" results in pack loading with a warning, it's a good indication it's not a feature at all

So far I have not seen good explanation why do you want game to accept invalid font definition. And by "invalid font definition" I mean "any provider is invalid". Because otherwise, by the same logic, you could also claim that recipes should accept invalid ingredients because "rest is fine".