Raconteur
- Raconteur
- JIRAUSER731725
- Europe/Stockholm
- Yes
- No
MC-255574
Low
Normal
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal:
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 1
6- 16 =0 >= 0 | Inrange
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal:
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 16 = 1 < 1 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal:
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 16 = 1 < 1 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal:
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 16 = 0 >= 0 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 16 = 1 < 1 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal:
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 -
16=0>=0| In range- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 -
16=0>=0| In range- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 -
16=0>=0| In range- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 -
16= 1 < 1 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 >= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 >= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 >= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 < 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16
>= 16 | In range- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16
>= 16 | In range- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16
>= 16 | In range- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17
<16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Foreword: I used mods and launched the game the game with a modified version of the source code to find the bug but we can reproduce it in vanilla.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Foreword:
I used mods and launched the gamethe gamewith a modified version of the source code to find thebugbutwecan reproduceitinvanilla.
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Foreword: I used mods and launched the game with a modified version of the source code to find the origin of the bug more easily but it can be reproduced in vanilla..
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Foreword: I used mods and launched the game with a modified version of the source code to find the origin of the bug more easily but it can be reproduced in vanilla
..
Problem:
The maximum range of a nether portal (PR) should be 128 blocks in the overworld, and 16 in the nether.
But it's actually 135 in the overworld instead of 128.
Reproduce the my test scenario:
These steps apply only to teleportation toward west, but I personally tested all the directions and obtained the same results.
Map setup:
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the overworld
- Place two nether_portal block at (0,1,0) and (0,2,0) and in the nether.
These portals are equivalent to each other in both dimensions. They are our points of reference.
Steps to test the range of nether portals teleportation range for a number of blocks N:
- Place two nether_portal block at (N,1,0) and (N,2,0) and in the overworld
- Go through the portal
- If you teleport to the reference portal at (0,1,0) in the nether, N <= PR. Else, if a new portal is generated, N > PR.
- Don't forget to delete the new generated portal if needed.
You can also use my test map, all the portal are placed with explications:
Test map (I can't upload it directly, it's too big).
Results:
Expected results, limit at 128:
- For N = 128: In range
- For N = 129: Out of range
- For N = 135: Out of range
- For N = 136: Out of range
Real results, limit at 135:
- For N = 128: In range
- For N = 129: In range
- For N = 135: In range
- For N = 136: Out of range
Origin of the bug:
I generated the code using the most recent release of MCP Reborn.
I searched for the distance filter that defines the max teleportation range and found this function.
PoiManager.javapublic Stream<PoiRecord> getInSquare(Predicate<Holder<PoiType>> predicate, BlockPos blockPos, int radius, PoiManager.Occupancy status) { int i = Math.floorDiv(radius, 16) + 1; return ChunkPos.rangeClosed(new ChunkPos(blockPos), i).flatMap((chunk) -> { // return all the portals in the chunks around blockPos return this.getInChunk(predicate, chunk, status); }).filter((portal) -> { BlockPos portalPos = portal.getPos(); return Math.abs(portalPos.getX() - blockPos.getX()) <= radius && Math.abs(portalPos.getZ() - blockPos.getZ()) <= radius; // distance filter here }); }
'blockPos' is the ideal position arrival portal. If you teleport from (128,1,0) in the overwolrd, 'blockPos' will be equal to (128/8, 1, 0/8) = (16, 1, 0) (ideal arrival coordinates in the nether).
'radius' will be equal 16 when teleporting form overworld to nether, and 128 when teleporting from nether to overworld.
It will first search all the portals in the chunks around that ideal coordinate, and then filter with the difference between 'radius' and the distance between the portal and 'blockPos'.
The problem come from 'blockPos': the values are integers.
I tested with a modified version of the game and printed the values when entering a portal (we have a portal at (0,1,0) in the nether):
- Teleport from (128,1,0) | 128 / 8 = 16.000 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (129,1,0) | 129 / 8 = 16.125 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (135,1,0) | 135 / 8 = 16.875 | blockPos = (16,1,0) | 16 - 0 = 16 <= 16 | In range
- Teleport from (136,1,0) | 136 / 8 = 17.000 | blockPos = (17,1,0) | 17 - 0 = 17 > 16 | Out of range
We can see here that 'blockPos' is the result of the floor division of your coordinate when you pass thought the portal in the overworld by 8. The problem is here: all 16.XX distance value in the nether bring us back to 16.
Suggested fix:
Add an 'idealOpposite' variable to the portal object to represent the ideal teleportation position in the arrival dimension.
Then, use this variable to always compare the range in the depart dimension.
Step to reproduce:
1) Create a new .minecraft instance for the game (in our case, just remove the "resourcePacks" and "incompatibleResourcePacks" lines form your options.txt will work)
2) Launch the game, wait for the options init
3) You can see in your options.txt that resourcePacks is an empty list
4) Go to the pack screen and close it immediatly, the game will reload ressources even if you did not change anything because the list of enabled packs on the screen contain the vanilla pack, but the list in the options do not
5) You can verify that "vanilla" has been added to the resourcePacks list in options, and that going back to the pack screen and close it will not trigger more reloadUPDATE:
Found an easy fix. You just have to add "vanilla" to the default list in the GameOptions class constructor.
Step to reproduce:
1) Create a new .minecraft instance for the game (in our case, just remove the "resourcePacks" and "incompatibleResourcePacks" lines form your options.txt will work)
2) Launch the game, wait for the options init
3) You can see in your options.txt that resourcePacks is an empty list (it should contain "vanilla" because the vanilla pack is loaded)
4) Go to the pack screen and close it immediatly, the game will reload ressources even if you did not change anything because the list of enabled packs on the screen contain the vanilla pack, but the list in the options do not
5) You can verify that "vanilla" has been added to the resourcePacks list in options, and that going back to the pack screen and close it will not trigger more reloadUPDATE:
Found an easy fix. You just have to add "vanilla" to the default list in the GameOptions class constructor.
Can you provide a copy of your world ? You can upload it elsewhere and just give us the link. Thanks !
I confirm that it don't work for me too. I can't find the origin for now, but I got this when trying to tp: (it's the same for the end dimension, the autocompletion only propose the overworld. I think the datapacks you used messed up the dimensions)
I tested with a vanilla client and with no datapack loaded btw. Remove mods or datapacks will not work, the world is already broken.
@[Mod] ampolive , I've seen this issue too and it's not a duplicate.
MC-183103refers to the portal mechanic introduced in 1.15. The range was too large because the search for the game was looking for the portal in the surrounding chunks, in a box of 17*17 chunks centered on the chunk containing the ideal block portal of arrival. It means that if your portal block was on the bordure of a chunk, the maximal teleportation distance was 8 * 16 + 15 = 143. You can see the diagram illustrating this below.1.15 teleportation limit:
In 1.16.2, they implemented a filter which acts after the detection of portals and which is supposed to bring the limit back to 128.
I represent it as a circle:
1.16.2 teleportation limit:
And the issue I reported is about this filter. It should be 128 blocks like on the schema, but it's 135 instead. So I think these issues are not the same.
Please be more specific, what are the steps to reproduce the bug? What were you hoping to do? And finally, I have the impression that your report is rather aggressive. The goal here is to help developers spot the many bugs that any game may have, not to spit on them.
It is the same bug that was described in this video ?
https://www.youtube.com/watch?v=rV1yJ5uM6ng
Upload the map somewhere and give us the link please.
You can report paper issues here: https://github.com/PaperMC/Paper/issues
Describe the bug more please. Are you on multiplayer ? Upload a screen with your F3 displayed...
Can you describe a detailed process to reproduce the bug ?
You can upload the 100MB map on an other platform and send the link for download here.
It's odd. Can you upload the logs ? We can't reproduce without more information.
You need to provide the crash log.
We need more to help you. Can you provide the game logs ?
Can you explain how you determined this? Have you really tested it?
I think this comment sounds more like a feature request than a bug report. This is not the right place for that.
I tested and yes, in the left list of items on the left, it say you can trade air. But if you try to trade, you can see that it's not possible, there is nothing to pick up in the trade result and the emerald is not consumed.
I assume that "air" is the default display when, for some reason, the item to trade is unavailable or invalid. For example this reddit post, the guy enter a wrong command and the item traded by the villager is invalid, and replaced by "Air": https://www.reddit.com/r/Minecraft/comments/ehgy6l/help_with_custom_villager_keeps_trading_air/
So I think it work as intended. I personally consider it as a unwanted easter egg.
Update: the only problem that I can find is that the trade is blocked after that. You may consider that as a bug... I don't know.
Still not enough informations. You need to provide logs like it was asked to you in
MCL-22371. You issue will be close again. Plus, it's the wrong project, it's about the Minecraft launcher.You fabric is installed on the server ?
I can confirm. I can reproduce it.
Still happens in 1.19.2.
Can be problem if you need to place a map in an item frame. If it's in the "out of the map" zone, the cursor do not display at all.
It does not affect most players, and even for the players that encounter it, it happen only one time.
It's a bug because the reloading of resources when you quit the resource pack screen should only happen when you added/removed a pack, or changed the order in the list. It's not a priority because occurences are rares, but this is one of these bugs that give a feeling of a non polished game, even more when you now that it needs only one line of code to fix it.
I've fixed it in a mixin if you want to check:
https://github.com/Brancieq-Paul/Pack-Stack-Memory/blob/main/src/main/java/fr/paulbrancieq/packlistfeatures/mixin/GameOptionsMixin.java
(the only relevant method for our case is the first Inject in the <init>)