During the Minecraft Live event seed parity was explained. The scenario given was a that Java player can generate a random world and that seed can be given to a bedrock player and they will get the same world. I realise this likely only covers biomes, terrain etc.
As at 1.18.0.27, seed parity for worlds with a random seed only works when going from Bedrock to Java. Ie a Bedrock player can generate a world with a random seed and give that seed to a Java player.
If a Java player generates a random world and gives that seed to a Bedrock player, the bedrock player gets a completely different world.
(see https://youtu.be/w6zLprHHZOk?t=3265 54:26 - 54:38)
Steps to Reproduce:
In java (latest snapshot) create a new world, leaving the seed field blank.
Once in that world use the /seed command to get the seed for the world.
Launch Bedrock Beta 1.18.0.27
Create a new world with the seed from java
Observed Results:
The worlds have completely different biomes and terrain.
Expected Results:
The worlds should have very similar biomes and terrain
Notes:
I realise this side of seed parity might simply not have been implemented yet. I figured it would turn up in one of the betas at some stage. Now that 1.18 is at the pre-release stages I'm worried this may have been overlooked.
Linked issues
is duplicated by 5
Comments 7
I have found that it also goes for some seeds the other way (Bedrock seeds not having parity with Java)
@unknown
Personally, I have not met such seeds and have not found information about this anywhere. Could you provide an example of such seeds. This could be a completely different problem.
64 bit seeds for everything might be a bit complicated as there would be implications for peoples existing worlds, and would require swapping out the RNG object on a lot of functions.
One option that would have minimal impact is to leave the existing seed variable, and whatever is accessing it, as it is. A new 64 bit seed variable could be added and then only use it to initialise the biome RNG. When parsing the seed field on the create world screen, the 64 bit interpretation of the seed could be put in to the new variable and a simple cast would put the lower 32 bits into the existing seed field.
A data fix would be required for existing worlds with negative seeds but thats as simple as changing the existing world seed to an unsigned long representation of the same number.
I think the world creation screen is already parsing the field as a 64 bit number as it overflows to a 32 bit number up to the 64 bit number limit. After that it treats the number as text.
The big issue, as pointed out, is the limitations of Bedrock Edition's number handler. Your solution is not horrible and could solve a few of the issues caused by the number handler, but it fails to solve the root of the problem, with that being the number handler itself. The only solution that can solve these issues is changing the number handler to support values up to 2 64 . Examples of these issues are simple to find with the stripped lands being a good showcase.
I vouch for this, 64 bit would be a great improvement to the Bedrock seed-finding community.
I would like to play in the same world as a YouTube series called Brotherhood 2 but the seed is not the Same!
This problem is 32 bit numbers. Java version uses 64 bit numbers for seed. This problem was first described in MCPE-18739, however, it is closed as "Works As Intended", but after the seed parity was officially announced for minecraft live, I think this problem needs to be revise.
I can confirm this report.