Water and lava have dedicated minecraft:block particles
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.
Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
| Event | Result | Notes |
|---|---|---|
| Process of breaking | N/A | Water and lava cannot be targeted, so this is impossible |
| Being broken |  No particles |
Only possible with commands: /setblock ~ ~ ~ air destroy |
| Being sprinted on | No particles |
Previously the case, fixed in 1.13 |
| Being fallen on |  Particles created |
Must be reproduce through MC-207949 |
| Being walked on by an iron golem | Particles created |
|
| Being dug through by an emerging warden | Untested |
|
| Being dug through by a departing warden | Untested |
|
| Being dug through by a sniffer | Untested |
|
| /particle command | Particles created |
Example: /particle minecraft:block minecraft:water |
Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177. - An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
Linked Issues
relates to5
MC-207949Landing on boats that are in water from moderate distances produces water particlesConfirmedMC-122547Barriers can produce fall particlesFixedMC-262507Block falling-on/sprinting/etc. particles do not take block hitbox shape into account
LowMC-240029Fire and soul fire have dedicated minecraft:block particlesInvalidMC-262505Iron golems can produce particles for blocks they're not colliding withFixed
Created Issue:
Water and lava have dedicated minecraft:block particles
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Iconic case of MC-1133Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
Attachments2
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
relates to
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
relates to
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on ParticlescreatedIconic case of MC-1133Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on I conic case ofFixed in 23w18aMC-1133Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
relates to
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on I conic case ofFixed in 23w18aMC-1133Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on No particlesMust be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The most notable case of this, from players falling, is due to
MC-1133, however this ticket regards the fact that particles can be produced at all, as there are several blocks in the game for which particles are never produced since particles being produced for them would make no sense. There are also cases listed in this 0ticket which are unrelated toMC-1133.Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.
Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.
Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
The bug
Water and lava are capable of producing minecraft:block particles of themselves in certain situations.
The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.
Table of results
The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
Event Result Notes Process of breaking N/A Water and lava cannot be targeted, so this is impossible Being broken Only possible with commands: /setblock ~ ~ ~ air destroy Being sprinted on Previously the case, fixed in 1.13 Being fallen on Must be reproduce through MC-207949 Being walked on by an iron golem Being dug through by an emerging warden Being dug through by a departing warden Being dug through by a sniffer /particle command Example: /particle minecraft:block minecraft:water Expected behaviour
As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
- A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
- A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
- Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix
MC-239407if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fixMC-122177.- An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.
![[Mojang] Timur Nazarov](../../../data/avatars/users/18945.svg){kind=small}
Mod edit:
When the player stands at the very edge of a block so that the center of the player is over the edge of the block, the game calculates the actions of the player according to the (air) block below the center of the player but not to the block the player is standing on.
- walking completely silent
- walking speed on Ice edge is normal
- fall damage when falling on the edge of slime blocks
- no reduced fall damage when falling on edge of hay bale
- wrong/no fall particles when landing on the edge of a block (allows for
MC-240028,MC-240029andMC-122547to be seen) - no damage while standing on the edge of magma blocks
- can jump normally on the edge of honey blocks
- jumping while standing on the edge of farmland does not turn it into dirt
- redstone ore not activated when standing on the edge
- not being affected by soul speed when standing on the edge of soul sand/soil
- when landing on wool with the player center above air, sculk sensors are activated (
MC-252389) - when walking on the edge of blocks, sculk sensors do not detect vibrations (
MC-207290) - taking fall damage at the edge of powder snow
Walking at the very edge of a block, and I mean the longest out possible on a block, will make it silent since it is not registering the walking. You are still on the block, just that it is silent. This bug has existed since before alpha.
The bug
Fire and soul fire are capable of producing minecraft:block particles of themselves in certain situations.
The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.
Table of results
The following table lists all cases in which minecraft:block particles are generated, and fire and soul fire's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.
| Event | Result | Notes |
|---|---|---|
| Process of breaking | Particles created |
Most easily noticed with swords in Creative |
| Being broken | No particles |
Includes /setblock ~ ~ ~ air destroy |
| Being sprinted on | Particles created |
Requires sprint-jumping through it and a keen eye |
| Being fallen on | Particles created |
Requires falling on a boat inside the fire:
/summon boat ~ ~ ~ {Invulnerable:1b}
|
| Being walked on by an iron golem | Particles created |
|
| Being dug through by an emerging warden | Untested |
|
| Being dug through by a departing warden | Untested |
|
| Being dug through by a sniffer | Untested |
|
| /particle command | Particles created |
Example: /particle minecraft:block minecraft:fire |
Expected behaviour
As mentioned before, block particles for fire and soul fire should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which fire and soul fire would be expected to follow:
- minecraft:air
- minecraft:cave_air
- minecraft:void_air
- minecraft:moving_piston
Actual behaviour
The game does indeed prevent fire and soul fire block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.
How to fix
Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode fire and soul fire to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.
These approaches are listed in detail in MC-240028.
Duplicate of MC-240028.