Gatinh0

I too am experiencing this. Block Emissive layers appear to now have no transparency. Entity emissive layers with transparency seem to be working properly.

Ever since since the update mentioned by OP, any portion of a layer that is intended to be alpha-transparent that used to work properly is now filled in with a solid color. The color chosen for the fill appears to come from a random pixel of the original block, or maybe is an average of pixel colors, because the fill color always seems to somehow relate to the block in question. I have multiple texture packs that I’ve made that used to work as intended when the emissive layer was first introduced, but now are affected by this bug. The only work-around is to not have any transparency in the block, so the entire block is emissive.

Here is a video clearly showing the player bumps up when passing through pitcher plant crops. The same is not true for any other crop, nor for the pitcher plant itself.

https://www.twitch.tv/gatkong/clip/AmazonianDreamyDoveOSkomodo-rGEoTCOG50uW2Rf2

Twitch video, wherein you see the 2.16.12-1.7.2.0 launcher clicked, and nothing responds, then the 7/8 launcher is clicked and it works.

https://www.twitch.tv/videos/2082318186

see attached launcher log

@[MCQA]] Zgajak

"Can you tell me if you have other users on your PC?"
=No, I am the only user on this PC.
"Are you switching accounts before booting Launcher?"
-No, there is only one Microsoft/Mojang/Minecraft account on this PC.

@[MCQA]] Zgajak

Today the Minecraft launcher did nothing when clicked, so I had to launch from the 7/8 launcher again. This is the first time I've had to do that since early February, so the problem is substantially improved since using the 7/8 launch in early February, but it's not entirely resolved.

Since the time I launched the game using the 7/8 launcher, which subsequently itself launched the 2.16.12-1.7.2.0 launcher, doing so seems to have somehow fixed whatever issue was plaguing the 2.16.12-1.7.2.0 launcher, because since that one time, I have 100% of the time been able to successfully launch Minecraft using the 2.16.12-1.7.2.0 launcher straight-away without difficulty, without having to use the 7/8 Launcher, without having to repair the 2.16.12-1.7.2.0 launcher, and without having to reboot my PC. Should I discover the 2.16.12-1.7.2.0 launcher resumes malfunction and needs repairing again, I will update this reply to indicate as such, but for now, it seems to have been fixed.

Of note... the 2.16.12-1.7.2.0 launcher now has a "quick play" selection menu in the upper-right hand corner. I may have just never noticed this before... but this is the first time I've ever noticed this menu's existence. Maybe the appearance of this new menu, and the fact that the 2.16.12-1.7.2.0 launcher is now working correctly are related? This might just be my inattention to this detail until now... but it's existence surprised me... so I thought MAYBE the two are related.

In reply to [MCQA] Zgajak:

Have you tried installing it from website/Xbox app?
-Yes
Have you tried installing 7/8 version of the Launcher?
-Yes, since you suggested it. When the 2.16.12-1.7.2.0 fails to respond as it always does, if I then launch from the old 7/8 launcher, that will then in course successfully open the 2.16.12-1.7.2.0 launcher. It's not really a "fix" for the broken 2.16.12-1.7.2.0 launcher so much as it is a work-around to force it to respond, much like a daily repair and restart will do.
*Have you updated your Windows? *

• Yes, Windows 11 Home version 10.0.22631 Build 22631

Can confirm for 1.20.1.

This affects not just creative mode loading structure blocks, but also datapacks procedurally loading a structure during worldgen such as a village house or a street.

To followup...
@Dhranios there are no mods, running vanilla with datapacks. No java code.

@[Mod] tryashtar See attached datapack as requested

. After extensive trouble shooting and testing, I've determined the give @s written_book command works as intended in single player (both alone and with many other datapacks running) and in multiplayer when running this datapack alone. The scenario wherein the give command fails to give at the @s target occurs when the server is running multiple other datapacks, even though server logs show no indication the server can't keep up (in the attached, I've included the server's latest.log during which the datapack's give written_book command fails so you can see, while the log has many things to say, none of the logs pertain to the datapack in question nor indicate any difficulty in the server keeping up). Considering it's still vanilla Minecraft, other datapacks running concurrently still shouldn't cause the give command to fail as it does. To experience the exact scenario wherein the give command is failing, you may join my open server at gapple.mchost.pro, and try placing a cauldron for the first time. It should give you a written book. It gives the book at spawn instead.

To wit, there are patches that enable proper scrolling while crouched, so it is indeed a Minecraft bug.

https://github.com/GameParrot/minecraft-mac-window-fix/releases

I understand. It's more complicated than that, apparently, because once a survival player has changed dimension, you can't continue to manipulate that player's position in the new dimension in same tick without weird coordinate anomalies... UNLESS the player is in creative mode!

If you teleport a player in survival mode across a dimension as a first command, and then in the same tick run a recursive-style mcfunction to move same player to a new location based on score (which uses relative and additional coordinates)...

e.g.
execute at @s run tp @s[scores={gat_xPos=256..}] ~256 ~ ~
scoreboard players remove @s[scores={gat_xPos=256..}] gat_xPos 256

...the player in survival mode doesn't move in the same tick as expected at all. Strangely, in creative the player does move in the same tick as intended.

The best work-around I've come up with is to first change the player's dimension in the first tick, and then schedule the recursive teleportations to occur all at once one tick later.

So for a custom feature modeled after the vanilla pile_hay, where would the "name": "pile_hay" go, since the json has no "feature":{ section in which to add name:?

Thanks.

{
  "config": {
    "state_provider": {
      "state": {
        "Properties": {
          "axis": "y"
        },
        "Name": "minecraft:hay_block"
      },
      "type": "minecraft:rotated_block_provider"
    }
  },
  "type": "minecraft:block_pile"
}

the trigger is literally called "minecrat:item_used_on_block"

There is a distinction between this report and the one you linked it to. The linked report is requesting a feature because they didn't properly understand/elucidate the issue, and so it was resolved as a feature request.

The advancement should be testing the block the item is being used on, and it doesn't. That is the bug.

1.18.1, a datapack attempting to load a structure block below y=0, only those portions of the loaded structure above y=0 load. Anything below y=0 is not loading.

The suggested work-around of cmd-tab to refocus the window doesn't entirely work. It does allow for one-click use of the gui as intended... but try to "Singleplayer", select a world, and then try to "Edit" World Name. The text input malfunctions making renaming the world impossible difficult. The game window still isn't properly focused.

Where is foliage color being specified? I don't see it in worldgen/biome json files in 1.18.

Question remains.... for worldgen biomes, where does one specify what structures should form in the biome if it is not under the now removed "starts"?

@Dylan if so, why would you not explain how to set said setting? Please share.

Yes, as of 1.17.1 this is still an issue.