Hamish Arblaster
- hamarb123
- hamarb123
- Australia/Sydney
- Yes
- No
MC-83592
MCPE-32634
No Effects From Rotten Flesh Sometimes
Device - Samsung Galaxy Note 3
Device - Samsung Galaxy Note 3
It starts off black, goes to the MINECRAFT screen, and either freezes indefinitely or closes.
Device - Samsung Galaxy Note 3
It starts off black, goes to the MINECRAFT screen, and either freezes indefinitely or closes.
Video (is too big): https://drive.google.com/open?id=1lJ5WUztnw3nyizGYLdcDapvEn5zGEn5x
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "
", (U+007F, looks like house character in game)0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", "". "I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "
ÿ" (U+002D U+0080), "-1", "+1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "
1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", "". "", (U+007F, looks like house character in game)I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), "-1", "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "
1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", "". "", (U+007F, looks like house character in game)I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), "-1", "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, TILDE with minus sign, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), "-1", "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, TILDE with minus sign, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080),
"-1", "+1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, TILDE with minus sign, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), MINUS MINUS ONE, "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE,
TILDE with minus sign, (U+007F, looks like house character in game)I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), MINUS MINUS ONE, "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "ÿ" (U+002D U+0080), MINUS MINUS ONE, "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+0080), "-ÿ" (U+002D U+0080), MINUS MINUS ONE, "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00
80), "-ÿ" (U+002D U+0080), MINUS MINUS ONE, "+1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "-ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1"
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "
-ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "
ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080), "-1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "
ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080), "-1"I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080)
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080)
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
I have also found some strings that generate into the 1 digit seeds to show they are not broken (doc). Here is a video showing this also.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080)
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
I have also found some strings that generate into the 1 digit seeds to show they are not broken (doc). Here is a video showing this also.
When a 1 character seed (where the codepoint is less than U+0080) is entered into the seed box, and the world is generated, the world will instead use a new random seed each time. This is also still broken when a '-' character (minus sign) is inserted in front of the first character.
I can confirm this bug exists for both the Windows 10 Edition (out of beta) and the Android version (in beta). I have not tested any other platforms, but I imagine the bug also exists on all of the platforms.
Also note, both platforms were 64bit, so it may not be broken on 32bit machines, but my Windows 10 machine was x64 (intel), and my android device was 64bit ARM (exynos), so I find that unlikely as it seems to work on 2 different processors on 2 different platforms already.
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they generated randomly (broken): "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "a", "-a", TILDE, MINUS TILDE, (U+007F, looks like house character in game)
I have tested the following seeds (without quotation marks) on Windows 10 (out of beta) and they didn't generate randomly (expected behaviour): "ab", "☺" (U+263A), "ÿ". (U+00FF), "ÿ" (U+002D U+00FF), MINUS MINUS ONE, "+1", (U+0080)
I also tested the seed 1 on android (in the beta for 1.11) and it generated randomly.
Since the cutoff point for the random seed appears to be U+0080, I imagine there is some accidentally incorrect conversions between unicode and ascii in the number parser for the seed box, as this is the ascii cutoff point, I find it interesting that it's also still broken with a minus sign in front of the other character.
Here is an example with the seed "1" entered on Windows 10 (out of beta): Minecraft 2019-04-15 07-37-20.mp4
The 1 character numerical seeds should generate a world with that seed, and the other 1 character seeds should be the same each time, that is the bug in its simplest form.
I have also found some strings that generate into the 1 digit seeds to show they are not broken (doc). Here is a video showing this also. There are also some seeds on the document that generate these seeds from numbers (credit to here / here) which generate those seeds because of overflow (quite odd that they even count as numbers as they are too big to fit in a 32bit integer memory location!), also note that the seed -1 was strangely excluded from this list, as it seemed to generate randomly no matter what number was entered.
confirmed
Still an issue on the Samsung Galaxy Note 3
It is both a release, and a snapshot
This has been fixed in the 1.6 update for Samsung Galaxy Note 3
Kyle morley Try a seed from the document I've added.
Timothy Chaplick I see what you did there, clever
Timothy Chaplick I have updated the google doc, and also note, you do not need to artificially create those seeds as you can do it with seeds from my doc (even -1!). I also added the newer versions.
Hi, I have this issue too. Please show that you care about macOS, you've ignored many macOS-only bugs that make the game unusable eg.
MC-121772.Hi, I have this issue too. Please show that you care about macOS, this bug makes the game unusable and it's existed since 1.13. It is not hard to fix since the mod https://github.com/andyvanee/hscroll works for versions up to 1.16 (it's not updated to 1.17 yet), which is a 76-line code fix, I shouldn't have to mod the game to make it work.
Hi, I have this issue too. Please show that you care about macOS, you've ignored many macOS-only bugs that make the game unusable eg.
MC-121772.Where do I get this updated version? macOS packages OpenAL with it, and I've already tried Soft OpenAL's latest version and it didn't fix it.
Edit: Thank you so much! I build https://github.com/kcat/openal-soft myself and it works now!
That's incorrect, firstly it was introduced in 1.13 (ie. If you play <=1.12 you still don't experience it). Secondly, being able to scroll sideways is not a bug and shouldn't even be able to be turned off, it is a feature on every modern OS. I believe it's one of the libraries that minecraft uses that causes the issue.
I think that a reasonable solution would be to add invert vertical and horizontal mouse wheel options to the menu screens.
I will look into whether there are any APIs that can solve all of our input issues on macOS.
I've created an example app that just detects scrolling in a way that is consistent when shift is pressed and when the user scrolls horizontally or vertically. See here: https://github.com/hamarb123/mc-121772-examplefix. I hope that these are integrated into Minecraft, but I plan to possibly make a modified glfw that will do this correctly (it can also easily be implemented in Java using objective c bridges and the addLocalMonitorForEventsMatchingMask:handler: api or overriding the appropriate methods like I did in my example).
It also fixes other issues (such as my new issue
MC-255800- I couldn't find an open one for this, which is where holding control and then left clicking does a right click instead). See the link earlier for all the issues it fixes. Some are included here:As with
MC-121772, the code I provide at https://github.com/hamarb123/mc-121772-examplefix can be used to fix this issue.Thanks for you reply,
If this is caused by LWJGL (which is my suspicion), this (or one of the others) should still be left open as it is a serious flaw in the input in Minecraft. It means that by sprinting you can no longer left click, which is ridiculous - is that not a bug?
This should be resolved as works as intended instead. I had a look at the input code for this and discovered that it was actually done by Minecraft in the input code. I think this is bad since, as I said, this makes using the default controls basically not playable on a real mouse. This should be (imo) removed or an option, since it makes it impossible to sprint and left click on a normal mouse, but can be somewhat useful on a trackpad (not useful enough imo to make the game substantially worse on macOS when using a mouse compared to other platforms).
Edit: fabric function name that implements this - Mouse.onMouseButton
Edit 2: I am copying this message to the one I'm apparently a duplicate of.
Modified copy of what I put in my duplicate issue
MC-255800This is not done by LWJGL at all (it may have been in older versions, but definitely isn't in 1.19 - I suspect not since 1.13).
This should be resolved as works as intended instead. I had a look at the input code for this and discovered that it was actually done by Minecraft in the input code. I think this is bad since it makes using the default controls basically not playable on a real mouse. This should be (imo) removed or an option, since it makes it impossible to sprint and left click on a normal mouse, but can be somewhat useful on a trackpad (not useful enough imo to make the game substantially worse on macOS when using a mouse compared to other platforms).
Fabric function name that implements this - Mouse.onMouseButton
I've made a fabric mod that works for 1.14+ that fixes this. If you want, you can download it at https://www.curseforge.com/minecraft/mc-mods/macos-input-fixes, https://modrinth.com/mod/macos-input-fixes or https://github.com/hamarb123/MCMacOSInputFixes.
Hi, there is a page for issues in my mod: https://github.com/hamarb123/MCMacOSInputFixes/issues. The scroll swapping on the hotbar was intentional and actually makes it consistent with how the rest of macOS scrolls (it can also be inverted by the natural scrolling direction option in macOS itself but this will change all of the scrolling obviously), note that Minecraft actually swaps specifically hotbar scrolling intentionally hence why I did this to make it what it 'should be', but I've had a few people comment about it, so I was planning to add an option to change the hotbar scrolling back. I've created a Github issue for it, feel free to add notifications to it so you can see when it gets released https://github.com/hamarb123/MCMacOSInputFixes/issues/1.
@timofey_s, you can also use my mod which is much easier to do since it's just a fabric mod and doesn't require installing apps & setting up permissions (https://www.curseforge.com/minecraft/mc-mods/macos-input-fixes), but it's 1.14+ currently only though. You can also make the function keys the function buttons in macOS settings if you want - this will change it system wide, but you can change it back later if you want - it just swaps when you need to press fn / not press fn for the keys (system preferences / keyboard settings, somewhere in there I think (I've got a touchbar so they're slightly different settings, but an equivalent set of options also exists for me)).
I will also note that my mod (https://github.com/hamarb123/MCMacOSInputFixes) works on all of 1.14-1.20, and supports some customisation settings to control precisely what behaviour you want
.
Can confirm it's fixed for me