A feedback area designed for scripting and mods suggestions and feedback. Please note bug reports and support issues will be removed.


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


Please sign in to leave a comment.

Sorted by oldest
  • 2
    Registered User commented
    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)
  • 0
    Registered User commented
    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.

  • 1
    Registered User commented
    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

    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.