krassertyp
- krassertyp
- krassertyp
- Europe/Stockholm
- Yes
- No
MC-131145![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
Normal![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
Minecraft uses floats for rotationYaw if you keek spinning in one direction the rotationyaw keeps increasing at one point its so high looking around gets difficult, due to the vagueness of floats https://streamable.com/qmvns (i try to adjust my yaw by a bit before and after the spinning. compare how well it works) if you keep spinning for long enough you are unable to move, particles dont spawn, you always highlite the block beneath you
By sprinting in low water you breake the swimming mechinic
By sprinting in low water you breake the swimming mechinic
You nolonger descent on your own aslong as you keep sprinting
that allows you to pretty much walk on water
https://streamable.com/2hpnq
Pushing a piston into the head of the player causes the player to go into swimming animation
image-2019-04-10-18-15-32-257.png
sneak underneath a 1.5 blocks high gap
slowly go to the edge of the ceiling
-> your height will be normal while having a smaller hitbox
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, have the same delay and receive the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
- TNT Exploding mid air and Stretching over a large distance https://streamable.com/1vmsk
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, have the same delay and receive the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, ha
vethe same delay and receive the same amount of pressure from the charges.We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :[https://imgur.com/a/Wom1zVW
]//Edit
This should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.Also the TNTs left and right should have cancelled each other out, shooting all
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :[https://imgur.com/a/Wom1zVW
]//EditThis should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.Also the TNTs left and right should have cancelled each other out, shooting all
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this ://Edit
This should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.Also the TNTs left and right should have cancelled each other out, shooting all
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this ://Edit
This should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.Also the TNTs left and right should have cancelled each other out, shooting all
Currently TNT cannons with multiple projectiles are unpredictable, as of the 1.14 Snapshots and its First pre release it does not Follow rules it Previously has.
The projectiles of a TNT cannon are no longer exploding the way they should, instead of exploding at the same time and location they spread out over a long distance and if one might get lucky enough you could be able to hear or see the different Explosions.
We have been Testing it throughout the past few Snapshots and have yet to find a Solution to this Problem.
We are currently experimenting with Commandblocks to ensure that all the TNT is in the same Location, has the same delay and receives the same amount of pressure from the charges.
We even tried glitching the TNT into certain blocks, so that the TNT is unable to move a Pixel, but none of that worked or improved anything in the slightest.
We are aware that with certain techniques would allow one to create an "Invisible" Delay between multiple TNT's but we have, after additional testing, realised that the chances of this being the Case with Commandblocks are as close to impossible as it gets.We believe that there could be some Problems with the current way collisions are Calculated/Created.
Here a few examples of TNT behaving wrong:
-TNT Exploding mid air and Stretching over a large distance
-TNT Splitting mid-air and Stretching :
-TNT Suddenly shooting down at an angle at the end of the TNT stretch: https://streamable.com/a2w41
All of these Clips have been created with the same Command-Block rig, without any changes to the Cannon.
We used this :
//Edit
This should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.Also the TNTs left and right should have cancelled each other out, shooting all
If a tnt entity collides with a block in X direction, in the first tick after being accelerated
, it does not loose its momentum
and keeps flying in the X direction, until it collides a second time.,however if you flip this contraption 90°, and accelerate the tnt torwards Z direction
its Z-motion is stopped from the first collision
In order to reproduce i aligned two armorstands
so they both land on the birch block and the slimeblock at the same time
while the center of their hitbox is above air
Both are aligned in diffrent directionsExpected behavior : Both behave the same
Actual behavior : one jumps on the slimeblock, the other one lands on the normal block
I attached a video showing this problem in action
Edit
noticed its only an edge case when the armorstand is being pushed 45° (same amount on slime as the normal block) so its probably not important
New changes have made it so, that entities interact with Blocks (e.g an Arrow destroying a powdered snow, or an entity getting stuck in an cobweb), if they fly through an Block, even if they are going fast, by checking blocks in a vector from start to end
However the collision detection still takes an axis aproach, in which they calculate the collision axis by axis.
This causes entities to interact with blocks they physically cant touch
for example arrows being able to destroy powdered snow through solid blocks, or TNT getting stuck in cobwebs that are also encased in solid blocks
Here are two examples of the bug in action
https://streamable.com/0ffaxb
https://streamable.com/0nw497
New changes have made it so, that entities interact with Blocks (e.g an Arrow destroying a powdered snow, or an entity getting stuck in an cobweb), if they fly through an Block, even if they are going fast, by checking blocks in a vector from start to end
However the collision detection still takes an axis aproach, in which they calculate the collision axis by axis.
This causes entities to interact with blocks they physically cant touch
for example arrows being able to destroy powdered snow through solid blocks, or TNT getting stuck in cobwebs that are also encased in solid blocks
Here are two examples of the bug in action
https://streamable.com/0ffaxb
https://streamable.com/0nw497
'
The Green lines show how the collision is calculatedThe yellow line shows how "blockinside" (such as cobwebs) are checked
at higher speeds there is a large difference between the blocks they interact, thus causing said issue
---------------
I believe intended behaviour should be, that either the blockinside calculation respects the current collision (green path) order, or that the collision also check collision in the direct (yellow) path
No, only krassertyp's comment is a duplicate of that; this report is not
NewcomerMC, no you used MC-123217!
krassertyp, can you please upload a structure file of the contraption in your last set of videos? The website you're using is really bad for pausing at a specific time, so I can't rebuild it from that.
You don't have to upload a structure anymore, I was able to rebuild it from the video.
But all it shows is that the redstone dust sends updates before the lever does. I tried it in all directions. And it's the same in 1.13.
And the two observers on top are superfluous and the two observers in a row can each be just one.
Now can you please finally upload a structure file of a non-bugusing contraption that breaks due to this bug? First you uploaded a lot that are using bugs, then you uploaded one that might be valid, but to a website that pauses weirdly, so I can't reproduce it, then something that doesn't even reproduce the bug.
krassertyp, can you please upload a structure file for this video? https://streamable.com/ndivg
Or maybe something else that reproduces it properly?
I'm asking for the 9th time now, it's getting ridiculous. If you don't show how this is a bug in this or the next attempt, I'll ask a mod to close this report, because there's not enough information then to see what the problem is.
Didnt want to create another report for this because its pretty much the same.
Turtle eggs also break when jumping at the edge of a block next to the egg
https://streamable.com/quthl
not a duplicate
the one linked to keeps the hitbox
when doing it like described above you keep the swimming state
i dont have an example of breaking, but rather of making things more complicated
previosly you could chain a observer piston, and then a redstoneblock to create a delay equal to 5 gameticks
now when doing the same will result in a 4 gametick delay
also you could first stack a tower of pistons, then place redstoneblocks infront of them, thus quasi-powering every piston in this tower
when updating one piston every piston used to extend after 3 gameticks
in this version the pistons instandly spit out the blocks after 0 gameticks
https://streamable.com/i6l3o
It does behave diffrent
"Please show me a redstone contraption that clearly behaves differently now than in 1.12"
Sure
1.12.2 : https://streamable.com/t7i7l
1.13 : https://streamable.com/i4lv5
what happens in 1.12.2 - lower : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 3, thus taking 5 gameticks. the right piston extends first as its one gametick earlier
whatt happens in 1.13 : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 0, thus taking 2 gameticks. the left piston extends first as its 2 gametick earlier
(the slimeblock just resets the redstoneblock that gets pushed out)
is this good enough?
if a 0 gametick signal reaches the piston, itll spit it out after 0 gameticks instead of 3
if a 1 gametick signal reaches the piston, itll spit it out after 1 gameticks instead of 3
if a 2 gametick signal reaches the piston, itll spit it out after 2 gameticks instead of 3
same prinzip
but the 0 tick was the easiest to build
and yeah i knew 0 ticks were probably not intended
but i thought this is more or less an official part of the game, as it doesnt do any hard and adds a lot of extra content
so
I now build this using 1 gametick signals. im guessing they are intended
https://streamable.com/ndivg
https://streamable.com/nu4sy
the problem is that normal piston now have the same behavior as described in "122911"
well the webside works fine for me, but i can upload it directly ofcourse
and now i made a contraption that shows that 2 tick pulses also qualify
and if streamable doesnt work, and the vid is larger than tthe upload limit, ill give a download link
https://mega.nz/#!wO4WRCqA!N_y9zyLgFQYMs_p7GKqGIwV7gChk0e6U3aRHo8IZfcI
confirmed for 18w30b
It is still effected
to be honest you need to spin a lot for it to be noticable, but its still a problem
im sorry i didnt know that
does the new one work?
fixed it. sorry again
This should be a proove that its unintended behaviour
https://streamable.com/7x6g9
each tnt entity is summoned by commandblocks, and should get effected the same.
Also the TNTs left and right should have cancelled each other out, shooting all the projectiles straight forward
We showed the content of the commandblocks in these pictures
https://imgur.com/a/Wom1zVW
incase the link doesnt work : /summon tnt x y z {Fuse:80}
we used commandblocks because they assure each tnt is at the same location every time, but it would also work with a simpler setup
Well i think the screenshot / videos were clear, but i can write a more technical explenation
We uses commandblocks, to remove the randomness factor when tnt gets ignited. the results would be no diffrent when using a real tnt cannons
If you prefer i could give you a screenshot using an acutuall cannon, and not commandblocks
Im not quit sure what information is missing
Despite each tnt being summoned at the same locations, being affected by the same amount of explosions, they dont all fly the same
We believe it is because the entity list is nolonger sorted by entities being added into the world. but rather being sorted "random"
Therefor it is possible, when using a cannon with lets just say 10 accelerators and 2 projectiles
It is now possible that 5 accelerator tnts update -> one projectile updates, teleports forward with the speed added by 5 acceleration tnts -> another 5 accelleration tnts update -> the second projectile teleports forward with the speed of 10 acceleration tnts.
In previous versions the projectiles would only update after all the acceleration tnt exploded
Overall i highly suggest watching the video Valicon linked. it explains the problem way better than i can, and contains all the neccessary informations
incase its still necessary
we made a testworld that showcases the random nature of tnt in the latest snapshots
https://cdn.discordapp.com/attachments/302427804413329408/567040250971684874/bug_world.zip
Confirmed for 19w36a
This guy has a valid point, yet the only way i found to replicate that glitch involves another bug
https://streamable.com/jrumy
i hope this still helps
After further testing, OP probably used this setup
https://streamable.com/83gm4
abusing the new wet sponge to sponge - nether placement to get a repeater into that "glitched" state
This is very much still an issue in latest releases of the game.
Just spinning in the same direction for long enough causes the rotationYaw value to reach high enough values. where float imprecision get noticable
also
MC-158404is defnetly a duplicateMisode
What makes you say that?
Why should i be able to extiguish a flame just by placing a soulsoil, and instandly removing it again?
i feel like one of these 2 behaviours should be the case
a) the fire shouldnt spread to the soulsoil, as the soulsoil doesnt host redflame
or
b) the fire does jump to the soulsand and turn blue, but jumps back to the wood and turns red again once the soulsoil gets removed.
they way it is right now is kind of contradictionary.
right now a red flame can turn blue, but not the other way around
Ok
but still i would like to know why a redfire on the side of a block can turn into a blue flame ontop of the soulsoil
but a blue fire ontop of a soulsoil cant turn red again, but rather just disapears
It IS still an issue in the latest version of the game
Here is a video of me prooving the glitch.
https://streamable.com/i3d55s
You can see that the distance the tnt flys significantly decreases if the slimeblock pushes it mid flight
As the motion of the Entity, wich is > 1 is being overwritten by the slimeblock to be exactly 1
Isuue has been resolved in 1.18.2 Pre-release 1