Arcensoth
- Arcensoth
- arcensoth
- America/Toronto
- Yes
- No
MC-89880![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as: code}}say Hello world!{{code8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as: monospaced}}say Hello world!{{monospaced
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as: monospaced}}say Hello world!{{monospaced8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
{monospaced}say Hello world!{monospaced}
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
{monospaced}say Hello world!{monospaced}
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: {{/entitydata @e[type=MinecartCommandBlock,r=1] {} }}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as: say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score: /scoreboard objectives add myscore dummy
2. Set the display of this score: /scoreboard objectives setdisplay sidebar myscore
3. Initialize your score: /scoreboard players set @p myscore 0
4. Summon a MinecartCommandBlock: /summon MinecartCommandBlock ~ ~ ~
5. Use the /stats command to populate the MinecartCommandBlock's CommandStats: /stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore
6. Confirm the CommandStats exist and are correct: {{/entitydata @e[type=MinecartCommandBlock,r=1] {} }}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as: say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] {}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] {}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run theMinecartCommandBlock(e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] {}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!
However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1]{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!
However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{\}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!
However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{\}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!
However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!
However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
{coed}say Hello world!
8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that **your score does not change**. Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e
[type=MinecartCommandBlock,r=0]~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:
execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct: /entitydata @e[type=MinecartCommandBlock,r=1] {}
7. Enter a command you know will succeed into the MinecartCommandBlock, such as:say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:
execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that *your score does not change*.
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:
execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that
*your score does not change*.Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:
execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that your score does not change.
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:
execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that your score does not change.
Current workaround:
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place.
A MinecartCommandBlock with CommandStats does not update the given scoreboard objective upon executing the command, whether it is successful or not.
Steps to reproduce:
1. Create a new score:
/scoreboard objectives add myscore dummy2. Set the display of this score:
/scoreboard objectives setdisplay sidebar myscore3. Initialize your score:
/scoreboard players set @p myscore 04. Summon a MinecartCommandBlock:
/summon MinecartCommandBlock ~ ~ ~5. Use the /stats command to populate the MinecartCommandBlock's CommandStats:
/stats entity @e[type=MinecartCommandBlock,r=1] set SuccessCount @p myscore6. Confirm the CommandStats exist and are correct:
/entitydata @e[type=MinecartCommandBlock,r=1] \{}7. Enter a command you know will succeed into the MinecartCommandBlock, such as:
say Hello world!8. Run the MinecartCommandBlock (e.g. by pushing it on to a powered activator rail) and notice that your score does not change.
Current workaround:
Oddly enough, it does work if you have the MinecartCommandBlock execute the original command through itself:execute @e[type=MinecartCommandBlock,r=0] ~ ~ ~ say Hello world!However, in order for this workaround to be reliable you must give the MinecartCommandBlock a unique custom name and execute the command through this name. Even so, this should not be necessary as the MinecartCommandBlock is the entity who is invoking the command in the first place. The CommandStats should update the respective score(s) without having to use the otherwise redundant execute command.
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 remain consistent.
Actual results
As evident in reload.png
, the tag order is shuffled arbitrarily each time datapacks are reloaded. The expected output is:
{{
[Server] foo:load1
[Server] foo:load2
[Server] foo:load3
[Server] bar:load1
[Server] bar:load2
[Server] bar:load3
}}The following are also inconsistent across reloads:
{{
/function #foo:load
/function #bar:load
/function #minecraft:load
/function #foo:tick
/function #bar:tick
/function #minecraft:tick
}}How to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3The following are also inconsistent across reloads:
/function #foo:load /function #bar:load /function #minecraft:load /function #foo:tick /function #bar:tick /function #minecraft:tickHow to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3
The following are also inconsistent across reloads:/function #foo:load /function #bar:load /function #minecraft:load /function #foo:tick /function #bar:tick /function #minecraft:tickHow to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3From this 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.
The following are also inconsistent across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickWhich suggests that order is violated even within the same tag definition.
How to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3
From this 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.
The following are also inconsistent across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickWhich suggests that order is violated even within the same tag definition.
How to reproduce
This behaviour can be reproduced by placing both datapacks from the attached datapacks.zip
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3The following are also inconsistent across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3
The following are also inconsistent acrossreloads:/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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 remain consistent.
Actual results
As evident in reload.png
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3While the actual output is random for each reload.
The following are also inconsistent across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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 remain consistent.
Actual results
As evident in reload.png
The expected output is:[Server] foo:load1[Server]foo:load2[Server] foo:load3[Server] bar:load1 [Server] bar:load2[Server] bar:load3Wh
ile theactualoutput israndom for each reload.The following a
re alsoinconsistent across reloads:/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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.
Actual results
As evident in reload.png
One iteration yielded the following results:
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2Where the expected output is always:
[Server] foo:load1 [Server] foo:load2 [Server] foo:load3 [Server] bar:load1 [Server] bar:load2 [Server] bar:load3Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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
.Actual results
As evident in reload.png
One iteration yielded the following results:
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2Where the expected output is always:
[Server] foo:load1[Server]foo:load2[Server] foo:load3[Server] bar:load1 [Server] bar:load2[Server] bar:load3Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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:load3Actual results
As evident in reload.png
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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:load3Actual results
As evident in reload.png
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
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:load3See also dinnerquote.png
Actual results
As evident in reload.png
[Server] foo:load3 [Server] bar:load3 [Server] foo:load1 [Server] foo:load2 [Server] bar:load1 [Server] bar:load2Details
The following also produce inconsistent results across reloads:
/function #foo:load /function #bar:load /function #foo:tick /function #bar:tickGiven 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
The new `/forceload` command replaces and improves upon `/chunk` however it still cannot be run from functions or command blocks.
The assumption is that, because the command was rewritten to allow for relative coordinates, it should be runnable by functions and command blocks.
The new `/forceload` command replaces and improves upon `/chunk` however it still cannot be run from functions or command blocks. Attempting to use this command inside a function will results in the attached parser error.
The assumption is that, because the command was rewritten to allow for relative coordinates, it should be runnable by functions and command blocks.
@Jeremie Dexter Can you (or a mod) please remove the screenshot attachments from the report? This report is about the lag caused by chunk-loading, not the rendering issues, and they are cluttering the attachments section. Thank you.
Irrecoverable chunk-loading lagLoading chunks creates irrecoverable lag (restart required)
The chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Video material: https://youtu.be/Zosu1BPpl6w
The linked debug reports are also attached to this report.
Lag is caused by loading chunks, and remains until the server is restarted.
See the lag in action at 10:15 and how it disappears after restarting at 12:15
In
this test, I am connecting to a remote vanilla serverrunning 1.14.1-pre1 that was released today. The client is also running vanilla 1.14.1-pre1.Debug report during lag: https://
pastebin.com/8ZTBipPvDebug report after restart:
https://pastebin.com/ZAVN9g6iThe chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of these test cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (see case_1_during_lag.debug.txt)
12:15 - And how it disappears after rebooting the server (see case_1_after_reboot.debug.txt)
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (see case_2_before_lag.debug.txt)
23:30 - After travelling 20k blocks, the lag has appeared (see case_2_during_lag.debug.txt)
30:50 - The lag persists despite several different methods of alleviating it
36:00 - After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txt)
The chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of these test cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (seecase_1_during_lag.debug.txt)
12:15 - And how it disappears after rebooting the server (seecase_1_after_reboot.debug.txt)
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (seecase_2_before_lag.debug.txt)
23:30 - After travelling 20k blocks, the lag has appeared (seecase_2_during_lag.debug.txt)
30:50 - The lag persists despite several different methods of alleviating it
36:00 - After rebooting the server, the lag no longer exists (seecase_2_after_reboot.debug.txt)The chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of these test cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (see case_1_during_lag.debug.txt
12:15 - And how it disappears after rebooting the server (see case_1_after_reboot.debug.txt
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (see case_2_before_lag.debug.txt
23:30 - After travelling 20k blocks, the lag has appeared (see case_2_during_lag.debug.txt
30:50 - The lag persists despite several different methods of alleviating it
36:00 - After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txt
The chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of these test cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15- See the lag in action (see case_1_during_lag.debug.txt12:15- And how it disappears after rebooting the server (seecase_1_after_reboot.debug.txt
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50- After travelling 16k blocks, the lag does not seem to have appeared (seecase_2_before_lag.debug.txt23:30- After travelling 20k blocks, the lag has appeared (seecase_2_during_lag.debug.txt30:50- The lag persists despite several different methods of alleviating it36:00- After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txtThe chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of these test cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (see case_1_during_lag.debug.txt
12:15 - And how it disappears after rebooting the server (see case_1_after_reboot.debug.txt
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (see case_2_before_lag.debug.txt
23:30 - After travelling 20k blocks, the lag has appeared (see case_2_during_lag.debug.txt
30:50 - The lag persists despite several different methods of attempting to alleviate it
36:00 - After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txt
debug_report_after_restart.txt
The chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted.
In all of the
setest cases, I am connecting to a remote vanilla server with a vanilla client.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (see case_1_during_lag.debug.txt
12:15 - And how it disappears after rebooting the server (see case_1_after_reboot.debug.txt
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (see case_2_before_lag.debug.txt
23:30 - After travelling 20k blocks, the lag has appeared (see case_2_during_lag.debug.txt
30:50 - The lag persists despite several different methods of attempting to alleviate it
36:00 - After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txtThe chunk-loading was addressed in
MC-149178and marked as "fixed" but I beg to differ. The mod comments in that report recommended creating a new report for 1.14.1, so here we go.Lag is caused by loading chunks, and remains until the server is restarted. This generally takes several thousand blocks of travelling to replicate with a single player online, but can quickly bring a multiplayer server to its knees after just a few hours of standard gameplay.
In all of the following test cases, I am connecting to a remote vanilla server with a vanilla client. The server is hosted on hardware that is entirely separate from the client that is connecting to it.
Case #1
Buffet cave world with mob spawning enabled and 512MB of memory
Video: https://youtu.be/Zosu1BPpl6w
Highlights:
10:15 - See the lag in action (see case_1_during_lag.debug.txt
12:15 - And how it disappears after rebooting the server (see case_1_after_reboot.debug.txt
Case #2
Default world with mob spawning disabled and 1GB of memory
Video: https://youtu.be/AaGVQvC1vW4
Highlights:
20:50 - After travelling 16k blocks, the lag does not seem to have appeared (see case_2_before_lag.debug.txt
23:30 - After travelling 20k blocks, the lag has appeared (see case_2_during_lag.debug.txt
30:50 - The lag persists despite several different methods of attempting to alleviate it
36:00 - After rebooting the server, the lag no longer exists (see case_2_after_reboot.debug.txt
Steps to reproduce:
```
- 1.
team add red
- 2.
team modify red color red
- 3.
summon minecraft:magma_cube ~ ~ ~Unknown macro: {Team}```
Notice how the mob is outlined in red for a split second before it becomes invisible and turns pure white.
Steps to reproduce:
# 1. team add red # 2. team modify red color red # 3. summon minecraft:magma_cube ~ ~ ~ {Team: red, Glowing: true, ActiveEffects: [{Id: 14b, Amplifier: 0b, Duration: 500, Ambient: true, ShowParticles:0b}]}Notice how the mob is outlined in red for a split second before it becomes invisible and turns pure white.
Steps to reproduce:
# 1. team add red # 2. team modify red color red # 3. summon minecraft:magma_cube ~ ~ ~ {Team: red, Glowing: true, ActiveEffects: [{Id: 14b, Amplifier: 0b, Duration: 500, Ambient: true, ShowParticles:0b}]}Notice how the mob is outlined in red for a split second before it becomes invisible and turns pure white.
Possibly caused by the fix for
MC-164163and may be related toMC-166397.Steps to reproduce:
# 1. team add red # 2. team modify red color red # 3. summon minecraft:magma_cube ~ ~ ~ {Team: red, Glowing: true, ActiveEffects: [{Id: 14b, Amplifier: 0b, Duration: 500, Ambient: true, ShowParticles:0b}]}Notice how the mob is outlined in red for a split second before it becomes invisible and turns pure white.
When using the `loot` command to produce loot inside of a container via `minecraft:contents`, the block's "outer" loot table (see `shulker_box.json`) is aware of the acting entity. It can even distinguish between players vs mobs, as well as `entity_scores`, by using `execute as` to change the entity context.
However, the "inner" loot table - defined by the container's `LootTable` (see table_with_scores.json), presumably invoked by `minecraft:contents` - loses all information about the acting entity despite it being the loot table to produce the final output.
The expected behaviour is that the inner loot table would retain the same knowledge (such as the acting entity and its scores) as the outer loot table that invoked it.
Steps to reproduce:
# 1. Make sure to add the attached files as part of a datapack # - `shulker_box.json` should replace the vanilla shulker box # - `table_with_scores.json` can be in a custom namespace # # 2. Set the shulker box with inner loot table and seed (for consistent/deterministic results) setblock ~ ~-2 ~ minecraft:shulker_box{ LootTable: 'custom:table_with_scores', LootTableSeed: 1 } # 3. Run the `loot` command as a player to produce loot from mining the shulker box into a dummy container setblock ~ ~-1 ~ minecraft:chest execute as @p run loot replace block ~ ~-1 ~ container.0 mine ~ ~-2 ~ # 4. Summon and try it as a skeleton to confirm that the outer loot table is aware of the difference summon minecraft:skeleton ~ ~3 ~ {NoAI: true, NoGravity: true} execute as @e[type=skeleton, sort=nearest, limit=1] run loot replace block ~ ~-1 ~ container.0 mine ~ ~-2 ~ # 5. Create the dummy objective and assign various scores to the player. # Observe how the scores influence the outcome of the outer table, but not the inner table. scoreboard objectives add scratch.foo dummy scoreboard players set @p scratch.foo -1 scoreboard players set @p scratch.foo 5 scoreboard players set @p scratch.foo 100
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Arcensoth, I cannot confirm that. The advancements seem to be properly granted to the player now. If there's any issues with the advancements triggers in 1.14.2-pre2, please create a new ticket.
Confirmed. I was just about to post a bug report about this.
I can also confirm that this change took place after 15w39c, because the original behaviour still works in 15w39c.
Indeed. I didn't notice sooner because I've been sitting on 15w39c until today.
One (hopefully temporary) workaround is to create an always-active repeat command block that teleports entities from the spawner to their expected position (the one given by the Pos tag). For this to work you'd need the SpawnRange set very low (i.e. 0) so you know exactly where the entities will spawn.
Confirmed for 1.9.4. As Skylinerw suggests, it would seem the MinecartCommandBlock must be reloaded before CommandStats applied via /stats will be realized.
I wouldn't say this is a priority issue, considering it's possible to summon the entity with CommandStats already in-place (and that most players probably already do this). Nonetheless, it is a bug.
Confirmed for 1.9.4. See attached crash report crash-2016-05-23_14.02.43-server.txt
Confirmed for 1.9.4. It is currently impossible to track fishing stats by any means, be it directly (via the stats menu) or through objectives (with the stats criteria type).
This is not fixed. It remains a problem as of the 1.10 full release. Try the steps provided in the description.
Well, that's severely disappointing.
Confirmed for 1.10 and 1.10.2. These files should always have content, even if the profiling lasts a mere second with no problems to report.
Confirmed for 1.12-pre5. Also happens with structure blocks.
Confirmed for 18w11a, see screenshot.
Confirmed for 18w15a.
Indeed it is a duplicate. The current work-around is to supply SpawnPotentials explicitly:
/give @p minecraft:mob_spawner{BlockEntityTag:{SpawnCount:15,SpawnRange:3,MinSpawnDelay:1,MaxSpawnDelay:40,RequiredPlayerRange:1,SpawnData:{id:"minecraft:chest_minecart"},SpawnPotentials:[{Entity:{id:"minecraft:chest_minecart"},Weight:1}]}}Still affects 1.14 full release
Still affects 1.14 full release
Nice!
This opens up a bunch of new possibilities for functions. Thanks!
This issue is not entirely fixed, and 1.14.1-pre1 continues to have significant problems with chunk-loading.
As recommend, I created a new MC-151082 with debug reports and a video demonstration to contribute my findings. I imagine there are several other people doing the same thing.
Hopefully this helps Mojang find and fix the underlying problem for 1.14.1, because otherwise vanilla multiplayer servers will continue to experience game-breaking lag after players load so many chunks.
@dexto Can you (or a mod) please remove the screenshot attachments from the report? This report is about the lag caused by chunk-loading, not the rendering issues, and they are cluttering the attachments section. Thank you.
Also your screenshot should ideally be a link or a thumbnail, and not embedded directly in the comment, as it is taking up the entire screen.
@dexto No worries, JIRA definitely has its own issues.
I'm not sure which report is for rendering specifically, apart from the original
MC-149178which was marked as "fixed" (even though it is very clearly not fixed).My goal with this report was to limit the scope to the server-side lag that's caused by (whats seems to be) chunk-loading. However it looks like the tracker mods are redirecting traffic from
MC-149178to here, so hopefully it doesn't just turn into the same generic "lag" report we already had.Edit #1: I left a comment on
MC-149178regarding the distinction between the server-side lag (outlined in this, new report) vs the client-side rendering issue you demonstrated (outlined inMC-149178).Edit #2: Looks like
MC-151084was intended to be for the client-side rendering, but it got resolved as a duplicate of this report. I think it would be better to have separate reports, even if they seem like symptoms of the same underlying problem.@violine1101 Thanks for linking the new issue, but I think we should split this into at least two separate problems: (1) server-side chunk-loading and (2) client-side rendering issues. The report I created was aimed at (1) the former; perhaps this issue should be re-opened (or another created) to address (2) the latter.
Edit: Looks like
MC-151084was created to more-accurately extend this report (MC-149178), whereasMC-151082addresses the lag in particular.Indeed, I intended
MC-151082to be focused on the server-side lag. I agree it would be better to have separate reports, even if they seem like symptoms of the same underlying problem.@luigiofthebakery That sounds like a viable cause, given that we have to load/unload chunks for the issue to occur. I've been running a 1.14 server for a small group of players that's limited to a 17x17 chunk playing area via worldborder, and have had no issues so far... presumably because there is very little chunk-loading occurring.
Do you still have the crash reports, and would you be willing to attach them - or at least the interesting bits - to the bug report?
Yeah sorry, I wasn't very clear with my original comment because at the time I wasn't sure about the distinction between the two problems.
I think there is some overlap in the symptoms, but the meat of that report is focused on single-player and doesn't necessarily suspect chunk-loading to be the cause. I believe I've narrowed down the culprit of this report to be server-side chunk-loading specifically.
This is still a problem in 1.14.2-pre2.
I looked at the advancements generated by the server, and I think the problem is that the advancement uses invalid trigger data.
Here's what the relevant portion of the working minecraft:nether/create_beacon looks like:
{ "trigger": "minecraft:construct_beacon", "conditions": { "level": { "min": 1 } } }And here's what the bugged minecraft:nether/create_full_beacon looks like:
{ "trigger": "minecraft:construct_beacon", "conditions": { "level": 4 } }I'm guessing the level predicate should use min instead of a number.
Agreed with Fabian. Marking it was "WAI" will mislead posterity into believing this is how enchanting is meant to work, which, as per Cory's comment, does not seem to be the case. Not to mention these changes were never officially announced, causing great confusion for survival players.
Affects 1.15-pre6 as well. The problem is that the game is not seeding the village chests. They should have their `LootTableSeed` set based on the world seed and coordinates, or some other hashing method based on the world seed. You can verify the absence of this tag by using `data get block` on a village chest that has not been opened.
The ability to teleport entities into the void has been a common technique for years. Having it removed from the game and failing with an error is a significant breaking change for commands/datapacks.
I'd suggest a new "super kill" command that immediately disposes of entities without any of the aforementioned side-effects, but that still wouldn't fix all of the outdated datapacks.
Can also confirm for 20w14a, and that linked worlds have worked fine for years up until this point.
Here's an excerpt of the warning from the game log:
Failed to read level <WORLD> data java.nio.file.FileAlreadyExistsException: C:\Users\<USER>\AppData\Roaming\.minecraft_snapshot\saves\<WORLD> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:81) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:504) at java.nio.file.Files.createDirectory(Files.java:674) at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) at java.nio.file.Files.createDirectories(Files.java:727)For what it's worth: my launcher randomly decided to update itself in the middle of the day today. Apparently it updated to the latest beta version (see below), despite me never being on the beta version of the launcher before. I double-checked in settings and as expected the beta option ("Use the beta version of the Launcher") remains untouched and still disabled, as I left it.
Launcher
2.2.2529
Thursday, March 25
Bootstrap
963
Thursday, March 18
UI
7293
Thursday, March 25
Yet another confirmation. Only pre1 shows up, and nothing after that. I am on Windows. I have changed nothing between these versions. The launcher broke on its own, for no apparent reason.