38

Follow

/inputraw command - automated give player heads, insert scoreboards into commands, and more!

The command:  /inputraw <rawJSON>

This works similarly to the /tellraw command with a huge difference:
It parses the input out to plain text then attempts to run it as if it was entered as a command.

For example you could execute the command as a player:
/inputraw [{"text":"give @s minecraft:player_head{SkullOwner:\""},{"selector":"@s"},{"text":"\"}"}]

and the output command would be:
give @s minecraft:player_head{SkullOwner:"SelectedPlayer"}

This would allow you to give ANY player their own player head using automated commands!

Not only that, but you could also insert scoreboards and player names into text.  for one example:
/inputraw [{"text":"give @s minecraft:cod{display:{Name:\"\\\"Big Fish\\\"\",Lore:[\"Fish Caught by: "},{"selector":"@s"},{"text":"\",\"Fish Length: "},{"score":{"name":"@s","objective":"fishing_score"}},{"text":"\"]}}"}]

If the player's fishing_score scoreboard=172 results in:
give @s minecraft:cod{display:{Name:"\"Big Fish\"",Lore:["Fish Caught by: SelectedPlayer","Fish Length: 172"]}}

Or giving "Cod" item:

Big Fish
Lore: Fish Caught by: SelectedPlayer
         Fish Length: 172

And this is only scratching the surface of what it could do:
Want to insert multiple scores automatically for auto generated clone and fill commands?  You can do that!
Want to make incrementing bossbars to autogenerate a new one for every boss?  You can do that!
Want to make self-writing commands using a combination of scoreboards and custom named entities?  You can do that!

The possibilities would be near endless.

Registered User shared this idea

• June 02, 2018 21:27
• Edited
• Report a Concern

Please sign in to leave a comment.

• 2

  Registered User commented

  Comment actions Permalink

  • June 04, 2018 22:19
  • Report a Concern
  • Comment actions Permalink

  Ah, this takes me back. Seven months ago, on the /r/MinecraftCommands discord server, someone had a very similar suggestion. It was called /compose instead of /inputraw, but otherwise did exactly what you now suggest. We drafted up documentation for it, came up with all sorts of cool ideas for what it was capable of, and one guy even wrote a simple mod to add it into the game. And it worked! We were starstruck.

  During the frenzy, Dinnerbone took a look and told us his thoughts and grounded us a bit more in reality, showing us the flaws we were perhaps willfully ignorant to. The first problem was names that contain quotes. Ideally, you'd be able to use this to make something like a sword that gets its name from an arbitrary entity. But by the very nature of the idea itself, this could result in a parsing error if a name with quotes breaks syntax.

  display:{Name:"This is a "slight" problem"}

  Dynamically escaping stuff is not only extremely difficult (if not impossible, as the evaluator has no idea of depth since the two components are right next to each other), it's also disingenuous because the resulting command would have a different output than it would if you used /tellraw before your JSON instead of /compose (or /inputraw).

  The nail in the coffin was the realization that, not only was it possible to construct inputs that would result in a syntax error in the final command, it was possible to construct inputs that would build wrongly! As Dinnerbone put it, "Not escaping would lead to XSS attacks in minecraft maps, a terrible notion. 'Hey did you know that by naming a pig ","clickEvent":"/op foo you can become op?'"

  I'm scrolling through the archives looking for more details. "Sure thing. I'm not saying we'll not consider the idea, I'm just presenting more things to think about," was the last relevant thing I can see he said. It's a great idea but with some huge pitfalls.

   

   (bad formatting removed, sorry ~nb)
• 1

  Registered User commented

  Comment actions Permalink

  • September 20, 2019 16:18
  • Report a Concern
  • Comment actions Permalink

  I kind of feel like this change is important now more than ever, as creating dynamic storage entries is currently impossible in the 1.15 snapshots!

• 0

  Registered User commented

  Comment actions Permalink

  • June 05, 2018 07:37
  • Report a Concern
  • Comment actions Permalink

  Hmm... interesting notions about it for sure!  I'd do think there's some more looking into this that is needed.  I'd hate to just give up on the idea as it's still quite powerful and useful, but perhaps it would need some retooling.
  One big difference between now and then is that mob names are now in rawjson themselves.
  So if you were to have the same name:
  display:{Name:"\"This is a \\\"slight\\\" problem\""}

  It would likely look something like this.  I don't know if that would make a difference, but that's definitely something to consider.

  I definitely don't think it should just be abandoned.  If anything, it's more to think about!  But those are just my own thoughts.

• 0

  Registered User commented

  Comment actions Permalink

  • November 30, 2020 21:31
  • Report a Concern
  • Comment actions Permalink

  I've been wanting something like this for a long time, but I had a slightly different way to implement it. I was thinking of adding a new argument to the /execute command that allows you to insert scoreboard values and stuff into the final command. For example, say you had a scoreboard objective called xPos and you wanted to teleport the player directly to the x-coordinate stored in there but keep every other coordinate the same. You'd do /execute as @p at @s using score @p xPos run tp @s <xPos> ~ ~

  Or lets say you have a scoreboard objective called Slot that tracks the index of the currently selected slot of a player and you want to use it to check the item in the same slot of another player. You'd do something like /execute using score Player1 Slot run data get entity Player2 Inventory[<Slot>]

  I realise even this can result in some problems, but it can achieve similar goals to your idea without some of the problems mentioned in the other comments.