Tyruswoo
Assigned
Reported
Comments
Try contacting the server owner. They can help you.
You could also try typing messages in chat asking for help until a moderator sees you are stuck.
I am having the same issue. The main thread for this issue is MCL-17343 Please vote for the issue there and watch the issue there, and tell all your friends to vote for the issue!
Can confirm also for Snapshot 21w05b. I am having the same problem. Pressing the "Play" button no longer works in the launcher.
Since loading of old worlds is temporarily disabled, my server is currently on Snapshot 21w05b. So I cannot upgrade the server to 21w11a, and I cannot start my client on 21w05b.
We've almost reached the third birthday for this bug. Still watching! And still using command blocks as work arounds.
To bypass this bug, I wrote a function that would work with rotated structures. The function detects a wool block directly next to the command block that ran the function, and then uses the relative position of that wool block to determine the direction of the bed, and the color of the wool block to determine the color of the bed. I used about 260 lines of code to make sure it had a setblock for the head and foot of each color of bed in each rotation.
Just checked, and beds still break when loaded from structure blocks, in Minecraft release 1.13.
However, I did figure out how to use the setblock command as a work-around. I didn't understand how to modify block states in the setblock command, with the new 1.13 syntax, but now I've got it. I updated the Minecraft commands wiki to include the code: https://minecraft.gamepedia.com/Commands/setblock
Here is Cloud Wolf's video that helped me learn this: https://www.youtube.com/watch?time_continue=196&v=R3plRS5eAb4
In Minecraft 1.13 Pre-Release 5, I experienced beds loading from structure blocks, but immediately breaking, leaving the bed's item on the ground. Voted for this issue.
Edit: I also tried using /setblock to place the bed manually. Setblock could set the foot of the bed, but not the head of the bed, even when modifying the NBT portion of the setblock command. Therefore, I couldn't find any work-around with commands to place the beds that structure blocks failed to place.
Thanks, Daniel. I hope we get a fix for this, someday!
Good catch!
Thank you!
Just checked that it works with the Cow Hi test, and uploaded a photo!
Great! Yeah, if both are fixed, that's even better!
In case it helps, here is my original description from my (duplicate) bug report:
Summary:
When /execute is used to make an entity run a function, the function is instead run by the source of the /execute command.
Expected outcome:
When /execute is used to make an entity run a function, the function is run by the targeted entity.
Steps to reproduce:
1. Create a function.
2. Run that function as yourself. Note that you run the function.
3. Execute that function to be run by another entity. Note that the entity does not know that it is running the function, as evidenced by @s not working. Instead, the function thinks it is being run by you, because you ran the execute command.
Attached images of this being demonstrated with a Hi function that runs the following command:
say I am @s Hi!
(Note: In Minecraft 1.12 Pre-Release 1 and 1.12 Pre-Release 2, this worked correctly, so that the function would run from the entity targeted by /execute. See attached images.)
This bug greatly reduces the uses of the @s selector. In 1.12 Pre-Release 1 and 1.12 Pre-Release 2, we were able to run the gameLoopFunction to target entities and tell them to run functions. This was great, because it allowed functions to run in an object-oriented fashion, so that commands were executed from their @s source. This bug breaks that feature.
Hoping this can be fixed!
I'm not trying to get recursive functions, myself. I guess some people may want recursive functions, but I'm just looking for the gameLoopFunction to be able to make entities execute functions. That wouldn't involve any recursion. I guess this must involve concerns about recursion, but I'd prefer us not worrying about recursion and just letting the function writer take responsibility for any recursion they cause, as recursion should be fairly obvious--I mean, the function writer will probably notice if they are having functions refer backwards. It's a lot easier to write functions in a "parent to child" fashion so that the gameLoopFunction calls certain functions, which may call other functions, but not recursing backwards. Anyway, so much more we can do if the gameLoopFunction can cause entities to run functions.
That sounds really complex! It seems pretty simple to just let @s refer to the target of /execute, but I guess there are a lot of things going on in the background! Really hope this can be fixed!
In my report, I tried to get a cow to say hi using the function Tyruswoo:Hi
This worked in 1.12pre1 and 1.12pre2, but in 1.12pre3 it was broken, making me (the executor) say hi. My intent was for the cow (the target of the execute command) to say hi.
Attached some images shown in my (duplicate) report: https://bugs.mojang.com/browse/MC-117588
I am having the same issue. The main thread for this issue is MCL-17343 Please vote for and watch the issue!