BelgianBomber
- BelgianBomber
- JIRAUSER722000
- Europe/Stockholm
- Yes
- No
MC-252667
Low
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.
16, this line was added to the Explosion class to not change the behavior of tnt entities while its eyeHeight was changed to 0.15 blocks above the block it is resting on. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder... which have an eyeheight of 0.85) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, this line was added to the Explosion class to not change the behavior of tnt entities while its eyeHeight was changed to 0.15 blocks above the block it is resting on. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder... which have an eyeheight of 0.85) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.
Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, th
is line was added to the Explosion class to not change the behavior of tnt entities while its eyeHeight was changed to 0.15 blocks above the block it is resting on. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder... which have an eyeheight of 0.85) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, the tnt and sand height was changed to 0.0 and 0.833 blocks respectively. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder... which have an eyeheight of 0.85) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.
Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, the tnt and sand height was changed to 0.0 and 0.833 blocks respectively. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder...
which have an eyeheight of 0.85) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, the tnt and sand height was changed to 0.0 and 0.833 blocks respectively. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder...) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.
How to fix it?
Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
Why even bother fixing it?
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, the tnt and sand height was changed to 0.0 and 0.833 blocks respectively. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder...) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.
How to fix it?
Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
Why even bother fixing it?
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
(entity instanceof PrimedTnt ? entity.getY() : entity.getEyeY())
in 1.8, the tnt and sand height was changed to 0.0 and 0.833 blocks respectively. The result of this is that fallingBlock (sand, gravel, anvils, concrete powder...) and tnt entities no longer travel along the same trajectory when exposed to an explosion on the X or Z axys.
How to fix it?
Adding the fallingBlock entity to this special case would allow sand and tnt entities to follow the same path when propelled by an explosion in multiple dimensions (x, y and z)(they already get affected the same way when the explosion is directly underneath the the projectile, being fallingBlock or tnt).
Why even bother fixing it?
A lot of people like myself who make tnt cannons would love to see this, because we often shoot both tnt and sand entities out, which is very inefficient now. It will not noticably affect other players, because they usually don't shoot sand entities with a lot of tnt in "normal' gameplay.
In conclusion, if it would be possible to make it so explosions affect both tnt and sand entities from their actual Y position instead of their eyeHeight, it would solve a lot of problems for us, it would not impact performance, and it will not break other current contraptions.
NOTE: the issue will not be fixed by making tnt get affected from its eyeHeight too; it would just propell itsself up then because the explosion takes places at the top of the bottom pixel (6.25% the size of an entity), the only fix is making both fallingBlock and tnt affected from the bottom.
When boosting sand down at high speed to a location below Y0, there are some instances where the sand will not
stackwhen it hits the floor. Sand will in those situations not travel to for example -7, but to -7.000000000000001, where according to the game, it is inside of the block below and thus will not become solid again.This exact setup can be replicated with this command (or the Y level given inside of the command) when trying to stack at y-7. Whether or not the sand will stack depends on the location before it gets moved, so here I give it a velocity of -10 but you can give it a velocity of -1000; it will not stack.
/summon minecraft:falling_block -9 1.2074466562545139 9 {Motion:[0d,-10d,0d]}
We make a lot of contraptions where we stack sand from bedrock to sky limit and this bug has caused a lot of issues, while it is probably a fairly easy fix.
I have not seen this bug happen when the entity is above y256 or below y0 before getting accelerated down.
When boosting sand (FallingBlock) down at high speed to a location below Y0, there are some instances where the sand will not turn solid when it hits the floor. Sand will in those situations not travel to for example -7, but to -7.000000000000001, where according to the game, it is inside of the block below and thus will not become solid again.
This exact setup can be replicated with this command (or the Y level given inside of the command) when trying to stack at y-7. Whether or not the sand will stack depends on the location before it gets moved, so here I give it a velocity of -10 but you can give it a velocity of -1000; it will not stack.
/summon minecraft:falling_block -9 1.2074466562545139 9
{Motion:[0d,-10d,0d]}We make a lot of contraptions where we stack sand from bedrock to sky limit and this bug has caused a lot of issues, while it is probably a fairly easy fix.
I have not seen this bug happen when the entity is above y256 or below y0 before getting accelerated down.
https://youtu.be/3qaBCarFNPM This video showcases how the issue occurs.
imparity between two entities that are the same size seems more like a bug than a feature, that's why I posted it here. I will move it to the appropriate forum