liach
- liach
- liach
- America/Los_Angeles
- Yes
- No
MC-148612![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
MC-164864![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
Example: Given two functions:
liach:output
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlfunction liach:output/doliach:output/do
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlsay Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,
MC-143266,andMC-1269at the same time. Will update when I get progress.46As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
Example: Given two functions:
liach:output
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlfunction liach:output/doliach:output/do
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlsay Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
Unable to find source-code formatter for language: text. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,
MC-143266,MC-143269, andMC-126946at the same time. Will update when I get progress.
As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
Example: Given two functions:
liach:output
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlfunction liach:output/doliach:output/do
Unable to find source-code formatter for language: mcfunction. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlsay Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
Unable to find source-code formatter for language: text.Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
Unable to find source-code formatter for language: text.Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
Unable to find source-code formatter for language: text.Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,
MC-143266,MC-143269, andMC-126946at the same time. Will update when I get progress.As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
Example: Given two functions:
liach:output
function liach:output/doliach:output/do
say Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,
MC-143266,MC-143269, andMC-126946at the same time. Will update when I get progress.
As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
Example: Given two functions:
liach:output
function liach:output/doliach:output/do
say Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,
MC-143266,MC-143269, andMC-126946at the same time. Will update when I get progress.As the title says, Function command returns wrong number of commands executed for embedded functions.
As far as I see, this wrong number of command is considered by the maxCommandChainLength game rule.
A data pack to replicate this issue is available in the attachment section here. (dp.zip)
Example: Given two functions:
liach:output
function liach:output/doliach:output/do
say Expected to have 2 commands ran in the function liach:outputExecution result of liach:output (Looks wrong)
[liach] Expected to have 2 commands ran in the function liach:output Executed 3 commands from function 'liach:output'Execution result of liach:output/do (Looks right)
[liach] Expected to have 2 commands ran in the function liach:output Executed 1 commands from function 'liach:output/do'What I expect for execution result of liach:output
[liach] Expected to have 2 commands ran in the function liach:output Executed 2 commands from function 'liach:output'The data pack containing these 2 functions is attached below (note that there is a few unrelated functions for testing other bugs)
I am working on a solution that fixes this bug,MC-143266,MC-143269, andMC-126946at the same time. Will update when I get progress.
When typing arguments for a node that has no suggestions, now the command suggestion will just report and error instead of showing the string representation of the command node that the user is completing.
Before: (tested in 19w36a) when typing /help and a space, [<command>] text floats in the suggestion area
Now: (19w46a) when typing /help and a space, an error is displayed instead.
Same thing can be replicated to other argument nodes without proper suggestions, like the path or scale for /data get or /function etc.
This "incorrect argument" report IMO is partially intended as 19w46b aims to show this error in command blocks (trailing spaces do break commands in command blocks); imo a best solution is to have the error and the suggestion both presented on client, and only present the error for command function parsing.
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Step of checking for the latest version:
- Go to https://piston-meta.mojang.com/mc/game/version_manifest_v2.json to find the latest list of versions. It is already sorted, with latest at top.
- Follow the URL given by the "url" field in the latest version, such as https://piston-meta.mojang.com/v1/packages/177e49d3233cb6eac42f0495c0a48e719870c2ae/1.21.json for 1.21.
- Search for the string "client_mappings" or ""
Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Step of checking for the latest version:
- Go to https://piston-meta.mojang.com/mc/game/version_manifest_v2.json to find the latest list of versions. It is already sorted, with latest at top.
- Follow the URL given by the "url" field in the latest version, such as https://piston-meta.mojang.com/v1/packages/177e49d3233cb6eac42f0495c0a48e719870c2ae/1.21.json for 1.21.
- Search for the string "client_mappings" or "
"Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Step of checking for the latest version:
- Go to https://piston-meta.mojang.com/mc/game/version_manifest_v2.json to find the latest list of versions. It is already sorted, with latest at top.
- Follow the URL given by the "url" field in the latest version, such as https://piston-meta.mojang.com/v1/packages/177e49d3233cb6eac42f0495c0a48e719870c2ae/1.21.json for 1.21.
- Search for the string "client_mappings" or "server_mappings", find the item, and follow the URL given by the "url" field, such as
Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Step of checking for the latest version:
- Go to https://piston-meta.mojang.com/mc/game/version_manifest_v2.json to find the latest list of versions. It is already sorted, with latest at top.
- Follow the URL given by the "url" field in the latest version, such as https://piston-meta.mojang.com/v1/packages/177e49d3233cb6eac42f0495c0a48e719870c2ae/1.21.json for 1.21.
- Search for the string "client_mappings" or "server_mappings", find the item, and follow the URL given by the "url" field, such as
Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
The obfuscation mappings released has
# (c) 2019 Microsoft Corporation. All rights reserved. ...for the first line (license statement). Yet for all versions released in 2020 up to 20w06a (including releases and combat tests) with obfuscation mappings, the statement still declares 2019 as the copyright year.
The year needs to be updated.
Step of checking for the latest version:
- Go to https://piston-meta.mojang.com/mc/game/version_manifest_v2.json to find the latest list of versions. It is already sorted, with latest at top.
- Follow the URL given by the "url" field in the latest version, such as https://piston-meta.mojang.com/v1/packages/177e49d3233cb6eac42f0495c0a48e719870c2ae/1.21.json for 1.21.
- Search for the string "client_mappings" or "server_mappings", find the item, and follow the URL given by the "url" field, such as https://piston-data.mojang.com/v1/objects/0530a206839eb1e9b35ec86acbbe394b07a2d9fb/client.txt
- Notice at the top of the txt file, the copyright year is still 2020, despite the version being released in 2024
Example: 20w06a client mapping file at https://launcher.mojang.com/v1/objects/63730ce216258836ad23e794ee3487b45d83ca52/client.txt
When using command like
/tellraw @s {"text":"abc","strikethrough":true,"underlined":true}Observe that the rendered text is problematic.
The strikethrough formatting is not rendered for the last entry of the chat hud and the underline formatting is not rendered for the second last entry of the chat hud.
This rendering problems happens as well if the custom text only has strikethrough or only has underlined as well; it is not caused by having two together. e.g.
/tellraw @s {"text":"abc","strikethrough":false,"underlined":true} /tellraw @s {"text":"abc","strikethrough":true,"underlined":false}Did not take a screenshot with f3 because there is another bug where characters lose bits when f3 screen is on, so a screenshot without f3 demonstrates the bug best
When using command like
/tellraw @s {"text":"abc","strikethrough":true,"underlined":true}Observe that the rendered text is problematic.
The strikethrough formatting is not rendered for the last entry of the chat hud and the underline formatting is not rendered for the second last entry of the chat hud.
This rendering problems happens as well if the custom text only has strikethrough or only has underlined as well; it is not caused by having two together. e.g.
/tellraw @s {"text":"abc","strikethrough":false,"underlined":true} /tellraw @s {"text":"abc","strikethrough":true,"underlined":false}Did not take a screenshot with f3 because there is another bug
MC-179839where characters lose bits when f3 screen is on, so a screenshot without f3 demonstrates the bug best
The order in which tagged functions are invoked is not consistent across reloads. The game respects neither the order in which datapacks are enabled nor the order of functions within the tag's definition.
Expected results
The expectation is that the invocation order remains consistent across reloads:
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3
See also dinnerquote.png
, which is meant to serve as an alternate explanation of the expected behaviour and not an official piece of evidence.
Actual results
As evident in reload.png
, the tag order is shuffled arbitrarily each time datapacks are reloaded. One iteration yielded the following output:
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2
Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tick
Given that foo and bar are defined in two separate datapacks, we can deduce two problems:
- Datapack ordering is not respected; otherwise all invocations of foo functions should come before those of bar.
- Function order within the tag definition is not respected; otherwise foo:load1 should be invoked before foo:load2, which in turn should be invoked before foo:load3.
How to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
into a world's datapacks folder and running /reload repeatedly. (Datapacks are also available on GitHub.)
Code Analysis
Code analysis by liach can be found in this comment
The bug
The locate command always returns "Could not find that structure nearby" even when the structure is right below you.
Affected structures
- Ocean monuments
- Ocean ruins
- Shipwrecks
- Igloos
- Desert pyramids
- Jungle temples
- Witch huts
How to reproduce
- Enter singleplayer
- Create superflat world with preset:
minecraft:bedrock,38*minecraft:stone,5*minecraft:dirt,5*minecraft:sand,110*minecraft:water;minecraft:deep_ocean;oceanmonument,decoration,stronghold,mineshaft,dungeon
- Enter /locate Monument
Code analysis
Code analysis by liach can be found in this comment.
The bug
When you spawn in a villager with an egg, it has a profession, but if you breed / use a spawn egg the villager will make a villager that has the old farmer skin, but when it grows up it has no profession, and no trade. And this 'non-villager' seems to be dominate ( always a non-villager ) when having a kid.
Code analysis
Code analysis by liach can be found in this comment.
Zombie villager fixed in 19w03b.
The bug
Functions can skip intermediate nested functions if maxCommandChainLength (-1) commands are already queued.
While it is generally problematic when a function stops midway due to this gamerule, this specific behavior for nested functions is even more problematic:
A >B >C D
Here the main function executes A, then a nested function containing B and C, and then D. Due to the behavior described above, it is possible that B and C are skipped, but D is executed. This can cause quite some problems when D relies on B and C having run before.
How to reproduce
- Download the attached datapack MC-143269.zip and place it in the datapacks folder of your world
- Decrease maxCommandChainLength
/gamerule maxCommandChainLength 3
- Run the function test:run_nested
/function test:run_nested
→
It does not display "Nested", but it does display "Requiring nested"
Code analysis
The following is likely outdated, please also have a look at liach's patch.
See net.minecraft.advancements.FunctionManager.execute(FunctionObject, CommandSource)
This could be solved by removing the check at the beginning and always adding the nested function to the queue.
The loop removing the queue elements could also be improved by passing
maxChainCommandsCount - executedCommandsCount - 1
to the execute method of the queued command instead of maxChainCommandsCount.
With maxChainCommandsCount = MCP: i; executedCommandsCount = MCP: j
And - 1 since executedCommandsCount is incremented afterwards.
Additionally commandQueue could be changed from a ArrayDeque to a ring buffer with the size of maxCommandChainLength, created every time a non-nested function is executed. There is for example CircularFifoQueue (Apache Commons Collections) which could be used.
![[Mod] Urielsalis](../../../data/assets/gravatar/urielsalis.jpeg){kind=small}
liach can you share the code responsible for doing this?
@liach, when you are the reporter or a ticket you can add affected versions yourself and do not need to comment on them.
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
liach, as the developers have assigned a priority to the ticket, we can determine that they plan on fixing it.
Missing override affects the immutability of BlockPosition and may cause unexpected problems or behaviors. See https://github.com/MinecraftForge/MinecraftForge/pull/2659#discussion_r57531008
Yes. This happens in 18w01a.
Still happens in 18w01a.
Is this the same as MC-2783? https://bugs.mojang.com/browse/MC-2783
When you remember to use the correct selector for one goal but not the other.
Given the beasts are a major addition in Village and Pillage, this bug still needs a fix. The illager beast is a selling point. Moreover, it's not hard to fix this bug.
Did you push with the block it's on?
Code analysis (yarn mappings): (aqr.a)
@Nullable @Override public EntityData prepareEntityData(final IWorld iWorld, final LocalDifficulty localDifficulty, final SpawnType difficulty, @Nullable final EntityData entityData, @Nullable final CompoundTag compoundTag) { this.setSpecificGoals(); if (difficulty == SpawnType.BREEDING) { this.setVillagerData(this.getVillagerData().withProfession(VillagerProfession.NONE)); } if (difficulty == SpawnType.COMMAND || difficulty == SpawnType.SPAWN_EGG || difficulty == SpawnType.SPAWNER) { this.setVillagerData(this.getVillagerData().withType(VillagerType.forBiome(iWorld.getBiome(new BlockPos(this))))); } return super.prepareEntityData(iWorld, localDifficulty, difficulty, entityData, compoundTag); }The code for breeding spawn type check is the cause of no profession and may be a leftover stub.
Well, this thing goes like this:
Hurt panda -> lower player rating in nearest village -> iron golem attack players with low rating
It is working as intended.
Aye Mojang, there is a code analysis for you and you don't take the ripen fruit!
Looking at
MC-146431, this bug is likely still present or fixed incorrectly (about its "fixed" state).1. I am not using any overlays.
2. Unfortunately, I believe the irc channels and discord would be too large that useful information would be flushed out. I prefer just talking on the JIRA.
This issue also makes it impossible to disable or enable file data packs with more than 2 consecutive spaces in its name.
Confirmed for 1.14 Pre-Release 2.
Confirmed in 1.14 Pre-Release 2 with the given armor stand setup.
A possible fix (Based on FabricMC yarn "1.14 Pre-Release 2+build.1"): (re.class) (All obfuscated names apply for 1.14 Pre-Release 2)
I have tested this fix with mixin and it appears to work.
This fix can resolve this issue; however, because of the addition of such a waitlist, in long term, Mojang can consider reworking command function object type and even removing the custom execution logic present within method ca$d#a. That should simplify command function code by a lot and improve its maintainability significantly.
Addition: by "simplifying command function code", I mean all those "addFirst" to the chain deque should be replaced by call to "CommandFunctionManager#execute", such as that in the early part of "CommandFunctionManager#execute" and the one in "CommandFunction.FunctionElement#execute"; the waitlist should be passed to the elements in the future as well (just add to waitlist, and check chain length limit with the length of both list)
When I was testing my fix for
MC-126946, I accidentally hit into issue and found a fix.Code analysis: (Using FabricMC yarn 1.14 Pre-Release 2+build.5)
(Method Lzb;a(Ljava/util/Map;)V)
In my opinion, the best fix is to supply the "ordered" boolean (i.e. call "za$a(Z)V" method) when the tag builders are prepared asynchrously, as order information is available already at that point and this can improve code maintainability.
I sincerely wish mojang can include this fix in Pre-3 and fix
MC-126946as well.Now, I have added another optimization (removing unnecessary boolean) and changed the command function entries to add to the waitlist instead of to the stack itself. This should make the code a bit easier to understand in the future.
See this (the license permits use of the code if you want):
https://github.com/liachmodded/MC-126946-128565/blob/master/src/main/java/com/github/liachmodded/datapacks/mixin/FunctionElementMixin.java
https://github.com/liachmodded/MC-126946-128565/blob/master/src/main/java/com/github/liachmodded/datapacks/mixin/CommandFunctionManagerMixin.java
Should have resolved this issue in the best sense.
With my test project, both
MC-126946andMC-128565is fixed; the dp.zip data pack has a function "liach:foo" to test this (need to run "liach:armorstand" to set up)This behavior defintely exist according to code, but I am not sure if this is a feature or a bug.
Confirmed for 1.14 Pre-Release 3.
I believe this should be fixed with
MC-126946together, as the fix offered here is based on a wrong data structure the code currently use. Will post an updated solution soon.If Dinnerbone or Mojang indeed plans to remove furnace minecarts, I suggest just marking this issue as "wontfix" instead of letting a ton of people waiting for this issue be fixed one day.
Fixes have been found and are packed in a mod I wrote.
https://github.com/liachmodded/MC-126946-128565/tree/2cbe0650ebe385027e484e7496fc63ebba690cad
Edit: This fix is not comprehensive; a better one needs some modification to brigadier.
Edit2: I confused the issue; the "incomprehensive fix" refers to that for embedded functions returning 0 as command result. (functions return 0 when called in another function)
Instead of using an FIFO queue, the fix should be incorporated to that for
MC-126946.A sample patched version is available at
https://github.com/liachmodded/MC-126946-128565/blob/2cbe0650ebe385027e484e7496fc63ebba690cad/src/main/java/com/github/liachmodded/datapacks/mixin/CommandFunctionManagerMixin.java#L99-L117
Confirmed with 1.14 Pre-Release 4. A more comprehensive fix is updated at https://github.com/liachmodded/MC-126946-128565/blob/2cbe0650ebe385027e484e7496fc63ebba690cad/src/main/java/com/github/liachmodded/datapacks/mixin/CommandFunctionManagerMixin.java#L70
First, I think it is intentional when a function commands returns 0 for chained executions to prevent vm stack overflow.
Second, functions got count twice in execution is actually
MC-148612(where I've posted a fix) andMC-143269(poster misunderstood the cause).A removal of chain length check for new function addition and addition of check to the chain after a regular execution should resolve this.
https://github.com/liachmodded/MC-126946-128565/blob/2cbe0650ebe385027e484e7496fc63ebba690cad/src/main/java/com/github/liachmodded/datapacks/mixin/CommandFunctionManagerMixin.java#L71
This needs some tricky fix... the execution of function would need to return some sort of lazy integer (atomic integer? completable future with integer?) and populate the value in the main dfs code body.
The first part of this issue is actually the same as
MC-135636. Should close this issue and move the corresponding topics to those single-topic issues linked instead.Confirmed in 1.14 Pre-Release 5. Has a set of code that hacked to solve this issue by calling the result consumers twice. https://github.com/liachmodded/MC-126946-128565/tree/b42d0455329408c2e2156d913be4ca2fd4255f8a/src/main/java/com/github/liachmodded/datapacks
In fact, this is a duplicate of
MC-130375In fact, this should have affected all minecraft versions in which function is present (i.e. all versions above minecraft 1.12)
Thank you @boq for your fix!
Thank you @boq for your fix!
Such issues also happen in advancement rewards when people accidentally refer to a function tag instead of a function.
I am assuming that Mojang uses the data generator in the Minecraft distributions to generate the advancement json files. If Mojang isn't, they can totally edit the json directly to fix this issue.
Looks like you mojang devs should check for the block state in the parameter of the method instead of asking the world for the current state.
This issue appears to be from the "startUseItem" (using 19w39a obfuscation map names for research) method in Minecraft class.
Snippet:
As you can see, the entity block forces to skip the logic for item interaction even though two types of entity interactions may request to "PASS" instead of "FAIL".
Suggested:
just switch the call from Files.newInputStream/newOutputStream to Files.newBufferedReader/newBufferedWriter and things will be fine. it isn't that hard, just a one line fix in abstract property handler.
Confirmed for 19w42a. This modifies the player item's nbt and off-thread java map editing may cause concurrent modification given compound tags are backed by regular hash maps.
Can confirm for 19w42a.
Steps of reproduction:
So the bug is that when there is no block in a chunk, the game assumes that the chunk is "not rendered" while it should be considered as "rendered".
See countRenderedChunks method in LevelRenderer (name from mojang client obfuscation map for 19w42a); apparently this logic does not count a chunk that is naturally empty.
Note: the icon uploaded shows a proper setup of blocks as described in step 5 and is a correctly generated world icon as a result of this placing blocks in empty chunks around to trick the game.
Guess you will add another render layer to solve this issue
Confirmed for 19w46a.
/say "a hello"Produces
instead.
Other examples error images:
In this case, the command cannot have a suggestion for an integer argument, and since it has no suggestion, an error is posted instead.
Also, given the purpose of this error (to prevent accidental trailing spaces in command blocks/functions), we may tweak the suggestion ui to display both suggestions and exceptions in a case like this.
Confirmed in 19w46a. Also thanks for adding a mojang priority.
Still the case in 19w46a.
Affects 1.15 pre release 1.
Affects 1.15 Pre release 1.
Affects 1.15 pre release 2.
Affects 1.15 pre release 3
Affects 1.15 pre release 4
Affects 1.15 pre release 5
That should be treated as the code analysis and fix suggestion. It shows why the crash can happen (because worldgen and server threads use the structure manager hash map concurrently)
Isn't this working as intended?
On a side note, the feature related to this bug has been first reported in
MC-64394, which (the feature) has been resolved as working as intended.Some code analysis:
Old logic (FabricMC yarn 1.15-pre4 build 1)
New logic (FabricMC yarn 20w08a build 6) with my comments:
The max out calculation is all new. The old logic is that it replaces the power obtained as a regular block with custom comparator output if i < 15.
Is maxing things out wrong?
This i < 15 statement makes me think that maxing out power later is the intended initial behavior (given if i == 15, extra check will not return a higher value and will waste cpu/memory when we are actually doing maxing out logic).
Is maxing things out right?
If it is, the getting power not through wall code probably should max with ambient block power as well, but it's clear that if the comparator outputing block has redstone output itself, things are clearly messed up.
My conclusion is that the final result is up to mojang to decide. In my opinion, the current status (i.e. in 20w09a) should be the most correct one (again this is only my opinion). The other side effects of the recent change (item frame) may be less noticed. If we do determine what should be regarded as "correct", we should determine what should be the power when both item frame and a comparator outputing block exists.
This is working as intended.
When you push the cart with your bare hand or something like a wooden stick while the cart is powered, though the item isn't consumed, you can observe a change in the cart's moving direction. The animation is for changing of direction, not just for the consumption of fuel.
This isn't really a problem as the stack overflow only happens on the network thread than the server thread. and since the server is stopping crashing the network thread isn't a big problem.
So the plant is like the root of the vine, isn't it?
Affects 20w13b. Reproduced with the exact same data pack.
Confirmed for 20w13b.
Confirmed in 20w14a with the water world preset, tested shipwrecks, ocean ruins, monuments, all three of which generates in the water world superflat preset.
Or with this generator config (water world superflat preset) in "server.properties"'s "generator-options" field:
{"structures":{"biome_1":{},"oceanmonument":{}},"layers":[{"block":"minecraft:bedrock","height":1},{"block":"minecraft:stone","height":5},{"block":"minecraft:dirt","height":5},{"block":"minecraft:sand","height":5},{"block":"minecraft:water","height":90}],"biome":"minecraft:deep_ocean"}After another peek, I found the cause of the problem and has a solution for it.
This is the current code for locating structure in the superflat chunk generator (fabricmc yarn mappings):
The problem is that some structure config keys, such as "oceanmonument" and "biome_1" as shown in the last comment's generator settings for server.properties, are not a direct mapping to structure names.
A suggested revision is as below:
This way, we are querying the biome of the superflat world whether such a feature exists (the biome already has all the processed structure information), which is more reliable.
I have applied this patch as a mod, and it apparently works well (see the screenshot of it working), while other unintended features that may have been specified by "biome_1", such as "Swamp_Hut", still correctly reports "Could not find that structure nearby".
Replication:
This bug can only be replicated when you join a remote server right after you freshly launched minecraft. If you've opened a local game or joined a server successfully, this crash won't be replicated.
Analysis:
Since 20w14a, tags have been refactored. As a result, tags, by default, are initialized with dummy entries that throw this IllegalStateException when called (before the tag container is set by the loaded local save). Because joining a local game or a remote server successfully previously would have set the tag container (no longer the dummy ones that crash), and as a result it won't crash.
When playing on remote servers, tags are sent by a Tag synchronization packet, yet the client starts rendering when it receives a Join game packet. As a result, when the game starts rendering fluids and checking tags, it might not have yet processed the tag packet if the network is bad, causing usage of dummy tags that throw exceptions and crash the game.
Confirmed in 20w15a.
Affects 20w15a.
Affects 20w16a.
Confirmed in 20w16a.
Oh my thank mojang for that vector3f 0.01 pose stack multiplication
This apparently hides some characters behind f3 as well. When the characters in chat hud has bit overlap with that from f3 menu, the chat hud loses its bits.
I've tested a mixin in a fabric mod and apparently that fixes the issue.
Proof: https://bugs.mojang.com/secure/attachment/285478/2020-04-23_02.59.45.png
(Released under public domain, feel free to take without crediting me)
So in ChatComponent.void render(com.mojang.blaze3d.vertex.PoseStack,int) method, you don't do poseStack translate -100 after push, you do translate 100 instead. It is a bug with a negative sign.
Affects 20w17a.
At least by 20w27a, the player head block entity attempts to load skin information on the server thread with a call to MinecraftSessionService.fillProfileProperties (with a true parameter) (usually implemented by yggdrasil) which will effectively block ticking on the server thread until the Minecraft server receives a response from the authentication server.
Most other calls to this fill profile properties are made on non-ticking threads, such as in executors on the client. This may be addressed like lighting where the block entity information is updated when the fetching of data completes asynchrously; however, it would potentially break commands expecting skull information to stay constant after generation from a command (such as setblock)
I have attached steps to reproduced in the issue body.