Are you sure you want to report this?

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!


Post a new comment:

Please sign in to leave a comment.

  • 1
    tryashtar 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
    MukiTanuki 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.

  • 0
    MukiTanuki 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!