Azkunki
- Azkunki
- azkunki
- Europe/Stockholm
- Yes
- No
Normal
MC-132124
When you're in the "Search" tab of the creative inventory, you can't close it using the key you binded to "Open / Close Inventory". This makes sense if that key is supposed to write something, but the problem is that it no longer works even when binding a key that doesn't write anything (I use "Enter", and tried as well with "Backspace", "Left Shift", "F7", "Prt Scr" and "Pause").
It is still possible to close the inventory using "Escape", or of course by simply switching to another tab before pressing the key we binded for that, though, but it's better to close it directly when the key you use allows to do that.
EDIT : I did search for that issue before posting but couldn't find anything. Now I see duplicates of two other bug reports with that, and it's said there it's "intended".
I'm honestly not sure about that, since it WAS working before (as long as using something else than a key that can write). So why would that change ? It may not be the most annoying bug ever, but it was useful to be able to close the inventory despite being in the search tab. And, as far as I know, there's no reason to stop that from being possible. Yes we can use "Escape", but that's not the key I binded for that, that's not the one I would bind even if I could, it's far from the keys I use (being left-handed, my hand for the keyboard is more around the arrow keys. No need to tell pressing "Escape" is anything but handy). And yes I can switch to another tab, but that's annoying if I often need to get something in the search tab (which is the most convenient one to find what you need).
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed for things like "~", "@", as well as "[ ]" and "{ }").
For example, if you write the command "/fill ~ -1 ~ ~+100 ~-1 ~+4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or "+100"). It's the same when moving with the arrow keys, you move from an argument to another instead of moving from a character to another. In other words, it acts exactly the same than when you hold "Ctrl".
This is quite annoying since it can make you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though : Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr, you can then keep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that.
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed for things like "~", "@", as well as "[ ]" and "{ }").
For example, if you write the command "/fill ~ ~ -1 ~ ~ +100 ~ -1 ~ +4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or "~ +100"). It's the same when moving with the arrow keys, you move from an argument to another instead of moving from a character to another. In other words, it acts exactly the same than when you hold "Ctrl".
This is quite annoying since it can make you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though : Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr, you can then keep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that.
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed for things like "~", "@", as well as "[ ]" and "{ }").
(note that I added spaces between " ~ " and values to prevent text formatting) For example, if you write the command "/fill ~ ~ -1 ~ ~ +100 ~ -1 ~ +4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or " ~ +100"). It's the same when moving with the arrow keys, you move from an argument to another instead of moving from a character to another. In other words, it acts exactly the same than when you hold "Ctrl".
This is quite annoying since it can make you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though : Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr, you can then keep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that.
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed for things like "~", "@", as well as "[ ]" and "{ }").
(note that I added spaces between " ~ " and
values to prevent text formatting) For example, if you write the command "/fill ~ ~ -1 ~ ~ +100 ~ -1 ~ +4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or " ~ +100"). It's the same when moving with the arrow keys, you move from an argument to another instead of moving from a character to another. In other words, it acts exactly the same than when you hold "Ctrl".This is quite annoying since it can make you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though : Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr, you can then keep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that.
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed for things like "~", "@", as well as "[ ]" and "{ }").
(note that I added spaces between " ~ " and other characters to prevent text formatting) For example, if you write the command "/fill ~ ~ -1 ~ ~ +100 ~ -1 ~ +4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or " ~ +100"). It's the same when moving with the arrow keys, you move from an argument to another instead of moving from a character to another. In other words, it acts exactly the same than when you hold "Ctrl".
This is quite annoying since it can make you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though : Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr, you can then keep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that.
If you hold the "Alt Gr" key for a short time (say one second or more), once you release it, it will be like if you were holding the "Ctrl" key (in case it matters, I'm using an AZERTY keyboard. And "Alt Gr" is needed forthingslike"~", "@", aswellas "[ ]" and "{ }").
(note that I added spaces between " ~ " and other characters to prevent text formatting) For example, if you write the command "/fill ~ ~ -1 ~ ~ +100 ~ -1 ~ +4 minecraft:ice", "Backspace" and "Del" are supposed to delete one character at a time, but if you've help "Alt Gr" for a little too long, it wil actually delete an entire argument (for example "minecraft:ice", or " ~ +100"). It's the same when movingwith the arrow keys,youmovefrom an argument to another instead of moving from a character toanother. In other words, it acts exactly the same than when you hold "Ctrl".
This is quite annoying since itcanmake you delete much more than what you expected to delete. Also, if you need to change something in the command (or in the sentence you're writing, of course), for example if on second thought you want to fill glass instead of ice, you can't.
It can be stopped though: Press the LEFT "Ctrl" key (the right one doesn't. At least for me), then it everything works again (until you hold again Alt Gr for a little too long).
Note : If you write or delete something while holding Alt Gr,you canthenkeep holding it as long as you want or it won't bug. It seems to only occur when you hold it a little too long while doing nothing else than that."Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rathre uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rathre uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rathre uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rath
re uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rather uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
"Alt Gr" is equal to pressing "Alt" + "Ctrl". Now, if you hold "Alt Gr" for something like a second, it will be as if you released "Alt" but NOT "Ctrl".
Using an AZERTY keyboard, "Alt Gr" is needed for several characters that are useful for commands : " ~ " , "@" , " ^ " , "{ }" and "[ ]"
Because it simulates a locked "Ctrl", actions like deleting text or moving the cursor with arrows will be work "word by word" instead of "character by character". For example :
/give @a[distance=..10,limit=5,sort=random] minecraft:blue_wool
First, if you do a typo, you're likely to not realise about the bug and delete the whole argument, if not several of them (here, write "blue_wiil" and you have what you need to delete literally everything. Although the most annoying is often when deleting a target selector).
Now, if you want to change to "red_wool", and / or something in the target selector maybe, you will have write the whole argument again (but the most annoying is really when you delete everything just because you didn't realise the bug was there. While most people probably won't even understand what the bug is)
Another problem is that Ctrl + A selects the whole text, but the game then still writes the letter too. So because of that, whenever you press the letter "A", everything you wrote will be replaced by "a". It took me quite some time to realize that because of MC-121278.
But what it means is : if MC-121278 is solved before this one is, it will become far, FAR worse than it is now ! (as long as it's not solved, it is the letter "q" that is a real problem, but it is rather uncommon. Which is not at all the case of the letter "a")
Pressing "v" can be annoying too, but at least it won't make you lose everything, it's a less common letter, and if you pressed "c" or "x" before, you won't notice anything. Unless you needed for later use what you last copied, since you won't have anymore anything to paste. Anywhere).
Notes :
1) There is a way to stop this bug : Press the LEFT "Ctrl" key (the right one does nothing. At least for me).
2) While holding "Alt Gr", pressing another key before the bug starts ensures that it will never start (until you release then hold again "Alt Gr").
3) The bug seems to be related to a "bad" framerate (including minor / average fps drops while otherwise having a good framerate), and maybe lag spikes, although the bug never seems to start instantaneously (and a lag spike is pretty short).
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=Unable to render embedded object: File (c ", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=Unable to render embedded object: File (c
", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=Unable to render embedded object: File (
c", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type= ! c", then it would suggest "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=
! c", then it would suggest "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type= Unable to render embedded object: File (c", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=
Unable to render embedded object: File (c", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=! c", then it would suggest "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e
[type=! c", then it would suggest "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=!c", then it would suggest] "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=!c", then it would suggest] "Unable to render embedded object: File (creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=Unable to render embedded object: File (c", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
It may actually be what is intended (I don't know), what I would rather expect, personnally, would be for example that if I write "/kill @e[type=Unable to render embedded object: File (c", then it would suggest "!creeper", "!cow", and other entity types starting with "c", with the ") not found." before that.
I would find that much more logical, but I can't tell if that's a bug or not, so I decided to consider that as a bug since I still would find that decision weird.
EDIT : Well, the "!" in my /kill command can't show, apparently, and I was unable to fix that, sorry.
On ice, block edges can become barely visible (unlike what I said in MC-128063, where they suddenly and clearly completely disappear). When that's at least possible to notice something.
In short, it seems to occur when these ice blocks are above water.For example, in screenshot #1, edges show properly, but in screenshot #2 it becomes quite faint already. There's no water under that block though, and according to my tests, here it seems to be because adjacent ice blocks create some kind of shadow to one another, making the dark line merge in it (still should probably be more visible, though).
However, I'm pretty sure it's supposed to be much more visible in a situation such as the one in screenshot #3, where we... really can't see anything. If looking at this block from the side, it becomes possible to notice something, but that's pretty hard (see screenshot #4).And screenshot #5 sums up a little all that : The part of the lines with "normal blocks" behind show properly, but when they start to cross water or ice, they become barely visible.
EDIT : About the first screenshot, the block isn't directly on the ground but it doesn't matter (the name has "on ground" because what's direclty underneath, apart from ice, is ground, not water).
On ice, block edges can become barely visible (unlike what I said in MC-128063, where they suddenly and clearly completely disappear). When that's at least possible to notice something.
In short, it seems to occur when these ice blocks are above water.For example, in screenshot #1, edges show properly, but in screenshot #2 it becomes quite faint already. There's no water under that block though, and according to my tests, here it seems to be because adjacent ice blocks create some kind of shadow to one another, making the dark line merge in it (still should probably be more visible, though).
However, I'm pretty sure it's supposed to be much more visible in a situation such as the one in screenshot #3, where we... really can't see anything. If looking at this block from the side, it becomes possible to notice something, but that's pretty hard (see screenshot #4).And screenshot #5 sums up a little all that : The part of the lines with "normal blocks" behind show properly, but when they start to cross water or ice, they become barely visible.
EDIT : About the first screenshot, the block isn't directly on the ground but it doesn't matter (the name has "on ground" because what's direclty underneath, apart from ice, is ground, not water).
On ice, block edges can become barely visible (unlike what I said in MC-128063, where they suddenly and clearly completely disappear). When that's at least possible to notice something.
In short, it seems to occur when these ice blocks are above water.For example, in screenshot #1, edges show properly, but in screenshot #2 it becomes quite faint already. There's no water under that block though, and according to my tests, here it seems to be because adjacent ice blocks create some kind of shadow to one another, making the dark line merge in it (still should probably be more visible, though).
However, I'm pretty sure it's supposed to be much more visible in a situation such as the one in screenshot #3, where we... really can't see anything. If looking at this block from the side, it becomes possible to notice something, but that's pretty hard (see screenshot #4).And screenshot #5 sums up a little all that : The part of the lines with "normal blocks" behind show properly, but when they start to cross water or ice, they become barely visible.
.EDIT : About the first screenshot, the block isn't directly on the ground but it doesn't matter (the name has "on ground" because what's direclty underneath, apart from ice, is ground, not water).
image-2018-06-26-18-38-35-380.png
I say "towards" a log because that's due to the order the game places the blocks. It places them from the lower coordinates of an axis towards the highest (except for Y maybe, it's a little weird, I'll talk about that later). Because of that, if the last block of leaves that the game creates is the first and only one to touch a wooden log, the first leaves were created without being "connected" to a log, so their distance is set to 7. And when the last block of leaves is created, they're now all "connected" to a log, but since it's the last block created, none of them (not even the last one) is updated.
If you're standing on the log, this issue happens when you create leaves :
• Towards negative X
• Towards negative Z
• Towards negative X + negative Z
• Towards negative Y. Which means here that it will be for an upside-down "tree" (and that for this axis, blocks are created from higher blocks to lower ones). However, I've at first been able to do so by hovering some blocks over the log and filling leaves between me and the log, and there was the issue, but for some reason I'm now completely unable to reproduce that again... I have no idea why, I can only show you where I managed to do that
(see screenshot). But at that moment, what happened was something that made me think of something kinda different for this bug : creating leaves under me to connect with the log would produce the bug, and creating leaves above me while sitting on the log would not. And I don't know why, now none do.I say "towards" a log because that's due to the order the game places the blocks. It places them from the lower coordinates of an axis towards the highest (except for Y maybe, it's a little weird, I'll talk about that later). Because of that, if the last block of leaves that the game creates is the first and only one to touch a wooden log, the first leaves were created without being "connected" to a log, so their distance is set to 7. And when the last block of leaves is created, they're now all "connected" to a log, but since it's the last block created, none of them (not even the last one) is updated.
If you're standing on the log, this issue happens when you create leaves :
• Towards negative X
• Towards negative Z
• Towards negative X + negative Z
• Towards negative Y. Which means here that it will be for an upside-down "tree" (and that for this axis, blocks are created from higher blocks to lower ones). However, I've at first been able to do so by hovering some blocks over the log and filling leaves between me and the log, and there was the issue, but for some reason I'm now completely unable to reproduce that again... I have no idea why, I can only show you where I managed to do that :
But at that moment, what happened was something that made me think of something kinda different for this bug : creating leaves under me to connect with the log would produce the bug, and creating leaves above me while sitting on the log would not. And I don't know why, now none do.
I say "towards" a log because that's due to the order the game places the blocks. It places them from the lower coordinates of an axis towards the highest (except for Y maybe, it's a little weird, I'll talk about that later). Because of that, if the last block of leaves that the game creates is the first and only one to touch a wooden log, the first leaves were created without being "connected" to a log, so their distance is set to 7. And when the last block of leaves is created, they're now all "connected" to a log, but since it's the last block created, none of them (not even the last one) is updated.
If you're standing on the log, this issue happens when you create leaves :
• Towards negative X
• Towards negative Z
• Towards negative X + negative Z
• Towards negative Y. Which means here that it will be for an upside-down "tree" (and that for this axis, blocks are created from higher blocks to lower ones). However, I've at first been able to do so by hovering some blocks over the log and filling leaves between me and the log, and there was the issue, but for some reason I'm now completely unable to reproduce that again... I have no idea why, I can only show you where I managed to do that :
But at that moment, what happened was something that made me think of something kinda different for this bug : creating leaves under me to connect with the log would produce the bug, and creating leaves above me while sitting on the log would not. And I don't know why, now none do.
Note : Adding the tag "distance" set to a value between 1 and 6 allows to get round the bug. But it also means that leaves with these values seem to check better for an update.
If you put water like in the screenshot, you will start swimming. But because of that, you will no longer be in the water, so you will immediatly stand up, which will move your head back in the water, so you will immediatly swim again, and so on.
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense.
• It allows stay on the surface without to keep swimming (as it did before, which I assume is why it's now the head that must be underwater).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height
– If only the head is in water, the hitbox shrinks to the head height (or at least to somewhere high enough to stay in the water). But maybe starting to swim only if looking high enough ? (I guess it would be necessary to look at least between 0° and -90°)
– If both the head and the feet are in water, the hitbox shrinks to the feet height. Or maybe more at the waist height ? (would make more sense, but I'm not sure what would be best)
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense.
• It allows stay on the surface without to keep swimming (as it did before, which I assume is why it's now the head that must be underwater).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height
– If only the head is in water, the hitbox shrinks to the head height (or at least to somewhere high enough to stay in the water). But maybe starting to swim only if looking high enough ? (I guess it would be necessary to look at least between 0° and -90°)
– If both the head and the feet are in water, the hitbox shrinks to the feet height. Or maybe more at the waist height ? (would make more sense, but I'm not sure what would be best)
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense.
• It allows stay on the surface without
to keepswimming (as it did before, whichI assume is why it's now the head that must be underwater).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height
– If only the head is in water, the hitbox shrinks to the head height
(or at least to somewhere high enough to stay in the water). But maybe starting to swim only iflookinghigh enough? (I guess it would be necessary to look at least between 0° and -90°)– If both the head and the feet are in water, the hitbox shrinks to the feet height
. Or maybe more at the waist height ? (would make more sense, but I'm not sure what would be best)I know what you think, "We told you it's WAI" (but I hope you will read what I wrote, because if you care for the game, there clearly is room to improve the swimming mechanics). And yeah, the fact that you start to swim when having the head in water is WAI. But you cannot seriously say that having our character switching between swim and run 5-10 times per second is a "normal feature" ! It doesn't make sense, it's disagreable both for the eye and for the ear (which includes that it's potentially DANGEROUS for epileptic people...), not counting the exact reason why it's made that way is the following :
At first, we could start to swim when our FEET were in water. The feet, because that's the more logical. The only problem was that it meant that when willing to stay at the surface of the water, it wouldn't work well for several reasons, and it was annoying. So it has been changed so that we now start to swim when the HEAD is in water.
→ In other words, we must now have the head in water only to fix the issue there was when that was the feet that were needed to be in water ! Except that there still is a problem. And although harder to encounter, it's worse.
You may think "but it's too hard to encounter this, there's no reason to setup something in a way that would induce this bug". But "not seeing how / why" does not mean "there is no reason to" ! And it just so happens that I did find an example where we could want to do that (and after not that much thinking, by the way) :
[PICTURE OVERALL VIEW]
[PICTURE EXIT]
[PICTURE HIDDEN TREASURE]I added some hazard with lava, which will of course make the player unable to get the disagreeable part. But that lava isn't necessary, especially if you put a timer. For example, there could be a button at the start, that would temporarily open something in what I called the "treasure room", that would then instead be a room from where you can temporarily open the exit.
In any case, what you would have to do here would be to swim in the water, so that you can go through a 1×1 hole.And this is a pretty simple case, but something more complex could be done, and for that, it would be worse. Let's imagine for example that there's something hidden under lava (something that must be done again if you fail afterwards). Whether you have a hint or not of where it is, every time you start the timer, you would be provided with a consumable allowing you to go only once and for a limited time under lava. So even if I make sure there's at the start a way for the player to be able to swim, well... You WILL have to go out of water to find that hidden thing. And then ? I can't put water on lava, and that would just suck if the player had to go back to the beginning ONLY to be able to start swimming again.
And there are other problems too, that I already talked about the last time within what would be a solution that would fix every single of all those issues :
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense (see screenshot named "one depth").
• It allows to move and stay on the surface without being in the swimming state (as it did before, which was annoying and is why it changed).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height (but again, to start swimming, we would have to look down enough).
– If only the head is in water, the hitbox shrinks to the head height. But to start swimming, we would have to look high enough (between 0° and -90° would be the more logical, under that we could get back to the issue we already have).
– If both the head and the feet are in water, the hitbox shrinks to the feet height (and you could start swimming whatever direction you're looking at).
Note : There is also
MC-132595, related to this bug or that is, at least, much easier because of it.
Also, note that due toMC-132252, this bug can't be reproduced in 1.13-pre5 (you get stuck in swimming mode although no longer in water. Not for the same reasons than forMC-132595). So you will need to go in 1.13-pre4 instead.
I know what you think, "We told you it's WAI" (but I hope you will read what I wrote, because if you care for the game, there clearly is room to improve the swimming mechanics). And yeah, the fact that you start to swim when having the head in water is WAI. But you cannot seriously say that having our character switching between swim and run 5-10 times per second is a "normal feature" ! It doesn't make sense, it's disagreable both for the eye and for the ear (which includes that it's potentially DANGEROUS for epileptic people...), not counting the exact reason why it's made that way is the following :
At first, we could start to swim when our FEET were in water. The feet, because that's the more logical. The only problem was that it meant that when willing to stay at the surface of the water, it wouldn't work well for several reasons, and it was annoying. So it has been changed so that we now start to swim when the HEAD is in water.
→ In other words, we must now have the head in water only to fix the issue there was when that was the feet that were needed to be in water ! Except that there still is a problem. And although harder to encounter, it's worse.
You may think "but it's too hard to encounter this, there's no reason to setup something in a way that would induce this bug". But "not seeing how / why" does not mean "there is no reason to" ! And it just so happens that I did find an example where we could want to do that (and after not that much thinking, by the way) :
[PICTURE OVERALL VIEW]
[PICTURE EXIT]
[PICTURE HIDDEN TREASURE]I added some hazard with lava, which will of course make the player unable to get the disagreeable part. But that lava isn't necessary, especially if you put a timer. For example, there could be a button at the start, that would temporarily open something in what I called the "treasure room", that would then instead be a room from where you can temporarily open the exit.
In any case, what you would have to do here would be to swim in the water, so that you can go through a 1×1 hole.And this is a pretty simple case, but something more complex could be done, and for that, it would be worse. Let's imagine for example that there's something hidden under lava (something that must be done again if you fail afterwards). Whether you have a hint or not of where it is, every time you start the timer, you would be provided with a consumable allowing you to go only once and for a limited time under lava. So even if I make sure there's at the start a way for the player to be able to swim, well... You WILL have to go out of water to find that hidden thing. And then ? I can't put water on lava, and that would just suck if the player had to go back to the beginning ONLY to be able to start swimming again.
And there are other problems too, that I already talked about the last time within what would be a solution that would fix every single of all those issues :
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense (see screenshot named "one depth").
• It allows to move and stay on the surface without being in the swimming state (as it did before, which was annoying and is why it changed).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height (but again, to start swimming, we would have to look down enough).
– If only the head is in water, the hitbox shrinks to the head height. But to start swimming, we would have to look high enough (between 0° and -90° would be the more logical, under that we could get back to the issue we already have).
– If both the head and the feet are in water, the hitbox shrinks to the feet height (and you could start swimming whatever direction you're looking at).
Note : There is also
MC-132595, related to this bug or that is, at least, much easier because of it.
Also, note that due toMC-132252, this bug can't be reproduced in 1.13-pre5 (you get stuck in swimming mode although no longer in water. Not for the same reasons than forMC-132595). So you will need to go in 1.13-pre4 instead.I know what you think, "We told you it's WAI" (but I hope you will read what I wrote, because if you care for the game, there clearly is room to improve the swimming mechanics). And yeah, the fact that you start to swim when having the head in water is WAI. But you cannot seriously say that having our character switching between swim and run 5-10 times per second is a "normal feature" ! It doesn't make sense, it's disagreable both for the eye and for the ear (which includes that it's potentially DANGEROUS for epileptic people...), not counting the exact reason why it's made that way is the following :
At first, we could start to swim when our FEET were in water. The feet, because that's the more logical. The only problem was that it meant that when willing to stay at the surface of the water, it wouldn't work well for several reasons, and it was annoying. So it has been changed so that we now start to swim when the HEAD is in water.
→ In other words, we must now have the head in water only to fix the issue there was when that was the feet that were needed to be in water ! Except that there still is a problem. And although harder to encounter, it's worse.
You may think "but it's too hard to encounter this, there's no reason to setup something in a way that would induce this bug". But "not seeing how / why" does not mean "there is no reason to" ! And it just so happens that I did find an example where we could want to do that (and after not that much thinking, by the way) :
I added some hazard with lava, which will of course make the player unable to get the disagreeable part. But that lava isn't necessary, especially if you put a timer. For example, there could be a button at the start, that would temporarily open something in what I called the "treasure room", that would then instead be a room from where you can temporarily open the exit.
In any case, what you would have to do here would be to swim in the water, so that you can go through a 1×1 hole.And this is a pretty simple case, but something more complex could be done, and for that, it would be worse. Let's imagine for example that there's something hidden under lava (something that must be done again if you fail afterwards). Whether you have a hint or not of where it is, every time you start the timer, you would be provided with a consumable allowing you to go only once and for a limited time under lava. So even if I make sure there's at the start a way for the player to be able to swim, well... You WILL have to go out of water to find that hidden thing. And then ? I can't put water on lava, and that would just suck if the player had to go back to the beginning ONLY to be able to start swimming again.
And there are other problems too, that I already talked about the last time within what would be a solution that would fix every single of all those issues :
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense (see screenshot named "one depth").
• It allows to move and stay on the surface without being in the swimming state (as it did before, which was annoying and is why it changed).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height (but again, to start swimming, we would have to look down enough).
– If only the head is in water, the hitbox shrinks to the head height. But to start swimming, we would have to look high enough (between 0° and -90° would be the more logical, under that we could get back to the issue we already have).
– If both the head and the feet are in water, the hitbox shrinks to the feet height (and you could start swimming whatever direction you're looking at).
Note : There is also
MC-132595, related to this bug or that is, at least, much easier because of it.
Also, note that due toMC-132252, this bug can't be reproduced in 1.13-pre5 (you get stuck in swimming mode although no longer in water. Not for the same reasons than forMC-132595). So you will need to go in 1.13-pre4 instead.
I know what you think, "We told you it's WAI" (but I hope you will read what I wrote, because if you care for the game, there clearly is room to improve the swimming mechanics). And yeah, the fact that you start to swim when having the head in water is WAI. But you cannot seriously say that having our character switching between swim and run 5-10 times per second is a "normal feature" ! It doesn't make sense, it's disagreable both for the eye and for the ear (which includes that it's potentially DANGEROUS for epileptic people...), not counting the exact reason why it's made that way is the following :
At first, we could start to swim when our FEET were in water. The feet, because that's the more logical. The only problem was that it meant that when willing to stay at the surface of the water, it wouldn't work well for several reasons, and it was annoying. So it has been changed so that we now start to swim when the HEAD is in water.
→ In other words, we must now have the head in water only to fix the issue there was when that was the feet that were needed to be in water ! Except that there still is a problem. And although harder to encounter, it's worse.
You may think "but it's too hard to encounter this, there's no reason to setup something in a way that would induce this bug". But "not seeing how / why" does not mean "there is no reason to" ! And it just so happens that I did find an example where we could want to do that (and after not that much thinking, by the way) :
I added some hazard with lava, which will of course make the player unable to get the disagreeable part. But that lava isn't necessary, especially if you put a timer. For example, there could be a button at the start, that would temporarily open something in what I called the "treasure room", that would then instead be a room from where you can temporarily open the exit.
In any case, what you would have to do here would be to swim in the water, so that you can go through a 1×1 hole.And this is a pretty simple case, but something more complex could be done, and for that, it would be worse. Let's imagine for example that there's something hidden under lava (something that must be done again if you fail afterwards). Whether you have a hint or not of where it is, every time you start the timer, you would be provided with a consumable allowing you to go only once and for a limited time under lava. So even if I make sure there's at the start a way for the player to be able to swim, well... You WILL have to go out of water to find that hidden thing. And then ? I can't put water on lava, and that would just suck if the player had to go back to the beginning ONLY to be able to start swimming again.
And there are other problems too, that I already talked about the last time within what would be a solution that would fix every single of all those issues :
Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense (see screenshot named "one depth").
• It allows to move and stay on the surface without being in the swimming state (as it did before, which was annoying and is why it changed).
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height (but again, to start swimming, we would have to look down enough).
– If only the head is in water, the hitbox shrinks to the head height. But to start swimming, we would have to look high enough (between 0° and -90° would be the more logical, under that we could get back to the issue we already have).
– If both the head and the feet are in water, the hitbox shrinks to the feet height (and you could start swimming whatever direction you're looking at).
Note : There is also
MC-132595, related to this bug or that is, at least, much easier because of it.
Also, note that due toMC-132252, this bug can't be reproduced in 1.13-pre5 (you get stuck in swimming mode although no longer in water. Not for the same reasons than forMC-132595). So you will need to go in 1.13-pre4 instead.
(hoped I could reopen the bug report. Actually no, but I know you guys are having notifications anyway so it doesn't change much)
Steps to reproduce :
• To see that the tag is missing :
- /fill ~-3 ~ ~-3 ~3 ~3 ~3 minecraft:water
- /fill ~-4 ~-1 ~-4 ~4 ~4 ~4 minecraft:glass outline
- /summon ~ ~ ~ minecraft:dolphin
- /data get @e[limit:1,type=dolphin]
- You can find the "Air" tag, which specifies how long the dolphin can stay IN water, but nothing that specifies how long the dolphin can stay OUT of water.
SCREENSHOT HERE
• To see that it does exist, though :
- Stay in your cage full of water
- /kill @e[type=dolphin]
- /summon ~ ~ ~ minecraft:dolphin {OverNineThousand:9001}
- Notice your dolphin is drowning as soon as it is summoned. That is because as soon as an entity is spawned with any tag being applied to it, all the other tags will have an "empty" value.
- Leave your cage to go somewhere on the ground.
- /summon ~ ~ ~ minecraft:dolphin {Air:4800}
- The dolphin instantly starts to take damage, again. And if you need to check that, repeat the above command after going back in the water cage to see that this time, the dolphin will not take any damage (also, if you then teleport it out of water, it won't take any damage either since being in water allowed it to replenish its "hidden tag").
Steps to reproduce :
• To see that the tag is missing :
- /fill ~-3 ~ ~-3 ~3 ~3 ~3 minecraft:water
- /fill ~-4 ~-1 ~-4 ~4 ~4 ~4 minecraft:glass outline
- /summon ~ ~ ~ minecraft:dolphin
- /data get @e[limit:1,type=dolphin]
- You can find the "Air" tag, which specifies how long the dolphin can stay IN water, but nothing that specifies how long the dolphin can stay OUT of water.
• To see that it does exist, though :
- Stay in your cage full of water
- /kill @e[type=dolphin]
- /summon ~ ~ ~ minecraft:dolphin {OverNineThousand:9001}
- Notice your dolphin is drowning as soon as it is summoned. That is because as soon as an entity is spawned with any tag being applied to it, all the other tags will have an "empty" value.
- Leave your cage to go somewhere on the ground.
- /summon ~ ~ ~ minecraft:dolphin {Air:4800}
- The dolphin instantly starts to take damage, again. And if you need to check that, repeat the above command after going back in the water cage to see that this time, the dolphin will not take any damage (also, if you then teleport it out of water, it won't take any damage either since being in water allowed it to replenish its "hidden tag").
After a while, dolphins on land will suffocate. This time is not written to NBT. An easy way to reproduce this is to spawn a dolphin, leave and join the world, and notice the dolphin immediately start to suffocate.
THIS IS NOT A DUPLICATE OF
MC-132311. At most it's related.
THIS IS NOT A DUPLICATE OF
MC-132311. At most it's related.
MC-132311→ Dolphins out of water instantly start to suffocate if you leave and then join back the world.
MC-132601(this bug report) → The tag isn't visible, although dolphins DO TAKE DAMAGE if you let them out of water long enough (they're not fishes ! They need more than 5 seconds to take damage ! And that's not because of lack of air that they die, that's because their skin is drying up). The reporter of the other bug was wrong about dolphins never taking damage. And that is why adding a tag when spawning them is a good way to show that the tag is there (whether "written to NBT" or not).
If this bug still is fixed (i.e. if "/data @e [limit=1,type=dolphin] " does show the tag we're talking about), you should instead mark that as fixed for the next release, instead of "duplicate". And of course, I'm taking the liberty to change back the title and add again the steps to reproduce (while adding something at the same time, to take care of what seemed too obvious to me to realize it : dolphins are not fishes) :
• To see that the tag is missing :
- /fill ~-3 ~ ~-3 ~3 ~3 ~3 minecraft:water
- /fill ~-4 ~-1 ~-4 ~4 ~4 ~4 minecraft:glass outline
- /summon ~ ~ ~ minecraft:dolphin
- /data get @e[limit:1,type=dolphin]
- You can find the "Air" tag, which specifies how long the dolphin can stay IN water, but nothing that specifies how long the dolphin can stay OUT of water.
• To see that it does exist, though :
- Stay in your cage full of water
- /kill @e[type=dolphin]
- /summon ~ ~ ~ minecraft:dolphin {OverNineThousand:9001}
- Notice your dolphin is drowning as soon as it is summoned. That is because as soon as an entity is spawned with any tag being applied to it, all the other tags will have an "empty" value.
- Leave your cage to go somewhere on the ground.
- /summon ~ ~ ~ minecraft:dolphin
- This dolphin doesn't take damage. However, it will if you wait long enough (something like 4-5 minutes).
- /summon ~ ~ ~ minecraft:dolphin {Air:4800}
- And this dolphin instantly starts to take damage, like for the one in water. Except that this one would not have died if it was in water, since its "Air" tag is set to 4800. And if you need to check that, then simply repeat the above command after going back in the water cage.
The timethat specifies how long a dolphin can stay out of water isn't written to NBTThe tag that specifies how long a dolphin can stay out of water isn't visible / written to NBT
THIS IS NOT A DUPLICATE OF
MC-132311. At most it's related.
MC-132311→ Dolphins out of water instantly start to suffocate if you leave and then join back the world.
MC-132601(this bug report) → The tag isn't visible, although dolphins DO TAKE DAMAGE if you let them out of water long enough (they're not fishes ! They need more than 5 seconds to take damage ! And that's not because of lack of air that they die, that's because their skin is drying up). The reporter of the other bug was wrong about dolphins never taking damage. And that is why adding a tag when spawning them is a good way to show that the tag is there (whether "written to NBT" or not).
If this bug still is fixed (i.e. if "/data @e[limit=1,type=dolphin]" does show the tag we're talking about), you should instead mark that as fixed for the next release, instead of "duplicate". And of course, I'm taking the liberty to change back the title and add again the steps to reproduce (while adding something at the same time, to take care of what seemed too obvious to me to realize it : dolphins are not fishes) :
• To see that the tag is missing :
- /fill ~-3 ~ ~-3 ~3 ~3 ~3 minecraft:water
- /fill ~-4 ~-1 ~-4 ~4 ~4 ~4 minecraft:glass outline
- /summon ~ ~ ~ minecraft:dolphin
- /data entity get @e[limit:1,type=dolphin]
- You can find the "Air" tag, which specifies how long the dolphin can stay IN water, but nothing that specifies how long the dolphin can stay OUT of water.
• To see that it does exist, though :
- Stay in your cage full of water
- /kill @e[type=dolphin]
- /summon ~ ~ ~ minecraft:dolphin {OverNineThousand:9001}
- Notice your dolphin is drowning as soon as it is summoned. That is because as soon as an entity is spawned with any tag being applied to it, all the other tags will have an "empty" value.
- Leave your cage to go somewhere on the ground.
- /summon ~ ~ ~ minecraft:dolphin
- This dolphin doesn't take damage. However, it will if you wait long enough (something like 4-5 minutes).
- /summon ~ ~ ~ minecraft:dolphin {Air:4800}
- And this dolphin instantly starts to take damage, like for the one in water. Except that this one would not have died if it was in water, since its "Air" tag is set to 4800. And if you need to check that, then simply repeat the above command after going back in the water cage.
When you're out of water, everything works fine. Except that this is the aquatic update, so let's go underwater.
I think there was a snapshot in which it was possible to pick up the water from a waterlogged block instead of the nearest water block, by holding the "Sneak" key. I might be wrong about that, but either way, this is something that is necessary. Not only it would come in handy (and quite a lot), but it would also... I mean, for some blocks, it would otherwise just be impossible to remove the water, unless pushing ourselves within it (with a piston) or removing all the surrounding water (well, there's still the bug that creates water sources on waterloggable blocks anyway, but let's imagine it's fixed).
Those blocks, or at least the ones I noticed, are the following :
[PIC HERE]
You can't pick the water from the chest or the cobblestone wall (but you can on fences), whatever you do. It's the same for stairs and slabs, but only in some cases such as the one shown in the screenshot.
When you're out of water, everything works fine. Except that this is the aquatic update, so let's go underwater.
I think there was a snapshot in which it was possible to pick up the water from a waterlogged block instead of the nearest water block, by holding the "Sneak" key. I might be wrong about that, but either way, this is something that is necessary. Not only it would come in handy (and quite a lot), but it would also... I mean, for some blocks, it would otherwise just be impossible to remove the water, unless pushing ourselves within it (with a piston) or removing all the surrounding water (well, there's still the bug that creates water sources on waterloggable blocks anyway, but let's imagine it's fixed).
Those blocks, or at least the ones I noticed, are the following :
You can't pick the water from the chest or the cobblestone wall (but you can on fences), whatever you do. It's the same for stairs and slabs, but only in some cases such as the one shown in the screenshot.
• Run : /summon minecraft:dolphin ~ ~ ~ {}
→ If out of water, the dolphin will instantly start to take damage.
→ If under water, the dolphin will instantly start to take damage.
For now, everything is normal.
• Run : /summon minecraft:dolphin ~ ~ ~
→ If out of water, the dolphin will (still) instantly start to take damage.
→ If under water, the dolphin will not (no longer) instantly start to take damage.
► When leaving completely empty (meaning "not even the brackets") the NBT tag argument, the entity should spawn with its usual tags, like when using a spawn egg. This is not what happens here, for the dolphin's "Moistness" tag
(that has been added in that last pre-release).• Run : /summon minecraft:dolphin ~ ~ ~ {}
→ If out of water, the dolphin will instantly start to take damage.
→ If under water, the dolphin will instantly start to take damage.
For now, everything is normal (takes damage out of water because Moistness=0, and under water because Air=0, since tags were empty in the command)
• Run : /summon minecraft:dolphin ~ ~ ~
→ If out of water, the dolphin will (still) instantly start to take damage.
→ If under water, the dolphin will not (no longer) instantly start to take damage.
► When leaving completely empty (meaning "not even the brackets") the NBT tag argument, the entity should spawn with its usual tags, like when using a spawn egg. This is not what happens here, for the dolphin's "Moistness" tag. Under water, the dolphin instantly resets its Moistness tag (... since under water), so they avoid damages. But of course, they still spawn with Moistness=0.
Dolphins spawned using /summon instantlydie when out of waterwhile ones spawnedusing spawneggs do notDolphins spawned out of water using /summon instantly take damage, while ones spawned with eggs do not
Steps to reproduce :
1) If you're not in a
nyworld, make surethere is nothing inthe FIFTH slot (not the fourth, the fifth !) of your hotbar2) /gamerule commandBlockOutput false
3) /give @p minecraft:repeating_command_block
4) Place the command block and click on "Needs Redstone" so that it switches to "Always Active"
5) Put this command in the command block : /replaceitem entity @a hotbar.4 minecraft:redstone
6) Click "Done"
7)
Open your inventory (there must be at least one free slot in it)8)
Shift-click on the item (a redstone dust) that's in the fifth slot of your hotbar. It should reappear. Shift-click again (you don't even need to do that quickly). This time, it will look like there's nothing anymorein theslot, and you can't continue shift-clicking
9A) If you put an item where the redstone should be, it will be replaced by a redstone dust (if the four slots to the left are NOT empty, shift-clicking an item in the inventory will place it too in the fifth slot, and it will be replaced as well by a redstone dust).
9B) The redstone dust will appear again as well if you close your inventory and use your drop key while on the fifth slot of your hotbar. If you have another command block that is supposed to detect the redstone dust item, it will work.Steps to reproduce :
1) If you're not in a random world, make sure the FIFTH slot (not the fourth, the fifth !) of your hotbar is empty, as well as at least one slot of your inventory
2) /gamerule commandBlockOutput false (only avoids flooding chat)
3) /give @p minecraft:repeating_command_block
4) Place the command block and click on "Needs Redstone" so that it switches to "Always Active"
5) Put this command in the command block : /replaceitem entity @a hotbar.4 minecraft:redstone
6) Click "Done"
7) Now, do one of the following actions (list may be incomplete) :
– Shift-click
– Click then drop out of the inventory
– Click then drop on the "Destroy Item" tile (creative mode)
8) The item is back, but after performing again one of the above actions, the slot will look empty, and trying to perform one of these actions yet another time won't bring the item back again. The only things that will work are :
– Using the "drop" key while the inventory is closed (so works only if the item is placed in the hotbar)
– Placing any item where the redstone should be (but that item will be lost)
Other things that might be helpful to know :
– Closing and opening the inventory BEFORE performing a second action will prevent the bug from happening
– If the command block places in that slot a stack of at least 2 items, by right-clicking it (instead of left-clicking), the bug will still happen but since there will be at worst (as long as only right-clicking) half of the original stack. Meaning that the third action is possible, and will provide the update needed to make things "normal" again.
– If thrown (by dragging the item out of the inventory) and then retrieved while the inventory is opened (even if it means closing it, moving and then opening it again), it will go back in the right slot (unlike the shift-click), but it will already be in the "bugged state" (i.e. performing only once one of the actions I listed will be enough to make the slot empty again)
Steps to reproduce :
1) If you're not in a random world, make sure the FIFTH slot (not the fourth, the fifth !) of your hotbar is empty, as well as at least one slot of your inventory
2) /gamerule commandBlockOutput false (only avoids flooding chat)
3) /give @p minecraft:repeating_command_block
4) Place the command block and click on "Needs Redstone" so that it switches to "Always Active"
5) Put this command in the command block : /replaceitem entity @a hotbar.4 minecraft:redstone
6) Click "Done"
7) Now, do one of the following actions (list may be incomplete) :
– Shift-click
– Click then drop out of the inventory
– Click then drop on the "Destroy Item" tile (creative mode)
8) The item is back, but after performing again one of the above actions, the slot will look empty, and trying to perform one of these actions yet another time won't bring the item back again. The only things that will work are :
– Using the "drop" key while the inventory is closed (so works only if the item is placed in the hotbar)
– Placing any item where the redstone should be (but that item will be lost)
Other things that might be helpful to know :
– Closing and opening the inventory BEFORE performing a second action will prevent the bug from happening
– If the command block places in that slot a stack of at least 2 items, by right-clicking it (instead of left-clicking), the bug will still happen but since there will be at worst (as long as only right-clicking) half of the original stack. Meaning that the third action is possible, and will provide the update needed to make things "normal" again.
– If thrown (by dragging the item out of the inventory) and then retrieved while the inventory is opened (even if it means closing it, moving and then opening it again), it will go back in the right slot (unlike the shift-click), but it will already be in the "bugged state" (i.e. performing only once one of the actions I listed will be enough to make the slot empty again)
Steps to reproduce :
1) If you're not in a random world, make sure the FIFTH slot (not the fourth, the fifth !) of your hotbar is empty, as well as at least one slot of your inventory
2) /gamerule commandBlockOutput false (only avoids flooding chat)
3) /give @p minecraft:repeating_command_block
4) Place the command block and click on "Needs Redstone" so that it switches to "Always Active"
5) Put this command in the command block : /replaceitem entity @a hotbar.4 minecraft:redstone
6) Click "Done"
7) Now, do one of the following actions (list may be incomplete) :
– Shift-click
– Click then drop out of the inventory
– Click then drop on the "Destroy Item" tile (creative mode)
8) The item is back, but after performing again one of the above actions, the slot will look empty, and trying to perform one of these actions yet another time won't bring the item back again. The only things that will work are :
– Using the "drop" key while the inventory is closed (so works only if the item is placed in the hotbar)
– Placing any item where the redstone should be (but that item will be lost)
Other things that might be helpful to know :
– Closing and opening the inventory BEFORE performing a second action will prevent the bug from happening
– If the command block places in that slot a stack of at least 2 items, by right-clicking it (instead of left-clicking), the bug will still happen but since there will be at worst (as long as only right-clicking) half of the original stack. Meaning that the third action is possible, and will provide the update needed to make things "normal" again.
– If thrown (by dragging the item out of the inventory) and then retrieved while the inventory is opened (even if it means closing it, moving and then opening it again), it will go back in the right slot (unlike the shift-click), but it will already be in the "bugged state" (i.e. performing only once one of the actions I listed will be enough to make the slot empty again)
shift-click on an itemrepeatedly given by a command block makesit disappearMoving in certain ways an item that is repeatedly given by a command block makes the slot appear empty
"Pick Block" not working properly isbound to something else than "Mouse 3""Pick Block" not working properly if bound to something else than "Mouse 3"
It never does for :
- /fill (both for " { " and " [ " )
- /setblock (both for " { " and " [ " )
- /clone (only for " [ " )
It also doesn't work for the following commands in two cases : upon auto-completing the block ID, and if the ID starts with " # " (for commands that can use them) :
- /clone (only for " { " since, as stated above, " [ " isn't suggested at all)
- /give
- /replaceitem
- /clear
→ But if you write the ID yourself, the suggestion shows.Most cases have been fixed. However, for none of the remaining cases am I 100% sure whether they're WAI or not. Still, here they are :
1) Brackets not being suggested, although not showing an error if used anyway.
Affects : /setblock, /fill and /clone.
Example : /setblock ~ ~ ~ minecraft:terracotta[]{} → None of the brackets are suggested for that block.
But it seems that when a bracket isn't suggested, it's always because there's no possible use for that, so the fact that they're not suggested there is highly likely to be WAI. Now, in this case we could then expect an error being displayed, but that is not the case. Maybe this is still WAI, simply done that way so that it can't conflict with whatever mods could do ? (I'd love to know if my assumptions are right, of course, so I can remove the useless parts)
2) Curly brackets not suggested for "#items"
Affects : /clear
Example : /clear @a #minecraft:fishes ; /clear @a #minecraft:anvil
I may be missing something, but this is where I'm the most certain this is not WAI. The reason behind that is simple : We're talking about items, not blocks, so as far as I know, there could be pretty much anything applied to them (custom name, description, enchantments...). Now that's still a kind of IDs I have never used yet. So, although I think I've understood what they're for (group of items / blocks, so it won't be one command for each kind of log (for example), it will be one command for all the logs), I start from the principle that I may still be missing something.
Of course, if point 1) is indeed something to fix, then the particular reason I mentionned for point 2) isn't important (it would then need to be fixed anyhow).
3) Brackets never showing after a tab-completion
Affects : Probably anything after which a bracket of any kind can be used, without adding a space first. Such as blocks in /setblock, /fill and /clone, items in /give, /clear and /replaceitem, and target selectors (that's everything I noticed, but there may be things I missed).
Just keeping that in the bug report, although I realized it's probably WAI as well. But it would be WAI only because it's hard to do otherwise, because of the two following facts : Brackets must now sometimes stick to another argument, and the Tab key isn't only used for tab-completion, it's also used to navigate between the suggestions. Finding a solution to that would be great, but apart from 2 bad solutions I thought of (removing "tab-navigation" and first space switching to bracket suggestions instead of writing a space) and going backwards with the brackets sticking to the argument they are linked to, I don't see anything that could be done. I mean, something like pressing the escape key to switch to the bracket suggestions could do the trick, but I was hoping for a solution that would make it more intuitive for new command-makers (as well as people that need to learn what changed since 1.12). Now, well, I highly doubt there is any possible solution at all that would fit everything I said... So what I think is :
► Best solution possible : Pressing the "Escape" key switches the suggestions from the main argument to the bracket ones (I guess it's better than nothing).
The bug
When writing a command, the game
shows youa list of suggestionsformanythings(unless you disabled that). But ifyou left your cursor where one of those lists will open, it willselect by default the suggestion the mouse is on, even the mouse didn't move atall,at any moment.How to reproduce
Of course, this is easier to reproduce for long lists with long IDs, such as blocks, potion effects and scoreboard criterias.
Choose the command you wish to use, leave your mouse somewhere on the list, on the fifth line for example (but not on the first line of course, or you won't see a difference). This is so that you can be sure the cursor is where you will need it to be.Close the chat, move a little your mouse if you feel like it's better (just be careful to put it back somewhere the list should be, even if that's not exactly where you first decided it would be), then write your command again. Notice it's not the first line being highlighted, it's the one with the mouse on it, and pressing Tab once will fill the command with the ID from that same line (instead of the one from the first line).
The bug
When writing a command, the game displays a list of suggestions about what you may want to write next (unless you disabled that). But if the suggestions appear under the cursor, it won't need to be moved to be active, hence selecting selecting by default the suggestion the mouse is on. Which can be annoying as pressing Tab will select that suggestion instead of the first one (and Tab is most often used to complete what is usually already on the first or second line of the suggestion list.
Of course, in practice, it has more chances to happen for commands with long lists of suggestions and long IDs, such as blocks (/give, /fill...) and scoreboard criterias. It may happen more easily on smaller screens, too (was on 1366×768 before, now 1920×1080, barely used commands for but I feel like it may happen less easily for me now. I may be wrong though, too early to tell).
How to reproduce
• Copy-paste the following : /give @p minecraft:jun
• Put your mouse above the suggestions that appear (preferably slightly above the text bar. As long as it's not on the first suggestion, it's okay). Just so that you know it's where you need it to be to reproduce the bug. Delete the command (without closing the chat, or you will have to place the mouse again), then paste it again, or type it if you prefer.
• As you can see, the suggestion your mouse is on is highlighted. Type "g" if you pasted and want to make sure it won't change anything.
• Press Tab, it will enter in chat bar the suggestion the mouse was on, instead of the first suggestion.
Christof Kynast, Azkunki : So you're proposing something like "Close creative inventory when inventory key is bound to a non-printable character (Tab, Mouse, etc)" ?
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
@FVbico
Just edited my own bug report of that, when I saw it was marked as resolved because duplicate etc, but no comment with it so I'll copy / past my edit here :
"I did search for that issue before posting but couldn't find anything. Now I see duplicates of two other bug reports with that, and it's said there it's "intended".
I'm honestly not sure about that, since it WAS working before (as long as using something else than a key that can write). So why would that change ? It may not be the most annoying bug ever, but it was useful to be able to close the inventory despite being in the search tab. And, as far as I know, there's no reason to stop that from being possible. Yes we can use "Escape", but that's not the key I binded for that, that's not the one I would bind even if I could, it's far from the keys I use (being left-handed, my hand for the keyboard is more around the arrow keys. No need to tell pressing "Escape" is anything but handy). And yes I can switch to another tab, but that's annoying if I often need to get something in the search tab (which is the most convenient one to find what you need)."
Thanks in advance for your reply, I hope.
Just tried with another keyboard, it does the same (that's the same layout though, so I wasn't expecting much). I already tried to switch to QWERTY using Shift + Alt, too, but it doesn't work in Minecraft (even if I do that while on the desktop then go back to Minecraft, my keyboard is back to AZERTY), so I don't think I can test much more by myself.
And yes, it does that only on Minecraft (and never noticed that in 1.12.2 or before, so I assume it wasn't doing that there).
Had in mind that it was equal to Ctrl + Shift (thinking about it, I'm stupid. It's ALT Gr, after all ^^' ), so that was what I tried. Just tried again with Alt instead of Shift then, and both with left and right Ctrl, and it doesn't lock Ctrl (I'm not going to do Ctrl + Alt instead of Alt gr though). No matters if I press Ctrl first or Alt first.
In any case, the control key staying virtually pressed is what I though too (now, why it does that ? Would be great to know if other people with AZERTY layout have this issue as well, and even more if there are people with a QWERTY layout that have it too)
PS : Actually just thought of a test I could do : Removing the AZERTY layout from my computer to leave only the QWERTY one, so that the game cannot change back to AZERTY (tried first to only make QWERTY as main keyboard but it wasn't enough). Even though I'd still like to see if it does that to other people too, the result here is that the bug stil occurs, in QWERTY as well.
But I don't want to disable command suggestions, they just don't need to interfere when you review messages you've already sent (forgot to check if there was an option for that though, now I know there is so still thanks for that). This is something else than having suggestions popping up when you're actually currently writing your command. If you're not, that it's something you already wrote earlier, it's useless, so just annoying (and if you do want to modify that command, you can do like for other arguments that do not make their suggestions pop up, like the "true" in "/effect give @p minecraft:potion_effect 100 4 true", or the block in "/setblock ~ ~ ~ minecraft:block_name")
And I don't know what "WAI" means. After a little thinking, I'm guessing that stands for "Works As Intended". But I truly doubt that. Typically, why should that work differently with potion effects and blocks ? Because it does, but it doesn't make sense. It should either always be the case (which would be a bad decision though), or never (in the situation I depicted only. Not talking about when you're writing a command).
@Bemoty
No, this is not a duplicate of the issue you linked. The issue I'm talking about is that you can see the block's hitbox, no matter if they are out are in water, as long as YOU are out of water. And once you are underwater, you can't see anymore ANY block hitbox, including from blocks that are out of water.
Also, as I already said in my report : " I'm not sure how I could be the first to talk about such an easy-to-spot bug, but I couldn't find anything about that, so...". But I was saying that because this is a new bug since 1.13 snapshots. There wasn't that issue before. And, once again, it is not a duplicate from the issue you linked. I'm not talking here about a barely visible hitbox, I'm talking about the fact that they do not show at all.
My other bug report, MC-128066 , that I made separately for a reason, looks much more like yours. This time it could be the same bug, though in your bug report there seem to be also other things completely different from that (but it does look a lot like what shows the screenshot with a barrier block. Also, once again, I did try to check if there was already a bug report. Not my fault if I can't always find them. Keep in mind you never saw the bug reports I never made since I found people already talking about them). You can then say my other bug report is a duplicate if you want, but this one isn't. So please, open it again. Thanks.
@Bemoty
Except that here, the hitbox does not render at all. And please, read my whole message this time, because I have really good reasons to think you didn't the two previous times (or that you did by not paying attention to what I was saying). Thanks in advance.
Similar consequences don't necessarily have the same causes. That's as true for bugs than it is for diseases, psychological problems, or computer issues. And here that's not even a similar consequence. This is not the fact that there's water between us and what we look that causes the problem, it's the fact that we ARE in water, looking in water while not being in water isn't a problem.
Also, the fact that other reports have been considered as duplicate doesn't mean the people who did that were right. The only thing I've learned with those reports is that the bug is actually older than what I though. And that's because 1.13 will make building in water much more popular, so this bug needs to be fixed for 1.13. So it would be a much better idea to give it some light. And that's not even a builder saying that, just someone that thinks about others (all I personally did in water were tests and I'll probably never do anything else than that).
@Kumasasa
It may be intented, indeed, and of course it completely makes sense when the key bound to "open / close inventory" can be needed to write in the search field, like the default [E].
However, when you bind to that another key, like [TAB] for Christof or [ENTER] for myself, it would work in 1.12.2 and before. Also, there are high chances that the devs just didn't realize about that, so that whatever they did, they probably didn't expect such a thing. Actually, maybe they even expected that nobody would notice any difference ?
In any case, having bound a key that could close the inventory while on the search is something that I found really useful, and I truly miss that :/
.
Alternatively, maybe a simple "Close Search Inventory" command could be added ? (or whatever name it would have) The other one would still be "Open / Close Inventory", so having nothing bound to "Close Search Inventory" would not change anything from how things are right now in snapshots. And it could be bound to the same key than "Open / Close...", since these are two actions that cannot conflict. Of course, it would mean that a key like [E] could work as well (else it wouldn't make sense to add that "Close Search..."). I think it would just be a good thing to make sure people understand well what this key would do, maybe with a popup (else, some could bind something like [E], not understanding what this is exactly, then forget, and think their search inventory closing is a bug). Also, "Close Search..." would be right under "Open / Close...", maybe even with some indentation (to show even better they are related).
@Kumasasa
If this can be done again without adding a new key just for that (or a check box to "Always force creative inventory to close"), then yeah
I was unable to find this bug report before making my own, but since I wrote there something about a solution that could be provided (and that I hope would be applied), I'd like to copy-paste that here :
« Suggested solution :
Allowing again to swim when only the feet are in water, but only when looking down above a set angle. Starting to swim between 70° / 75° and 90° seems perfect to me. This would also provide a solution to those two issues :
• It was no longer possible to swim in a 1×1 hole if the depth was never more than 1 block. Being able to swim in a depth of 1 block without being able to start swimming in a depth of 1 block doesn't make sense.
• It allows to stay on the surface without the swimming animation (as it did before, and made the screen glitch quite like in this issue (if looking between 0° and -90°), which I assume is why it's now the head that must be underwater), while still allowing to either begin swimming swiftly and smoothly (no need to break sprinting by sneaking and then having to sprint again) or look what's under the surface by staying above it, despite holding the sprint key.
Also, I would suggest that, when starting to swim :
– If only the feet are in water, the hitbox shrinks to the feet height
– If only the head is in water, the hitbox shrinks to the head height (or at least to somewhere high enough to stay in the water). But maybe starting to swim only if looking high enough ? (I guess it would be necessary to look at least between 0° and -90°)
– If both the head and the feet are in water, the hitbox shrinks to the feet height. Or maybe more at the waist height ? (would make more sense, but I'm not sure what would be best) »
What ? Resolved because "Works As Intended" ? It doesn't make sense, why would such a thing be intended ?? Not counting there's someone assigned to this, I don't think it would be the case if it was really intended.
Still in 18w22c.
Affects 18w22c.
Rewrote the description. I think it was needed (and I hope it's indeed better now, but I'd say it is).
Not sure if it's back or if it has always been a different case of the bug, but target selectors used within /scoreboard commands have this bug in pre2 !
Affects pre2
What the heck ? This is a duplicate, no problem with that. But this clearly is a bug, and the other bug report is "Works As Intended" ?? And accompanied by a message from a staff member that can be translated as "Don't want to bother solving your bug, use instead that workaround-that-should-not-be-asked-to-use" ???! Omg...
Okay, it may not be an incredibly important bug here, BUT you've done the same with
MC-127265whereas that is a bug that can be dangerous for some people ! (ever heard of epilectic people ?) What kind of nonsense is that ?? Seriously...Oh, and although I'm sure you don't care, remember about the part where I was talking about the OTHER tag, that it set to 0 as well but that we have no way to know, even with a /data, so we can't even fix ourselves what you refuse to...
This was the first, but clearly is that last version in which I will try to help. I have better to do than fighting for a game I apparently care more about than the ones in charge of it, despite barely playing it anymore...
@Pau Olivares
1) Build underwater something dolphins won't be able to escape from (you can also use a command like "/fill ~ ~ ~ ~ 8 ~ 8 ~ 8 minecraft:glass outline". Just make sure to remove the spaces between " ~ " and the numbers that follow, I have to add them to prevent text formatting. Also, I'm not 100% sure "outline" is what is needed here. I'd say it is, but if it's not, replace it by "hollow")
2) Go inside it
3) /summon dolphin ~ ~ ~
4) It will need some time (4800 ticks) before drowning
5) /summon dolphin ~ ~ ~ {WhateverTagYouWant:9000}
6) It will take drown as soon as summoned
7) /summon dolphin ~ ~ ~ {WhateverTagYouWant:9000,Air:4800}
8) /summon dolphin ~ ~ ~ {WhateverTagYouWant:9000,Air100}
9) The first one will drown after as much time as a normal dolphin, the second one will start drowning after 5 seconds
10) Now spawn them on the ground
11) /summon dolphin ~ ~ ~
12) /summon dolphin ~ ~ ~ {WhateverTagYouWant:9000}
13) /summon dolphin ~ ~ ~ {WhateverTagYouWant:9000,Air:4800}
14) Dolphin from step 11 will need some time before dying (probably 4800 ticks as well), and dolphins from step 12 and 13 will both start dying as soon as they spawn
EDIT : (adding some additionnel steps you can reproduce if you want)
15) To make sure : /gamerule DoMobSpawning false
16) Then : /kill @e[type=dolphin]
17) Go where you built your "dolphin trap / cage" : /summon dolphin ~ ~ ~ {IAmATag:42}
18) Stay near the dolphin before entering that command (and do so quickly) : /data get @e[type=dolphin,limit=1,distance..10]
19) Find the "Air" tag and see it is already set to 0. You can also try to find tag similar to "Air", that would determine for how long a dolphin can stay out of water.
20) Now : /summon dolphin ~ ~ ~
21) Entering that command again : /data get @e[type=dolphin,limit=1,distance..10]
22) You can check again, in case it would now be visible
@Misode
Thank you for pointing out ! I did not think about trying that with other mobs, I should have.
@Andrew
I understand better about that part, indeed (although I find a little annoying to have to specify the skeleton should have a bow), however, I never talked about nor used spawn eggs. The problem here (and it is indeed the same for the other bug report. In any case, if it wasn't, mine should then not be considered as a duplicate) is :
► /summon dolphin ~ ~ ~
→ No tags specified, and the dolphin has air
► /summon dolphin ~ ~ ~ {OgygenPump:1}
→ The dolphin has no air
If the mob had no air either in the first command, okay. It would be stupid in my opinion, but at least it would be consistent. But that's not what happens. And, although that's not exactly the same, I rather see that the same way than invisible armor stands are also invulnerable (not the tag), or that NoAI mobs are invulnerable (still not the tag) and have an effect similar to NoGravity.
(by the way, it still does not change what I said about
MC-127265. For which I even gave what seems to me to be the perfect solution)@ToseRedstone
Weird, but interesting and it could make sense. I'll investigate to see if what you say applies to me as well.
Thank you
It makes me think about the fact that if you use an empty bucket while having the head in a water block, you can't pick that water block. If the first block (other than the water one your head is in) you're looking at it is also a water block, it will pick this one instead, and if it's something else (like dirt, gravel or sand), nothing will happen.
However, if the water block you're in has a "waterloggable" block, like a sign, if you aim at it and hold "Sneak", you can remove it (although doing so is useless right now, at least in water generated with the map : Adjacent water block will create another water source in the waterloggable block. Wasn't that fixed in a previous snapshot ? Also, when you hold sneak, isn't it supposed to pick the water in the waterlogged block (if there is one) you look at, even if it's several blocks away ? I'm pretty sure it was, but it's not what it does anymore).
For example, in this screenshot where I'm inside a stairs block :
• If I aim at the sand, it picks the water block next to the stairs
• If I aim at the top part of the stairs, it picks the water that's inside the stairs
• If I aim under the top part of the stairs, which is the case in the screenshot (as you can see with the block outline that is the one of the block behind the stairs), nothing happens when I try to pick water
@Michael Wobst
Yes, it still is. It just so happens that I was doing my tests on it ^^ And so, it indeed seems to be to to framerate. But I do say to framerate, not lag spikes ! Thing is, I limit my Minecraft's framerate at 30 fps. And even in a void world, without moving and checking my framerate with Alt + F3, I quickly end up with a virtually locked Ctrl. And of course, I made sure it was the case even when not having the slightest lag spike while holding Alt Gr.
Then, since I was in a void world (and that overheating isn't instananeous), I tried turning my framerate to "Unlimited". I've been quite surprised to see that I could reach approximately 250 fps (but hey, void world, not moving at all, and by the time I finished testing, I was more around 150 fps), and it was much more constant than I thought it would be. Also, although I was still able to reproduce the bug, it indeed became harder.
For exemple, one thing I've done, both with 30 fps max and unlimited fps, was to write a bunch of letters, then repeat the two following steps : holding Alt Gr for a short time (say 0.5-0.7s), then pressing backspace. When limited to 30 fps, I would usually get the bug after 3-5 iterations. With unlimited fps it was much harder, and even when trying to hold Alt Gr for a longer time (maybe 3s ?), the bug wouldn't start easily.
Once more thing : It really seems to be caused by more or less low framrate, but it doesn't seem to be the case for lag spikes. Or maybe you would have to release Alt Gr after the lag spike starts but before it stops, in which case it would require quite a great timing, but I'm not sure (I mean, it can't be exclusive to lag spikes since I can reproduce the bug incredibly easily, all the time, while my fps is limited to 30 and I have no lag spike at all).
Affects 1.13-pre4
Still in 1.13-pre4
Forgot to add that afterwards (I noticed that in pre4 I think) but, still within the /scoreboard command, the bug can also affect the name of the objectives.
For instance, I had the objectives "Hits", "hitsdealt" and "hitstaken". And that must have been with this command that I noticed that :
/scoreboard players set @a 0 Hits
→ (not 100% sure I put the arguments in the right place and all, but it should be good) And it would stop me when looking back in the messages' history, because of the fact I had TWO other objectives (I'm not sure only one would work, but I actually did not try) starting the same way than the one used in that command.
Fixed in 1.13-pre5 (along with
MC-124990andMC-126136, that have already been set to "fixed". I guess this one not being set to "fixed" as well is only a little oversight ?)I update it for a reason, you should read it instead. And it's a duplicate of a "WAI" that should absolutly not be "WAI". And I explain why.
EDIT : Oh and by the way, it took me easily 5 hours to write and test etc everything. So also for that, I would appreciate if people could care a little more about something that should not exist.
Sorry for the notification if it bothers someone, I just wish to say that I wanted to try something with the example of the skeleton, that it took me time to think about that at the right moment, but that I finally did it.
The thing is that the example about the skeleton was said in a way that meant "skeleton spawn egg = skeleton with a bow" but "skeleton summoned via command = skeleton withOUT a bow, unless specified". And so after testing, I've seen that actually, as long as you do not add ANY tag within the summon command, the skeleton will have a bow. And so, it actually does work in a consistent manner (just not the one I thought of. And although I find it a little weird, well, this is a choice). And so I take back some things I said.
There still is the problem of the invisible tag though, so I created a bug report for that (sorry again for the notification if it bothers you).
Dolphins are not fishes, they do take damage if you let them out of water long enough (4 minutes if that's as long as for the time before they drown, but I did not test that and, like my bug report "duplicate" of this one points out, the corresponding tag cannot be found).
And because they are not fishes is why I don't like to say that they "suffocate", by the way (although I've heard that's the kind of damage the game applies to them).
PS : I know this is marked as fixed for the next release, it was only to point out mistakes that were made.
I could, indeed, but how ? :/ I can't seem to find a way to do that here. Else, there's Reddit but I'm not sure at all they read messages there, or Twitter but it doesn't seem to be the proper place for that, to me (and I guess my message could easily be overwhelmed anyway in the flow of other tweets ? I never use or check Twitter so I have no idea about that).
Do you have any suggestion on where / how I should proceed ?
NB : It's probably too late for that to be fixed in 1.13 anway, but this could still be done for 1.13.1 or so !
No, I was talking about in-game dolphins there.
Summon again a dolphin out of water (but maybe rather in a cage of glass than in a cave, since you said something about an inconsistency that seemed to be due to stone blocks, and that way you will still make sure it can't go in water). I just checked and now there is the tag that was missing : "Moistness".
However, there actually is a new bug right now (I'll create a bug report for that), so you will either have to summon the dolphin in water THEN teleport it in the cage, or use a spawn egg. You can also use this command and change the value of the tag as you please (remember the time unit are ticks, not seconds) :
/summon minecraft:dolphin ~ ~ ~ {Moistness:100}
In this example, the dolphin will start to take damage after 100 ticks, or 5 seconds. Default value is 2400 (2 minutes. I suspect it has been lowered, but I have no idea and, honestly, that's not important x) It's not like they put that 100 as the default value).
What did you fix exactly, for 1.13-pre6 ? Because both cases of the bug I talked about still are there (so still affects that last release).
In case it's needed to make things clearer :
Yep. I mean, it probably WAS there already, at least that's what I've always considered, but it was just not showing when using "/data entity get @e[limit=1,type=dolphin]". That is what was about my bug report that is marked as "duplicate" of yours, although it shouldn't (related, yeah, duplicate, certainly not).
Now, I don't know. I can only say that I think the tag, although invisible for a player, was already encoded in the game, so that it is why dolphins would still eventually die, but that it was also buggy (as your bug report points out). I have no idea if this was directly linked to the fact the tag wasn't visible or if it was due to something else. Now, I guess the important thing is that both problems are solved, right ?
About when you ask how that was working, if you meant about how to make the dolphin take damage without leaving and then joining back the world, well, you just had to wait long enough ^^ If you want a nice step-by-step guide, I guess the best I can do is to redirect you towards
MC-132601. Although, I wrote everything while out of the game and did not check if there was any mistake (and it so happens that I just noticed one, with the /data, so I'll fix it. But then it should be good).See the screenshot in
MC-132601? You can notice that there's no "Moistness" tag anywhere. That was the problem. It really is nothing more than that.The only other thing to point out is that I couldn't know yet how that tag was supposed to be called, so of course, that's why I never talk about "Moistness" anywhere. That was rather "whatever its name, it's not there".
(and all of that reminds me that I wanted to test, now that I know the tag's name, if using it in a command would work or not. In 1.13-pre5 or before, of course. Not very useful, although I think it would allow to know whether the tag was only invisible or not written to NBT. That is still not very useful, but I'm curious).
Not visible does not mean nonexistent. It could still be in the code, and most likely was.
And I just tried, by the way, and in 1.13-pre4 (because I have a profile with last snapshot and a profile with pre4 but too lazy to move to pre5 whereas it changes nothing here) :
• Adding "Moistness" doesn't work (I guess it didn't even have a name yet anyway)
• The dolphin would already start to take damage after 2400 ticks (2 minutes). I recalled when launching the game that I was wondering about that too, so I checked while I was at it.
@Play Dash
But it was "Fixed" short before 1.13-pre6 came out, hence RimaNari's comment (and maybe Greg's one too, I don't know).
Now, we will soon see anyway whether pre7 fixes this or not (but it most likely will, of course), so let's just wait for that ^^
@FVbico
I never said either it was marked as fixed for pre6, and it just so happens I do remember it was indeed already "1.13+". Now, if that wasn't short before pre6 came out, then it was short after that (fixed at 3PM, Rima's comment at 3:42PM. But is there a way to know the exact moment a version was released ? If so, it would allow to check. Else it doesn't matter much anyway x) Thanks for the info with the tabs by the way, never really paid attention to them, could prove useful)
@Kumasasa
No, it's something different. The issue you linked involves pressing simultaneous keys, but is not in any way caused by Minecraft (as stated there. There are plenty of combinations that are impossible, but precisely because it's a hardware issue, these combinations are 'never' the same from a keyboard to another).
Here, it is by holding for a little too long a single key ("Alt Gr"), and that's an issue that wasn't there in 1.12.2.
@Dominik
Not seeing the fps fluctuate doesn't mean they don't fluctuate. And although I highly doubt the bug is caused by low framerate, it does seem to worsen it (at least in some cases). Doesn't mean it's the case, but you should check with Alt + F3 (the graph don't show up every time, so it may be necessary to try several times, and it never works when F3 infos are already visible, so hide them first), you should check if you have at least some little lag spikes, when playing normally, that would bring you... let's say under 60 fps. You can try as well to limit your fps to 30, to check if it gets worse or not.
@Violine
I'm on Windows 7. But it looks like it's not due to the OS anyway.
Did you try to limit the fps to 30 ? Also, maybe you didn't wait long enough ?
@Neko
Because everything it says is false ? That's what you're implying... Not everything written there may be true, but how was I supposed to know that this information was false ? And by the way, is it even indeed false ? I mean, I doubt you know by heart everything down to its slightest details yourself, so it could very well still actually be true, just you not knowing.
Now, whether the wiki was right or not, the only thing I can say is that it would be a nice feature.
Even more efficient way to waste one's time than here, though.
@Bertrand @Valentin @Jonathan
In my opinion, having this bug still around is still better than fixing it BUT not fixing at the same time MC-127862. For a short explanation of the issue : "Alt Gr" can cause "Ctrl" to be virtually locked. Meaning that when it's the case, typing the letter "A" (quite common letter) would delete everything (which already happens on QWERTY / QWERTZ keyboards that also have an Alt Gr key, such as german ones).
Of course, that bug isn't problematic only with "A" key, but it would make it worse.
Still in 1.13.
@ZeNico
I said "having this bug still around is still better than fixing it BUT not fixing at the same time MC-127862". That means "the best would be to fix them BOTH as soon as possible", not "it's better to not fix these bugs at all".
"Plus, there, we are talking about keyboard shortcuts that are often used in game!"
Except that it does not have irreversible consequences, it's annoying at most. Whereas MC-127862 is a bug that is far worse since there you can lose everything you were writing (something you might not remember well, and the bug stays active as long as you don't happen to press "Ctrl". And in top of that, only the left one works if I'm not mistaken. So if you don't know how to stop the bug, you're in for a lot of trouble, maybe up to restarting your game. Because EVERY time you will use arrow or deletion keys, it will act for the whole word). And if you fix the bug with shortcuts combinations using A (or Q / Z / W / M), as I already said, it will just make MC-127862 much worse. Because then, every single time you will type an "A" while the bug is active will instantaneously delete everything you were writing (I mean, this time you won't even have the time to realize you should stop pressing backspace (most likely) and maybe save some text from deletion, and it will occur insanely often since the letter "A" is a pretty common one. Maybe even more (a little more) in French than in English ("on vA pAs se mentir, cette combinAison de bugs est pArticulièrement chiAnte").
In other word, to never be affected by this bug even when it's active, you would manage to always write exactly what you wanted to write (so never in need to modify anything) while doing a lipogram in "A"... Good luck :/ (a lipogram in "Q" is much, much, much easier, you can't disagree on that)
NB : A "lipogram" is a text in which you purposely omit one of several letters. Doing so with the letter "E" of course is the hardest, but it's still quite a challenge as well with the letter "A". While the letter "Q" is
quitepretty easy to avoid.I'm not sure what to think. It seems to have only been partially fixed, in the sense that you can for example write "minecraft:acacia_button{}" without having an error being displayed, but the game still doesn't suggest opening a curly bracket. Of course, this block would have no use of it (and it seems to be why that bracket isn't suggested, the same way " { " and " [ " are both "missing" for blocks such as carpets). But I guess a mod could add one ? Maybe that in this case, the curly bracket would then automatically start being suggested as well ? That would be a nice thing, but I am unable to test if that's the way it works.
To make it clear though, now " [ " does show in most cases for /fill, /setblock and /clone, as well as " { " for /give, /replaceitem and /clear (normal blocks only for the last one). And if the fact that they don't appear for any block is intended, then I guess we're still missing the suggestion " { " for all "#blocks" in /clear commands (but then I think it would be the only thing missing).
As for the part of the bug where I talked about brackets not showing after a tab-completion, I realized it must be WAI since "Tab" can be used to move between the suggestions. Of course it won't both allow to navigate through the block suggestions but only suggest the brackets at the same time.
It would have been nice if the game could provide the bracket suggestions in a more intuitive way, but both solutions I thought of are bad (keeping in mind a player not knowing about these brackets should still easily see them being suggested).
Anyway, maybe I should remove that part ?
I'd like to add something I said in my bug report (that is a duplicate). So I'll copy-paste that here. Like I said there, I'm not sure this was something that existed, but even if it wasn't, I'm hoping the devs couls add that while they're at it, because it would be so useful ! (at least for IDs such as scoreboard criterias) So here it is :
" I can't remember if something like that was there in 1.12, but a useful thing would be to have additionnal suggestions that would always be at the top (except if there are results that would end before having a "non-letter character") but that would never suggest anything after the next "non-letter character".
Explanation :
► So, in short, nothing changes at all about which full IDs are shown, we only add what are all the categories in which they are scattered. "
@Stef B
Except that if you start doing that in Minecraft, you'll get used to doing that out of Minecraft as well :/ Which then makes it annoying anywhere, not only in Minecraft. And to make it even worse, Ctrl+Q is a shortcut that can sometimes act like Alt+F4 (and you won't always get a warning saying you have unsaved changes. For instance, if I do it like that, when writing in my browser, it won't always warn me about anything, depending on what site I'm writing (although it doesn't seem to work anywhere anyway right now, for me. Which is weird, especially that I'm pretty sure it should have worked on Firefox and windows explorer (also tried on Notepad++, but I may have unbound that there, which could be an explanation). Maybe I've got some bug that makes that useless yet potentially annoying shortcut not work anymore for me ?)
@val59000mc
It's not at all the third most voted bug (it's the 287th), and it has been reported around 1.5 year ago. Which doesn't change that it's surprising such a bug is still around after so long of course, it's like they don't care (which is why I'm not active anymore here, and as well why I have much higher hopes in "you-know-what-game-I'm-talking-about" (or maybe not, but I obviously can't say here clearly what I'm talking about). At least it's quite promising on every aspect so far (and with some luck, maybe it will make Mojang wake up)).
Can anyone still reproduce this bug ? I assume it's still there, but I'm on a new computer now, and I can't seem to reproduce it anymore (even tried putting something on Alt Gr while I was away, which was for about 1h30min, but no. That was on 1.14.4, which was already confirmed by @Sven).
I've been thinking it could maybe be caused by hardware ? My laptop (on which I had the bug) had Intel i3 CPU and NVidia GPU (GTX 410M I think). My new PC has AMD Ryzen 5 1600 CPU and AMD RX570 GPU.
And Windows 10, although it doesn't seem at all to change anything.
EDIT : Also my framerate was still limited to 30 (like before). Since I talked about framerate that may be at least part of the issue. Although I probably had a quite more stable 30 fps than on my laptop.
That's good news I guess ! Although it would be nice to get feedback from more people. In any case, I may check on my laptop later (since I still have it), it would be interesting to see if I can still reproduce that bug. Especially that I think on the contrary the new hardware helped for me ^^ (although not necessarily from being more powerful) I mean, pressing Alt Gr for about 1h30min was on 1.14.4, where we know the bug wasn't fixed ! (doesnt mean it was fixed for me, but it became at least really hard to reproduce, thus either impossible or very unlikely to happen under normal circumstances).
I never tried myself on that version though (not on my laptop), only on 1.14 (and without Optifine, since it wasn't out yet back then (may be a nice idea for my test on my laptop to do it without Optifine actually, and if I can reproduce the bug, try again but this time with Optifine). Even with 1.13 I never tried reproducing it with Optifine, I was barely launching the game once in a while for some tests).
Yeah, still happens on my laptop (maybe a little harder, but still pretty easily).
I can only agree with @ZeNico13 (and, I mean, it's the bug update. If it's not a priority now, when will it be ?). However, and although it does not concern me anymore thanks to my new computer (but for the sake of those that are still affected), I'd like to remind you that there's also MC-127862, which will become worse if and when MC-121278 will be fixed (if it's the only one of the pair to be fixed).
In short, it would become worse because it would mean that Ctrl+A wouldn't require to actually (physically) do Ctrl+Q on the keyboard, hence with MC-127862, when writing something, it would become far, far more common to lose everything, since "A" is obviously much more common than "Q" (MC-12762 is basically the Ctrl key being virtually locked, so keyboard shortcuts can interfere, in a variety of ways, while doing something else).
@anonymous : No. We're talking about a keyboard shortcut that can more or less work anywhere, not only on Minecraft. And for this reason, even if it was possible to change the keyboard shortcut, it would be a bad idea since you would get used to your custom shortcut on Minecraft and keep doing it outside of Minecraft as well, where it would still be Ctrl+A. If would ever get used to your custom shortcut on Minecraft (which wouldn't prevent using the wrong shortcut more or less often, even out of Minecraft, most likely).
Also, even if it was possible to change the shortcut AND that it was a thing only on Minecraft, it could still be an issue, since as you said yourself, not every key fits the way you play.
Seems mostly fixed with 1.16 pre2, although not entirely. This is the most I could do with this new pic, and only with honey blocks :
It seems to depend a lot on what is under the water. In short, with sand well lit, the line disappears a lot more, while sand less lit or dirt make the line more visible (I could even notice it with fishes passing by).
@Michael Wobst
Looks like it indeed ! I guess my issue can be set to "Resolved" then (but maybe still make them related ? Seems possible to me that my issue could come back by fixing
MC-187598, depending on how it would be done).@[Mod] Galaxy_2Alex
(and while I'm at it, moving "out of water" because it currently implies spawning the dolphin in water then moving it out of it does the same, which is not the case)
I think "die" is misleading (the dolphin's HP doesn't instantly drop to 0. Unless that's what happens now ? Although I would then say it must actually be another bug). Probably not that important but I prefer to change that