3
Command Block Question!
HappyHippo77
EagleNugget
Hey, I was working with falling blocks today and was wondering if it was possible to effect the motion NBT tag relative to where the player is looking (Like the new ^ ^ ^ feature in 1.13). Essentially I want to be able to shoot out a falling block in the direction I'm facing. Is this possible?
P.S. I am using 1.13 so I'll need an answer that works with 1.13. :)
P.S. I am using 1.13 so I'll need an answer that works with 1.13. :)
Create an account or sign in to comment.
13
1
The chances of this working to me are a 45% chance this would be possible. ALSO this command I never heard or seen so this is a very hard concept to make.
1
It is doable but it's going to take quite a bit of scripting. The main problem, as mentioned by Pepijn, is that you cannot use relative directions within the summon command. Quite frankly I doubt that Pepijn's idea is going to work because Minecraft doesn't know the concept of variables. Ergo: you can't "just" grab a value from somewhere and then put that into a command of some sort.
So the solution is to check in which direction a player is looking and then setting the motion value based on that. I'll demonstrate looking west and south.
Looking west means that the y rotation sits between 80 and 100 (see the debug screen), so we get this:
So the key to your solution is to set up 5 different commands (checking for North will require 2; rotation sits roughly between 160..180 and -180..-160) which all check the direction the player is facing. And if that matches you execute a summon command with the appropriate motion (examples above).
So the solution is to check in which direction a player is looking and then setting the motion value based on that. I'll demonstrate looking west and south.
Looking west means that the y rotation sits between 80 and 100 (see the debug screen), so we get this:
- /execute positioned as ShelLuser if entity @s[y_rotation=80..100] run summon minecraft:falling_block ^ ^1 ^1 {BlockState:{Name:"minecraft:bedrock"},Time:1,Motion:[-1.0,0.0,0.0]}
- /execute positioned as ShelLuser if entity @s[y_rotation=-30..30] run summon minecraft:falling_block ^ ^1 ^1 {BlockState:{Name:"minecraft:bedrock"},Time:1,Motion:[0.0,0.0,1.0]}
So the key to your solution is to set up 5 different commands (checking for North will require 2; rotation sits roughly between 160..180 and -180..-160) which all check the direction the player is facing. And if that matches you execute a summon command with the appropriate motion (examples above).
1
Please update your knowledge on Minecraft commands, you can use execute store and data get to store and grab values.
1
Sure, but those options are limited. You cannot use those results in unrelated commands, such as summon parameters. So values which you might be able to obtain using data get (which in itself is limited to entities and block entities) cannot be magically substituted in Motion parameters.
(edit) And I'm sure you'd know what the problem is if you first summon an entity and then later on try to merge Motion data into it.
(edit) And I'm sure you'd know what the problem is if you first summon an entity and then later on try to merge Motion data into it.
1
If you're not experienced with commands, do not assume what other people say is false. Especially in a forum post with someone looking for help. Verify what you can't and can do, if you're not willing to put in the effort just don't comment on these kind of posts.
You can "execute as @e[tag=foo] store result score @s xpos run data get entity @s Pos[0] 1000" to get the position into a scoreboard, then after doing the subtraction from the player xpos, you can "execute as @e[tag=foo] store result entity @s Motion[0] double 0.001 run scoreboard players get @s xpos" to return the score and put it back into the Motion nbt.
Merging motion into falling blocks is indeed visually annoying, because they don't update their position client side very often, but this is not a problem for every entity hence why it's better to use armor_stands with a block on their head.
You can "execute as @e[tag=foo] store result score @s xpos run data get entity @s Pos[0] 1000" to get the position into a scoreboard, then after doing the subtraction from the player xpos, you can "execute as @e[tag=foo] store result entity @s Motion[0] double 0.001 run scoreboard players get @s xpos" to return the score and put it back into the Motion nbt.
Merging motion into falling blocks is indeed visually annoying, because they don't update their position client side very often, but this is not a problem for every entity hence why it's better to use armor_stands with a block on their head.
1
I didn't assume that what you're saying was false, all I said was that I doubt that it would work and I still do. Don't try to read between the lines please. See: I never insinuated that your commands were wrong; all I said was that you couldn't use variables in commands in order to generate the right summon command.
And to get the proper effect which is least affected by things like lag and other possible hiccups you really want to summon the entity as you want it to be; so using the right Motion parameters from the get-go. Reason for that is two-fold: first possible glitching, but most of all the fact that a falling block is affected by gravity so the longer you wait to apply the right motion (even a few ticks) the more risk you'll take that you're going to have to compensate for that "out of the box" motion in some way. And then you're over complicating things.
As for me being familiar with commands or not; well, you could do your own form of research on that as well :P
And to get the proper effect which is least affected by things like lag and other possible hiccups you really want to summon the entity as you want it to be; so using the right Motion parameters from the get-go. Reason for that is two-fold: first possible glitching, but most of all the fact that a falling block is affected by gravity so the longer you wait to apply the right motion (even a few ticks) the more risk you'll take that you're going to have to compensate for that "out of the box" motion in some way. And then you're over complicating things.
As for me being familiar with commands or not; well, you could do your own form of research on that as well :P
2
Sadly, you can't directly using the new local coordinates (^) in NBT. The way around this is to summon an entity (usually an area effect cloud or armorstand) in the direction the player is looking (execute at @p run summon armor_stand ^ ^ ^5 as a quick example), then store the position of that entity and the position of the player in a scoreboard. Subtract all three values and you will end up with 3 numbers that you can put back into the Motion tag of the falling block.
2
I'm a little too inexperienced with the new 1.13 mechanics to fully understand this, but I'm sure that once I am this will help me a lot! Thanks!
1
Here is a small example, I used armor stands with blocks on their heads instead of falling blocks (and placing the block when they land) because falling blocks don't really like it when you update their Motion during runtime, while armorstands have no problem with it.
www.dropbox.com/s/92zkwgqrw7yzc8x/Motion%20test.zip?dl=0
www.dropbox.com/s/92zkwgqrw7yzc8x/Motion%20test.zip?dl=0
2
I like your thinking. Theoretically it should be doable since you can /summon moving targets and a falling block is (or was) just that. Haven't tried this for myself yet but I'll give it a try later on and share my findings.
2
The good news is that this should indeed work in theory. If you check the entity nbt data then you'll notice that it does indeed support the motion:[] property so you should be able to "shoot" it out. However, so far I haven't been able to get any falling block to work properly on 1.13.
1
This is how I summon falling blocks in 1.13 in case it helps any:
/summon falling_block ~ ~ ~ {BlockState:{Name:stone},Time:1,Motion:[0.0d,0.0d,0.0d]}
/summon falling_block ~ ~ ~ {BlockState:{Name:stone},Time:1,Motion:[0.0d,0.0d,0.0d]}
1
Good call, I totally overlooked the Time property, that's why it didn't work for me.
