Ah ha! After sliced_lime's latest custom dimension/biome tutorial video, I figured out that this is not a bug, but something I've done wrong. Notice that the individual biome settings (altitude, temperature, humidity, etc) in the dimension files are the same from dimension to dimension. This means that when the game attempts to place these biomes along the contours of the perlin maps, all of the biomes are equally likely to to placed at any given point, so the worldgen just picks the first biome in the list.
I'll attempt to set this ticket to resolved.
Now that sliced_lime released more info about new fields in the dimension_type definitions, I was able to update the attached data pack and get it functional again. However, the reported behavior is still occurring. I've updated the affected versions, above.
Sure, custom_dimensions.zip added.
I used the Re-Create world feature to make a fresh 1.16.1 world using the same settings as my test worlds from the snapshots, and it also copies the custom dimension data pack from earlier tests. Opening it for the first time shows no data pack errors in the logs, and the '/datapack enabled' command shows that the dimension test data pack is enabled. However, the custom dimensions don't show up in the autocomplete for the 'execute in' command, and are not found if manually typed in (without the autocomplete). I have to assume something has changed in the expected structure for custom dimension data packs, but changed in such a way that the snapshot syntax doesn't create errors.
It's hard to say. The data pack as described no longer seems to work at all. The data pack loads without errors, and is listed as enabled, but none of the dimensions show up in the "execute in" command autocomplete. Has something about custom dimension data pack structure changed? I haven't found updated documentation yet.
If it matters at all, I've had the same experience. I came to create a ticket about this exact behavior, and found this ticket.
In MC-184836, I provided a custom settings file that does not duplicate dimension names (as the example linked here), and also produces a crash. In my example, a new dimension is added with a unique name and a copy/paste of the settings for the normal overworld, except the seed is changed. The game crashes on world creation, and the crash report linked in MC-184836 has crash details.
I would mention that MC-184653 details a situation where the custom settings file duplicates dimension names. My example uses a unique dimension name, and arguably unique dimension settings, and still produces a crash.
I can confirm that the issue is still present in 1.8.1 Prerelease 3 and Launcher version 1.5.3.
The behavior I'm seeing is ghosting of the blue channel into the red channel. It's easiest to see by looking at a light colored object, like an oxeye daisy or a torch, and closing the 'blue' eye. This way you only see the red channel, and the blue ghosts.
Still going on in 14w02c, as well.
@ Grum: I know you've said in the past that you guys wouldn't be focusing much effort to fixing such a novelty feature like 3D anaglyph mode, but since we all don't have Oclus Rifts, it's the most accessible way to see Minecraft in 3D. Even in it's current state, it's a pretty amazing experience. I'd like to humbly ask you guys to reconsider.
Sorry about the confusion, I copy/pasted the wrong filename when I wrote the report (I hate typing file names). Those attachments demonstrate the issue perfectly, though. Thanks!
@Kumasasa The original behavior that I reported to start this ticket does persist into 13w10a (I reran my original tests in a new map). However, even then I suspected what I saw wasn't the result of a bug per se, but unfortunate behavior in stacked hoppers.
tl;dr Yes, still going in 13w10a.
Confirmed in 13w10a.
I'm having difficulty reproducing the behavior myself, actually. I originally saw the issue in a backup of an existing world, where I was testing hoppers with a mob system I previously built. I see the issue there, but not on the simple test I built blocks away, consisting of just a water stream and a hopper. Plenty of item duplication and invisible items bugs to be seen, but not the 'clogging' I reported. The hopper under the mob system (pictured) still shows the behavior, though. Every time and egg comes by, it completely clogs the hopper, and nothing can get through.
This bug doesn't seem to be fixed in snapshot 13w01b.
This 'bug' doesn't seem to be fixed in snapshot 13w01b.
I like this functionality, so I hesitate to call it a bug.
I'm having the same issue after a fresh install of the Minecraft Launcher on Linux Mint 21.3. I've attached a screenshot of the (black) login window alongside the output to the terminal. The red box shows the lines that appeared after I pressed the Microsoft Login button.
[media]Edit: I should note, I installed the Debian package, which I probably shouldn't have done in Linux Mint. I uninstalled it, switched to the flatpak version, and everything's working fine.